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 Mon, 30 Jul 2012 17:14:42 GMT
	Hi Regina,

On 30.07.2012 18:34, Regina Henschel wrote:
> Hi all,
> I want to suggest OASIS to change the definition of draw:angle. The
> draft mail follows below. What do you think about it?
> Kind regards
> Regina
> Draft of the mail to OASIS:
> For <draw:gradient> type 'Linear' section 19.218 defines "The axis of
> the gradient is specified with the draw:angle attribute clockwise to the
> vertical axis."
> It actually means, that in the internal coordinate system (that with an
> upright y-axis), rotating this y-axis clockwise with the draw:angle
> gives the gradient vector.
> <draw:angle> section 19.122 repeats this in a less exact form. For the
> angle itself it specifies:
> "The draw:angle attribute has the data type angle 18.3.1."
> And in section 18.3.1 you read, "An angle, as defined in ยง4.1 of [SVG].
> An angle is a double value that may be followed immediately by one of
> the following angle unit identifiers: deg (degrees), grad (gradiants) or
> rad (radians). If no unit identifier is specified, the value is assumed
> to be in degrees."
> But that is wrong for the implementations in Apache OpenOffice,
> LibreOffice, and Microsoft Office. All of them allow in draw:angle only
> integers without unit and interpret them as 0.1deg. Calligra does not
> use draw:gradient but uses svg:gradient. Microsoft Office can read
> negative integers, but writes itself always non negative integers.
> Apache OpenOffice and LibreOffice read and write only non negative
> integers.
> Therefore I suggest to alter the definition of draw:angle in this way:
> Instead of the sentence
> "The draw:angle attribute has the data type angle 18.3.1."
> use the text
> "The draw:angle attribute has the date type integer. A value of n is
> interpreted as n*0.1 degrees."

Sorry, I would not do that. This would limit the possible precision 
without needs in a format definition. If the precision in the cores is 
limited or not does not play a role for the definition (it will 
increase, we are on it). I would rather suggest to go with the SVG 
definition and propose that. It's always good to get closer to other 
graphic standards.

It also needs to be evaluated to which orientation "The axis of
the gradient is specified with the draw:angle attribute clockwise to the 
vertical axis." leads. What does this mean?

The Y-Axis goes down (X to the right), thus the correct mathematical 
orientation would go anti-clockwise, starting at 0.0 on the Y-Axis which 
is below the origin. It may be wrong, the same as the current object 
rotation (and shear) is wrong in this aspect, see our current UI and 
what it does for a 5 degree object rotation (and would need to be 
proposed to be changed, too).

Thus, when we are at it, we may need to correct the orientation of 
draw:angle, too. BTW: It is correct in the MS UI and their core data. Do 
the same 5 degree rotation there.

I am currently not sure where draw:angle is used, is it the object 
rotation or the gradient rotation, or is it used for both? If used for 
both, I would not want precision to be limited to 0.1 degrees for 
objects. I would evtl. accept this for gradients.

If it is used for both, we should think about the orientation (also for 


View raw message