[reportlab-users] Numerous pdfs generation
fbs at tinyerp.com
Fri Jan 9 09:49:29 EST 2009
No test have been done yet, I was just requesting if any way to manage
this size/speed concern already existed to avoid any bad surprise later.
The document generation engine will be ready in about a month. I'll do
some test then, and see if it will work fine with just a sufficient
amount of RAM.
In case it doens't, the "xobjects" and 'linearized pdf' seems to be two
PS : The pdf file must be unique for a marketing campaign, it's a
constraint from the routing companies that manage the printing and
sending of the mailings.
Andy Robinson wrote:
> 2009/1/9 Fabian <fbs at tinyerp.com>:
>> Yes, it's the 6M pages a day.
> Have you actually done some experiments and looked at the resulting
> file sizes, and/or run out of memory? What limits do you hit?
> I presume that these are stacks of highly similar documents - for
> example a big stack of invoices. The trick here is to make very thorough
> use of 'form xobjects' for anything which is used frequently. So, for
> example, your invoice template and letterhead might need to be drawn
> and stored just once in that mega-pdf-file. Then you only need to render
> the words which differ on each page in the main story. If you use these
> techniques, it's amazing how many pages you can spit out and how
> quickly. And it's not worth an R&D effort if a couple of extra GB of RAM
> will do the trick.
> The second question I'd ask is if the client really needs each of
> these to be delivered as a single file. If they have, say, a 200,000
> page stack of invoices, would they not be equally happy with a directory
> of files each containing 1000 pages, or by client IDs, or some
> other structure making it easy to find the PDF they want?
> When clients have asked me for huge docs in the past, they have always
> seen the wisdom of breaking it up a bit after some initial discussion.
> - Andy
> reportlab-users mailing list
> reportlab-users at reportlab.com
More information about the reportlab-users