[reportlab-users] Finding space left

[Robin Becker]

On 12/02/2010 00:02, Adrian Klaver wrote:

> This email, to which there was no response, got me delving into finding space

> left on a page:

> http://two.pairlist.net/pipermail/reportlab-users/2009-December/009166.html

>

> Unfortunately, the more I have looked the more confused I have become. I found

> this thread and I sort of understand:

> http://two.pairlist.net/pipermail/reportlab-users/2009-September/008767.html

>

> The issue for me is the chicken and egg nature of the problem:). There are

> various methods that take aW,aH but it is not obvious to me where to get that

> information in a particular context. For purposes of experimentation I am using

> a SimpleDocTemplate with the first page being a title page and the later pages

> handling a Table. Ideally I would like to do a summary row at the bottom of

> each page. I thought of subclassing Table to figure space left and then making

> room for a row. For what ever reason I cannot seem to get my head around how to

> go about that.

>

> Thanks,


One thing we don't have is a mechanism to allow tables to inject an extra row at 
a split point ie where we break because lack of space has occurred. I think that 
would be the right way to go about this and the use case is very common ie bills 
etc etc. In the past when we have done this for clients I think we just ignored 
tables since for most purposes the rows are fixed height. That allows 
pre-computation of the split points.

I think the problem of having automatic end of split rows is probably solvable 
given enough effort, but there are probably easier ways to do this especially if 
you allow room for the extra row to be drawn just outside the frame ie you lie 
about your real height and just blindly draw the extra row(s) in the first part 
of a split table. That would require a new table behaviour and probably some 
extra styling stuff, but it ought to be doable.

Theer is an additional problem associated with billing mechanisms in that we 
want access to the content at draw time so that stuff like partial sums can be 
computed etc etc. Conceptually we can do that already with paragraphs that have 
ondraw tags embedded within them, but that is fairly costly. For fast tables 
that contain only simple strings we probably ought to have some kind of call 
back that can be used by the cell drawing methods.
-- 
Robin Becker