Re: sign problem with shear angle in transform matrix

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...

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.

Luckily, the full ObjectTransform in ODF and UNO API *is* correct due to handing in/out a full Matrix in LinearAlgebra, 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.

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 ;-(

HTH!

Hi all,

the matrix, which is product by TRGetBaseGeometry and which is available as property "Transformation" in macros, is mathematically wrong, because the shear element has a wrong sign. What to do?
A) Convert the matrix into a mathematically correct one, where it is needed, e.g. in case it will be multiplied by another matrix.
B) Change core to use the mathematically correct matrix.
C) Other idea?

I've used approach A for now. See https://cgit.freedesktop.org/libreoffice/core/commit/?id=f44140bebb9c493d97ba5aef26c9692c53a6b93f and my new patch in https://gerrit.libreoffice.org/#/c/core/+/86244/
I think, because the property "Transformation" might be used by existing macros, it would not be good to change its content. Another reason is, that option B would require large changes (some work in Armins aw080), so that it should at least be accompanied by an expert developer.

Before I continue, I want to know, whether you think it is OK to use option A.

The attachment has an example to reproduce the problem.

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)