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)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:doc, filter:docx, regression
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
 
Reported: 2020-06-04 18:10 UTC by claffer
Modified: 2021-04-30 07:40 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Word document containing scanned images (1.89 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-04 18:11 UTC, claffer
Details
Word DOCX compared MSO LO (578.96 KB, image/png)
2020-06-09 08:00 UTC, Timur
Details
Word DOC (2.04 MB, application/msword)
2020-06-09 08:03 UTC, Timur
Details
Minimized example file (364.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-12-01 15:23 UTC, NISZ LibreOffice Team
Details

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
Description:
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 6.4.4.2 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
2.
3.

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.

Version: 6.4.4.2
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: 7.2.0.0.alpha0+ (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:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=15d821aa366265f86fda4484574e598b5744d23b

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