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!

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)