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.gr...@me.com] Sent: Wednesday, August 01, 2012 02:21 To: ooo-...@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? [ ... ] _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
