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

[Lennart Regebro]

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/20220420/9754ef53/attachment.htm>