Bug 75694 - CUPS fails to print PDF files correctly
CUPS fails to print PDF files correctly
Product: Red Hat Linux
Classification: Retired
Component: cups (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2002-10-11 01:31 EDT by Matthew Wilkens
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-22 05:41:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Wilkens 2002-10-11 01:31:47 EDT
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):

How reproducible:

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:
Comment 1 Tim Waugh 2002-10-11 10:32:16 EDT
Some PDFs I tried worked fine, but I'll keep this report open until 1.1.16 is 
packaged.  Thanks for the report.
Comment 2 Alexander Kourakos 2002-10-19 16:31:14 EDT
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.
Comment 3 Stephane Peter 2002-11-06 15:12:19 EST
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).
Comment 4 Stephane Peter 2002-11-07 17:59:50 EST
FWIW, I notified the CUPS guys about this issue and a fix should be included in
version 1.1.17.
Comment 5 Tim Waugh 2003-01-22 05:41:54 EST
..which was released as an RHSA recently.  Closing (please re-open if it doesn't
fix it).

Note You need to log in before you can comment on or make changes to this bug.