From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 Description of problem: Using an Okidata Okipage 10e printer with gimp-print-ijs driver. CUPS 1.1.15 supplied with RedHat 8.0 doesn't handle PDF files correctly. lpr <somefile>.pdf results in no output from the printer, though everything looks OK in the CUPS error log. Every other file type I've tried seems to print fine. The problem seems to be in the pdftops filter; using any other program (xpdf, Acrobat Reader, the pdftops or pdf2ps utilities) to produce a postscript file, then printing that file, works fine. Upgrading to the newly-released CUPS 1.1.16 (which uses a pdftops filter based on xpdf 1.0.1) fixes the problem. This issue is particularly important for people with Mac OS X clients connecting to a RH 8 server to print, since OS X produces PDF output for all printing. Version-Release number of selected component (if applicable): 1.1.15 How reproducible: Always Steps to Reproduce: 1. Add a printer using the browser-based CUPS admin tool. 2. Print a PDF by issuing "lpr file.pdf" or directly from an OS X application on a remote machine. 3. No output from printer. Additional info:
Some PDFs I tried worked fine, but I'll keep this report open until 1.1.16 is packaged. Thanks for the report.
Yup, this problem just bit me too. I was using cups-lprd for a while and I finally got around to using IPP, which means my mac doesn't send the final PostScript, it sends the "raw" PDF. But now anything with foreign characters or 8-bit characters comes out completely wrong. For instance, Chinese or Greek is a bunch of squares or unrelated ASCII characters. Even ligatures like "fi" are blank in my english documents. pdftops is broken. Saving to poscript and then printing the postscript file works fine.
I had the same issues here, and it is apparently caused by the 'pdftops' filter trying to call the 'uncompress' command on some files that include compressed data. There is a USE_GZIP macro that should be defined in the source code so that it will try to call gzip instead, as the uncompress command seems to be unavailable by default on newer Redhat releases (which is a very bad idea, IMHO).
FWIW, I notified the CUPS guys about this issue and a fix should be included in version 1.1.17.
..which was released as an RHSA recently. Closing (please re-open if it doesn't fix it).