Re: sign problem with shear angle in transform matrix

Hi Regina,

yup. you are correct - I mixed up the full Matrix UNO API call with
stuff in aw080, sorry. More comments inline...

On 21-Jan-20 00:53, Regina Henschel wrote:
> 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.

Interesting - so they do the same thing and let it look like the
coordinate system we all know from school and that rotates
counterClockWise - a good argument to mabe just stay with that in the
files. But that raises a problem with the full matrix we do not write
but can read from ODF - there, the rotation is correct AFAIK (not sure
about Shear...)

> 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.
Agreed!
> 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.
Sigh - yes.
> > 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?

No. I did by purpose not change that in aw080. But we might/should
comment it.

With the MS case above, maybe we should go the other way and use
left-handes AKA MS AKA ccw-oriented just everywhere - in ODF and UNO
API? That would at least be consequent and maybe easier to achieve (if
at all) as the other way round. I am just not sure if we would run into
problems with linear combinations - matrix multiplication and
changing/correcting the orientation are not commutative AFAIK...

> > 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
>
> _______________________________________________
> 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)