Bug 827490 - Certain glyphs are printed as empty boxes when printing to postscript printer
Certain glyphs are printed as empty boxes when printing to postscript printer
Status: CLOSED DUPLICATE of bug 827632
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-01 11:25 EDT by Marc Milgram
Modified: 2012-06-06 10:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-06 10:08:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample PDF file that prints incorrectly (19.89 KB, application/pdf)
2012-06-01 11:25 EDT, Marc Milgram
no flags Details
Scan of printer output (15.08 KB, application/pdf)
2012-06-01 11:29 EDT, Marc Milgram
no flags Details
PPD file for Red Hat's Office printer (9.61 KB, text/plain)
2012-06-04 10:25 EDT, Marc Milgram
no flags Details

  None (edit)
Description Marc Milgram 2012-06-01 11:25:59 EDT
Created attachment 588517 [details]
Sample PDF file that prints incorrectly

Description of problem:
When printing certain documents to a postscript printer, certain characters or images are printed as an empty box instead of what should be printed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. view attached .pdf file in evince
2. print file (using either lpr or evince) to a postscript printer
3. Compare printed output to output from evince
Actual results:
Some of the characters are printed as empty boxes

Expected results:
The printed page looks as good as the on screen representation

Additional info:
I first ran into this problem on Fedora 16 with an HP 2605dn printer in postscript mode.  If I tell the print subsystem that it is a PCL5e printer, all the characters are printed correctly, but the output is generally not as good as the postscript output.

This worked correctly in Fedora 15.
Comment 1 Marc Milgram 2012-06-01 11:29:47 EDT
Created attachment 588518 [details]
Scan of printer output

I scanned what was printed to the XEROX WorkCentre 5655, and attached it here.
Comment 2 Marc Milgram 2012-06-01 11:33:07 EDT
I captured the network traffic that was sent to the HP2605dn printer, and extracted the text.  Evince displayed the file correctly.

I don't think this is a bug with the printer because it is the same on two different printers from different manufacturers.
Comment 3 Marc Milgram 2012-06-03 08:14:18 EDT
Firefox and evince have this problem, Openoffice and Chrome do not exhibit this problem.
Comment 4 Jiri Popelka 2012-06-04 08:37:06 EDT
Thanks for the investigation Marc.

The attached pdf prints fine here using lpr&evince, so we need more information.

- Please attach the PPD for your printer from /etc/cups/ppd.
- What does 'rpm -q ghostscript poppler-utils foomatic' show ?
- Please attach the output from printing troubleshooter, when printing the attached pdf via lpr or evince.
Comment 5 Marc Milgram 2012-06-04 10:25:52 EDT
Created attachment 589170 [details]
PPD file for Red Hat's Office printer


Here is the requested information (and attached):


I found that this document prints correctly from lpr, but not from evince.  I have a different document that prints incorrectly from both evince and lpr.

I will attach troubleshoot.txt momentarily.
Comment 7 Jiri Popelka 2012-06-04 11:07:10 EDT
The error_log in the troubleshoot.txt is somehow almost missing.
Can you attach the /var/log/cups/error_log ? You can strip it to contain only the job that was running around [04/Jun/2012:10:21:29 -0400]

The info I'm missing are the filters used, i.e. something like these lines in error_log
I [date] [Job 95] Started filter /usr/lib/cups/filter/pdftops (PID 20275)
I [date] [Job 95] Started filter /usr/lib/cups/filter/foomatic-rip (PID 20276)
so we'll be able to run them by hand [1] and see in which step the empty boxes appeared.
If there's by any accident no such an info in the error_log try to get it as described in [2].

[1] https://fedoraproject.org/wiki/Printing/Debugging#Running_filters_by_hand
[2] https://fedoraproject.org/wiki/Printing/Debugging#Getting_debug_information_by_other_means

(In reply to comment #5)
> I have a different document that prints incorrectly from both evince and lpr.

Could you attach it or send it to me ?
Comment 8 Marc Milgram 2012-06-04 11:38:04 EDT
I notice that I get a bunch of errors of the form:
(evince:20452): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Comment 11 Jiri Popelka 2012-06-04 12:08:50 EDT
Ok, according to the error_log the input was application/pdf.
pdftops and foomatic-rip filters were applied and the output was sent to printer.
We'll do the same by hand.

The steps are:
1) PPD=/etc/cups/ppd/grayscale-fl2.ppd /usr/lib/cups/filter/pdftops 1 me '' 1 '' <rewards.pdf >pdftops.ps
2) check that pdftops.ps is ok
3) PPD=/etc/cups/ppd/grayscale-fl2.ppd /usr/lib/cups/filter/foomatic-rip 1 me '' 1 '' <pdftops.ps > gs.prn
4) check that gs.prn is ok (it's actually postscript too)
5) print it via 'lpr -P grayscale-fl2 gs.prn'
6) check the printout
Comment 14 Jiri Popelka 2012-06-04 14:05:47 EDT
(In reply to comment #11)
> 5) print it via 'lpr -P grayscale-fl2 gs.prn'

Sorry, I forgot. We want cups to sent the file directly to printer without any additional processing so step (5) should be:
lpr -P grayscale-fl2 -o raw gs.prn
Comment 18 Jiri Popelka 2012-06-06 08:10:35 EDT
(In reply to comment #3)
> Firefox and evince have this problem, Openoffice and Chrome do not exhibit
> this problem.

It's possible that this as another duplicate of bug #827632.
I know that Firefox and evince emit print jobs in PDF.
Try to print from Openoffice (did you mean libreoffice ?) and Chrome
and check [1] whether the print jobs are emitted in PDF or postscript.

Also try to print some postscript file with lpr.

[1] egrep '/usr/lib/cups/filter/|CONTENT_TYPE' /var/log/cups/error_log
Comment 19 Jiri Popelka 2012-06-06 08:17:16 EDT
(In reply to comment #16)
> I ran the debugging against my home machine.  gs.prn output with the same
> errors as before.

Does the "with the same errors" mean that the printout contains the empty boxes ?
The gs.prn file looks OK here in evince/okular so there must be something in the postscript code that evince/okular understands but the printer does not.
Comment 22 Jiri Popelka 2012-06-06 10:08:59 EDT
(In reply to comment #21)
> I told Firefox to print to a file in Postscript, then printed that
> Postscript file.  It printed correctly.

Ok, closing as duplicate of bug #827632, we'll continue there.

*** This bug has been marked as a duplicate of bug 827632 ***

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