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

[Andy Robinson]

> Henning von Bargen:
> 
> > Andy, I think that you're going the right way with your proposed
> > new table sizing algorithm.
> 
> For the fun of it I googled for "table rendering algorithm" and
> get a bunch of items... Also, LaTeX has quite some tabular en-
> vironments to study, at least for those able to adapt their
> brains to LaTeX macros...
> 



I have ready many of those over the last few years
(and weeks).  What was needed now: something fully 
backward compatible with all our existing apps, and 
reasonably fast, to add row/col spans and still
do vaguely sensible sizing.  I THINK it will not change
any existing cases we handled, it handles more cases 
than before, but it's far from perfect.

I still have not tackled the performance problem
of 1000-row tables, by the way. But now I've got stuck
in to the algorithms that should not be too hard.

I expect a lot of our users, and certainly the one
which drove this work, need to do documents with
financial tables running over many pages. IE's
code is visibly slow because of the multiple passes
needed, and because it wants to consider every distinct
table cell edge independently and draw it. Ours has
the potential to go VERY fast when just splatting
grids of numbers and strings onto the page, and drawing
a few boxes around them. It put the burden on the user
to pick the right line drawing instructions.

In the long term we need more than one table model, with
clearly stated performance tradeoffs. I think a more
flexible one would involve something more like a GUI 
packer, with struts and springs (like InterfaceBuilder),
and could be used for page frame arrangement as well
as tables.  But I would not use it for a set of monthly
accounts...


- Andy