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:24:18 GMT
On 30.07.2012 19:14, Armin Le Grand wrote:
>      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).

Argh, mixed things up. Y-Axis down, X to the right, the correct 
mathematical orientation would be clockwise starting at (1.0, 0.0) on 
the X-Axis, right of the center.
Sorry for mixing things up. Fact is that we currently use the wrong 
orinetation in our Core, UI and file format, though. Make the experiment 
with a object, rotate it by 5 degrees, do the same in MS.

> 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
> shear)...
> Sincerely,
>      Armin
> --

View raw message