Consider translation of transformation matrix of image rotation

Regina Henschel rb.henschel at
Fri Feb 23 19:38:59 UTC 2018

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

> -----Ursprüngliche Nachricht-----
> Von: Regina Henschel [mailto:rb.henschel at]
> Gesendet: Friday, February 23, 2018 15:13
> An: LO dev fdo <libreoffice at>
> Cc: Armin Le Grand <Armin.LeGrand at>
> Betreff: Consider translation of transformation matrix of image rotation
> Hi Armin, hi all,
> this is about
> and my proposal
> 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

More information about the LibreOffice mailing list