[reportlab-users] Problem with row&column spanning code not calculating table heights

[David Fraser]

Andy Robinson wrote:

>>I'm not sure if there's a simple general formulation that is easy to
>>solve.
>>    
>>
>
>I am pretty sure there isn't :-) So far we have been adding in
>"common cases" as they occur, and problems are pretty
>rare.  I am hoping that after one or two more case-by-case 
>enhancements we will be down to a couple of bug/weirdness
>reports per year. Obviously we are looking at this one.
>
>
>There is a well defined HTML algorithm but it renders slowly.
>Maybe one way to go is to have an 'algorithm' attribute
>set to "reportlab-default" and let people write their
>own in version 2 :-)
>  
>
Thanks for the explanation. I'll try think about the algorithms thing ...

>I will reiterate by the "real world" guidelines I always give
>to make sure you get reasonable tables in the month
>you need them.
>(1) work out and explicitly specify your widths
>(2) let it work out the heights, unless there is a good
>reason why it can't; if it can't, then provide some
>heights.
>(3) if doing big data sets which will span several pages,
>make lots of one-row or few-row tables and put them
>after each other in the story.  It's easier on your
>brain.
>  
>
The reason a lot of these options are difficult for us is that we 
dynamically generate reports based on data in which:
1) the number of columns is dynamic
2) the actual content is dynamic
3) the size is often large (many pages)

We actually do them in HTML and then produce printable version in PDF 
using reportlab.
The HTML algorithm works nicely although it took a bit of time to work 
out how best to use it.
But in order to do 1/2/3 above, we'd need to basically implement some 
version of this algorithm ourselves.
That's why it seems sensible for it to be done in reportlab, even if 
it's via an 'algorithm' attribute...
although I can see there's a fair amount of work to be done here

David