Red Hat Bugzilla – Bug 827490
Certain glyphs are printed as empty boxes when printing to postscript printer
Last modified: 2012-06-06 10:08: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):
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
Some of the characters are printed as empty boxes
The printed page looks as good as the on screen representation
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.
Created attachment 588518 [details]
Scan of printer output
I scanned what was printed to the XEROX WorkCentre 5655, and attached it here.
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.
Firefox and evince have this problem, Openoffice and Chrome do not exhibit this problem.
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.
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.
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  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 .
(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 ?
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()
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
(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
(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  whether the print jobs are emitted in PDF or postscript.
Also try to print some postscript file with lpr.
 egrep '/usr/lib/cups/filter/|CONTENT_TYPE' /var/log/cups/error_log
(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.
(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 ***