# incubator-ooo-dev mailing list archives

##### Site index · List index
Message view
Top
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Date Wed, 01 Aug 2012 09:21:15 GMT
Hi Dennis,

On 30.07.2012 22:21, Dennis E. Hamilton wrote:
> There appear to be three considerations:
>
>   1. What is type and unit of draw:angle in the <draw:gradient> element?
>      In ODF 1.0, ODF 1.1, and ISO/IEC 26300:2006 (now aligned with ODF 1.1), the type
is integer and there is no explanation of the scale of the unit.  ODF 1.2 gives special attention
to the integer case and observes that the unitless integer is all that works for down-level
compatibility with ODF 1.1 consumers.
>
>      If it is to be decreed that all/most implementations are correct and the specification
has been left incorrect since 2005, that is a very difficult situation.  I assume the correct
statement is that the unit for draw:angle is 0.1 degree.
>
>   2. Orientation?
>      The orientation leaves much to be described, since it is a vector that is rotated,
not an axis.  It appears that practice and what little is said in the specifications satisfy
standard geometric practice, as follows:
>
>      a. Consider a vector that lies along the X axis with orientation in the positive-X
direction.
>      b. A positive rotation of that vector by 90 degrees will place the vector along
the Y axis with the positive-X points now at the same positions on the positive-Y axis, etc.
The draw-angle will be 90 degrees (however expressed).
>      c. More generally, the angle is that of the positive-gradient vector (from the origin)
with the positive-X vector (from the origin), as measured from the positive-X vector rotating
toward (and through, if necessary) the positive-Y vector direction.
>
> (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?

> I suspect this can be clarified easily in all of ODF 1.0 through ODF 1.2, since there
seems to be no conflict with implementations.  Conversions to and from other formats need
to be attentive to any difference in the reference orientation of axes and definition of the
angle.
>
>   3. Non-Integer Types and Values?
>
> Allowing fractional values and units in draw:angle seems to be problematic and it does
not directly deal with the integer type expression of 0.1-degree intervals.
>
> I agree that should be done by switching to SVG cases when available (and there should
be more alignment of that in ODF 1.3).
>
> This means that draw:angle should probably continue to be expressed in plain integers
with a clarification that the unit is 0.1-degrees.
>
> That would at least limit the damage of this persistent discrepancy between practice
and the specification.
>
>   - Dennis
>
> -----Original Message-----
> From: Regina Henschel [mailto:rb.henschel@t-online.de]
> Sent: Monday, July 30, 2012 11:29
> To: ooo-dev@incubator.apache.org
> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation
>
> [ ... ]
>
> 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
>
>>>
>>> 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.
>
> [ ... ]
>
>

Mime
View raw message