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). I would rather suggest to go with the SVG
definition and propose that. It's always good to get closer to other
graphic standards.
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?
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).
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 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.
If it is used for both, we should think about the orientation (also for
shear)...
Sincerely,
Armin
--
ALG
