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
Created attachment 161617 [details] Word document containing scanned images this document illustrates the issue described in the bug listing.
Please attach a screen clip, Word vs Writer, would be helpful...
(In reply to V Stuart Foote from comment #2) > Please attach a screen clip, Word vs Writer, would be helpful... Or never mind. Better to open the .docx in Word and then 'save-as' export to ODF .odt -- the document is corruptly formatted in OOXML with no hope of an ODF export or of filter import to LibreOffice. It needs correct structure. Would suggest a two column layout, with margins and controlled picture alignment.
Such bugs can't be "notourbugs". The document is DOCX; its reference render is as Word does. When we can't render it as Word does, we should assume our bug. The fact that Word has buggy export to ODF has nothing to do with the problem. Confirmed with Version: 7.1.0.0.alpha0+ (x64) Build ID: e848e95faa5cea1f258c9f97d99ffc91614e5a3b CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
(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?
(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.
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.
Created attachment 161787 [details] Word DOC DOC saved in MSO from DOCX
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
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.
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
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.
Based on my comment 12, I assume this is a duplicate of bug 112313