Bug 162091 - DOCX LAYOUT: Incorrectly positioned image - relative to second column
Summary: DOCX LAYOUT: Incorrectly positioned image - relative to second column
Status: RESOLVED FIXED
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: bisected, filter:docx
Depends on:
Blocks: DOCX-Images DOCX-Section
  Show dependency treegraph
 
Reported: 2024-07-18 16:18 UTC by m.pullan
Modified: 2025-08-26 15:39 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip file containing the word document exhibiting the issue and some expanatory screen shots (754.27 KB, application/x-zip-compressed)
2024-07-18 16:18 UTC, m.pullan
Details
667_Word2010.pdf: how it looks in Word 2010 - same as reported for LO (1.74 KB, application/pdf)
2025-08-26 15:14 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description m.pullan 2024-07-18 16:18:07 UTC
Created attachment 195379 [details]
Zip file containing the word document exhibiting the issue and some expanatory screen shots

After extracting the attached zip file you should find the following files:

1) 667.docx - the actual word document that exhibits the issue.
2) anchor.png - a screen shot showing the position of the anchor when the image is selected.
3) word.png - a screen shot showing the expected layout as presented when the document is opened in MS Word

When viewing the attached word document the image in the document showing a map for Apocopis paleaceus is incorrectly positioned. Just to clarify, this is the first map image in the document 667.docx.

As can be seen in the image anchor.png the anchor point appears in the correct/expected position but the image itself appears to bear no relationship to the position of the anchor. 

All other images in the document appear to be correctly positioned bit they are all laid out in the leftmost column, so perhaps it is an issue arising when the image location flows into the the second column.
Comment 1 Dieter 2024-08-12 11:32:29 UTC
m.pullan, thank You for reporting the bug. I can see the problem when opening the document, but I have two further questions:
Which version of LO you are using (please copy and paste information from Help -> About Libreoffice)?
Is the document created in MS Office or in LO? If it is created in LO please also attach the original odt-file. Thank you
=> NEEDINFO
Comment 2 m.pullan 2024-08-13 09:22:57 UTC
The bug was initially apparent in a very old version of Libre office 7.0.6.2. Obviously I considered that this may be the root of the issue so I updated to the latest release version and the issue was still apparent. 

I have updated the version field in the report form - it now indicates 24.2.5.2.

The document was self generated - i.e. from neither Word or LibreOffice using the Microsoft XML schema documentation as a guide. While I am willing to accept that this may be part of the problem the fact that the document is laid out correctly in Word nevertheless suggests that there is some kind of issue. Either there is a layout issue in Libre Office or Word is better able to compensate for some error in the document structure on my part.

Thanks for takin a look at this.
Comment 3 Dieter 2024-08-14 09:48:02 UTC
Thnak you for further information.

I confirm it with

Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL threaded

Steps:
1. Open file 667.docx from attachment 195379 [details] and have a look at page 2
Comment 4 Justin L 2025-08-26 15:14:10 UTC
Created attachment 202524 [details]
667_Word2010.pdf: how it looks in Word 2010 - same as reported for LO

This is a compatibilityMode 15 document - modified by Office 2013 or higher.

I noticed that in LO the layout was not completely stable. Sometimes it would load with a bit of a page break, and then the image was "properly" placed at the column margin.

This document (667.docx) is properly laid out in LO 25.2.4 after mk's
    tdf#165094: do not skip empty page because of wrong page descriptor
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185751
Comment 5 Justin L 2025-08-26 15:39:33 UTC
Historically, the indicated image was placed OK (e.g. LO 3.6.7). It was badly affected in LO 6.4.0.1 by 7.0 commit 08f13ab85b5c65b5dc8adfa15918fb3e426fcc3c
Author: Michael Stahl on Mon Dec 16 12:58:46 2019 +0100
    tdf#112202 writerfilter,sw: fix loss of headers
    
    * For continuous section breaks, WW8 import filter has a heuristic to
      find the first page break in the section and set the PageDescName
      property on that node to apply the page style with the headers of the
      new section; do something similar in writerfilter
      SectionPropertyMap::CloseSectionGroup()

    Reviewed-on: https://gerrit.libreoffice.org/85213

Both the break and the fix sound like LAYOUT side effects.