[reportlab-users] Re: Problem with row&column spanning code not calculating table h eights

[Henning von Bargen]

Andy Robinson wrote:

> I will reiterate by the "real world" guidelines I always give
> to make sure you get reasonable tables in the month you need them.

> (1) work out and explicitly specify your widths
> (2) let it work out the heights, unless there is a good
> reason why it can't; if it can't, then provide some heights.
> (3) if doing big data sets which will span several pages,
> make lots of one-row or few-row tables and put them
> after each other in the story.  It's easier on your brain.
> 
> Best Regards,
> 
> Andy

According to (3), I can still offer my patch for tables.py
(in my own project I named the class "LongTable" instead of "Table")
that calculates only the necessary row-heights for the current page
and thus works in O(nRows) compared to the normal "Table" O(nRows^2) run
time.
Using this "LongTable" class (only a few lines changed comparing to "Table"
class)
would eliminate the need for (3) in real-world multi-page tables
and also allows using Paragraph instances for every cell value without
significant
performance issues.

I also made some modifications to paragraph.py which are more suitable for
tables.
1. When line-wrapping, try line-breaking not only at " " spaces,
    but on inner-word "-" characters, too.
2. When a word is too long to fit into one line and it does not contain any
"-",
    put as many characters as possible into the line and the rest into the
next line.

These modifications are valuable for the german language, where very long
words
are nothin unusual.

Try running some table layouts with data like
"supercalifragilisticexlialigetic"
or some German words like "Entwicklungshilfeministerium" etc., and you'll
see the difference.

Best regards,
Henning