[reportlab-users] Is ReportLab suitable for this task?

[reportlab-users@reportlab.com]

Thanks Larry, I'll keep you in mind if we decide to go forward on this.

> I've done several applications very much like what you describe
> for my clients.  I would be happy to discuss a consulting
> relationship with you to work on this application if you like.
>
> I decided to answer your questions (as best I could) below:
>
> Larry Bates
> Syscon, Inc.
> ---------------------------------------------------------

snip

> So, a couple of questions.
>
> 1)  Will the process of formatting the data to PDF in ReportLab cause the
> time to generate a statement go beyond 1/3 of a second?  Probably a tough
> question without more specifics, but what specifics would you need?
> >>>
> >>>I have an application that creates an 8 page PDF with background boxes
> >>>bargraphs, tabular data, etc. and it takes less than 1 second to
produce
> >>>this document.  That is about 8-10 pages per second.  This is on a
> >>>3Ghz P4.  Data is coming to me via ODBC from MS Access database.
> >>>Text only statements should be faster.  Note: You can use ReportLab's
> >>>PageCatcher if you want to merge a background form with you data
> >>>stream.  That is what I do and it eliminates the requirement of the
> >>>application "drawing" the background forms.  Also makes changing the
> >>>background form much easier because it is stored in a separate file.
> >>>

That sounds like it would be close to meeting the requirement.  I'd guess
that 3 statements per second would average 10-12 pages per second and, as
you say, they wouldn't be as complicated as yours (at least not right off
the bat).

> 2)  We need two kinds of outputs, 1) a file for the printer, and 2)
> individual PDFs for import into the COLD/imaging system.  For the printer
> file, we need a file with enough statements to use 5,000 pieces of paper
(so
> the operators can just load a box of paper per file).  Could the printer
> file be just one 5000 page PDF or does that become too large for ReportLab
> to handle in memory?  How would you handle this?
> >>>
> >>>I've never tried to produce a PDF that large.  Would need to test.
> >>>Can't you just queue up a bunch of individual files to the printer
> >>>to reach your 5000 page limit?  This might need to be a separate
> >>>printing application that would save the building of the large .PDF
> >>>files.
> >>>

The problem with individual files rather than a large file on the printer
management end.  Apparently when the file is transferred to the printer mgmt
software it gets a queue number and loses its identifying characteristics.
Since they sometimes have to reprint because of an error, they need to work
with one large file so that they can know which queue number to work with.
There is some print job management software on the printer which could read
job management code in the file that could allow the operators to see the
identifying info but for some reason (probably time) that was not fully
pursued.  I'd expect that if we redid the process we'd try to figure that
out but for now, without knowing what would be involved, I think we need to
work with a few large files rather than many small ones.

> 3)  We use an IBM Infoprinter which says that it supports PDF.  Does
anyone
> have experience with this printer and PDF?  Will using a PDF format rather
> than PCL slow things down inordinately?
> >>>
> >>>Sorry, can't help you here.  You would need to send a .PDF file to
> >>>it to see if it prints properly
> >>>

snip

Yep.
-- Don