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