Description: If create ODT with pasted images (default alignment and anchoring settings) and then save it as DOCX, images are misplaced. Steps to Reproduce: 1. Open attached file in lowriter. 2. Save it as DOCX, close file 3. Open saved file in lowriter. Actual Results: Images are misplaced in DOCX Expected Results: Images in DOCX are placed by the same way like in ODT Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.4.1 Build ID: 1:6.0.4~rc1-3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (C); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 142093 [details] Sample file
Created attachment 142094 [details] Screenshot of page with misplaced images after converting to DOCX
I can confirm with 5.1.6.2 and Version: 6.1.0.0.alpha1+ Build ID: 741b7c35ac9cc118a9d70925c71f27147551d204 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Found in 4.2 but not in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)
bibisect-42max: After this commit the three images are all in the same place. d8935d2016dcdc8bb589d087e9784a7a9c3dea8f is the first bad commit commit d8935d2016dcdc8bb589d087e9784a7a9c3dea8f Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 19:56:00 2015 +0800 source-hash-8f8b31abd02876c3601e343b8b3274754f8a61b6 commit 8f8b31abd02876c3601e343b8b3274754f8a61b6 Author: Luboš Luňák <l.lunak@suse.cz> AuthorDate: Tue Aug 6 17:02:42 2013 +0200 Commit: Luboš Luňák <l.lunak@suse.cz> CommitDate: Tue Aug 6 17:17:53 2013 +0200 compatibility setting for MS Word wrapping text in less space (bnc#822908) The document itself is stupid and uses a SURROUND_THROUGH object with a number of empty lines that make it act is if it in fact was SURROUND_NONE, rather than actually disabling wrapping for the object and be done with it. But the difference was that Word still managed to fit those empty lines next to the object into the little space that was there, while LO already considered the space too small. So keep a compatibility setting for Word documents in order to avoid problems with such lame documents and hopefully that's enough. Change-Id: I7d17b90de381fd86914ce5efd9c5a29fe4850edc After this commit is error as in the printscreen, but commit doesn't look relevant. 77e080343efdfab70eb7aa9e87d8085586fe6967 is the first bad commit commit 77e080343efdfab70eb7aa9e87d8085586fe6967 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 19:56:36 2015 +0800 source-hash-6c0e752093ddedca0a6f0063567aff19997bab03 Bibisect: This commit covers the following source commit(s) which failed to build 4dfb33788de68c827cb7a768efe2012cc0ed1ac5 786f0eae0673bc18a6e2a71323c70af671e46e66 1a89eaeabd31dddfbad037e8109431a924632543 commit 6c0e752093ddedca0a6f0063567aff19997bab03 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Thu Aug 8 09:23:50 2013 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Aug 8 09:23:50 2013 +0100 wrong .ui name Change-Id: Ieb10eedd791aab6ea251c3fd33d74a2232e2bd6b @Luboš, is your commit relevant?
The bibisect result is certainly not unique. Some wisdom here bug 77964 comment 16
Looking at again.. this feels bit like more or less 'bad luck' on export. The fundamental issue is position of anchors etc. Bug 135849 is based on this (slightly modified), but illustrates similar issues when moving. Only thing out loud.. possibility to prevent this would be emulating a page break presence. Image are far less likely to jump around to different pages (but not sure what the over all effect would be related to the whole text flow concept
I didn't check this bug but I remove bibisectRequest and set bibisected per c5.
Marking as duplicate of NOTABUG 124059, because it has the same characteristics of depending on the same "enough space to wrap", and since LO and Word natively have different ideas about this you can't always go cleanly from one format to another. MS Word opens this DOCX in roughly the same way, so this is only an export bug - which I claim is invalid due to format limitations. *** This bug has been marked as a duplicate of bug 124059 ***