Created attachment 149409 [details] Sample ODT Open the attached ODT, created in Writer, containing a single rotated image. Save as DOCX and reopen (or open it in Word). => The image is too big, and falls off to the right (the position is different in Word and Writer). There's no issue with a DOCX containing a rotated image, originating from Word, and there's no issue with the sample attachment 140588 [details] from bug 116371. Observed using LO 6.3.0.0.alpha0+ (e0745a11597e5d57eb8001a295314e86810a6027) / Windows 7. Needs the DOCX part of bug 116371 fix, b226383a83e41bbced9fc2a02dc09a449401ec97.
Created attachment 149410 [details] Wrongly exported DOCX
Created attachment 149411 [details] Similar sample DOCX (created in Word) Roundtripping this file keeps the image correctly rotated.
I confirm it with Version: 6.3.0.0.alpha0+ (x64) Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded
It seems that the following line uses the size of the original image, not the size of the resized image: aSize = pGrfNode->GetTwipSize(); https://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/docxattributeoutput.cxx?r=d55b26a0#4879 What complicates things is that the original rSize parameter in DocxAttributeOutput::FlyFrameGraphic(...) is the frame's layout size, which is the bounding rectangle of the resized+rotated image. What seems to be needed is the size of the resized image, not sure where that is stored/calculated (in ww8::Frame, maLayoutSize is the aforementioned layout size, and maSize is the original size).
*** Bug 134093 has been marked as a duplicate of this bug. ***
*** Bug 134094 has been marked as a duplicate of this bug. ***
*** Bug 139103 has been marked as a duplicate of this bug. ***
Created attachment 173258 [details] proposed patch @Aron Budea: I think, it is not a size but a position problem. When it comes to DocxSdrExport::startDMLAnchorInline(), the parameter rSize has the unrotated size of the image, as it is needed in Word. But in contrast to other objects, line#683 awt::Point aPos(pFrameFormat->GetHoriOrient().GetPos(), pFrameFormat->GetVertOrient().GetPos()); gives the position of the unrotated image. So it is not needed to create the unrotated position back from the rotated position, which is done in lclMovePositionWithRotation(). I put my proposed patch as attachment here, because I will not have time enough in the next days to work out a proper patch (testing with other objects than Writer-images and testing the other documents in the bug reports and creating unit tests). It might be that instead of adding the case in lcl_IsRotateAngleValid() it is necessary to add the exclusion directly in if (pObj && lcl_IsRotateAngleValid(*pObj)) in line#688.
I'm working on it, see https://gerrit.libreoffice.org/c/core/+/118243
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a020f2c3993fd8b625cee07ed73949982e719fca tdf#123569 correct position of rotated Writer image It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
There are two cases, which are not covered by the patch: (1) If a rotated Writer-image is anchored "as-character", then currently the line height is only increased to the area, the unrotated image would need. To get the same rendering in Word, it would be necessary to use negative effectExtent values. Those are possible in OOXML, but Word cannot interpret negative values. I think, that LibreOffice should not render it this way, but increase the line height, so that the complete image is visible. (2) If you set a shadow to a rotated Writer-image, the shadow is calculated from the surrounding frame, not from the rotated image. Word builds the shadow from the image and as such it will be imported, because on import the image will become a Draw-image. Here too I think, LibreOffice is wrong. In addition it has the error, that when setting the shadow, the frame size is not automatically increased, but the image shrinks. Both problems are not related to the position problem of this bug report and should go into separate bug reports. Therefore I set this one to fixed. I have made a lot of tests, but if you find problems other than (1) and (2), reopen it.
VERIFIED with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ac80ec817eb07c77a51bc0729985a473c734182e CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Regina, thanks for fixing it!