Description: DOCX image partly off page Steps to Reproduce: 1. Open the attached file 2. Save as DOCX 3. File reload (Note; appears to be import error; docx fine with older) Actual Results: Front cover page partly off page Expected Results: Not Reproducible: Always User Profile Reset: No Additional Info: Found in 7.2 not in 7.0
Created attachment 169405 [details] Example file
Confirming with: Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f2389a70da606768a39ee599de6a5b24058734aa CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Seems to have started with: https://git.libreoffice.org/core/+/195eae4852012eed6da72c0a9f55094a09aa2867 author Miklos Vajna <vmiklos@collabora.com> Thu Jan 23 18:05:26 2020 +0100 committer Miklos Vajna <vmiklos@collabora.com> Thu Jan 23 22:22:56 2020 +0100 sw DoNotCaptureDrawObjsOnPage: don't capture wrap-through Writer images, either Adding CC to: Miklos Vajna Fun fact: opening the Properties dialog of the image and closing it with OK puts the image back onto the paper area.
Created attachment 169411 [details] The original file and its docx version in LO7.2 alpha
(In reply to Telesto from comment #0) > Additional Info: ... > not in > 7.0 This doesn't seem correct, based on the bibisect results.
Created attachment 174204 [details] The positioning settings of the example file Looks like the original file has a -1 cm positioning to the left and top, but this is ignored by Writer for odt, but (initially) not for docx.
Created attachment 174205 [details] The exported file in Word and Writer side by side However it looks the same as in Word.
Created attachment 174206 [details] The original files exported versions in Word from 4.2 and 4.1 This was good in 4.1, but not before or after. The weak point is the -2 cm position exported and seen in Word. This was exactly -1 cm position in 4.1 (and it looked in Word as the original), but got broken in 4.2.
Created attachment 174207 [details] The original file exported by LO 4.1
Putting back bibisectRequest the other commit just uncovered the problem.
bibisected with linux-42max to: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9413f2124dff0c38fd52d318d5ac2f392a7d36e0 author Luboš Luňák <l.lunak@suse.cz> 2013-05-23 16:32:44 +0200 committer Luboš Luňák <l.lunak@suse.cz> 2013-05-23 16:36:46 +0200 improve exporting of picture alignment to docx
There seems to be something wrong with the ODT itself (from comment 1). If I FIRST edit the picture properties, then hit OK, and THEN export to DOCX, everything is OK. I get <wp:posOffset>-360045</wp:posOffset> </wp:positionH> <wp:positionV relativeFrom="paragraph"> <wp:posOffset>-360045</wp:posOffset> </wp:positionV> However, if I simply round-trip the file, I get <wp:posOffset>-741680</wp:posOffset> </wp:positionH> <wp:positionV relativeFrom="paragraph"> <wp:posOffset>-360045</wp:posOffset> </wp:positionV> Since the dialog reports that both the top and left margins are identical (1cm), and so are the apparent picture offsets (-1cm), these two number should have been identical. And yet the ODT has the different frame values svg:x="-2.06cm" svg:y="-1cm". Thus, the actual internal SW values do not reflect the layout/dialog values, so how can export possibly get it right? Even ODT export keeps the wrong value. removing REGRESSION. If anything is to be fixed here, it seems like it would be need to be in ODT import - where "illegal" values are fixed at import instead of at layout. Another fix needed would be in the dialog - to show the actual value in case the image is not "captured" ("forced to be fully inside the page frame") instead of the minimum value allowed for the captured case. (So, in the DOCX with the shifted picture, pressing OK should not change anything - comment 2.)
Problem might be in anchor "to character", when the paragraph does not have any characters. When I insert a non-breakable space in the paragraph, the export is correct.