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

[Michael Stahl]

On 01/08/12 20:38, Dennis E. Hamilton wrote:
> 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.

there are already the svg:linearGradient and svg:radialGradient elements
in ODF 1.2, for example playing with Calligra Stage 2.4.3 i was able to
produce a ODF presentation document with this, which seems to do fine
without any explicit angle at all:

>>   <svg:linearGradient draw:name="gradient1" svg:spreadMethod="pad" svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%">
>>    <svg:stop svg:offset="0.11" svg:stop-color="#dc143c"/><svg:stop svg:offset="0.473324" svg:stop-color="#00ced1"/><svg:stop svg:offset="0.589196" svg:stop-color="#00ff00"/>
>>   </svg:linearGradient>
>>   <svg:linearGradient draw:name="gradient2" svg:spreadMethod="pad" svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%">
>>    <svg:stop svg:offset="0" svg:stop-color="#ffffff"/><svg:stop svg:offset="1" svg:stop-color="#00ff00"/>
>>   </svg:linearGradient>

unfortunately it seems that OOo derived suites only support the _other_
ODF specific gradient element(s) that have this draw:angle attribute.

i don't actually know anything about graphics, so i'll let Armin judge
whether that SVG stuff in ODF 1.2 is sufficient  :)

> 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?

_if_ something new is needed in ODF then that would be my general
approach as well: don't change semantics of existing markup in an
incompatible way, but deprecate it and add new markup as necessary with
improved semantics.

the advantage is that existing products can then write both
representations in a new version, and the deprecated markup can still be
understood by older versions.

>  - 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?
> 
> [ ... ]
> 
>