<div dir="ltr">Thanks Robin.<div><br></div><div>The existing settings that Lennart Regebro added actually support preferring either type of split:<div><br></div><div>- splitByRow=1, splitInRow=0 (or omitted): try by-row split, don't try in-row</div><div>- splitByRow=1, splitInRow=1: try by-row split first; if that fails, try in-row split</div><div>- splitByRow=0, splitInRow=1: try in-row split first; if that fails, try by-row split.</div></div><div><br></div><div>It's a little hard to see that from the implementation of Table.split, though!</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Nov 27, 2025 at 6:26 AM Robin Becker <<a href="mailto:robin@reportlab.com">robin@reportlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Yoshua,</div><div>the current code seems to refer byRow splits and I am unsure if in row is to be preferred. If a printer was doing it then the look and overall size requirement would be used to select the split.</div><div><br></div><div>For now I will leave the rowsplit try first.even though it can lead to the overflowing row being pushed to the next page. It seems fairly obvious that in row can use less overall space though.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Nov 2025 at 17:52, Yoshua Wakeham <yosh@atticus.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Robin!<div><br></div><div>Thanks for letting me know about the UseUpSpace() flowable, I hadn't seen that before. I'm not surprised to hear that manually inserting a page break is not the best approach! :)</div><div><br></div><div>It's true that prioritising an in-row split over a by-row split can largely avoid this problem. That said, I agree it's not obvious which split should be preferred in many cases. I think it makes sense to preserve the existing config options, which allow the user to prioritise whichever kind of split they prefer.</div><div><br></div><div>Also, I did encounter a case (which I haven't since been able to reproduce) where the bug surfaced even when prioritising in-row splits. An in-row split initially failed as the leftover content was less than the minimum height, then by-row split succeeded, then the insertion of the header row pushed down the postponed content, which allowed the previously-failing in-row split to succeed! Definitely an edge case, and as I say not one I've so far been able to minimally reproduce, but another point in favour of inserting UseUpSpace(), I would say.</div><div><br></div><div>Best,</div><div>Yosh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 26, 2025 at 6:14 AM Robin Becker <<a href="mailto:robin@reportlab.com" target="_blank">robin@reportlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Yoshua,</div><div>I did some more (over) thinking and it seems to me that the problem is that when split by row and split in row are bothe supported that we try split by row first. The first two rows can be split off and that leaves enough space tfor the table to be place on the remaining space.Because the header is repeated you get the header again on the same fra,e/page which is obviously wrong. However, if split in row had been tried most of the large row would appear in the split part 1. The would make the outcome look like the first attached attached, we might still need to fix any oustanding space, but it's not clear which split is actually best</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Nov 2025 at 09:30, Robin Becker <<a href="mailto:robin@reportlab.com" target="_blank">robin@reportlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Yoshua,</div><div><br></div><div>I tried your patch and it does work, but I think it's better to use [part1, UseUpSPace(), part2} instead of [part1, PageBreak(), part2}.</div><div><br></div><div>I will visually try the modified code against all the tests.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 25 Nov 2025 at 12:50, Robin Becker <<a href="mailto:robin@reportlab.com" target="_blank">robin@reportlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Yoshua,</div><div><br></div><div>you really like splitting rows. It's something of a problem for reportlab as it's just grafted on to the old table code and much harder than the non row splitting case.</div><div><br></div><div>Clearly finding a suitable split point across multiple columns is harrer than splitting by rows. </div><div><br></div><div>Assuming that the problem is that a row split may leave space behind I guess that the problem is that we should just fill that space and leave the layout to the higher levels.</div><div><br></div><div>Certainly just using a PageBreak is not right as it will cause problems for the higher level eg we might want a frame break or be inside one of the other container layouts.</div><div><br></div><div>I'll take a look at the example and see if the fix can just use up the space.</div><div><br></div><div>Thanks for the contribution . If only we had infinitely long pages :(</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Nov 2025 at 22:53, Yoshua Wakeham via reportlab-users <<a href="mailto:reportlab-users@lists2.reportlab.com" target="_blank">reportlab-users@lists2.reportlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<br><br>I've found a bug in table-splitting code that can occur when all of `splitByRow`, `splitInRow`, and `repeatRows` are non-zero. Namely, a between-row split immediately followed by a within-row split can cause header/repeated rows to be drawn in the middle of a page/frame.<br>Suppose a table T is too tall to fit in a frame, so `T.split()` is called. When `splitByRow=1` and `splitInRow>1`, we attempt a between-row split before checking whether a within-row split would have succeeded. Suppose the between-row split succeeds, splitting the table into T1 and T2.<br><br>Notably, the repeated rows specified by `repeatRows` will then be inserted at the start of T2, before `T.split()` returns `[T1, T2]`.<br><br>It seems that reportlab then tries to fit T2 into the space that remains in the frame after T1 is accounted for. Since we know the first row of T2 is too big to fit in that space, the between-row split fails, and instead we try a within-row split. If that succeeds, it exposes the bug – because the repeated header rows will be drawn in the middle of the frame, along with the top half of the newly-split row!<br><br>I've confirmed this is reproducible in version 4.4.4.<br><br>I'm attaching a minimal reproducible example. The output frames look like this on v4.4.4:<div><img src="cid:ii_midqq7mb2" alt="CleanShot 2025-11-13 at 14.24.08@2x.jpg" width="542" height="158"><br></div><div><img src="cid:ii_midqqjer3" alt="CleanShot 2025-11-13 at 14.24.21@2x.jpg" width="542" height="143"><br></div><div><br></div>I'm not sure how best to fix this, but for the sake of argument, I've attached a patch that simply inserts a `PageBreak()` between the two returned tables (as long as the successful split was between rows). That ensures that the between-row split has the intended effect, and no content can "sneak" back onto the page. With my patch applied, the output looks like what we would expect:<div><br></div><div><img src="cid:ii_midqr4ev4" alt="CleanShot 2025-11-13 at 14.29.58@2x.jpg" width="542" height="134"><br></div><div><img src="cid:ii_midqrgby5" alt="CleanShot 2025-11-13 at 14.30.11@2x.jpg" width="542" height="141"></div><div><div>If there's another approach that would make more sense, I'd be happy to put time into fixing this.</div><div><br></div><div>Thanks so much!</div><div>Yosh</div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><b style="color:rgb(34,34,34)">Yoshua Wakeham</b><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">Senior Software Developer</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">yosh@atticus.tech</span></div></div></div>
_______________________________________________<br>
reportlab-users mailing list<br>
<a href="mailto:reportlab-users@lists2.reportlab.com" target="_blank">reportlab-users@lists2.reportlab.com</a><br>
<a href="https://pairlist2.pair.net/mailman/listinfo/reportlab-users" rel="noreferrer" target="_blank">https://pairlist2.pair.net/mailman/listinfo/reportlab-users</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Robin Becker<br></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Robin Becker<br></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Robin Becker<br></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Robin Becker<br></div>
</blockquote></div>