incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Date Thu, 02 Aug 2012 09:20:51 GMT
	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 

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.

> 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 

> Would that break the knot better?

Yes, I think so.

>   - Dennis
> -----Original Message-----
> From: Armin Le Grand []
> Sent: Wednesday, August 01, 2012 02:21
> To:
> 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?
> [ ... ]

View raw message