[reportlab-users] Tons of table questions

[Dinu Gherman]

Andy Robinson:


> The non-linearity is as follows.  If you make a big table with,

> say, 1000 rows x 10 cols, and space for 40 rows on each page,

> and specify  no widths to help us, then we have to size every

> table cell - that's 10,000 objects. We then work out the optimal

> column widths for the present page.  We then say "OK, I can

> only fit about 40 rows on this page",  and we split it into a 40-

> row table and a 960-row table.

>

> Then, on the next page, we start again, this time sizing 9600

> cells.  But this page might have a different frame width, so we

> just dumbly start again and recalculate all those table cell sizes.


I see. Is there a reason to continue sizing cells in vain after
reaching a frame split?


> AFAIR the LongTable optimisation works by just looking at

> the first few rows to work out the column widths.


That seems to me the right thing to do, ideally until the
first split occurs.


> Smarter implementations are certainly possible but I would

> urge people to just create a bunch of smaller tables in the

> first place.  If you are outputting thousands of rows, you

> probably have some kind of grouping mechanism or want

> headers and footers anyway, and it's easiest to style things

> AND faster to render if you use a separate table for each visually

> similar slab of content.


Agreed, and I do use repeating a header (repeating footers do
not exist, if I'm not mistaken). But grouping sometimes is just
not an option.

Concatenated tables, as I described before, might be a work-
around, but then one would need to draw a header (if you need
one) only after a split, but not at the beginning of the table,
which is also not possible.

Dinu