[reportlab-users] RE: Formatting long tables

[Henning von Bargen]

> From: Robin Becker <robin@reportlab.com>
> Subject: Re: [reportlab-users] Re: Formatting long tables
> Reply-To: reportlab-users@reportlab.com
> 
> In article <000901c30ff7$30768bc0$0301a8c0@auenland.org>, Henning von
> Bargen <h.vonbargen@cityweb.de> writes
> ........
> >I make the following assumption for long tables:
> >
> >The available width is equal in all frames where table is going to be
> >rendered.
> >Otherwise your layout is a mess anyway (but you could still fix all
column
> >sizes).
> ..... reasonable
> >When auto-calculating column widths:
> >In a table with M columns, assume that
> >the width is not specified for m columns.
> >
> >The existing approach (as I understand it)
> >is to divide the remaining available width by m,
> >so that all unspecified column widths are equal
> >and the table fills the available width exactly.
> .... this is the one that's not strictly true.
> Assume M columns with m unspecified. If the data defines some of the
> widths for the unspecified ones then these become known and a reduced
> number say m' <= m are used in the equal split. The problem arises when
> one or more of the cells has a tradedoff between width & height. The
> containing column then has no fixed width.

OK, then my algorithm would word a little different:
It would treat string-only data the same as paragraphs and other content:
Ask the content how wide it would like to be,
but only once (when wrap() is called for the first time).
>From then on all columns have fixed width.

> >Auto-sizing column widths should better happen
> >only once, the first time wrap() is called.
> >From then on, all column widths should be considered fixed.
> ......
> possibly genius sampling algorithm elided
> 
> Suppose there were 300 rows in which one of the unknown columns had a
> min requirement all determined by the contents. Using that as a fixed
> width is fine if all succeeding rows have smaller width for that column.
> A global algorithm might work in that case. 
> -- 
My algorithm would make the column too small iff there are are cells with
larger width for that column in one of the unconsidered rows.
It will result in the optimal width for small tables
and in almost optimal width for long tables most of the time.
It should very rarely result in bad-looking tables, since we choose
enough random data (very bad-looking tables iff most of the cells 
we considered were very short by chance).
And you could always choose to consider all rows explicitly if you like
(or better set column widths explicitly).

For small tables (less than 100 rows) my algorithm should give the same
results as the current algorithm.

An idea how spans could be handled in the sizing-algorithm:
If a cell spans m columns, then each of these column statistical data
should be updated with (content-length / m). Better than just ignoring them?
But how to handle row spanning? Seems difficult.

Reasonable auto-sizing column-widths seems quite complex.
AFAIK LateX has no concept of auto-sizing column widths,
you can only say: Make the column as wide as "SomeText" is.

Henning