|
Hi Regina,
yup. you are correct - I mixed up the full Matrix UNO API call
with stuff in aw080, sorry. More comments inline...
On 21-Jan-20 00:53, Regina Henschel
wrote:
Hi
Armin,
Armin Le Grand schrieb am 20-Jan-20 um 14:32:
Hiho,
sorry for the late answer :-)
History: When doing deep change work quite some years ago, I did
*not* realize that rot angle and shear angle were *mirrored* -
sigh. This was probably historically the case due to the Y-Axis
going down technically in OutDev's (right-handed), but handled
in interactions and UI (aka visually) as going *up* (aka
left-handed). Thus, the model data was using the UI orientation
- sigh ;-( Since this was done everywhere it did not pop up as
an error - until someone else tried to import the XML ODF stuff
we write and read - and yes, the error was unnoticed forwarded
to ODF format - sigh :-( You won't believe how surprised/shocked
I was when I found out about it...
I see the problem in ODF, that shear and rotation angle is
specified in degree but used in radians. The orientation of the
angle in file format can be corrected on import/export if needed.
Currently a skewX(w) needs to be interpreted mathematically as
transformation matrix
/ 1 tan(-w) 0 \
| 0 1 0 |
\ 0 0 1 /
OOo1.1.5 and Scribus interpret a skewY(w) as matrix
/ 1 0 0 \
| tan(-w) 1 0 |
\ 0 0 1 /
Because documents with skewY(w) were not produced by LibreOffice
and therefore it doesn't affect own documents, I have used that
interpretation.
And for a rotation, that is on screen 20deg clockwise, both
LibreOffice and MS Office write rotate(-0.34907) into the file, so
that orientation should be kept in that meaning.
Interesting - so they do the same thing and let it look like the
coordinate system we all know from school and that rotates
counterClockWise - a good argument to mabe just stay with that in
the files. But that raises a problem with the full matrix we do
not write but can read from ODF - there, the rotation is correct
AFAIK (not sure about Shear...)
Currently the specification does not contain the orientation at
all.
In aw080 I corrected this more or less everywhere internally -
the SdrObjects were anyways in a state that the just had a
B2DHomMatrix as geometric definition, thus this had to be
correct (right-handed) in the model - we are not that far in the
current core... Angles were flipped everywhere for UI and where
APIs were involved - UNO API and ODF as far as needed.
Yes, how to define it in core is a different problem. Knowing your
efforts in aw080, I have decided not to try it. I would appreciate
if only mathematically correct matrices were used internally.
Agreed!
But
converting this requires such a great effort and touches so many
areas that it can only be achieved as a team in a reasonable
amount of time.
Sigh - yes.
Luckily, the full ObjectTransform in ODF and UNO API *is*
correct due to handing in/out a full Matrix in LinearAlgebra,
No, the matrix in API is not correct. Try it by using property
"Transformation" in macros. TRGetBaseGeometry and
TRSetBaseGeometry use wrong sign in shear angle. It was not yet
discovered, because TRGetBaseGeometry and TRSetBaseGeometry were
internally only used to transport the geometry values, and not in
multiplication with other matrices. In my two patches I have made
TRmatrix -> math matrix -> do some matrix multiplication
-> TRmatrix.
I have attached a document with matrix tools in macros. Select the
yellow shape. Then press Alt+F11. Select the macro 'Main' and run
it. It takes the matrix from the shape, multiplies it with a
scaling matrix with factor 1 in x-direction and factor 3 in
y-direction and applies the result to the shape. The result is
wrong. The result will be correct if you toggle the sign before
multiplying and toggle it back after multiplying, see the other
document.
thus right-handed and can
be used for compatibility and preferred in
the future - for the rest we'll have to keep that error alive as
long as we won't get a new ODF format.
As said above, the orientation in rotation, skewX and skewY from
ODF can easily be changed on import/export, that is not the
problem. The problem is not in ODF, but in the "Transformation"
attribute in the API. Any user, who has macros which manipulate
shapes by matrices, will have corrected them like I have done it
in the attached file. So if the API matrix will be changed to the
mathematically correct one, those users need to be alarmed, that
they have to change their macros. Do we want that?
No. I did by purpose not change that in aw080. But we
might/should comment it.
With the MS case above, maybe we should go the other way and use
left-handes AKA MS AKA ccw-oriented just everywhere - in ODF and
UNO API? That would at least be consequent and maybe easier to
achieve (if at all) as the other way round. I am just not sure if
we would run into problems with linear combinations - matrix
multiplication and changing/correcting the orientation are not
commutative AFAIK...
BTW: Is there an official site to already claim these angles to
change orientation for ODF1.4...? And is that claimed...?
At least it will be transformable by some XSLT between 1. and a
potentially corrected 1.4.
That's not the case for the API, though ;-(
Kind regards
Regina
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
|
