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 

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

-----Ursprüngliche Nachricht-----
Von: Regina Henschel [mailto:rb.hensc...@t-online.de]
Gesendet: Friday, February 23, 2018 15:13
An: LO dev fdo <libreoffice@lists.freedesktop.org>
Cc: Armin Le Grand <armin.legr...@extern.cib.de>
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:

It has a construction
     basegfx::B2DHomMatrix aFullTransform;

     with later on
     if ( !aFullTransform.isIdentity() )

Should I use
     basegfx::B2DHomMatrix aFullTransform;
     bool bHasTransformation;

     if ( bHasTransformation )

It has
     if ( aTransformedCenterPosition != aCenterPosition ) Is this check useful, 
or should I calculate the correction always, although the result might be the 
original value?

Is this the correct place at all to correct the position?

Kind regards

LibreOffice mailing list

Reply via email to