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