[reportlab-users] Force table not to split

[Bill Freeman]

Gert Burger wrote:

> Bill Freeman wrote:

>   

>> Gert Burger wrote:

>>     

>>> Hi

>>>

>>> I am creating reports which contain many small tables, each fit the

>>> width of the page and are about 1/4 of its length. Each table only

>>> contains 2 rows of which the first is the header.

>>>

>>> By default it seems to split between rows, which is exactly not what I

>>> require. I would rather have it move the whole table to the next page.

>>> The documentation(userguide.pdf Chapter 7 Introduction) mentions a

>>> canSplit attribute but nothing more about it.

>>>

>>> How would one force reportlab not to split tables?

>>>   

>>>       

>> One possibility is to calculate the height of the table, and, if you

>> don't have that much space left

>> in the frame, force the next frame.  (If there is an easier way, this

>> is still what's going on under

>> the hood, I'll bet.)

>>

>> Bill

>>

>>

>> _______________________________________________

>> reportlab-users mailing list

>> reportlab-users at reportlab.com

>> http://two.pairlist.net/mailman/listinfo/reportlab-users

>>

>>     

> I guessed it would be something like that, but how would one do that in

> platypus?

>   

I'm not sure what it would mean to do it in platypus, so let me be 
clearer about what I was thinking.

I once explored the innards of the table class, trying to figure out how 
to make it split by columns, as
the documentation implies that it can.  I found no code to do this, and 
nothing that even looks at the
constructor argument that says which way to split first (so I guess that 
the documentation if for a
feature that will happen someday, or a feature that was too much trouble 
to keep working and was
elided).  But I did wind up with some understanding of split by rows.  
There is already code that
calculates the table size (row heights, in particular), and code that 
compares that to the height
available.  When it decides to split, it returns a list of flowables to 
insert into the flowables list in
place of itself.

So the general solution would be to create a derived class that uses the 
portions of the underlying
functionality to calculate size, and if things aren't going to fit (you 
may have to duplicate most of
a fairly large method to catch it at just this point), and instead of 
letting it split the table, return a
list of a spacer or other page/frame/column ending flowable, and your 
table.  (IIRC, the page
break flowables work by adding a spacer sized to take the remaining 
space.)  I'm afraid that
I don't recall details like what method to look at, but it's just Python 
code.

On the other hand, it sounds as though all your tables might be of the 
same height, so you might
take a short cut by having a simpler subclass that just looks to see 
that you have that much room,
and inserts a spacer if not.

Best of luck,
Bill

And I hope the list will correct any misinformation I've offered.