sign problem with shear angle in transform matrix

classic Classic list List threaded Threaded
6 messages Options
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

sign problem with shear angle in transform matrix

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RectangleSheared.odg (25K) Download Attachment
Miklos Vajna-6 Miklos Vajna-6
Reply | Threaded
Open this post in threaded view
|

Re: sign problem with shear angle in transform matrix

Hi Regina,

On Mon, Jan 06, 2020 at 02:35:02PM +0100, Regina Henschel <[hidden email]> wrote:
> 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.

Indeed, in case we have live with this, then not breaking compatibility
with existing UNO API clients is always the best, I think.

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (201 bytes) Download Attachment
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: sign problem with shear angle in transform matrix

In reply to this post by Regina Henschel

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
-- 
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

TransformationByMacroWithShearAngleToggle.odg (20K) Download Attachment
TransformationByMacro.odg (20K) Download Attachment
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
-- 
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: sign problem with shear angle in transform matrix

Hi Armin,

Armin Le Grand schrieb am 22-Jan-20 um 18:13:

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

I have assumed in SdXMLImExTransform2D::GetFullTransform(), that the
matrix() value in file format gives mathematically correct matrix. That
is the current handling in case IMP_SDXMLEXP_TRANSOBJ2D_MATRIX already.
I have not found any application, that actually writes it, so could not
test this assumption. But it makes sense to treat it as mathematically
correct.

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

Agree, better documentation is needed. Same for the API property
TransformationInHoriL2R

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

In ODF we have already different orientations, so ODF needs to specify
the orientation in each single case.

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

Yes multiplication will not work. In
SdrObjCustomShape::AdjustToMaxRect() I decompose the matrix from
TRGetBaseGeometry, compose a mathematically correct one, do my
transformations, decompose the result and compose a matrix suitable for
TRSetBaseGeometry.

If the 'wrong' shear angle of the matrix in
TRGetBaseGeometry/TRSetBaseGeometry will not be corrected, then it
should be documented, perhaps in include/svx/svdobj.hxx. When I worked
on AdjustToMaxRect(), it took me a while to realize that the wrong shear
angle was the reason that it didn't work as expected.

Kind regards
Regina
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice