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

[Lennart Regebro]

Uh, yeah, I suddenly realized that the problem I solved with copying the
table must be solved later down in the standard split code, so that must be
entirely unnecessary.

I'll fix that.


On Thu, May 26, 2022 at 1:14 PM Robin Becker <robin at reportlab.com> wrote:

> On 24/05/2022 18:53, Lennart Regebro wrote:
> > On Tue, May 24, 2022 at 11:28 AM Robin Becker <robin at reportlab.com>
> wrote:
> >
> >> Hi Lennart,
> >>
> >> thanks for the new patch. I assume everyone will recognize you as genius
> >> if it all works :)
> >>
> >
> > If that was true I would not have to make spreadsheets to figure out the
> > logic when I can't get all the cases to work at the same time. :-)
> >
> > [image: image.png]
> >
> Hi Lennart, I guess genius status is deferred a bit. Whenn I apply the
> patch I find that we are getting an error related
> to deepcopy of the cell values in the script docs/genAll.py which creates
> reportlab-userguide.pdf
>
> > (.py310) robin at minikat:~/devel/reportlab/REPOS/reportlab/docs
> > $ python genAll.py
> > "/home/robin/devel/reportlab/.py310/bin/python" genuserguide.py
> > Built story contains 1842 flowables...
>  > .........
> >   File "/home/robin/devel/reportlab/reportlab/platypus/tables.py", line
> 2032, in split
> >     result = self._splitRows(availHeight, doInRowSplit=not
> self.splitByRow)
> >   File "/home/robin/devel/reportlab/reportlab/platypus/tables.py", line
> 1589, in _splitRows
> >     data = deepcopy(self._cellvalues)
>  > .......>   File
> "/home/robin/devel/reportlab/.py310/lib/python3.10/copy.py", line 161, in
> deepcopy
> >     rv = reductor(4)
> > TypeError: cannot pickle '_io.BufferedReader' object
>
>
>
> I did a quick debug and find that the problem is caused by one of the cell
> values being/containing an image eg
>
>
> >> /home/robin/devel/reportlab/.py310/lib/python3.10/copy.py(165)deepcopy()
> > -> raise
> > (Pdb) p reductor
> > <built-in method __reduce_ex__ of _io.BufferedReader object at
> 0x7fb33f846350>
> > (Pdb) p x
> > <_io.BufferedReader name='../images/replogo.gif'>
>
> the code that fails is I think a bit like this
>
> I = Image('../images/replogo.gif')
> P0 = Paragraph(.......
> P = Paragraph(......
> data=  [['A',   'B', 'C',         P0, 'D'],
>         ['00', '01', '02', [I,P], '04'],
>         ['10', '11', '12', [P,I], '14'],
>         ['20', '21', '22',      '23', '24'],
>         ['30', '31', '32',      '33', '34']]
> t=Table(data,style=[......
>
> I suppose we have either have to make ImageReader support a deepcopy or
> defer / change the deepcopy. In this case I
> don't think the splitInRow is in operation so previously we didn't create
> a deepcopy. Deferring to the special
> splitInRow case should save us time in the normal case, but obviously we
> would like to support the special cases.
>
> First off it seems overkill to deepcopy the whole data. Previously the
> rows went either into one table or its successor
> no copying needed. Now I assume the problem is that we are splitting cells
> and want to have two separate versions of the
> same cells.
>
> It seems reasonable to me that the cells / styles that get split must be
> created in two parts one for the top part of
> the table and the second  for the lower table. Since these must be new I
> don't see where the copy comes in.
>
> I will have to think about the ImageReader problem as it's the most likely
> problem causer; in addition there are far too
> many options which attempt to save storage reduce open files etc etc etc.
> I think years ago we worried more about
> storage so defrred reading the whole image into memory. The deferral
> caused problems with too many open files etc etc.
> It all needs cleaning up.
>
> Of course the real issue here is that we don't require any of reportlab
> content to be immutable. A lot of things are
> made harder because of that.
> --
> Robin Becker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20220526/9fd74897/attachment.htm>