Regina Henschel schrieb:
Hi all,
I want to use the transformation matrix in my macro, but it does not
contain what I expect. So I need some help to understand it.
Take a draw document with page border 0cm.
Draw a rectangle at left=2cm; top=1cm and width=2cm; height=4cm.
Now in Position&Size set the slant angle to 20°.
The transformed rectangle gets the transformation matrix (rounded)
2001 1454.4 2727
0 3996 1000
0 0 1
I thought that if a apply the transformation matrix to
1
1
1
then I will get the coordinates of the former right bottom corner.
Therefore I expect the matrix
2000 -1455.9 2727.9
0 4000 1000
0 0 0
Now I have three questions:
1) Is it correct, that Draw has a positive value in line1/column2 ?
Yes. For historical reasons, the OOo Drawinglayer has a right-handed 2D
coordinate system, that means the Y-Axis points down (as can be seen in
the positions dialog; the bigger the position, the more downward on the
page is the object). This also has the consequences, that all
mathematical stuff related to a left-handed coordinate system as we
learn it in school is 'mirrored' in Y. This is true for shear and
rotation angle values (e.g. positive rotation goes clockwise).
2) If it is correct, how is the transformation to be used?
Keep in mind that You are working with a right-handed coordinate sytem.
3) Why does Draw have the value 2001 and not 2000? For rectangle without
shearing it has 2001 and 4001 instead 2000 and 4000.
Also for historical reasons. The model data is still on integer
coordinates (also the shear and rotate values, see class GeoStat in
svdtrans.hxx). This and the GetWidth() method at Rectangle() (which adds
+1 to the width which is good for pixel-based geometry, but not for
model-based calculations) lead to the current situation.
The matrix get/set is a convenience implementation supporting double
precision to the outside world (don't ask how this could be done to work
with the old stuff flawlessly), but internally currently still (has to)
fall back to map the given values to integers.
We are working on enhancing this step by step, but the model is still
unchanged. It will also be difficult to get rid of the +1 stuff in the
UNO API (and FileFormat) since we need a defined point in ODF versioning
to do so...
kind regards
HTH!
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
