Bug 137590 - FILEOPEN DOCX Image in table incorrectly imported position
Summary: FILEOPEN DOCX Image in table incorrectly imported position
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Objects
  Show dependency treegraph
 
Reported: 2020-10-19 11:38 UTC by NISZ LibreOffice Team
Modified: 2023-11-13 12:57 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the original document side by side in Word and Writer 6.3 - good (395.96 KB, image/png)
2020-10-19 11:38 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer 7.1master (424.42 KB, image/png)
2020-10-19 11:38 UTC, NISZ LibreOffice Team
Details
Sample resaved in MSO as DOC (287.00 KB, application/msword)
2020-10-21 07:29 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-10-19 11:38:23 UTC
Created attachment 166500 [details]
Screenshot of the original document side by side in Word and Writer 6.3 - good

The attachment #48879 [details] from bug #39056 contains a table with some images on the second page, that are positioned horizontally to the column and vertically to the paragraph.
These settings were imported correctly in 6.3 but broke in 6.4, now the vertical alignment is -2.87 cm instead of 0.1. Wrap -> Spacing settings are also -1.64 cm top and bottom instead of 0.

Steps to reproduce:
    1. Open attachment #48879 [details]

Actual results:
Images on the right appear closer to the top of the page than in Word.

Expected results:
Same image position as in Word.

LibreOffice details:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: c064766901722082df0d759c95434c1460fcdba5
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

Also in:
Verzió: 6.4.0.3 (x86)
Build az.: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: alapértelmezett; VCL: win; 
Területi beállítások: en-US (hu_HU); Felület nyelve: hu-HU
Calc: CL

Not yet in:
Version: 6.3.0.4 (x86)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL

Additional Information: 

Bibisected using bibisect-win64-6.4 to:
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e042a83843ed2573dbce9338058b3dc545dd6898 

author
Miklos Vajna <vmiklos@collabora.com> Tue Oct 15 21:44:42 2019 +0200 

committer
Miklos Vajna <vmiklos@collabora.com> Wed Oct 16 08:20:37 2019 +0200 

writerfilter: sync layout-in-cell vs wrap-though behavior with ww8 import
Comment 1 NISZ LibreOffice Team 2020-10-19 11:38:42 UTC
Created attachment 166501 [details]
Screenshot of the original document side by side in Word and Writer 7.1master
Comment 2 Timur 2020-10-21 07:29:15 UTC
Created attachment 166567 [details]
Sample resaved in MSO as DOC

Repro. 
attachment #48879 [details] is 2007 DOCX, same if resaved in MSO (where "Layout in table cell" cannot be unchecked). 
Also similar issue with DOC. Except that image position in DOC wasn't good in 6.3.
Comment 3 Justin L 2021-11-12 05:28:21 UTC
repro 7.3+. Still looks like the screenshot in comment 1.

I'm assuming this has exposed some other deficiency in our import handling, or else in the way FollowTextFlow is implemented.
Comment 4 QA Administrators 2023-11-13 03:12:20 UTC Comment hidden (obsolete)
Comment 5 Regina Henschel 2023-11-13 12:57:31 UTC
The position is still wrong in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 50add2043752c7b07beccef9a509bea6c09619f8
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL threaded