[reportlab-users] Broken PDFs with multiBuild and file objects

[Andy Robinson]

> The problem is this, the file object needs to be reset each time 
> it goes through the
> build loop. There are three cases
> 
> 1) filename
> 2) file like object with write/tell/seek
> 3) file like object with write only (eg socket)
> 
> The fix is fairly obvious for 2, but for 3 it's not clear whether 
> we should use a null
> writable for the earlier iterations and do a final extra 
> iteration with the proper
> filename value to get the output or
> perhaps use a StringIO.

One possibility is to always make a PDF as a binary stream
(stringIO or string), and only write it to disk or
the output device when done.  

PDF isn't a sequential format, at least not the simple way we
do it, so you need the whole object tree in memory. We could
add some new APIs so that the primary, preferred way is to make
a PDF in memory, and the existing behaviour builds simply on
this to save to a filename if given.

Multibuild could then 'always' build in memory, and when
no further change is needed it could then write the resulting
stream either to disk or to the file-like device once only.

Of course, ReportLab 3000's smarter layout algorithm will
do a better job as the first 2/3 passes will only size
objects and not draw them, but that's a way off :-)

- Andy
(thinking aloud after a week off, may not make sense yet)