[reportlab-users] RE: splitting in table cells
robin at reportlab.com
Mon Jan 10 07:47:37 EST 2005
Henning von Bargen wrote:
> To answer my own question:
> It doesn't work with 1.20, either.
> So I've started writing my own patch.
> The current status is:
> * It is working in principle, at least
> if the cells do contain paragraphs.
> * It should be possible to extend the
> solution for strings and other flowables, too.
> * However, handling sequences (lists, tuples)
> of other objects would be more complicated.
> And I'm still facing one specific problem regarding the
> styles/lines/backgrounds: Since I'm splitting a row in the
> table, in effect I have to duplicate a row in the middle
> of the table and I don't know how to adopt the internal
> routines cr_0_0 etc.
> I'd like to send my code to the main developer of tables.py
> for a review - perhaps someone at ReportLab could continue
> my efforts?
we are investigating cell splitting right now; by all means send to me for
review. To fully automate this I think we need a slight extension of the split
method. At present split is called with only the remaining available space. That
means that the flowable to be split cannot work out whether it should resort to
One solution is to do extraordinary things when a cell is larger than a
specified maximum independent of the owner frame etc etc; another is to allow
for some information to be passed in from outside eg maximum frame height etc.
We can do this by having a splitEx method which defaults to something like
def splitEx(self, aW, aH, maxW, maxH):
self._splitMaxW = maxW
self._splitMaxH = maxH
r = self.split(aW,aH)
del self._splitMaxW, self._splitmaxH
those flowables which need to know the maxW/H can use it at the appropriate
places ie to determine if they need to do something extraordinary.
The row copying routines are indeed a mess. We handle data/styles in a fairly ad
hoc way. The spanning stuff also fails fairly badly when splits occur.
More information about the reportlab-users