RE: Definition of draw:angle in ODF1.2 does not fit to implementation

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

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

[ ... ]