[reportlab-users] RE: Table sizing algorithms - comments welcome

[Andy Robinson]

> .... as I now understand it we're distributing width equally to things
> (currently all flowables) that are not quickly sizeable.
> 
> There are some nits with the current algorithm
> 
> 1) We need to disambiguate for those things which are immediately fixed
> in width eg an image with a known dimension. This could be done as
> discussed earlier by adding an api to the Flowable class.

Exactly.  A few helper attributes or methods - is your size
knowable or does it depend on the container? - and we can handle 
more cases.  

For unknowable sizes such as paragraphs, HTML is a bit cleverer
than us.  It does things twice. It works out the maximum possible 
width (i.e. put the paragraph on one very wide line) for each cell
in a row, then 'takes logarithms' (I kid you not) and uses this
as proportions to scale the widths to fit.  Others argue you should
take square roots, or any other function of the length.  The point is
that if column 1 has fairly short paragraphs and column 2 has long ones,
column 2 will get more space.  

An important case is a sub-table in a cell of another table.  If the 
subtable has a knowable size irrespective of its container, no problem.
Otherwise it gets a bit harder.

2 other things we have not added but which would be easy to add
are
(1) percentage width specifications
(2) proportional width (column A is 2x column B)
These could all be mixed in the colWidths array, with a defined
resolution order.  IMHO if we had these, the chances of a user 
saying "but I really can't provide any clues as to my intent, 
please do it for me" decline much further. 

> 
> 2) Some flowables are sizeable via their wrap method eg a table with all
> known column widths. The current algorithm is breadth first ie it does
> not attempt to discover actual widths of deeper elements. 
> An alternative would be available if we made the wrap apis more formal.
> Should wrap return the correct (minimum) width when it fails?

Or, going further, do we stop returning simple numbers and switch
to some triplet of (minimum, ideal, maximum) widths?

My hunch is that (2) is bigger type of change which would
involve a careful crawl through all our code, but I am open
to persuasion.

- Andy