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
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"/>
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.
Hello Justin L, Thank you for reporting the bug. I can't confirm that the bug is present in master. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26 CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_FI); UI: en-US Calc/Writer: threaded
confirmed still opening wrong in master.
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.
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.