Hi Armin,
Armin Le Grand schrieb am 23.02.2018 um 16:39:
Hi Regina,
It works in principle,
What does that mean ?!?
It solves the issue. Question is, whether something can be improved or
should be changed.
A: An empty constructed basegfx::B2DHomMatrix is on identity (no-op), so it is
ideal to test if it is used. Will even work when usages add-up to identity
matrix whant means 'no change'. Yes, use isIdentity() please.
OK. I had seen by setting a break point, that it is indeed initialized
with identity. Only it is not directly obvious.
B: You might calculate it, but it is not really needed. Since we rotate arouhd
center (only) it is sufficient to extract rotation and set it - we know it's
around center. The rest of the shape (svg:x/y/width/height) is the unrotated
shape, so this is sufficient. It can be calculated to make error-checks if
wanted. It will have to be calculated when someone will use more of the
transformation later (or we do)
A correction is needed, because Word uses a shape with position (0|0) on
which the transformation matrix is applied, when it writes out the
document to ODF.
Example: An image position=(3cm|4cm), width=6cm height=2cm, rotate by
30° comes out by Word as
draw:transform="translate(-1.18307in -0.39567in) rotate(-0.5236)
translate(2.36015in 1.96928in)" and missing svg:x and svg:y (which means
svg:x="0" and svg:y="0"). In UI it is a rotated image with center
(6cm|5cm), same as LibreOffice, but the file format is different.
[BTW -1.18307in≈3cm; -0.39567in≈1cm; half of width/height]
That is, what the issue is about. The way Word writes it, is not common,
but possible. I think, that LibreOffice should be able to read such
files for interoperability.
My question is more, whether the comparison might be more expensive than
the saved effort for the calculations. Or do you know a better way to
detect whether a correction of the position is needed? I hesitate to
test on position (0|0), because that would be a "Word only" fix and does
not cover other included translations.
C: Not sure whant you mean here. Correcting the position means it's
'overdefined'. The (svg:x/y/width/height) and back-calculating from
transformation with (-translate, rotate, translate) to rotate around center
*should* always give the same center. If not, it is *not clear* which
definition is the correct one. This is the reason the transformation should
*not* contain positioning at all. The idea is: Apply (svg:x/y/width/height)
first (pos and size), then apply transformation to it (rotate, shear, mirror
(scale-1)).
For LibreOffice it should give the same center, but with files generated
by Word there is the above described problem.
My concern is, that I might add something here, which is not on the way
to a final solution for transformations. I don't know your further plans
for the FlyFrames.
Kind regards
Regina
-----Ursprüngliche Nachricht-----
Von: Regina Henschel [mailto:[email protected]]
Gesendet: Friday, February 23, 2018 15:13
An: LO dev fdo <[email protected]>
Cc: Armin Le Grand <[email protected]>
Betreff: Consider translation of transformation matrix of image rotation
Hi Armin, hi all,
this is about https://bugs.documentfoundation.org/show_bug.cgi?id=115590
and my proposal https://gerrit.libreoffice.org/#/c/50176/
It works in principle, but I'm not sure about some details:
A
It has a construction
basegfx::B2DHomMatrix aFullTransform;
with later on
if ( !aFullTransform.isIdentity() )
Should I use
basegfx::B2DHomMatrix aFullTransform;
bool bHasTransformation;
if ( bHasTransformation )
instead?
B
It has
if ( aTransformedCenterPosition != aCenterPosition ) Is this check useful,
or should I calculate the correction always, although the result might be the
original value?
C
Is this the correct place at all to correct the position?
Kind regards
Regina
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
