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.
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 <draw:angle> 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 <angle> 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 <draw:gradient> and <draw:opacity>, with
---
<draw:angle> is the inverted rotation in 10th of a degree as integer
value (no longer reference 18.3.1 and say it's equal).
<svg:angle> is the rotation as defined by SVG (including being float and
supporting deg, rad and grad).
If <svg:angle> is present, it has precedence over <draw:angle>. 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
<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.
We can use the SVG <angle> 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:[email protected]]
Sent: Wednesday, August 01, 2012 02:21
To: [email protected]
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?
[ ... ]
