On Thu, Aug 2, 2012 at 5:20 AM, Armin Le Grand wrote:
> Hi Dennis (and others),
>
>
> On 01.08.2012 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.
>
>
> I do not think that you misunderstand. The X-Axis points to the right, the
> Y-Axis down, the origin is top-left (pretty standard, expected by everyone).
> Thus, mathematically, the positive orientation of angles goes clockwise.
>
There are different conventions for this. The one you describe is is
common in computer graphics, probably originally due to the way the
raster scan works in CRT displays and in line printers, e.g., left to
right, top to bottom. Mathematicians have their own convention. And
physicists, of course they have at least two conventions. So the only
correct answer is to specify the convention unambiguously in the
specification.
> Unfortunately someone did define it 'mirrored' in the cores for StarOffice
> (maybe more than 15 years ago), is used in the UI and this was copied to the
> UNO API and the ODF format for all angles (independent from usage for
> gradients or objects). This is not based on using the 2nd possible
> coordinate system with Y-Axis pointing up, but simply by using the 'wrong'
> (mirrored) values for angles throughout the office consequently.
>
>
>> 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.
>
>
> My first idea was to define the orientation (is not really defined now) for
> ODF1.2 and older, and to define it mirrored for ODF1.3, applying a xslt
> transformation to manage that.
>
> You are right that for all products not immediately applying to this change
> rotations would break. This would speak for adding a new property.
>
>
>> To correct the geometry for transformations, I suggest that another,
>> rigorously-defined gradient element be introduced, preferably one from SVG.
>
>
> Transformations are okay and need no change, they contain the angle
> corresponding to the coordinate system.
>
> As Michael Stahl wrote, svg:linearGradient and svg:radialGradient are
> already part of ODF1.2.
>
> These are no replacement for draw:gradient, thus are no candidates for
> deprecating the draw:gradient (and draw:opacity, the transparence gradients)
> for ODF1.3. It is another kind of gradient with the pros and cons described
> by Michael Stahl.
>
> (BTW: What to do if an object has draw:gradient AND svg:linearGradient
> defined at the same time (or even more, add svg:radialGradient)...?).
>
> We should not mix up varios themes here (maybe I started doing so, I
> apologize). We have two things here:
>
> (a) Non-SVG Gradient definitions (old ones)
> (b) Angle definitions in various places
>
> There is no general problem with (a), except the contained angle and it's
> orientation. Thus I talk more about (b) where (b) is about the old gradients
> with use currently, but also start/end angles in circle/ellipse
> shapes.
>
> The Object rotation does not have a direct and single rotation attribute
> (AFAIK, there is svg:x, svg:y, svg:width/height, but no svg:angle), but has
> to use (and does use) a transformation when rotation is needed (which uses
> angles correctly, no problem there).
>
> Using a 2nd 'rigorously-defined' angle would be sufficient here. As
> mentioned in earlier mails, SVG has as basic data type (see SVG
> 4.2). It is already listed in ODF 1.2, see 18.3.1 of ODF spec (Does this
> mean it could already be used?). It is even referenced as data type in
> draw:angle, draw:start-angle and draw:end-angle (!), see e.g. 19.112
> draw:angle in ODF1.2 which says: 'The draw:angle attribute has the data type
> angle 18.3.1'. When this would be true, draw:angle would not even be needed
> since it's identical to svg:angle already (which it is not, another error?).
>
> Thus I suggest allowing both in and , with
>
> ---
>
> is the inverted rotation in 10th of a degree as integer value
> (no longer reference 18.3.1 and say it's equal).
>
> is the rotation as defined by SVG (including being float and
> supporting deg, rad and grad).
>
> If is present, it has precedence over . For
> compatibility, please support both when creating ODF documents.
>
> ---
>
> Other candidates wit this problem are (not sure when marked with '?'):
>
> 19.140 draw:end-angle
> 19.213 draw:start-angle
>
> 19.226 draw:text-rotate-angle (?)
> 20.95 draw:caption-angle (?)
> 20.339 style:rotation-angle (?)
> 20.375 style:text-rotation-angle (?)
>
>
>> If there is a down-level concern, I would define the new element such
>> that, when it and are both present, the new element
>> pre-empts in ODF 1.3 and beyond. This way, a down-level
>> implementation will presumably process the and ignore the
>> element introduced in ODF 1.3, since it is not defined down-level.
>
>
> We can use the SVG basic data type, no need for an own, new
> definition.
>
>
>> Would that break the knot better?
>
>
> Yes, I think so.
>
>> - Dennis
>>
>>
>> -----Original Message-----
>> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
>> Sent: Wednesday, August 01, 2012 02:21
>> To: ooo-dev@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?
>>
>> [ ... ]
>>
>>
>>
>
>