Definition of draw:angle in ODF1.2 does not fit to implementation

[Dennis E. Hamilton]

Hi Armin,

Thanks for your valuable comment.

I had thought that the description using "clockwise" was in reference to the page appearance and not the abstract treatment (with "right-hand rule").  Perhaps I misunderstand where the origin is understood in the projection onto the page.

MORE IMPORTANT CONCERN

I think you raise a more important question concerning changing for ODF 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 1.3.

I recommend that there be no breaking change of draw:angle between ODF versions.  It is probably best to deprecate it while clarifying the orientation of the angle-opening rotation and the units of the angle.  I think preventing down-level breakage is impossible without that and the support explanations will be a nightmare otherwise.  It seems to me that the ODF 1.2 description is best corrected in an Errata and the problem made immediately known in an OIC Advisory.  

To correct the geometry for transformations, I suggest that another, rigorously-defined gradient element be introduced, preferably one from SVG.

If there is a down-level concern, I would define the new element such that, when it and <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and beyond.  This way, a down-level implementation will presumably process the <draw:gradient> and ignore the element introduced in ODF 1.3, since it is not defined down-level.

Would that break the knot better?

 - Dennis

-----Original Message-----
From: Armin Le Grand [mailto:Armin.Le.Grand at me.com] 
Sent: Wednesday, August 01, 2012 02:21
To: ooo-dev at incubator.apache.org
Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation

	Hi Dennis,

On 30.07.2012 22:21, Dennis E. Hamilton wrote:
[ ... ]
> (This is anti-clockwise in the standard geometric orientation.  When projected onto the page, this appears to be clockwise because the origin tends to be in the upper left corner and the positive-Y direction is downward, the positve-X direction is rightward.)

It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it 
is mathematically wrong oriented (thus, projected on the page, 
anti-clockwise).

Thus, when just want to stay compatible and extend/correct the 
definitions, defining it as integer, 0.1 degrees and mathematically 
(non-projected to page) clockwise rotation would describe the current 
behaviour.

Unfortunately this 'wrong' orientation is problematic. As long as it is 
only locally used it can simply be mirrored. The problem comes up when 
working with transformations; when receiving the transformation of an 
graphic object and decomposing it to extract rotation, that rotation 
will be mathematically correctly oriented. It has to be since else 
linear combination of transformations would not work.

This is not in the environment of gradients, but in general all angles 
in ODF have this problem (probably for historical reasons, the UIs use 
the same wrong orientation). Our competitor does not have that error.

Isn't this correctable for all angles e.g. for ODF1.3 and can be handled 
by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values 
easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3?

[ ... ]