Re: Patch to support tables with oversize cells
Lennart Regebro via reportlab-users <[email protected]> Thu, 26 May 2022 14:11:22 +0200
| Newsgroups | gmane.comp.python.reportlab.user |
|---|---|
| Message-ID | <CAHT-kBeQAVNmVhK20tbXZnYCdsf75vo3dQtB0czcsuXS3q_ziw@mail.gmail.com> |
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 <[email protected]> wrote: > On 24/05/2022 18:53, Lennart Regebro wrote: > > On Tue, May 24, 2022 at 11:28 AM Robin Becker <[email protected]> > 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@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 >