Bug 827490

Summary: Certain glyphs are printed as empty boxes when printing to postscript printer
Product: [Fedora] Fedora Reporter: Marc Milgram <mmilgram>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: jpopelka, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-06 14:08:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Sample PDF file that prints incorrectly
none
Scan of printer output
none
PPD file for Red Hat's Office printer none

Description Marc Milgram 2012-06-01 15:25:59 UTC
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):
cups-1.5.2-12.fc17.x86_64

How reproducible:
100%

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 15:29:47 UTC
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 15:33:07 UTC
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 12:14:18 UTC
Firefox and evince have this problem, Openoffice and Chrome do not exhibit this problem.

Comment 4 Jiri Popelka 2012-06-04 12:37:06 UTC
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.
https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter

Comment 5 Marc Milgram 2012-06-04 14:25:52 UTC
Created attachment 589170 [details]
PPD file for Red Hat's Office printer

Hi,

Here is the requested information (and attached):

ghostscript-9.05-1.fc17.x86_64
poppler-utils-0.18.4-3.fc17.x86_64
foomatic-4.0.8-8.fc17.x86_64

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 15:07:10 UTC
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 15:38:04 UTC
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 16:08:50 UTC
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 18:05:47 UTC
(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 12:10:35 UTC
(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 12:17:16 UTC
(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 14:08:59 UTC
(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 ***