Hi Armin,
it is very kind that you guide me in learning more of Draw internal.
Armin Le Grand schrieb:
<----stuff deleted---->
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.
Is this right, "If a apply the matrix, which is in the property
'Transformation' to the points (0|0), (1|0), (1|1), (0|1) [of cause in
homogeneous form], then I get the corners of the rectangle. Multiplying
with 1/1000 cm then gives the coordinates on the sheet, case page
borders=0." ?
If that is right, then please look again at the values in the second
column in the examples. I think, that they are wrong. And I think that
they are wrong, because for shearing the angle is used with the wrong sign.
In the TRGetBaseGeometry, which you mention below, I see
// build return value matrix
2997 rMatrix =
basegfx::tools::createScaleShearXRotateTranslateB2DHomMatrix(
2998 aScale,
2999 basegfx::fTools::equalZero(fShearX) ? 0.0 :
tan(fShearX),
3000 basegfx::fTools::equalZero(fRotate) ? 0.0 : -fRotate,
3001 aTranslate);
Shouldn't it be
2999 basegfx::fTools::equalZero(fShearX) ? 0.0 :
tan(-fShearX)
But I'm just starting to learn more about the code, so I might be
totally wrong.
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.
Where do I find the used Matrices in the code? I do not mean the poor
mathematical calculating in Create*B2DHomMatrix in
basegfx/source/matrix/b2dhommatrixtools.cxx. But I'm searching where the
input values from the Position&Size dialog are transformed and where the
actual transformation matrix for the property "Transform" is calculated
for classical draw objects like arc and ellipse.
I see that the Create*B2DHomMatrix routines use rotating around origin
and shearing with fix x-axis or fix y-axis respectively. But the UI does
rotate and shear with other fix elements. So somewhere the values have
to be transformed.
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.
That is clear.
<----Example deleted---->
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 have manipulated a transformation matrix already to upright a chart
(see issue 72995).
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.
For a poor line, shearing can indeed be substituted. But if the
associated string would be concidered too, shearing would look different.
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.
<----rest deleted, reply concerning ODF in other mail ---->
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
