Bug 147360 - Fileopen DOCX: shapes in page 1 and 2 open frames overlapped on 2nd page in LO (same as DOC opens in MSO)
Summary: Fileopen DOCX: shapes in page 1 and 2 open frames overlapped on 2nd page in L...
Status: RESOLVED DUPLICATE of bug 146984
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: filter:docx
Depends on:
Blocks: DOCX-Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2022-02-10 22:30 UTC by Bill
Modified: 2023-03-16 13:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Sample DOCX (44.99 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-02-28 15:13 UTC, Timur
Sample compared in MSO and LO (109.46 KB, image/webp)
2022-02-28 15:25 UTC, Timur
Sample DOCX saved as DOC in MSO (60.00 KB, application/msword)
2022-02-28 15:26 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Bill 2022-02-10 22:30:03 UTC
A. background

Some 7 years ago, I catalogued about 240 specimens of a mineral collection. I did this on a windows-7 home box, using microsoft office word home and student 2010. Neither windows-7 nor microsoft office word 2010 are maintained any longer. I do also have microsoft office home and student 2016, but that, too, is no longer maintained. I recently installed LibreOffice on that windows box.

I also have a Linux Fedora-34 workstation. I have LibreOffice on this workstation.

I need to get all those 240ish catalogue forms properly converted to LibreOffice documents on my Fedora workstation.

B. problem

When I try to load any of those catalogue forms in LibreOffice, the document is not even close to being correctly formatted. Also, some of the original text does not show up.  Further “digging” shows the following...
1. The first page appears empty; what should be on the first page is on the second page, covering up what should be on the second page.
2. If I cut the in-front frames from the second page, and paste them onto the first page,
those frames are correctly placed on the first page.  But the content of the frames on both pages is incorrectly positioned well right of the proper place.  Clicking an anchor icon sometimes correctly shifts the frame contents to the proper place, but sometimes deletes the frame contents.
3. Frame borders are too thin and too light.
4. Fonts are changed, some to acceptable substitutes, some to different fonts that aren't even close in appearance.

C. example

Since these files are huge, I put them on the google drive rather than attaching them to this bug.

file “specimen label 239”
(this is one of the actual catalogue forms)

file “MSOffice2010_capture.JPG”
(this shows how the catalogue form appears in microsoft office 2010 word)

file “MSOffice2016_capture.JPG”
(this shows how the catalogue form appears in microsoft office 2016 word)

file “LOwriter_capture.JPG”
(this shows how the catalogue form appears in LibreOffice writer)

D. version information

(source box)

windows 7 home premium service pack 1

Microsoft Office Home and Student 2010
version 14.0.7268.5000 (32-bit)

Microsoft Office Home and Student 2016
version 2002 (build 12527.22079 click-to-run)
microsoft word 2016 MSO (16.0.12527,22086) 32-bit

LibreOffice version information (on the windows-7 box):
Version: (x64) / LibreOffice Community

(target workstation)

Fedora 34 (last updated February 10, 2022)

LibreOffice Version:
Build ID: 10(Build:1)
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded

Steps to Reproduce:
See the "description" above.

Actual Results:
(see the "desacription" above.

Expected Results:
LibreOffice Writer should look just about identical to how it appeared in miscrosoft office write.

2. When I click an anchor icon, a frame's contents should move to its correct location, not disappear.

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:
Build ID: 10(Build:1)
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded
Comment 1 Bill 2022-02-16 19:46:50 UTC
Since submitting this bug, I've tried resetting my user profile, both on my Linux workstation and on my windows-7 box.  It made no difference.  I don't see a way of changing that checkbox here in bugzilla.

In the original description, part B,
* the frame behavior is the same in both operating systems.
* I experience the frame content shift i=on the Linux workstation only.
Comment 2 [REDACTED] 2022-02-25 07:52:58 UTC
Confirmed in Version: / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

I also hear a lot about problems with text boxes in MS Word that get badly imported into Writer, because text boxes in Word and Writer are very different (Apache OpenOffice forum, Ask LibreOffice).
Comment 3 Timur 2022-02-28 15:13:23 UTC
Created attachment 178581 [details]
Sample DOCX

Sample DOCX should be attached. It's here. Same look if resaved in MSO.
Comment 4 Timur 2022-02-28 15:25:33 UTC
Created attachment 178582 [details]
Sample compared in MSO and LO

As seen in screenshot, MSO opens shapes on pages 1 and 2 and LO opens frames only on page 2. 
Never was OK, empty pages in OO, 1 page in LO 4.0, 4.2 and 7.4+ similar. 
Could be a duplicate, but not easy to find.
Comment 5 Timur 2022-02-28 15:26:25 UTC
Created attachment 178583 [details]
Sample DOCX saved as DOC in MSO

Let's keep here also DOC saved in MSO.
Comment 6 Justin L 2023-03-15 16:02:18 UTC
DOCX is fixed in 7.6. (Likely one of my recent patches.) I'll leave it open until bibisect catches up and I can confirm exactly which commit it was.
Comment 7 Justin L 2023-03-16 13:22:05 UTC
fix by commit 828fde37632a5bb0542b6925454690a5287d6490
Author: Justin Luth on Tue Mar 14 14:20:58 2023 -0400
    tdf#153613 tdf#146984 writerfilter: split para after anchors

*** This bug has been marked as a duplicate of bug 146984 ***