Details

      Description

      Copied from office-comment list

      Original author: Regina Henschel <rb.henschel@t-online.de>
      Original date: 4 Aug 2012 12:39:26
      Original URL: http://lists.oasis-open.org/archives/office-comment/201208/msg00002.html

        Attachments

          Activity

          Hide
          patrick Patrick Durusau added a comment -

          Andreas J. Guelzow suggests that changing the specification to fit mis-implementations of the standard will break existing implementations.

          Should we close this issue with a request to implementations that don't follow ODF 1.2?

          Show
          patrick Patrick Durusau added a comment - Andreas J. Guelzow suggests that changing the specification to fit mis-implementations of the standard will break existing implementations. Should we close this issue with a request to implementations that don't follow ODF 1.2?
          Hide
          andre.rebentisch Andre Rebentisch (Inactive) added a comment -

          The proposal is "For ODF1.3 I suggest to deprecate them in favor of a solution nearer to SVG." and to adapt the 1.2 spec to conform the actual implementations and the corpora of existing documents. Apparently no existing implementation follows the present spec here, so the argument does not apply.

          Show
          andre.rebentisch Andre Rebentisch (Inactive) added a comment - The proposal is "For ODF1.3 I suggest to deprecate them in favor of a solution nearer to SVG." and to adapt the 1.2 spec to conform the actual implementations and the corpora of existing documents. Apparently no existing implementation follows the present spec here, so the argument does not apply.
          Hide
          aguelzow Andreas Guelzow (Inactive) added a comment -

          Repeating the argument "Apparently no existing implementation follows the present spec here" does not make it anymore true. Regina only tested a few implementations (namely 4, 3 of them coming from the same source base).

          In Gnumeric the following function is used to read the value for draw:angle:

          static char const *
          oo_parse_angle (GsfXMLIn *xin, xmlChar const *str,
          char const *name, int *angle)
          {
          double num;
          char *end = NULL;

          g_return_val_if_fail (str != NULL, NULL);

          num = go_strtod (CXML2C (str), &end);
          if (CXML2C (str) != end) {
          if (*end != '\0') {
          if (0 == strncmp (end, "deg", 3))

          { end += 3; }

          else if (0 == strncmp (end, "grad", 4))

          { num = num / 9. * 10.; end += 4; }

          else if (0 == strncmp (end, "rad", 2))

          { num = num * 180. / M_PIgnum; end += 3; }

          else

          { oo_warning (xin, _("Invalid attribute '%s', unknown unit '%s'"), name, str); return NULL; }

          }
          } else

          { oo_warning (xin, _("Invalid attribute '%s', expected angle, received '%s'"), name, str); return NULL; }

          *angle = ((int) num) % 360;
          return end;
          }

          I believe this is what the spec currently specifies. So at least one implementation follows the current spec.

          Show
          aguelzow Andreas Guelzow (Inactive) added a comment - Repeating the argument "Apparently no existing implementation follows the present spec here" does not make it anymore true. Regina only tested a few implementations (namely 4, 3 of them coming from the same source base). In Gnumeric the following function is used to read the value for draw:angle: static char const * oo_parse_angle (GsfXMLIn *xin, xmlChar const *str, char const *name, int *angle) { double num; char *end = NULL; g_return_val_if_fail (str != NULL, NULL); num = go_strtod (CXML2C (str), &end); if (CXML2C (str) != end) { if (*end != '\0') { if (0 == strncmp (end, "deg", 3)) { end += 3; } else if (0 == strncmp (end, "grad", 4)) { num = num / 9. * 10.; end += 4; } else if (0 == strncmp (end, "rad", 2)) { num = num * 180. / M_PIgnum; end += 3; } else { oo_warning (xin, _("Invalid attribute '%s', unknown unit '%s'"), name, str); return NULL; } } } else { oo_warning (xin, _("Invalid attribute '%s', expected angle, received '%s'"), name, str); return NULL; } *angle = ((int) num) % 360; return end; } I believe this is what the spec currently specifies. So at least one implementation follows the current spec.
          Hide
          rcweir Robert Weir (Inactive) added a comment -

          Cannot change defined behavior for ODF 1.2. Might be good for OIC TC to look at this. For ODF 1.3, we should look at SVG.

          Show
          rcweir Robert Weir (Inactive) added a comment - Cannot change defined behavior for ODF 1.2. Might be good for OIC TC to look at this. For ODF 1.3, we should look at SVG.
          Hide
          regina.henschel Regina Henschel added a comment -

          Set component to 'Graphics', so that the issue can be found by a search with filter 'Graphics'.

          Show
          regina.henschel Regina Henschel added a comment - Set component to 'Graphics', so that the issue can be found by a search with filter 'Graphics'.
          Hide
          mstahl Michael Stahl (Inactive) added a comment -

          just for the record, i've adapted LibreOffice now to import values of draw:angle with the unit suffix as defined in ODF 1.2; without unit suffix will still be imported wrongly as 10th of degrees, for compatibility with legacy versions.

          the fixed import is in LibreOffice releases 4.4.6 and later.

          fixing this completely in LibreOffice will happen in a year or two, when we can assume that current versions are no longer used.

          suspect that for ODF 1.2 the draw:angle was adapted to the SVG specification but regrettably without any OpenOffice.org developer looking at how that implementation handles draw:angle, so we ended up in the current mess.

          Show
          mstahl Michael Stahl (Inactive) added a comment - just for the record, i've adapted LibreOffice now to import values of draw:angle with the unit suffix as defined in ODF 1.2; without unit suffix will still be imported wrongly as 10th of degrees, for compatibility with legacy versions. the fixed import is in LibreOffice releases 4.4.6 and later. fixing this completely in LibreOffice will happen in a year or two, when we can assume that current versions are no longer used. suspect that for ODF 1.2 the draw:angle was adapted to the SVG specification but regrettably without any OpenOffice.org developer looking at how that implementation handles draw:angle, so we ended up in the current mess.
          Hide
          patrick Patrick Durusau added a comment -

          As per 26 Sept. 2016

          check for other issues on draw angle

          Show
          patrick Patrick Durusau added a comment - As per 26 Sept. 2016 check for other issues on draw angle

            People

            • Assignee:
              Unassigned
              Reporter:
              rcweir Robert Weir (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: