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

[Yoshua Wakeham]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251124/72f88552/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/20251124/72f88552/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/20251124/72f88552/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/20251124/72f88552/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/20251124/72f88552/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro_split_repeatrows_bug.py
Type: text/x-python-script
Size: 1241 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251124/72f88552/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-explicit-page-breaks.patch
Type: application/octet-stream
Size: 1988 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20251124/72f88552/attachment-0001.obj>