<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi Regina, yup. you are correct - I mixed up the full Matrix UNO API call with stuff in aw080, sorry. More comments inline... <div class="moz-cite-prefix">On 21-Jan-20 00:53, Regina Henschel wrote: </div> <blockquote type="cite" cite="mid:ae3e7cec-cff5-f9ab-acf6-a7a807cd474c@t-online.de">Hi Armin, Armin Le Grand schrieb am 20-Jan-20 um 14:32: <blockquote type="cite">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... </blockquote> 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. </blockquote> 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...) <blockquote type="cite" cite="mid:ae3e7cec-cff5-f9ab-acf6-a7a807cd474c@t-online.de"> Currently the specification does not contain the orientation at all. <blockquote type="cite"> 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. </blockquote> 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.</blockquote> Agreed! <blockquote type="cite" cite="mid:ae3e7cec-cff5-f9ab-acf6-a7a807cd474c@t-online.de">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. </blockquote> Sigh - yes. <blockquote type="cite" cite="mid:ae3e7cec-cff5-f9ab-acf6-a7a807cd474c@t-online.de"> <blockquote type="cite"> Luckily, the full ObjectTransform in ODF and UNO API *is* correct due to handing in/out a full Matrix in LinearAlgebra, </blockquote> 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 <blockquote type="cite">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. </blockquote> 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? </blockquote> 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... <blockquote type="cite" cite="mid:ae3e7cec-cff5-f9ab-acf6-a7a807cd474c@t-online.de"> <blockquote type="cite"> 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 ;-( </blockquote> Kind regards Regina <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ LibreOffice mailing list <a class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/libreoffice">https://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)</pre> </body> </html>