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.
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. 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.
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?
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
Attachment:
TransformationByMacroWithShearAngleToggle.odg
Description: application/vnd.oasis.opendocument.graphics
Attachment:
TransformationByMacro.odg
Description: application/vnd.oasis.opendocument.graphics
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
