[reportlab-users] long tables
Andy Robinson
reportlab-users@reportlab.com
Mon, 14 Apr 2003 17:24:37 +0100
> Then the calc() function could just stop as soon as the
> computed height
> for the first m rows is greater than availHeight.
> It could then return the height computed so far
> and maybe set a flag stating that even more rows follow.
> With this solution, the size calculation would occur only
> once for each row.
>
> Just an idea. Has anyone tried it? Could it cause trouble?
>
That's exactly what I wanted to do all along, but never
got around to. Feel free to try :-)
There are 2 headaches at present we should think about.
(1) the frame used on page 2 may not be the same size as
the one used on page 1 and so on. So you could cache the
sizing info for the table, but would have to recheck that
page 2 was flowing into a frame of the same size before
reusing it. (IMHO we should size enough stuff to figure
out the stuff for the current page, then not calculate
the rest of the cells, as it sidesteps this).
(2) we have a basic problem with paragraphs in table
cells, as Robin outlined a few days back. Paragraphs
don't have a preferred width. What algorithm should
be applied in a case like this (generalized to many
rows and columns)?
<tr>
<td>
Really really long text here in cell one, would wrap
over many lines of text. Blah blah blah.
</td>
<td>
Short column two.
</td>
</tr>
<tr>
<td>
Short column one
</td> <td>
Really really long text here in cell two, would wrap
over many lines of text. Blah blah blah.
</td>
</tr>
The full HTML table algorithm will kill performance
for big multi page tables, and what's more it requires
paper to have scrollvars which is generally not true
in real life. So we need to define some sensible goals.
Ideas welcome!
- Andy