Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Corrupt PDFs with Scribus + PDF::Reuse + PDF::Table

by ides (Deacon)
on Feb 20, 2008 at 22:22 UTC ( #669121=perlquestion: print w/ replies, xml ) Need Help??
ides has asked for the wisdom of the Perl Monks concerning the following question:

Dear fellow monks, I've run into a strange problem I can't seem to solve on my own and hope that someone has an idea of something else to try.

I've written a system that generates a bunch of PDF invoices for one of my clients. I built the initial visual layout of the top half of the first page with Scribus ( logo, various fields for client name, invoice date, subtotal, sales tax, grand total, etc. ) and use PDF::Reuse to fill in those values.

I then open the document PDF::Reuse created with PDF::API2 and append a PDF::Table onto it with the individual line items on the invoice.

The PDFs appear fine. You can view them in acroread, xpdf, even Adobe Reader on a Mac. All of the data is there and visible. The problem arises when you print them.

Some of them will generate strange PostScript errors that I can't make any sense of. Also, if you print multiple PDFs are once often the first PDF will be fine, but subsequent PDFs will not print out the data for the fields PDF::Reuse has filled in. Despite the fact that you can see the data when viewing the PDF.

I've upgraded Scribus to the latest stable version. Upgraded to the latest versions of PDF::API2, PDF::Reuse, and PDF::Table. Thinking maybe my older version of Scribus was generating a wonky template. Even went so far as to test a few PDFs with CAM::PDF instead of PDF::Reuse with the same results. I've fiddled with every PDF exporting option ( embedding or not the fonts, various versions of the PDF spec, using different fonts ). I've omitted the PDF::Table stage before and still see the same PDF::Reuse form field population issues on printing.

Has anyone run into a similar problem like this that might shed some light on what is going on? Anyone have an idea on a better way to accomplish the same goals? Any ideas are appreciated! Thanks!

NOTE: I would show you the code, but the system is quite a bit of code and considering the PDFs are generated without error and can be viewed I don't feel that this is likely an issue with my Perl source.

Frank Wiles <frank@revsys.com>
www.revsys.com

Comment on Corrupt PDFs with Scribus + PDF::Reuse + PDF::Table
Re: Corrupt PDFs with Scribus + PDF::Reuse + PDF::Table
by snoopy (Deacon) on Feb 21, 2008 at 23:14 UTC
    Some suggestions.

    1. My best guess is that something is altering the graphics state and not restoring it. Not sure if you are doing any translation, rotation, scaling, etc, but make sure graphics state is not being saved & restored (e.g. using PDF::API2's $gfx->save and $gfx->restore on page graphics).

    2. If you're getting postscript error's, it could be useful to see them!

    3. I've found that ghostscript gives the best diagnostics. If you haven't already, it's worthwhile to try view your pdf's directly with ghostscript, checking for errors. Also convert to postscript using pdf2ps (or xpdf's pdftops) and also view these with ghostscript.

    Good luck!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://669121]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (8)
As of 2014-09-19 08:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (133 votes), past polls