Bug 165068 - LAYOUT: Floating image misplaced somehow by a following floating table (specific document)
Summary: LAYOUT: Floating image misplaced somehow by a following floating table (speci...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: DOCX-Floatingtable
  Show dependency treegraph
 
Reported: 2025-02-05 22:30 UTC by Justin L
Modified: 2025-07-08 11:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
tdf94598-6.docx_mso.pdf: how it looks in Word 2019 (318.34 KB, application/pdf)
2025-02-05 22:30 UTC, Justin L
Details
Claims_good.docx: The good round-tripped file, with xmllint --format document.xml (295.58 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-02-10 21:33 UTC, Justin L
Details
Claims_bad.docx: The bad round-tripped file, with bookmark removed (295.54 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-02-10 21:35 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2025-02-05 22:30:39 UTC
Created attachment 199007 [details]
tdf94598-6.docx_mso.pdf: how it looks in Word 2019

The image at the top of the page (defined well before any tables are seen) has been pushed to the bottom of the page.

I'm not sure what is going on here, so not marking as a regression. If I round-trip the file first (I'm using Word 2010), then it opens OK in LibreOffice.

It was opening fine until 7.6 commit ce3308a926f036b87515b8cd97d2b197063dc77a
Author: Miklos Vajna on Wed Apr 12 08:13:07 2023
    tdf#61594 sw floattable: import floating tables as split flys by default

Steps to reproduce
1.) open Claims Form - Motor Vehicle Accident Report Form - Mar17-1.docx (attachment 134965 [details] from bug 94598)

Notice that the top of the page is filled with empty paragraphs. This area should be covered by the picture that you see at the bottom of the page.

If I select the second empty paragraph, I notice that the picture is selected as well - confirming that it is anchored there. If I delete the selected second paragraph and then undo, then the image is now laid out properly.

Found by Collabora's. mso-test
Comment 1 Justin L 2025-02-10 21:33:05 UTC
Created attachment 199122 [details]
Claims_good.docx: The good round-tripped file, with xmllint --format document.xml

(In reply to Justin L from comment #0)
> I'm not sure what is going on here, so not marking as a regression. If I
> round-trip the file first (I'm using Word 2010), then it opens OK
This has almost certainly exposed some strange layout bug. Using this "always good" document, I can make it an "always bad" layout by just removing
    <w:bookmarkStart w:id="0" w:name="_GoBack"/>
    <w:bookmarkEnd w:id="0"/>
Comment 2 Justin L 2025-02-10 21:35:03 UTC
Created attachment 199123 [details]
Claims_bad.docx: The bad round-tripped file, with bookmark removed

The only difference between the good and bad version is hand-removal of the mentioned bookmark before re-zipping it.
Comment 3 mikhail.machine 2025-02-11 07:41:18 UTC Comment hidden (no-value)
Comment 4 Justin L 2025-02-22 20:00:37 UTC
confirmed still opening wrong in master.
Comment 5 Timur 2025-07-07 19:01:56 UTC
Bisected is commit which enabled floating, but forcing it before this started from: 

commit d477fa8ac1b0d3ee81427217bbb5950278ab16db	[log]
author	Miklos Vajna <vmiklos@collabora.com>	Fri Mar 17 14:00:17 2023 +0100
committer	Miklos Vajna <vmiklos@collabora.com>	Fri Mar 17 14:10:34 2023 
sw floattable: unconditionally map <w:tblpPr> to SwFormatFlySplit

CppunitTest_sw_ooxmlexport8's testN816593 failed in the
SW_FORCE_FLY_SPLIT=1 case because the re-import of the document merged
two tables into one.
The problem starts earlier, we didn't import the table with a <w:tblpPr>
as a floating table, but we should.
Comment 6 Timur 2025-07-08 11:23:33 UTC
For me this was fixed in 25.8 with :

commit b3e1d66d944106bef177a01f7d180ed507c9716c	[log]
author	Justin Luth <jluth@mail.com>	Tue May 06 12:15:59 2025 -0400
committer	Justin Luth <jluth@mail.com>	Tue May 06 23:41:09 2025 +0200
tdf#166474 revert tdf#164907 sw: Calculate row height ... #2

This reverts 25.8 commit e9ed6f1d2cc145e7514bf0a27b8c77f370ceab2d
(backported to 25.2.2).

It turns out that Oliver's 25.2 commit was correct after all, and that "other factors" were coming into play that had confused the issue.

I found this by doing an mso-test against my commits for tdf#164907 and tdf#165492. I noticed that the improvements for DOC files seemed to only be half-improved.
I hadn't clued in to that while going through DOCX files, but afterwards I revisited them and then could see a similar need.