[reportlab-users] Header appears mid-page due to splitByRow/splitInRow interaction

[Robin Becker]

Hi Yoshua,
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

On Wed, 26 Nov 2025 at 09:30, Robin Becker <robin at reportlab.com> wrote:

> Hi Yoshua,
>
> I tried your patch and it does work, but I think it's better to use
> [part1,  UseUpSPace(), part2}  instead of  [part1,  PageBreak(), part2}.
>
> I will visually try the modified code against all the tests.
>
> On Tue, 25 Nov 2025 at 12:50, Robin Becker <robin at reportlab.com> wrote:
>
>> Hi Yoshua,
>>
>> 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.
>>
>> Clearly finding a suitable split point across multiple columns is harrer
>> than splitting by rows.
>>
>> 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.
>>
>> 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.
>>
>> I'll take a look at the example and see if the fix can just use up the
>> space.
>>
>> Thanks for the contribution . If only we had infinitely  long pages :(
>>
>>
>>
>> On Mon, 24 Nov 2025 at 22:53, Yoshua Wakeham via reportlab-users <
>> reportlab-users at lists2.reportlab.com> wrote:
>>
>>> Hello,
>>>
>>> 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.
>>> 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.
>>>
>>> Notably, the repeated rows specified by `repeatRows` will then be
>>> inserted at the start of T2, before `T.split()` returns `[T1, T2]`.
>>>
>>> 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!
>>>
>>> I've confirmed this is reproducible in version 4.4.4.
>>>
>>> I'm attaching a minimal reproducible example. The output frames look
>>> like this on v4.4.4:
>>> [image: CleanShot 2025-11-13 at 14.24.08 at 2x.jpg]
>>> [image: CleanShot 2025-11-13 at 14.24.21 at 2x.jpg]
>>>
>>> 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:
>>>
>>> [image: CleanShot 2025-11-13 at 14.29.58 at 2x.jpg]
>>> [image: CleanShot 2025-11-13 at 14.30.11 at 2x.jpg]
>>> If there's another approach that would make more sense, I'd be happy to
>>> put time into fixing this.
>>>
>>> Thanks so much!
>>> Yosh
>>>
>>> --
>>> *Yoshua Wakeham*
>>> Senior Software Developer
>>> yosh at atticus.tech
>>> _______________________________________________
>>> reportlab-users mailing list
>>> reportlab-users at lists2.reportlab.com
>>> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>>>
>>
>>
>> --
>> Robin Becker
>>
>
>
> --
> Robin Becker
>


-- 
Robin Becker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CleanShot 2025-11-13 at 14.24.08 at 2x.jpg
Type: image/jpeg
Size: 19443 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CleanShot 2025-11-13 at 14.24.21 at 2x.jpg
Type: image/jpeg
Size: 16124 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CleanShot 2025-11-13 at 14.29.58 at 2x.jpg
Type: image/jpeg
Size: 16179 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CleanShot 2025-11-13 at 14.30.11 at 2x.jpg
Type: image/jpeg
Size: 16560 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inrow-first.pdf
Type: application/pdf
Size: 1713 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: byrow-first.pdf
Type: application/pdf
Size: 1709 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251126/679212c8/attachment-0003.pdf>