Created attachment 197951 [details] fdo74763-1.docx_mso.pdf: how it looks in Word 2019 Opening bug 74763's _ResourceRepository_1000212_130335157858319525_G3-M4-D-Lesson 15(1).docx (attachment 93726 [details]) used to be 11 pages long, now it is 14. Starting at page 10, we now have several empty-looking pages instead of a single page "floor plan" table. This started in 25.2 with commit 4f5b896d004af023f210f235aeafa9abc50068d2 Author: Oliver Specht on Thu Jun 27 08:57:43 2024 +0200 tdf#155229 Calculate row height incl. border if 'atLeast' is set CC: Oliver I suspect this change just exposes something else, so not flagging Oliver as the regressionist. (I spot checked 5.3, 6.3, 7.3, 7.5 and this table looked basically OK in all of them.)
Confirmed in LO Version: 25.2.0.0.alpha0+ (3746195ff989a4596afc456d53010d8860bd7b64) / Windows.
Reproducible. Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: dd1870369618b2f1fcc7faa9c8e217e556e56c1a CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Not reproducible. Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This looks like "just" a layout issue. When trying to create a minimal version, things get "fixed" if I delete headers, or footers, or the floating table on the previous page.
Created attachment 198046 [details] 164188_minimal.docx: seems to be related to the TextSection, and MoveBwd There are several pieces at play here it seems. First, on page 1, there is some text that gets wrapped below the floating frame. (if that text is removed, or if a page break is introduced, then the problem is not seen). Second, if the section (TextSection) is removed, then the full table is painted. The problem is related to the text section not being considered to be tall enough, and thus not all of the table is painted. However, that doesn't seem to explain the multiple empty pages currently seen...
Using comment 4's minimal example, I get a different bibisect result: 7.6's commit ce3308a926f036b87515b8cd97d2b197063dc77a Author: Miklos Vajna on Wed Apr 12 08:13:07 2023 +0200 tdf#61594 sw floattable: import floating tables as split flys by default Again, likely not a regression, but just exposing a problem. I assume that the text section ought to grow by the size of the header/footer that it now spans?
One typical problem is that floating tables didn't try to split in the past, now this is attempted, but cases like in-header anchor or in-fly anchor should be an exception: if the floating table doesn't fit a header, nothing is solved by trying to split it, since the next page will have the same header. I'm not sure if that's the problem here, but that's a first thought.
(In reply to Miklos Vajna from comment #6) > in-header anchor or in-fly anchor should be an exception Neither of these apply. It is a simple floating table just before a new section. No repeating headers or anything fancy like that either. In terms of layout (of comment 4's file of course), this seems to be what is happening: -the table has been given an arbitrary height and position (looks like a copy of the size from page 1 before the join) and then adds the entire height of the table, so that it exceeds the deadline (once it gets positioned correctly). That's fine, because it doesn't need nearly that much, so it eventually shrinks by 8152. However, the section frame was NOT allowed to grow past the deadline, and now SwLayoutFrame::ShrinkFrame tells GetUpper [the SwSectionFrame] to shrink by the same 8152 amount. Specifically, SwSectionFrame::Grow[9974], but only has room to grow [6736] because deadline[30373] limits growth from frameArea[9840x5309@(1084,18328)] 9974 + 5309 + 18328 == 33611 9974 - 6736 == 3238 == 33611 - 30373 Meanwhile the table 9840x9156@(1084,4953) at ::join time is told to grow [5030], and then it is repositioned at [9840x14186@(1084,18906) 9156 + 5030 == 14186 14186 + 18906 == 33092 which is over the deadline 30373. Since the table size is actually 6034, the height[14186] is reduced by [8152], and that causes the section height [5309 + 6736 == 12045] to be reduced down to[3893] - obviously not enough to hold a 6034 table plus some extra paragraphs.