Consider translation of transformation matrix of image rotation
rb.henschel at t-online.de
Fri Feb 23 19:38:59 UTC 2018
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.
> -----Ursprüngliche Nachricht-----
> Von: Regina Henschel [mailto:rb.henschel at t-online.de]
> Gesendet: Friday, February 23, 2018 15:13
> An: LO dev fdo <libreoffice at lists.freedesktop.org>
> Cc: Armin Le Grand <Armin.LeGrand at 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
More information about the LibreOffice