incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <rb.hensc...@t-online.de>
Subject Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Date Mon, 30 Jul 2012 18:29:03 GMT
Hi Armin,

Armin Le Grand schrieb:
> 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).

Using decimals or using units will be an incompatible change. Neither of 
AOO, LO or MSO accept decimals or units. But the real problem is not the 
type, but the fact, that currently a stored value of 300 is interpreted 
as 30deg which is different from the spec.

  I would rather suggest to go with the SVG
>> definition and propose that. It's always good to get closer to other
>> graphic standards.

In general I would say yes. But wouldn't it better to leave 
draw:gradient in our implementation as it is and implement for double 
precision and for all the other nice features like multiple stop colors 
svg:linearGradient and svg:radialGradient ? Those are already in the spec.

>>
>> 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?

Yes, that could be more precise. A picture with example would make it 
clear. Therefore I described in "It actually means, that in the 
internal..." how it is actually handled in all three AOO, LO, and MSO.

>>
>> 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.

Again, that would only become precise in the spec with a picture with 
coordinate system and marked oriented angle.

My proposal is not about all angles, but only for this special angle.

>
>> 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 have not looked, what MS does in their own format, but for a 
discussion at LO I have looked how they read and write ODF.
PowerPoint2013 does it this way:
The angle of 0° in the UI means that the gradient vector goes from left 
to right in UI.
The angle in the UI rotates this gradient vector clockwise on screen. 
Values from 0 to 359.9 are allowed.

In file format it is the same as from LO (and AOO), for example:
draw:angle="700" results from
   PP UI-angle=20° clockwise on screen
   LO UI-angle=70° counterclockwise on screen
draw:angle="3300" results form
   PP UI-angle=120° clockwise on screen
   LO UI-angle=330° counterclockwise on screen

>>
>> 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.

It is only used for draw:opacity and draw:gradient and not used in the 
svg:linearGradient or in any other part, which needs angles. Therefore I 
thought, that adapting the spec to the existing implementations, would 
be easier as the other way round.

>>
>> If it is used for both, we should think about the orientation (also for
>> shear)...
>>

Kind regards
Regina


Mime
View raw message