Bug 109218

Summary: Shapes misplaced when document with multiple shapes saved as .doc or .docx
Product: LibreOffice Reporter: mike.hall
Component: filters and storageAssignee: Attila Bakos (NISZ) <bakos.attilakaroly>
Status: VERIFIED DUPLICATE    
Severity: normal CC: ilmari.lauhakangas, kelemeng, libreoffice
Priority: medium Keywords: filter:docx
Version: 3.6.7.2 release   
Hardware: x86-64 (AMD64)   
OS: All   
See Also: https://bugs.documentfoundation.org/show_bug.cgi?id=128190
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 112793, 136358    
Attachments: multi-frame document
AnchorPositionBeforeAndAfterExport
TheSameSettingsBeforeAndAfterExport
AnotherSimpleExampleFile
The example file and its docx-version after manually fixing up its layout

Description mike.hall 2017-07-19 14:41:10 UTC
Created attachment 134738 [details]
multi-frame document

Document with multiple frames is scrambled when saved as .doc or .docx, works fine if kept as .odt - tested with 5.4.0.2

To reproduce:
Open attachment
Save as .doc or .docx
Close
Reopen

Observed behaviour:
The frames are significantly displaced
Text in one of the frames loses a newline

Expected behaviour:
The document reopens with the frames in their original positions and formatting unchanged

Bugs 55946, 61494 and 67318 seem to be related, but not quite the same.

This bug makes interworking with colleagues with MS Word extremely problematical.

Suspect that the bug is the same in other OS's, but not tested.
Comment 1 Buovjaga 2017-08-11 18:53:08 UTC
Repro.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: db17a874af37350b3270932175854ee674447bc1
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 11th 2017

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 2 QA Administrators 2018-10-02 02:52:10 UTC Comment hidden (obsolete)
Comment 3 Attila Bakos (NISZ) 2020-02-05 09:39:08 UTC
Created attachment 157659 [details]
AnchorPositionBeforeAndAfterExport

NOTE: As in this picture can be seen, on export, the anchors move to right and that is the reason why the frames misplaced. Behind this, the problem is that, in Writer there are four anchors: as char, at char, at paragraph, and at page. In OOXML (docx) there are the as char and at char and at page options are available. If the anchor type is at paragraph ( like in this situation ) the program will convert it to as char type (on export). In spite of in the user interface it shows as paragraph, the anchor will be on the character. That's why the whole stuff moves to right horizontally (because there is no character on the left side of the image due to wrap settings).
Comment 4 Attila Bakos (NISZ) 2020-02-05 09:41:03 UTC
Created attachment 157660 [details]
TheSameSettingsBeforeAndAfterExport
Comment 5 Attila Bakos (NISZ) 2020-02-05 09:42:57 UTC
Created attachment 157661 [details]
AnotherSimpleExampleFile
Comment 6 NISZ LibreOffice Team 2020-06-05 13:01:24 UTC
These are actually shape objects, not frames. Changing meta bug.
Comment 7 NISZ LibreOffice Team 2020-12-17 08:40:09 UTC
Created attachment 168251 [details]
The example file and its docx-version after manually fixing up its layout

After changing the horizontal positioning of the top right shapes from "Paragraph area" to "Left paragraph border" (and adjusting the amount back to its original 11 cm value - which is not read correctly back in this screenshot :() the layout seems to get fixed.

See bug #138782 about this.
Comment 8 Attila Bakos (NISZ) 2021-05-05 06:30:02 UTC

*** This bug has been marked as a duplicate of bug 138782 ***
Comment 9 Timur 2021-05-05 13:02:24 UTC
This was marked fixed for DOCX.
DOC has an issue of "Address Block" anchored to paragraph being changed to character, so it's position is changed.
But there are so many bugs on that, I will not report another one.
Comment 10 NISZ LibreOffice Team 2021-05-07 06:06:07 UTC
Verified in: 

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9df3aa7ea72d61462e430643f2a80906dce4e15b
CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: default; VCL: win
Locale: ug-CN (hu_HU); UI: hu-HU
Calc: threaded