Regina Henschel schrieb:
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." ?
Yes.
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.
This is possible. I remembered a task handling the same problem with the
rotation angle, and (after some seacrhing :-)) i found it. It's #i78696#
where You can see that the 'old' DrawingLayer (that's what i call it's
form before i inherited it) the angle was mathematically already wrong
and thus linear matrix combinations did not work correcly. Sigh. This is
corrected in the core and the API, but had to stay in the FileFormat (to
correct it there, a new ODF version is needed).
It is possible that the shear angle has the same problem. The different
usage of shear from GeoStat (the old core) in TRGetBaseGeometry and
ViewContactOfSdrRectObj::createViewIndependentPrimitive2DSequence() is a
sign for that thesis.
This would require a similar fix as #i78696#, correction for core and
API, but not for FileFormat.
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.
No, i appreciate Your investigations and everything is possible in the
(old) code. It's written by humans...
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.
Difficult to explain. As said, the model still uses the old definitions
of GeoStat. For visualisation, primitives are created for the model
objects from the VCs and VOCs, mainly in
createViewIndependentPrimitive2DSequence(). The primtives completely use
the created transformation matrices (and will get them later from a
reworked model directly :-)). These transformations are correct and use
rotation and shear mathematically correct.
The DrawingLyer is in a transition state. The model is old and partially
not well-defined, the visualisation stack is new and uses
transfomations. The same is tue for the interactions. Migrationg that
whole stuff is a sysiphus-task for me and will take some more years...
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.
No, this can be done in any case. You may create a combined homogen
matrix with any combination of ShearX and ShearY and can always extract
just one of the shears. I use ShearX, thus any ShearY is expressed as a
combination of ShearX and rotation. You can directly see this from the
linear combination of the symbolic forms of the matrix types involved.
It's similar to a rotation around a point: You move -point, rotate, move
+point in combination. That combination can be decomposed to just a
rotate around origin and a translation which creates the same operation.
That IS the core functionality of linear combination of homogen matrices.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
