Bug 117611 - Images anchored 'To Paragraph' in ODT are misplaced after saving as DOCX and anchored 'To Character'
Summary: Images anchored 'To Paragraph' in ODT are misplaced after saving as DOCX and ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:docx, regression
Depends on:
Blocks: Anchor-and-Text-Wrap DOCX-Images
  Show dependency treegraph
 
Reported: 2018-05-14 14:41 UTC by Yauhen Kharuzhy
Modified: 2022-09-09 00:30 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample file (915.94 KB, application/vnd.oasis.opendocument.text)
2018-05-14 14:42 UTC, Yauhen Kharuzhy
Details
Screenshot of page with misplaced images after converting to DOCX (480.15 KB, image/png)
2018-05-14 14:43 UTC, Yauhen Kharuzhy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yauhen Kharuzhy 2018-05-14 14:41:43 UTC
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
Comment 1 Yauhen Kharuzhy 2018-05-14 14:42:37 UTC
Created attachment 142093 [details]
Sample file
Comment 2 Yauhen Kharuzhy 2018-05-14 14:43:55 UTC
Created attachment 142094 [details]
Screenshot of page with misplaced images after converting to DOCX
Comment 3 raal 2018-05-14 16:25:20 UTC
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;
Comment 4 Telesto 2020-08-17 15:33:31 UTC Comment hidden (obsolete)
Comment 5 raal 2020-08-17 16:25:48 UTC
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?
Comment 6 Telesto 2020-08-17 16:54:55 UTC
The bibisect result is certainly not unique. Some wisdom here bug 77964 comment 16
Comment 7 Telesto 2020-08-17 17:18:28 UTC
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
Comment 8 Timur 2020-09-30 09:15:25 UTC
I didn't check this bug but I remove bibisectRequest and set bibisected per c5.