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! On 06-Jan-20 14:35, Regina Henschel wrote: > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice -- ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
