[reportlab-users] Experimental early serializing pdfdoc.py for

[Thomas Blatter]

Hi,

>... OK; do you feel able to hack that out or have you done enough?

   Sure, i was prepared from the beginning to clean up the code, but before i'd do that i wanted to know from the reportlab community if there is any interest in early serializing.
   
   What i was thinking is since PDF has many use cases with different requirements (presentations, flyers, books, mass mailing, ...) that several pdfdoc.py's could coexist given a clean interface, the one to be used being chosen in rl_config. I can for example imagine variants which put the crossref and trailer at the beginning of the file (i assume this loads faster in acrobat reader, in particular larger documents like books). Implementing this behaviour in the current pdfdoc.py wouldn't actually need a lot of work. A good deal more work based on this idea would be the production of linearized PDFs. And finally a probably unrealistic and eventually not that useful dream of mine would be a pdfdoc.py which produces postscript instead of PDF.

   In short all this would require a well-defined interface definition for pdfdoc.py's classes.

   Out of context: i was asked if early serializing affects platypus, and i said no, as long as one does not print several templates in a single document. This is not accurate, one of the main culprits in memory consumption is the pdf data, in the saveToFile phase of the actual pdfdoc.py i observed that memory usage roughly doubles. So people who have a problem with memory footprint with platypus documents may profit as well from the early serializing.

Thomas Blatter