Hi Armin,
Armin Le Grand schrieb:
On 30.07.2012 19:14, Armin Le Grand wrote:
Hi Regina,
On 30.07.2012 18:34, Regina Henschel wrote:
Hi all,
I want to suggest OASIS to change the definition of draw:angle. The
draft mail follows below. What do you think about it?
Kind regards
Regina
Draft of the mail to OASIS:
For <draw:gradient> type 'Linear' section 19.218 defines "The axis of
the gradient is specified with the draw:angle attribute clockwise to the
vertical axis."
It actually means, that in the internal coordinate system (that with an
upright y-axis), rotating this y-axis clockwise with the draw:angle
gives the gradient vector.
<draw:angle> section 19.122 repeats this in a less exact form. For the
angle itself it specifies:
"The draw:angle attribute has the data type angle 18.3.1."
And in section 18.3.1 you read, "An angle, as defined in §4.1 of [SVG].
An angle is a double value that may be followed immediately by one of
the following angle unit identifiers: deg (degrees), grad (gradiants) or
rad (radians). If no unit identifier is specified, the value is assumed
to be in degrees."
But that is wrong for the implementations in Apache OpenOffice,
LibreOffice, and Microsoft Office. All of them allow in draw:angle only
integers without unit and interpret them as 0.1deg. Calligra does not
use draw:gradient but uses svg:gradient. Microsoft Office can read
negative integers, but writes itself always non negative integers.
Apache OpenOffice and LibreOffice read and write only non negative
integers.
Therefore I suggest to alter the definition of draw:angle in this way:
Instead of the sentence
"The draw:angle attribute has the data type angle 18.3.1."
use the text
"The draw:angle attribute has the date type integer. A value of n is
interpreted as n*0.1 degrees."
Sorry, I would not do that. This would limit the possible precision
without needs in a format definition. If the precision in the cores is
limited or not does not play a role for the definition (it will
increase, we are on it).
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.
Thus, when we are at it, we may need to correct the orientation of
draw:angle, too. BTW: It is correct in the MS UI and their core data. Do
the same 5 degree rotation there.
I have not looked, what MS does in their own format, but for a
discussion at LO I have looked how they read and write ODF.
PowerPoint2013 does it this way:
The angle of 0° in the UI means that the gradient vector goes from left
to right in UI.
The angle in the UI rotates this gradient vector clockwise on screen.
Values from 0 to 359.9 are allowed.
In file format it is the same as from LO (and AOO), for example:
draw:angle="700" results from
PP UI-angle=20° clockwise on screen
LO UI-angle=70° counterclockwise on screen
draw:angle="3300" results form
PP UI-angle=120° clockwise on screen
LO UI-angle=330° counterclockwise on screen
I am currently not sure where draw:angle is used, is it the object
rotation or the gradient rotation, or is it used for both? If used for
both, I would not want precision to be limited to 0.1 degrees for
objects. I would evtl. accept this for gradients.
It is only used for draw:opacity and draw:gradient and not used in the
svg:linearGradient or in any other part, which needs angles. Therefore I
thought, that adapting the spec to the existing implementations, would
be easier as the other way round.
If it is used for both, we should think about the orientation (also for
shear)...
Kind regards
Regina
