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 downlevel
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 positiveX
direction.
> b. A positive rotation of that vector by 90 degrees will place the vector along
the Y axis with the positiveX points now at the same positions on the positiveY axis, etc.
The drawangle will be 90 degrees (however expressed).
> c. More generally, the angle is that of the positivegradient vector (from the origin)
with the positiveX vector (from the origin), as measured from the positiveX vector rotating
toward (and through, if necessary) the positiveY vector direction.
>
> (This is anticlockwise 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 positiveY direction is downward, the positveX direction is rightward.)
It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it
is mathematically wrong oriented (thus, projected on the page,
anticlockwise).
Thus, when just want to stay compatible and extend/correct the
definitions, defining it as integer, 0.1 degrees and mathematically
(nonprojected 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. NonInteger 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.1degree 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.1degrees.
>
> 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@tonline.de]
> Sent: Monday, July 30, 2012 11:29
> To: ooodev@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 YAxis goes down (X to the right), thus the correct mathematical
>>> orientation would go anticlockwise, starting at 0.0 on the YAxis 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. YAxis down, X to the right, the correct
>> mathematical orientation would be clockwise starting at (1.0, 0.0) on
>> the XAxis, 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.
>
> [ ... ]
>
>
