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:[email protected]]
Sent: Monday, July 30, 2012 11:29
To: [email protected]
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.
[ ... ]
