[reportlab-users] formatting long tables

Robin Becker reportlab-users@reportlab.com
Thu, 1 May 2003 12:03:50 +0100


In article <000a01c30f69$0aef1810$0301a8c0@auenland.org>, Henning von
Bargen <h.vonbargen@cityweb.de> writes
>Hi Robin, here is my version of tables.py.
>
>Regarding your remarks with potential problems:
>
>Yes, there might be problems with auto-sized tables
>if the availWidth on the next frame is different than
>the current frame (I can't think of other problems).
>
>But this seems a very exotic case to me.

Well if we don't restrict to fixed size columns we could get the
following problem even with constant width frames. Establish widths with
the first page, then we either allow for varying column sizes on
succeeding pages or we fix the column widths. In the latter case we
might find that even though a feasible column width assignment exists
that the quick and dirty method leads to an overflow on later pages. So
it seems for auto-sizing there's no easy solution without varying column
widths.

>
>The created PDF files from test() in table.py and hvbtable.py were
>identical.
>
>What needs to be done is running all availabe tests
>and then compare the resulting PDFs.
>
>BTW I don't know of any system (except LaTeX, maybe)
>including Oracle Reports that is able to handle tables
>with height and width larger than one page correctly.
>Do you have a testcase for such big tables?

I don't know a lot about tex et al, but I seem to remember tbl allowed
for vertical overflows. I cannot think that someone would want
simultaneous vertical and horizontal overflow handling.

>
>My modification makes the creation of professional
>database-driven reports a lot faster.
>(and what if hyphenation would work in paragraphs,
>the german language has a lot of long words (compared to english)).
>
>Henning
-- 
Robin Becker