Bug 75694

Summary:	CUPS fails to print PDF files correctly
Product:	[Retired] Red Hat Linux	Reporter:	Matthew Wilkens <mattwilkens>
Component:	cups	Assignee:	Tim Waugh <twaugh>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	redhat-01
Target Milestone:	---
Target Release:	---
Hardware:	athlon
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-22 10:41:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matthew Wilkens 2002-10-11 05:31:47 UTC

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:

Comment 1 Tim Waugh 2002-10-11 14:32:16 UTC

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 20:31:14 UTC

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 20:12:19 UTC

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 22:59:50 UTC

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 10:41:54 UTC

..which was released as an RHSA recently.  Closing (please re-open if it doesn't
fix it).