Re: [office-comment] Definition of draw:angle in ODF1.2 does not fit to implementation

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

On Sat, 2012-08-04 at 13:39 -0600, Regina Henschel wrote:
> Hi members,
> 
> the definitions of the attributes draw:angle (19.112) and 
> draw:rotation(19.209) do not fit to the actual implementations.
> 
> The definitions refer to the data type angle in section 18.3.1:
> "An angle, as defined in §4.1 of [SVG]. An angle is a double value that 
> may be followed immediately by one of the following angle unit 
> identifiers: deg (degrees), grad (gradiants) or rad (radians). If no 
> unit identifier is specified, the value is assumed to be in degrees."
> 
> The actual implementations use the value without unit but they interpret 
> it as having unit 0.1 degrees and they use data type integer.

I would consider this a bug in the implementations. That should be fixed
there. The specs with regard to  draw:rotation(19.209) is completely
specified. The spec for draw:angle (19.112) is indeed missing the
direction of rotation. (Of course it could argued that in the absence of
a specification the standard mathematical angle measurement would
apply.)

> 
> I have tested PowerPoint, LibreOffice, Symphony, and Apache OpenOffice 
> so far. I haven't got a Linux system and cannot test Calligra.

Note that Gnumeric follows the specification in that a missing
identifier means "deg".
> 
> The attribute draw:angle is only used with the elements draw:gradient 
> and draw:opacity and the attribute draw:rotation is only used with the 
> element draw:hatch. So a change for these attributes would not effect 
> other places in the spec. For ODF1.3 I suggest to deprecate them in 
> favor of a solution nearer to SVG.
> 
> To align the spec with the existing implementations I suggest:
> (1) Remove the reference to section 18.3.1
> (2) Specify that a value n is treated as n*0.1 degrees.
> (3) Perhaps constrain the value to integer.
> 
> I suggest to do this as errata for ODF1.2.

This is definitely not a possible subject for an errata to change the
interpretation of the value. The bug is in the implementations mentioned
and a change would break other implementations.

Andreas
  
> 
> I'm not a native English speaker and no expert for spec writing, but 
> here my wording:
> In section "19.112 draw:angle" and same in section "19.209 draw:rotation":
> old
> "The draw:angle attribute has the data type angle 18.3.1."
> new
> "The draw:angle attribute has the data type integer. The attribute value 
> n is treated as angle value n*0.1degrees."
> 
> The problem has been discussed on ooo-dev@incubator.apache.org and 
> libreoffice@lists.freedesktop.org, links below. The discussion brought 
> up the problem of angle orientation too, but that can only be solved in 
> ODF1.3.
> 
> The discussion was a little bit scattered, therefor several links:
> Initial mail with subject "Definition of draw:angle in ODF1.2 does not 
> fit to implementation"
> http://thread.gmane.org/gmane.comp.apache.incubator.ooo.devel/23201
> http://lists.freedesktop.org/archives/libreoffice/2012-July/035988.html
> Answers and threads
> http://thread.gmane.org/gmane.comp.apache.incubator.ooo.devel/23207
> http://lists.freedesktop.org/archives/libreoffice/2012-July/035994.html
> http://lists.freedesktop.org/archives/libreoffice/2012-July/035999.html
> http://lists.freedesktop.org/archives/libreoffice/2012-August/036118.html
> 
> 
> Kind regards
> Regina
> 

-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta

Attachment: signature.asc
Description: This is a digitally signed message part