[reportlab-users] Patch to support tables with oversize cells

[Lennart Regebro]

Hi, sorry for the delay in this, I was on vacation.

Splitting spanned cells turns out to be not easy at all. Well, the
splitting was no problem, it's dealing with the styles.

I believe I have found an edge case in Reportlab which I'm not sure if it's
intended or not, and fixing it will require quite a major refactoring, so I
would like your opinion on this. Basically, you can color a spanned cell
only partially in current Reportlab, but supporting splitting such a cell
leads to some weirdness.

If you set the background color only on the starting cell for a spanned
cell, then that whole cell will get that background color. But if you set a
background color on only some out of the rows, only that part of the cell
will get colored. If you then split that cell, then what parts of that
split cell are colored can change,

Fixing this would require calculating the colors or all cells before a
split, and then, when the table is drawn, not doing any such
"recalculation". But the first question is: Is this really supported? Is
that how it is supposed to work? That you can set partial background colors
on spanned cells?

Attaching PDF that demonstrates this. I accidentally overwrote the code
used to generate it, though. *facepalm*

//Lennart


On Wed, Apr 20, 2022 at 1:38 PM Lennart Regebro <lregebro at shoobx.com> wrote:

> Right, the current code first tries to split in the non-spanned rows, and
> fails (because they are only one line high and can't be split), and then it
> tries to splitByRow, but then the spanned row prevents that. In this case,
> since we have a span we could split that spanned row, and then do a
> splitByRow.
>
> I'll look into that, maybe it will be easy.
>
>
> On Wed, Apr 20, 2022 at 11:04 AM Robin Becker <robin at reportlab.com> wrote:
>
>> Hi Lennart,
>>
>> I did some investigation of the problems I saw in that last example (see
>> attached new version of the script useData==2).
>>
>> It seems that the real problem is that because of the spanned cell in
>> column 0 row 0 that in _splitRows @ 1565
>>
>> n=self._getFirstPossibleSplitRowPosition(availHeight)
>>
>> returns a value of 0 for the first possible split row position.
>>
>> Then at line 1633 we get
>>
>> n=0 usedHeights=0 cellvalues=['A\nB\nC\nD', 'BBBBB', 'C', 'D', 'E']
>> curRowHeight=18 minSplit=15.0 maxSplit=15.0
>> minSplit + maxSplit > curRowHeight=True
>> minSplit > (availHeight - usedHeights)=False
>>
>> I assume that because of the spanned rows we are just using the first
>> (n=0) row to work out the minSplit/maxSplit and
>> then the failure follows from the first test.
>>
>> 1) It's not obvious what n should be in the splitInRow row span case.
>> 2) It seems the splitInRow case requires us to consider far more than the
>> height of one row.
>> --
>> Robin Becker
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20220513/12d6a332/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_edgecase_1.pdf
Type: application/pdf
Size: 2898 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20220513/12d6a332/attachment.pdf>