Re: sign problem with shear angle in transform matrix

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