[reportlab-users] Table cell too large vertically

[Andy Robinson]

Blake, we agree totally that it SHOULD be fixed, we just haven't been
able to do it in about 12 years.   If you can crack it in 2-4 hours,
even after a week of familiarisation with the code, we would be
delighted to hire you to do it and you could pretty much name your
hourly rate ;-)

The ReportLab library does no backtracking.  It can't say "that did
not work, I'll back up and try again".  This was a design decision to
get decent speed out of a large Python object model.  Splitting works
by returning two table objects, one to go on this page and one for the
next, with suitably modified styles for the "next page" table.   It
also has to handle horizontal and vertical column spanning, the fact
that a table cell can contain anything (including more tables, with
padding around them), some cells having defined width and some being
flexible.   If you split one cell you then have to figure out, for
each cell alongside it (some of which may span rows) how much of their
content must go on the first page or second page.

We looked at the algorithms used to do table layout in browsers and
they are not simple (and require C+-like speeds and multiple tries at
things), and they don't even handle splitting.

Now it may well be that a split could be possible in the special case
that there was no spanning alongside.

As for a better workaround:  If your table content is just text, and
you know the width, you can work out the size of a paragraph quite
easily and accurately by calling wrap() and passing in the width and a
larger-than-needed height; it will reply with the width and heigh it
actually needs.   So you could pre-scan all your content and break
into smaller chunks before building rh table.  Ugly, but could be
quite accurate and would not complicate rendering.

- Andy

On 22 March 2016 at 19:55, Blake McBride <blake1024 at gmail.com> wrote:
> Yes, with multiple columns it is a little more complex.  But, this is a
> serious problem, and must be handled at the reportlab level if it is to be
> handled correctly.  I'd think for someone familiar with the code this could
> be a two or four hour project.  Well worth the effort to solve a fundamental
> issue.  Just my 2 cents...
>
> As it is, I guesstimated the max length and split large rows into multiple
> rows.  It is an ugly solution but allows me to move forward.
>
> Thanks.
>
> Blake McBride
>
>
>
> On Tue, Mar 22, 2016 at 1:27 PM, Tim Roberts <timr at probo.com> wrote:
>>
>> Blake McBride wrote:
>> >
>> > Having written several report generators over the years, I think the
>> > algorithm should be:
>> >
>> > if row is too big for an entire page
>> >     while more text
>> >         print as much as you can on the current page
>> >         reduce text by what was printed
>> >         page break
>> > else if row is too big for the current page (but small enough for a
>> > new page)
>> >     page break
>> >     print row
>> > else
>> >     print row
>>
>> But remember, that's easier said than done.  You might have word wrap in
>> every cell going across.  For this to work, you would have to be doing
>> that word wrapping on every cell in parallel.  When one cell detects
>> that it's about to exceed the page, you'd need to send a signal to all
>> of the other cells telling them to fill out as much as they can, then
>> pause until after the page break, then resume.  And what about paragraph
>> widow control?  That requires backtracking.
>>
>> There's a lot of state to carry around.
>>
>> --
>> Tim Roberts, timr at probo.com
>> Providenza & Boekelheide, Inc.
>>
>> _______________________________________________
>> reportlab-users mailing list
>> reportlab-users at lists2.reportlab.com
>> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>
>
>
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>