[reportlab-users] Patch to support tables with oversize cells

[Robin Becker]

Hi Lennart,

I did the obvious monkey patch to the Table class and can now see that the splitInRow case table split method is 
modifying something in the original table.

The two split offspring don't seem to show any differences between the standard and patched case.

.......
> 
> Hi Lennart,
> 
> I did some more analysis on the minute differences I am seeing. I produced a failure test here
> 
> 
> https://www.reportlab.com/ftp/lennart/ttablelines.py
> 
> this produces a simple table with various styles and then checks to see how it can be split.
> 
> The test goes
> 
> 1) t=Table(....)
> 2) lst_add(t) #add to the story
> 3) tc = copy.deepcopy(t) if os.environ.get('DEEPCOPY','0')=='1' else t
> 4) for s in tc.split(4*inch,30): lst_add(s) #add the tow split bits
> 
> As a check I monkeypatch the canvas used for build so all the line commands get printed
> 
> I then find differences between the lines drawn when tc is t ie no deepcopy of t is done.
> If a deepcopy is done then I see no differences between the standard and patched lines.
> 
> As a check I also tried comparing the output lines between standard no copy and standard deepcopy cases, but there were 
> no differences in the lines drawn for those cases.
> 
> I think the implication is that for this simple split case the patched code is making some change to the original table.
> 
> Since we are assumed to be making two completely fresh tables from the original and the rows are disjoint we ought not 
> to make any change to the structure of the original.
> 
> At present I don't know if the lines that are added/changed etc belong to the first table, the two split ones or all three.
> 
> I can probably make up some mechanism to print out a message when the tables are drawn so we know when each starts in 
> the list of lines. I think a monkepatch on the Table.draw will allow us to do that.


-- 
Robin Becker