You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Armin Le Grand <Ar...@me.com> on 2012/08/01 11:21:15 UTC
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
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
> 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.
>
> [ ... ]
>
>
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by Fridrich Strba <fr...@graduateinstitute.ch>.
Hello,
On 01/08/12 22:16, Michael Stahl wrote:
>>> <svg:linearGradient draw:name="gradient1" svg:spreadMethod="pad" svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%">
>>> <svg:stop svg:offset="0.11" svg:stop-color="#dc143c"/><svg:stop svg:offset="0.473324" svg:stop-color="#00ced1"/><svg:stop svg:offset="0.589196" svg:stop-color="#00ff00"/>
>>> </svg:linearGradient>
>>> <svg:linearGradient draw:name="gradient2" svg:spreadMethod="pad" svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%">
>>> <svg:stop svg:offset="0" svg:stop-color="#ffffff"/><svg:stop svg:offset="1" svg:stop-color="#00ff00"/>
>>> </svg:linearGradient>
>
> unfortunately it seems that OOo derived suites only support the _other_
> ODF specific gradient element(s) that have this draw:angle attribute.
>
> i don't actually know anything about graphics, so i'll let Armin judge
> whether that SVG stuff in ODF 1.2 is sufficient :)
There is a little tiny problem in there. The draw:gradient element is
more verbose then the svg:*Gradient semantics. You can express square,
elliptical, axial ... gradients that way. The down-side is that, due to
the implementation in the time of the specification, this allows only
bi-colour gradients.
SVG on the other hand is much less expressive in what the "shape" of the
gradient concerns, but it is allowing a multitude of stops with
different colours. The svg:*Gradient semantics in the ODF specification
is not exactly the corresponding to the SVG fully, but is only a subset
of the features. The specification allows also only 2 colours per
gradient. So first good thing would be to actually adopt the complete
gradient semantics from SVG. This would not be a huge burden for the
implementers I guess and would allow more complicated gradients then
what we have currently.
>> If there is a down-level concern, I would define the new element such that, when it and <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and beyond. This way, a down-level implementation will presumably process the <draw:gradient> and ignore the element introduced in ODF 1.3, since it is not defined down-level.
>>
>> Would that break the knot better?
>
> _if_ something new is needed in ODF then that would be my general
> approach as well: don't change semantics of existing markup in an
> incompatible way, but deprecate it and add new markup as necessary with
> improved semantics.
>
> the advantage is that existing products can then write both
> representations in a new version, and the deprecated markup can still be
> understood by older versions.
Also, one could be pro-active and simply refer to SVG for this stuff.
Since in SVG 2.0, there will be some more gradient types that would be
nice to support if LO drawing application wants to look like a serious
tool to the graphics folks.
Cheers
F.
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by Michael Stahl <ms...@redhat.com>.
On 01/08/12 20:38, Dennis E. Hamilton wrote:
> Hi Armin,
>
> Thanks for your valuable comment.
>
> I had thought that the description using "clockwise" was in reference to the page appearance and not the abstract treatment (with "right-hand rule"). Perhaps I misunderstand where the origin is understood in the projection onto the page.
>
> MORE IMPORTANT CONCERN
>
> I think you raise a more important question concerning changing for ODF 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 1.3.
>
> I recommend that there be no breaking change of draw:angle between ODF versions. It is probably best to deprecate it while clarifying the orientation of the angle-opening rotation and the units of the angle. I think preventing down-level breakage is impossible without that and the support explanations will be a nightmare otherwise. It seems to me that the ODF 1.2 description is best corrected in an Errata and the problem made immediately known in an OIC Advisory.
>
> To correct the geometry for transformations, I suggest that another, rigorously-defined gradient element be introduced, preferably one from SVG.
there are already the svg:linearGradient and svg:radialGradient elements
in ODF 1.2, for example playing with Calligra Stage 2.4.3 i was able to
produce a ODF presentation document with this, which seems to do fine
without any explicit angle at all:
>> <svg:linearGradient draw:name="gradient1" svg:spreadMethod="pad" svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%">
>> <svg:stop svg:offset="0.11" svg:stop-color="#dc143c"/><svg:stop svg:offset="0.473324" svg:stop-color="#00ced1"/><svg:stop svg:offset="0.589196" svg:stop-color="#00ff00"/>
>> </svg:linearGradient>
>> <svg:linearGradient draw:name="gradient2" svg:spreadMethod="pad" svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%">
>> <svg:stop svg:offset="0" svg:stop-color="#ffffff"/><svg:stop svg:offset="1" svg:stop-color="#00ff00"/>
>> </svg:linearGradient>
unfortunately it seems that OOo derived suites only support the _other_
ODF specific gradient element(s) that have this draw:angle attribute.
i don't actually know anything about graphics, so i'll let Armin judge
whether that SVG stuff in ODF 1.2 is sufficient :)
> If there is a down-level concern, I would define the new element such that, when it and <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and beyond. This way, a down-level implementation will presumably process the <draw:gradient> and ignore the element introduced in ODF 1.3, since it is not defined down-level.
>
> Would that break the knot better?
_if_ something new is needed in ODF then that would be my general
approach as well: don't change semantics of existing markup in an
incompatible way, but deprecate it and add new markup as necessary with
improved semantics.
the advantage is that existing products can then write both
representations in a new version, and the deprecated markup can still be
understood by older versions.
> - Dennis
>
> -----Original Message-----
> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
> Sent: Wednesday, August 01, 2012 02:21
> To: ooo-dev@incubator.apache.org
> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation
>
> Hi Dennis,
>
> On 30.07.2012 22:21, Dennis E. Hamilton wrote:
> [ ... ]
>> (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?
>
> [ ... ]
>
>
RE: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Hi Armin,
Thanks for your valuable comment.
I had thought that the description using "clockwise" was in reference to the page appearance and not the abstract treatment (with "right-hand rule"). Perhaps I misunderstand where the origin is understood in the projection onto the page.
MORE IMPORTANT CONCERN
I think you raise a more important question concerning changing for ODF 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 1.3.
I recommend that there be no breaking change of draw:angle between ODF versions. It is probably best to deprecate it while clarifying the orientation of the angle-opening rotation and the units of the angle. I think preventing down-level breakage is impossible without that and the support explanations will be a nightmare otherwise. It seems to me that the ODF 1.2 description is best corrected in an Errata and the problem made immediately known in an OIC Advisory.
To correct the geometry for transformations, I suggest that another, rigorously-defined gradient element be introduced, preferably one from SVG.
If there is a down-level concern, I would define the new element such that, when it and <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and beyond. This way, a down-level implementation will presumably process the <draw:gradient> and ignore the element introduced in ODF 1.3, since it is not defined down-level.
Would that break the knot better?
- Dennis
-----Original Message-----
From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
Sent: Wednesday, August 01, 2012 02:21
To: ooo-dev@incubator.apache.org
Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi Dennis,
On 30.07.2012 22:21, Dennis E. Hamilton wrote:
[ ... ]
> (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?
[ ... ]
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by Rob Weir <ro...@apache.org>.
On Thu, Aug 2, 2012 at 5:20 AM, Armin Le Grand <Ar...@me.com> wrote:
> Hi Dennis (and others),
>
>
> On 01.08.2012 20:38, Dennis E. Hamilton wrote:
>>
>> Hi Armin,
>>
>> Thanks for your valuable comment.
>>
>> I had thought that the description using "clockwise" was in reference to
>> the page appearance and not the abstract treatment (with "right-hand rule").
>> Perhaps I misunderstand where the origin is understood in the projection
>> onto the page.
>
>
> I do not think that you misunderstand. The X-Axis points to the right, the
> Y-Axis down, the origin is top-left (pretty standard, expected by everyone).
> Thus, mathematically, the positive orientation of angles goes clockwise.
>
There are different conventions for this. The one you describe is is
common in computer graphics, probably originally due to the way the
raster scan works in CRT displays and in line printers, e.g., left to
right, top to bottom. Mathematicians have their own convention. And
physicists, of course they have at least two conventions. So the only
correct answer is to specify the convention unambiguously in the
specification.
> Unfortunately someone did define it 'mirrored' in the cores for StarOffice
> (maybe more than 15 years ago), is used in the UI and this was copied to the
> UNO API and the ODF format for all angles (independent from usage for
> gradients or objects). This is not based on using the 2nd possible
> coordinate system with Y-Axis pointing up, but simply by using the 'wrong'
> (mirrored) values for angles throughout the office consequently.
>
>
>> MORE IMPORTANT CONCERN
>>
>> I think you raise a more important question concerning changing for ODF
>> 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and
>> ODF 1.3.
>>
>> I recommend that there be no breaking change of draw:angle between ODF
>> versions. It is probably best to deprecate it while clarifying the
>> orientation of the angle-opening rotation and the units of the angle. I
>> think preventing down-level breakage is impossible without that and the
>> support explanations will be a nightmare otherwise. It seems to me that the
>> ODF 1.2 description is best corrected in an Errata and the problem made
>> immediately known in an OIC Advisory.
>
>
> My first idea was to define the orientation (is not really defined now) for
> ODF1.2 and older, and to define it mirrored for ODF1.3, applying a xslt
> transformation to manage that.
>
> You are right that for all products not immediately applying to this change
> rotations would break. This would speak for adding a new property.
>
>
>> To correct the geometry for transformations, I suggest that another,
>> rigorously-defined gradient element be introduced, preferably one from SVG.
>
>
> Transformations are okay and need no change, they contain the angle
> corresponding to the coordinate system.
>
> As Michael Stahl wrote, svg:linearGradient and svg:radialGradient are
> already part of ODF1.2.
>
> These are no replacement for draw:gradient, thus are no candidates for
> deprecating the draw:gradient (and draw:opacity, the transparence gradients)
> for ODF1.3. It is another kind of gradient with the pros and cons described
> by Michael Stahl.
>
> (BTW: What to do if an object has draw:gradient AND svg:linearGradient
> defined at the same time (or even more, add svg:radialGradient)...?).
>
> We should not mix up varios themes here (maybe I started doing so, I
> apologize). We have two things here:
>
> (a) Non-SVG Gradient definitions (old ones)
> (b) Angle definitions in various places
>
> There is no general problem with (a), except the contained angle and it's
> orientation. Thus I talk more about (b) where (b) is about the old gradients
> with use <draw:angle> currently, but also start/end angles in circle/ellipse
> shapes.
>
> The Object rotation does not have a direct and single rotation attribute
> (AFAIK, there is svg:x, svg:y, svg:width/height, but no svg:angle), but has
> to use (and does use) a transformation when rotation is needed (which uses
> angles correctly, no problem there).
>
> Using a 2nd 'rigorously-defined' angle would be sufficient here. As
> mentioned in earlier mails, SVG has <angle> as basic data type (see SVG
> 4.2). It is already listed in ODF 1.2, see 18.3.1 of ODF spec (Does this
> mean it could already be used?). It is even referenced as data type in
> draw:angle, draw:start-angle and draw:end-angle (!), see e.g. 19.112
> draw:angle in ODF1.2 which says: 'The draw:angle attribute has the data type
> angle 18.3.1'. When this would be true, draw:angle would not even be needed
> since it's identical to svg:angle already (which it is not, another error?).
>
> Thus I suggest allowing both in <draw:gradient> and <draw:opacity>, with
>
> ---
>
> <draw:angle> is the inverted rotation in 10th of a degree as integer value
> (no longer reference 18.3.1 and say it's equal).
>
> <svg:angle> is the rotation as defined by SVG (including being float and
> supporting deg, rad and grad).
>
> If <svg:angle> is present, it has precedence over <draw:angle>. For
> compatibility, please support both when creating ODF documents.
>
> ---
>
> Other candidates wit this problem are (not sure when marked with '?'):
>
> 19.140 draw:end-angle
> 19.213 draw:start-angle
>
> 19.226 draw:text-rotate-angle (?)
> 20.95 draw:caption-angle (?)
> 20.339 style:rotation-angle (?)
> 20.375 style:text-rotation-angle (?)
>
>
>> If there is a down-level concern, I would define the new element such
>> that, when it and <draw:gradient> are both present, the new element
>> pre-empts <draw:gradient> in ODF 1.3 and beyond. This way, a down-level
>> implementation will presumably process the <draw:gradient> and ignore the
>> element introduced in ODF 1.3, since it is not defined down-level.
>
>
> We can use the SVG <angle> basic data type, no need for an own, new
> definition.
>
>
>> Would that break the knot better?
>
>
> Yes, I think so.
>
>> - Dennis
>>
>>
>> -----Original Message-----
>> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
>> Sent: Wednesday, August 01, 2012 02:21
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to
>> implementation
>>
>> Hi Dennis,
>>
>> On 30.07.2012 22:21, Dennis E. Hamilton wrote:
>> [ ... ]
>>
>>> (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?
>>
>> [ ... ]
>>
>>
>>
>
>
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by Regina Henschel <rb...@t-online.de>.
Hi all,
Armin Le Grand schrieb:
> Hi Dennis (and others),
[..]
> We should not mix up varios themes here (maybe I started doing so, I
> apologize). We have two things here:
>
> (a) Non-SVG Gradient definitions (old ones)
> (b) Angle definitions in various places
>
> There is no general problem with (a), except the contained angle and
> it's orientation. Thus I talk more about (b) where (b) is about the old
> gradients with use <draw:angle> currently, but also start/end angles in
> circle/ellipse shapes.
>
> The Object rotation does not have a direct and single rotation attribute
> (AFAIK, there is svg:x, svg:y, svg:width/height, but no svg:angle), but
> has to use (and does use) a transformation when rotation is needed
> (which uses angles correctly, no problem there).
>
> Using a 2nd 'rigorously-defined' angle would be sufficient here. As
> mentioned in earlier mails, SVG has <angle> as basic data type (see SVG
> 4.2). It is already listed in ODF 1.2, see 18.3.1 of ODF spec (Does this
> mean it could already be used?). It is even referenced as data type in
> draw:angle, draw:start-angle and draw:end-angle (!), see e.g. 19.112
> draw:angle in ODF1.2 which says: 'The draw:angle attribute has the data
> type angle 18.3.1'. When this would be true, draw:angle would not even
> be needed since it's identical to svg:angle already (which it is not,
> another error?).
>
> Thus I suggest allowing both in <draw:gradient> and <draw:opacity>, with
>
> ---
>
> <draw:angle> is the inverted rotation in 10th of a degree as integer
> value (no longer reference 18.3.1 and say it's equal).
I support the idea to define it directly for the 0.1 degree cases,
independently of a reference. I'm not sure, whether "invert rotation" is
really clear. Is it possible to add a picture to the spec? Then it would
be possible to show the axis, the gradient vector and a concrete angle.
>
> <svg:angle> is the rotation as defined by SVG (including being float and
> supporting deg, rad and grad).
>
> If <svg:angle> is present, it has precedence over <draw:angle>. For
> compatibility, please support both when creating ODF documents.
>
> ---
I have searched in the spec where the data type angle is referenced. I
add my findings here. All tests are only for AOO.
>
> Other candidates wit this problem are (not sure when marked with '?'):
>
> 19.140 draw:end-angle
> 19.213 draw:start-angle
They are used with unit 1 degree. They use decimal values. The values in
the UI are the same as in file format. A positive angle in file format
is shown as counterclockwise on screen.
>
> 19.226 draw:text-rotate-angle (?)
> 20.95 draw:caption-angle (?)
For both I don't know an object that uses it. How can I generate such an
object?
> 20.339 style:rotation-angle (?)
used for text direction of axis tick labels in charts. A positive value
in file format is shown counterclockwise on screen.
> 20.375 style:text-rotation-angle (?)
Used for character rotation 90° or 270°. I know no other use.
(20.2) chart:angle-offset (used in Pie-chart)
All three use unit 1 degree. style:text-rotation-angle has a constraint,
that the value must be integer.
20.17 dr3d:end-angle (used in 3D rotation objects for not full rotation)
19.209 draw:rotation (used for hatches)
19.112 draw:angle (used for gradient and opacity)
All three use unit 0.1 degree.
The orientation of draw:rotation and draw:angle is counterclockwise on
screen for a positive angle in file format.
(19.161) draw:extrusion-rotation-angle (used for custom shapes in
extruded state)
(19.104) dr3d:shadow-slant (used for shadow of 3D-scene)
Both use unit 1 degree. draw:extrusion-rotation-angle has no UI with
direct input but uses buttons with 5 degree steps.
>
[..]
Kind regard
Regina
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Posted by Armin Le Grand <Ar...@me.com>.
Hi Dennis (and others),
On 01.08.2012 20:38, Dennis E. Hamilton wrote:
> Hi Armin,
>
> Thanks for your valuable comment.
>
> I had thought that the description using "clockwise" was in reference to the page appearance and not the abstract treatment (with "right-hand rule"). Perhaps I misunderstand where the origin is understood in the projection onto the page.
I do not think that you misunderstand. The X-Axis points to the right,
the Y-Axis down, the origin is top-left (pretty standard, expected by
everyone). Thus, mathematically, the positive orientation of angles goes
clockwise.
Unfortunately someone did define it 'mirrored' in the cores for
StarOffice (maybe more than 15 years ago), is used in the UI and this
was copied to the UNO API and the ODF format for all angles (independent
from usage for gradients or objects). This is not based on using the 2nd
possible coordinate system with Y-Axis pointing up, but simply by using
the 'wrong' (mirrored) values for angles throughout the office consequently.
> MORE IMPORTANT CONCERN
>
> I think you raise a more important question concerning changing for ODF 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 1.3.
>
> I recommend that there be no breaking change of draw:angle between ODF versions. It is probably best to deprecate it while clarifying the orientation of the angle-opening rotation and the units of the angle. I think preventing down-level breakage is impossible without that and the support explanations will be a nightmare otherwise. It seems to me that the ODF 1.2 description is best corrected in an Errata and the problem made immediately known in an OIC Advisory.
My first idea was to define the orientation (is not really defined now)
for ODF1.2 and older, and to define it mirrored for ODF1.3, applying a
xslt transformation to manage that.
You are right that for all products not immediately applying to this
change rotations would break. This would speak for adding a new property.
> To correct the geometry for transformations, I suggest that another, rigorously-defined gradient element be introduced, preferably one from SVG.
Transformations are okay and need no change, they contain the angle
corresponding to the coordinate system.
As Michael Stahl wrote, svg:linearGradient and svg:radialGradient are
already part of ODF1.2.
These are no replacement for draw:gradient, thus are no candidates for
deprecating the draw:gradient (and draw:opacity, the transparence
gradients) for ODF1.3. It is another kind of gradient with the pros and
cons described by Michael Stahl.
(BTW: What to do if an object has draw:gradient AND svg:linearGradient
defined at the same time (or even more, add svg:radialGradient)...?).
We should not mix up varios themes here (maybe I started doing so, I
apologize). We have two things here:
(a) Non-SVG Gradient definitions (old ones)
(b) Angle definitions in various places
There is no general problem with (a), except the contained angle and
it's orientation. Thus I talk more about (b) where (b) is about the old
gradients with use <draw:angle> currently, but also start/end angles in
circle/ellipse shapes.
The Object rotation does not have a direct and single rotation attribute
(AFAIK, there is svg:x, svg:y, svg:width/height, but no svg:angle), but
has to use (and does use) a transformation when rotation is needed
(which uses angles correctly, no problem there).
Using a 2nd 'rigorously-defined' angle would be sufficient here. As
mentioned in earlier mails, SVG has <angle> as basic data type (see SVG
4.2). It is already listed in ODF 1.2, see 18.3.1 of ODF spec (Does this
mean it could already be used?). It is even referenced as data type in
draw:angle, draw:start-angle and draw:end-angle (!), see e.g. 19.112
draw:angle in ODF1.2 which says: 'The draw:angle attribute has the data
type angle 18.3.1'. When this would be true, draw:angle would not even
be needed since it's identical to svg:angle already (which it is not,
another error?).
Thus I suggest allowing both in <draw:gradient> and <draw:opacity>, with
---
<draw:angle> is the inverted rotation in 10th of a degree as integer
value (no longer reference 18.3.1 and say it's equal).
<svg:angle> is the rotation as defined by SVG (including being float and
supporting deg, rad and grad).
If <svg:angle> is present, it has precedence over <draw:angle>. For
compatibility, please support both when creating ODF documents.
---
Other candidates wit this problem are (not sure when marked with '?'):
19.140 draw:end-angle
19.213 draw:start-angle
19.226 draw:text-rotate-angle (?)
20.95 draw:caption-angle (?)
20.339 style:rotation-angle (?)
20.375 style:text-rotation-angle (?)
> If there is a down-level concern, I would define the new element such that, when it and <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and beyond. This way, a down-level implementation will presumably process the <draw:gradient> and ignore the element introduced in ODF 1.3, since it is not defined down-level.
We can use the SVG <angle> basic data type, no need for an own, new
definition.
> Would that break the knot better?
Yes, I think so.
> - Dennis
>
> -----Original Message-----
> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
> Sent: Wednesday, August 01, 2012 02:21
> To: ooo-dev@incubator.apache.org
> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation
>
> Hi Dennis,
>
> On 30.07.2012 22:21, Dennis E. Hamilton wrote:
> [ ... ]
>> (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?
>
> [ ... ]
>
>
>