Bug 133680 - Fileopen DOCX or DOC: Some images are stacked (negative or absolute position?)
Summary: Fileopen DOCX or DOC: Some images are stacked (negative or absolute position?)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:doc, filter:docx
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
Reported: 2020-06-04 18:10 UTC by claffer
Modified: 2023-05-11 16:01 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Word document containing scanned images (1.89 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-04 18:11 UTC, claffer
Word DOCX compared MSO LO (578.96 KB, image/png)
2020-06-09 08:00 UTC, Timur
Word DOC (2.04 MB, application/msword)
2020-06-09 08:03 UTC, Timur
Minimized example file (364.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-12-01 15:23 UTC, NISZ LibreOffice Team
kensukes_kingdom-MIN2.docx: with LayoutInTable setting removed (364.47 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-12-01 13:16 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description claffer 2020-06-04 18:10:07 UTC
the document has 8 pages each of which shows 2 distinct image scans per page

On Word for Office 365 MSO (16.0.12624.20348) 64 bit edition on Windows 10 they render correctly. On Libreoffice Writer running on Linux Mint 19.3 Cinnamon, the rendering shows scans stacked on top of one another.

Steps to Reproduce:
1.double click document to open it

Actual Results:
the issue is obvious in that the scans are clearly stacked on to pof each other

Expected Results:
it should show the scans two per page

Reproducible: Always

User Profile Reset: Yes

Additional Info:
Compare the document rendering between Libreoffice Writer on Mint versus Office Word on Windows 10 and the ence should be clearly evident.

Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 claffer 2020-06-04 18:11:52 UTC
Created attachment 161617 [details]
Word document containing scanned images

this document illustrates the issue described in the bug listing.
Comment 2 V Stuart Foote 2020-06-04 18:43:34 UTC Comment hidden (obsolete)
Comment 3 V Stuart Foote 2020-06-04 19:28:29 UTC Comment hidden (obsolete)
Comment 4 Mike Kaganski 2020-06-05 06:49:57 UTC Comment hidden (obsolete)
Comment 5 V Stuart Foote 2020-06-05 14:27:44 UTC
(In reply to Mike Kaganski from comment #4)

Wait, the OOXML .docx is bogus--it does not render correctly/consistently in Word (2016) or Word 365--the inserted pictures jump all over the pages--why should we be burdened with attempting to parse out an ODF filter import from a clearly malformed document?
Comment 6 Mike Kaganski 2020-06-05 14:39:17 UTC
(In reply to V Stuart Foote from comment #5)
> Wait, the OOXML .docx is bogus--it does not render correctly/consistently in
> Word (2016) or Word 365--the inserted pictures jump all over the pages

Oh do they? I had only opened the document in Word 2016 and scrolled down and up, and it looked like it didn't jump (although their positioning was inconsistent - meaning the images on one page were in different coordinates wrt counterparts on another page; but then the images likely were put by hand...?). Is there a howto to see the jmping?

> --why should we be burdened with attempting to parse out an ODF filter import
> from a clearly malformed document?

Of course, if I overlooked that, it's OK to not try to "fix" what doesn't work in Word - please close it again, but please don't forget to mention how to repro the jumping in Word, to justify the decision. Sorry for the noise.
Comment 7 Timur 2020-06-09 08:00:32 UTC
Created attachment 161786 [details]
Word DOCX compared MSO LO

This is old DOCX but regardless, same if resaved in MSO.
MSO 2016 8 pages with 16 images, LO 7.1+ 6 pages. Previous LO 5.0 14 pages, OO 6 pages stacked.

Only some images are wrong: 3, 4, 11, 12. 
Could be issue with negative or absolute image position.
Has "Layout in table cell" but no change if turned off.
If "Allow overlap" is turned off in DOCX, MSO opens 14 pages and LO remains with 6.

If DOCX is saved in MSO as DOC, it opens with 9 pages (one empty).
Normally this shows that document is troublesome. 

Note: this is so wrongly created document...scanned booklet images put in DOCX... PDF is better used for that.
Comment 8 Timur 2020-06-09 08:03:51 UTC
Created attachment 161787 [details]
Word DOC

DOC saved in MSO from DOCX
Comment 9 NISZ LibreOffice Team 2020-12-01 15:23:26 UTC
Created attachment 167722 [details]
Minimized example file

Only 3 pages, still a problem with:

Version: (x64)
Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL
Comment 10 NISZ LibreOffice Team 2020-12-01 15:32:10 UTC
This seems to have started in 5.3. 
Before the minimized example document opened starting with an empty page, but after that the three images were on two pages like in Word.
Comment 11 NISZ LibreOffice Team 2020-12-01 16:03:02 UTC
Seems to have started with:


author	Tamás Zolnai <tamas.zolnai@collabora.com>	2016-12-20 17:14:58 +0000
committer	Tamás Zolnai <tamas.zolnai@collabora.com>	2016-12-21 11:40:49 +0000

tdf#96218: MSO DOCX image incorrectly placed when using Alignment Position

Adding CC to: Tamas Zolnai
Comment 12 Justin L 2021-12-01 13:16:41 UTC
Created attachment 176626 [details]
kensukes_kingdom-MIN2.docx: with LayoutInTable setting removed

Since there is no table involved, I'd say it was just coincidence that things looked better before.

I removed the LayoutInTable setting and that lets us bibisect further back. It already had overlapping pages in LO 3.5, but the way they overlapped changed in LO4.0

A short 2-page list of changes: https://cgit.freedesktop.org/libreoffice/core/log/?id=15d821aa366265f86fda4484574e598b5744d23b&qt=range&q=179a6db61ee30cf776747802f06edeef45fec461..5f91f8a368343d8921a01edb7359cd300892f09d

That probably isn't very helpful though.

I did notice that in MS Word, all the paragraph markers show up on the second page, while in LO they all show up on the first page. In other words, Word seems to consider that there isn't enough space to wrap the text in this situation, while LO does think it has enough space.
Comment 13 Justin L 2023-05-11 16:01:15 UTC
Based on my comment 12, I assume this is a duplicate of bug 112313