Armin Le Grand schrieb:
Regina Henschel schrieb:
Hi Armin,
Armin Le Grand schrieb:
Regina Henschel schrieb:
Hi Armin,
Armin Le Grand schrieb:
Regina Henschel schrieb:
..
Take a line
A line is unfortunately a bad example; it does not really get
transformed from the tought unit line from (0,0) to (1,0), but
internally creates a two-point polygon with the points where they belong
and no transformation at all. Could You use a rectangle as example,
please? This will make things more reliable to reproduce.
The transformation for a rectangle implies to be applied to a unit
rectangle from (0,0) to (1,1), thus completely defining position, size,
rotation and shear of the shape. The order is:
M = MTranslate * MRotate * MShearX * MScale
? I have expected a equation
M = MTranslatePos * MTranslateCenter * MRotate * MShearX * (inverse
MTranslateCenter) * MScale
No, the model is designed to always rotate objects around their topleft
position. This makes things much easier and allows the 4term composition
mentioned above. This also means that shear, scale and rotate are
defined arount the top-left positon.
Anyways, when You combine Your suggestion and Your rotate and shear are
center-defined, the next matrix decompositon will reduce Your factors to
a maximum of 6 linear independent values (the maximum You can exztract
from a 3x2 matrix), thus You automatically get scale (2 values), shearX
(1), rotate (1) and translation (2). That is also the reason why
mathematically it is not possible to extract shearX and shearY
separately; in princiiple You have to decide which You prefer when
decomposing the matrix.
with MTranslateCenter with dx=ScaleX/2 and dy=ScaleY/2, because
rotation and shearing are done on the center point of an object and
the rotation matrix is usually defined for rotating around origin and
shearing matrix is defined for fix x-axis.
Of cause it is possible to use one translation, but the values are not
simple, because translation is not commutative with rotation or shearing.
of course multiplied from right to left as usual in matrix notation.
Take a classic rectangle at position (-1cm|-1cm) and
width=2cm|height=2cm. Set a slant angle of 20 degrees via dialog.
The matrix is
2001 728.304 -636
0 2001 -1001
0 0 1
Applying the matrix to (0|0) and (1|1) results in
/ \ / \ / \
| 2001 728.304 -636 | | 0 | | -636 |
| 0 2001 -1001 | * | 0 | = | -1001 |
| 0 0 1 | | 1 | | 1 |
\ / \ / \ /
/ \ / \ / \
| 2001 728.304 -636 | | 1 | | 2093.304 |
| 0 2001 -1001 | * | 1 | = | 1001 |
| 0 0 1 | | 1 | | 1 |
\ / \ / \ /
The coordinates on screen are (-0.64cm|-1cm) and (0.64cm|1cm).
The matrix is wrong for the rectangle too.
Creating the matrices manually on paper (without rotation) as
described above, results in (besides the +1 in width and height) :
2000 -727.94 -636.03
0 2000 -1000
0 0 1
which would give the correct coordinates.
I also need to know on which level You get the matrix: From ODF
FileFormat, from UNO API or from SdrObject level? This is not always the
same, unfortunately...
I get it from UNO API. I use a Basic macro, where I get the selected
shape, set a breakpoint and look at the shape with the "watch" tool.
This gives You the transformation to be applied from the implied unit
object to the current state. This is usually the unit rectangle from (0,
0) to (1, 1) and for lines it's the line along the X-Axis (0,0) to (1,0).
When You set this matrix via API You absolutely control the object
values. When You want to modify the object, retrieve this matrix,
multiply it with YOur cnage and set back the result. In that way You are
able to e.g. shear even a line what is not possible when directly
setting the matrix.
I also checked for line: Looking at SdrPathObj::TRGetBaseGeometry(..)
shows that neither shear nor rotate is given for lines. You get scale
and translate and the polygon with two points, moved to (0,0). For
historical reasons the polygon is scaled, since with the old integer
definitions the unit-scaled polygon would lose all information.
Indeed i think for line we have an error here: The (scaled for
historical reasons) unit line along the X-Axis should be given as
polygon and (scale, rotate, translate) as matrix. As described, a line
never has a shear in it's base definition.
It's not really an error, You get the polygon of the line with two
points which contains the rotation and the matrix which contains scale
and translation, thus all information is given correctly.
It would be better to have the unit line (along the X-Axis) and the
rotation in the matrix, thus i wrote #i108450# to adjust that.
If I save the file and unpack it, the rectangle has
<draw:rect draw:style-name="gr1" draw:text-style-name="P1"
draw:layer="layout" svg:width="2cm" svg:height="2cm"
draw:transform="skewX (0.3490658503988) translate (-0.636cm -1cm)">
There is no matrix.
The ODF defines that there can be one or even a linear combination of
matrices, mixed with the wiodth/height attributes. The exporter tries to
export as treadable as possible, thus for non-rotated, non-sheared
objects the more human-redable position and size is used.
Kind regards
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
