Printing produces broken PDF (missing images)

Bug #443026 reported by Martin Pitt on 2009-10-05
52
This bug affects 8 people
Affects Status Importance Assigned to Milestone
libcairo
Won't Fix
Medium
cairo (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
cups (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
evince (Ubuntu)
High
Sebastien Bacher
Karmic
High
Sebastien Bacher

Bug Description

Binary package hint: cups

Lots of embedded graphics are now not printed in printed PDF documents, they just appear as a white space on paper. This never happened for me in Jaunty, so this looks like a regression in one of the PDF filters?

I attach an example document which reproduces the issue. The graphics below "Skizze" is not printed at all, if you open the document in evince and just print it.

However, if I do "pdf2ps Aufgabe01.pdf" and open/print Aufgabe01.ps with evince, it works.

Unfortunately, trying to convert it back with pstopdf, the resulting PDF doesn't print at all and just causes the print job to stay in the queue forever.

It happens with my Samsung ML-1610 with the SpliX 2.0 driver.

Reproduction recipe without a printer:

  - Open reproducing document with evince
  - Print into a PDF file
  - gs output.pdf

ProblemType: Bug
Architecture: amd64
CheckboxSubmission: 526c13623eeda7bcc3936c7be57b2d29
CheckboxSystem: c8e8edcc4d15e0d55af04774be77e330
CupsErrorLog:
 E [05/Oct/2009:08:43:01 +0200] Unable to remove temporary file "/var/spool/cups/tmp/.hplip" - Is a directory
 E [05/Oct/2009:08:43:02 +0200] [cups-driverd] Bad driver information file "/usr/share/cups/drv/sample.drv"!
Date: Mon Oct 5 13:19:10 2009
DistroRelease: Ubuntu 9.10
Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: Keine Ziele hinzugefügt.
MachineType: Dell Inc. Latitude D430
Package: cups 1.4.1-4
Papersize: a4
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-11-generic root=UUID=3b048108-a02f-48da-bffb-3e2ef238d47a ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: cups
Uname: Linux 2.6.31-11-generic x86_64
dmi.bios.date: 05/21/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0HU754
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA00:bd05/21/2007:svnDellInc.:pnLatitudeD430:pvr:rvnDellInc.:rn0HU754:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude D430
dmi.sys.vendor: Dell Inc.

Related branches

Martin Pitt (pitti) wrote :
Martin Pitt (pitti) wrote :

error log with debug mode

Martin Pitt (pitti) wrote :

For completeness I also attach the generated PPD file (I didn't do any customizations, it's just what comes out of default automagic installation).

printers.conf:

---------------------
<DefaultPrinter ML-1610>
Info Samsung ML-1610
Location dagobert
MakeModel Samsung ML-1610, SpliX V. 2.0.0
DeviceURI usb://Samsung/ML-1610
State Idle
StateTime 1254636948
Type 12372
Filter application/vnd.cups-raw 0 -
Filter application/vnd.cups-raster 0 rastertoqpdl
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
</Printer>
---------------------

tags: added: regression-proposed
tags: added: regression-potential
removed: regression-proposed
Till Kamppeter (till-kamppeter) wrote :

The PDF output of evince seems to be broken:

The original file Aufgabe01.pdf I can send directly ("nc -w1 <IP> 9100 < <file>") )to two PDF printers (HP LaserJet P3005, HP Color LaserJet CM3530 MFP) and it comes out very quickly. If I print into a PDF file from evince and then send the resulting output.pdf to the same two printers it takes several minutes until both report that they do not have enough memory for the job.

Also Ghostscript (both versions 8.64 and 8.70) is able do display Aufgabe01.pdf but not output.pdf. Example Ghostscript output for output.pdf:

till@till-laptop:~/printing/foomatic/openprinting/mysqldb$ gs output.pdf
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 2.
Page 1
Error: /rangecheck in --run--
Operand stack:
   --dict:7/16(L)-- 86.363 742.734
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 2 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
   --dict:1150/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:285/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:21/40(L)-- --dict:10/15(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.70: Unrecoverable error, exit code 1
till@till-laptop:~/printing/foomatic/openprinting/mysqldb$

Ḿany printer drivers use Ghostscript directly taking PDF, so most printers will probably not print this job at all.

Printing both files directly to CUPS with "lpr" and on the HP Color LaserJet CM3530 MFP (the manufacturer PPD makes CUPS using it in PostScript mode) gets correct printouts with Aufgabe01.pdf, both on print queues set up on the local Karmic and on the remote Jaunty box. output.pdf comes out without the drawing through the queue on the remote Jaunty box and correctly through a local queue on the Karmic machine.

On Karmic there is no working "cupsfilter" utility unfortunately, it segfaults already before starting the first filters. Seems that upstream has added new functionality without testing it.

Till Kamppeter (till-kamppeter) wrote :

Running

PPD=/etc/cups/ppd/ml1610.ppd /usr/lib/cups/filter/pdftopdf 1 1 1 1 "PageSize=A4" output.pdf > pdftopdf-out.pdf
PPD=/etc/cups/ppd/ml1610.ppd /usr/lib/cups/filter/pdftoraster 1 1 1 1 "PageSize=A4" pdftopdf-out.pdf > out.raster

on Karmic generates a CUPS raster file containing the drawing.

Changed in cups (Ubuntu):
milestone: none → ubuntu-9.10
importance: Undecided → High
Changed in evince (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-9.10
Martin Pitt (pitti) wrote :

I confirm that this is evince's fault. It currently hardly manages to print just about any PDF correctly, either it spawns a gs which doesn't ever finish, or it produces broken printouts. I downgraded to jaunty's evince, and everything works fine again.

Changed in cups (Ubuntu):
milestone: ubuntu-9.10 → none
status: New → Invalid
Changed in evince (Ubuntu):
status: New → Confirmed
summary: - Does not print graphics in PDF documents; after pdf2ps it works
+ Printing produces broken PDF

The bug has been described on https://bugs.edge.launchpad.net/bugs/443026

"Lots of embedded graphics are now not printed in printed PDF documents, they just appear as a white space on paper. This never happened for me in Jaunty, so this looks like a regression in one of the PDF filters?

I attach an example document which reproduces the issue. The graphics below "Skizze" is not printed at all, if you open the document in evince and just print it.

However, if I do "pdf2ps Aufgabe01.pdf" and open/print Aufgabe01.ps with evince, it works.

Unfortunately, trying to convert it back with pstopdf, the resulting PDF doesn't print at all and just causes the print job to stay in the queue forever.

It happens with my Samsung ML-1610 with the SpliX 2.0 driver.

Reproduction recipe without a printer:

  - Open reproducing document with evince
  - Print into a PDF file
  - gs output.pdf"

*** Bug 24517 has been marked as a duplicate of this bug. ***

*** Bug 24518 has been marked as a duplicate of this bug. ***

(sorry I managed to file duplicates by retry on slow internet)

Testcase on GNOME 2.28, cairo 1.8.8:

* download http://foundation.gnome.org/reports/gnome-report-2009-Q2.pdf
* open it in evince and print to a file
* try to run gs on the printed pdf for example to send to a printer

$ gs gtkprint.pd
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 18.
Page 1
Error: /rangecheck in --run--
Operand stack:
   --dict:7/16(L)-- 61.336 763.179
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 18 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
   --dict:1150/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:285/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:21/40(L)-- --dict:5/5(L)--
Current allocation mode is local
Last OS error: 11
GPL Ghostscript 8.70: Unrecoverable error, exit code 1

Created an attachment (id=30379)
the generated pdf when printing from evince

Using cairo git seems to lead to the same issue

If ghostscript is crashing it is a ghostscript bug.

Those pdf are also crashing printers apparently, http://launchpadlibrarian.net/33023145/Aufgabe01.pdf is used as example in the ubungu bug

"

The PDF output of evince seems to be broken:

The original file Aufgabe01.pdf I can send directly ("nc -w1 <IP> 9100 < <file>") )to two PDF printers (HP LaserJet P3005, HP Color LaserJet CM3530 MFP) and it comes out very quickly. If I print into a PDF file from evince and then send the resulting output.pdf to the same two printers it takes several minutes until both report that they do not have enough memory for the job.

Also Ghostscript (both versions 8.64 and 8.70) is able do display Aufgabe01.pdf but not output.pdf. Example Ghostscript output for output.pdf:

till@till-laptop:~/printing/foomatic/openprinting/mysqldb$ gs output.pdf
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 2.
Page 1
Error: /rangecheck in --run--
Operand stack:
   --dict:7/16(L)-- 86.363 742.734
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 2 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
   --dict:1150/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:285/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:21/40(L)-- --dict:10/15(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.70: Unrecoverable error, exit code 1
till@till-laptop:~/printing/foomatic/openprinting/mysqldb$

Ḿany printer drivers use Ghostscript directly taking PDF, so most printers will probably not print this job at all.

Printing both files directly to CUPS with "lpr" and on the HP Color LaserJet CM3530 MFP (the manufacturer PPD makes CUPS using it in PostScript mode) gets correct printouts with Aufgabe01.pdf, both on print queues set up on the local Karmic and on the remote Jaunty box. output.pdf comes out without the drawing through the queue on the remote Jaunty box and correctly through a local queue on the Karmic machine.

On Karmic there is no working "cupsfilter" utility unfortunately, it segfaults already before starting the first filters. Seems that upstream has added new functionality without testing it."

Changed in evince (Ubuntu Karmic):
assignee: nobody → Robert Ancell (robert-ancell)
Martin Pitt (pitti) on 2009-10-14
Changed in evince (Ubuntu Karmic):
assignee: Robert Ancell (robert-ancell) → Ubuntu Desktop Bugs (desktop-bugs)
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Robert Ancell (robert-ancell)
Sebastien Bacher (seb128) wrote :

Heh, I'm the one who suggested undoing this change for karmic ;-) Joke aside I think it's a good workaround for now, somebody with a clue about pdfs and why some are handled correctly or not by cups should take that with the cairo or poppler guys upstream next cycle

Here I can only say the same as I already said in bug 419143:

The problem is not the fact whether evince produces PostScript or PDF output when sending a print job to CUPS but the PDF which gets sent to CUPS. This is not necessarily produced by evince, but rather by some library like GTK or Cairo. So a real fix has to be done in the appropriate library.

Another, but only partial fix would be to make evince simply passing through the input file if it is PDF. This does not cover the case of evince be used to display a non-PDF file (PostScript could also be passed through).

Making evince outputting PostScript again is only a workaround for the time being until PDF generation gets fixed. In addition, this causes other problems which we solved by switching over to PDF output. If we do this step, it only should be done in the Ubuntu package, not upstream.

Also any attempt to solve the problem by modifying the CUPS filters is only a workaround, as CUPS prints all PDF files from other sources than evince just fine.

Martin Pitt (pitti) on 2009-10-14
description: updated
Sebastien Bacher (seb128) wrote :

I've opened a cairo bug upstream too now, https://bugs.freedesktop.org/show_bug.cgi?id=24519

Changed in cairo (Ubuntu Karmic):
status: New → Triaged
importance: Undecided → High
Changed in libcairo:
status: Unknown → Confirmed
Sebastien Bacher (seb128) wrote :

The issue has been discussed with cairo upstreams on IRC, to summarize:

- the printed pdf is displayed correctly in evince or acroread which seems to indicate it's correct (they don't have better validation tool and didn't spot something wrong from a look to the file either)
- the fact that gs breaks on it is considered a gs bug
- they are happy to fix cairo issues if somebody can point what is incorrect in the pdf written

cairo 1.8.8 is also known to not deal in an efficient way with images in pdf which create slowness issues but that should be fixed in git

Changed in evince (Ubuntu Karmic):
assignee: Robert Ancell (robert-ancell) → Sebastien Bacher (seb128)
Sebastien Bacher (seb128) wrote :

I've uploaded an evince change to undo the pdf printing commit for karmic

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package evince - 2.28.0-0ubuntu3

---------------
evince (2.28.0-0ubuntu3) karmic; urgency=low

  * debian/patches/80_revert_pdf_printing.patch:
    - don't use pdf printing for karmic to wokaround cairo pdfs creating
      issues (lp: #443026)

 -- Sebastien Bacher <email address hidden> Wed, 14 Oct 2009 18:46:03 +0200

Changed in evince (Ubuntu Karmic):
status: Confirmed → Fix Released

I do not understand how it is related, but I still can not print document from evince 2.28-0-0ubuntu4
(continued from https://bugs.launchpad.net/ubuntu/+source/evince/+bug/451265 )

Changed in libcairo:
status: Confirmed → Invalid

I also encountered this problem, printing an email from evolution to a networked printer running intrepid. On the cups server I get the following error:
E [28/Oct/2009:09:15:23 +0000] PID 31032 (/usr/lib/cups/filter/foomatic-rip) stopped with status 3!

If I print the email to a pdf and print said pdf from evince I get the same error.

If I print the email to a postscript file and print resulting ps file from command line/evince it works.

This suggests to me that there is an underlying problem with generating pdfs somewhere. This is not good since it presumably will break many programs which try to print using pdfs.

crashsystems (crashsystems) wrote :

I still seem to be having a problem. I tried printing Aufgabe01.pdf on a
fresh install with all updates applied (as of 20 minutes ago). Two pages
printed, but each was blank except for what looks like gibberish at the top.
I've uploaded photos of each page to this comment, as well as the log file
generated by the troubleshoot wizard in printer configuration. The printer I
tested on is a Lexmark X652de.

It looks to me like ether this bug is not fixed, I've discovered a new bug,
or my printer hates me.

Can everyone who suffered this bug during the development period of Karmic try Janne Hyötylä's fixed Cairo packages from bug 419143? You get it through his PPA:

https://launchpad.net/~janne-hyotyla/+archive/jhyotyla

Please do the following for testing:

Before installing the package from the PPA print the failing PDFs (the ones attached to this bug report) with evince, using "Print to file" in the list of available printers and choosing PDF as output format. Then print the result to your printer using "lp <file name>" in a terminal window. The printout should fail (no images/graphics will get printed).

Then install the fixed Cairo packages from the above-mentioned PPA and do the PDF printing test again. Does the printout come out correctly (with images/graphics) now?

Max Berger (max-berger) wrote :

I can confirm that the recently released evince 2.28.1-0ubuntu1.2 fixes my printing bug (bug 479897). This was without installing the cairo package mentioned above.

Steve Beattie (sbeattie) on 2009-11-30
tags: added: karmic regression-release
removed: regression-potential
François Ingelrest (athropos) wrote :

I get the 'OFFENDING COMMAND: 0a "0a"' error for most PDFs I try to print with Evince (see #479897). Printing the same file from the command line using lpr as suggested in comment #4 works fine. This is with an up-to-date Karmic.

Everyone with the 'OFFENDING COMMAND: 0a "0a"' problem, plese see bug 419143. There is also a proposed fix. AFAIK this fix is already in the updates for Karmic. So update your system. If the problem persists after the update, please tell in bug 419143. Thanks.

Changed in libcairo:
importance: Unknown → Medium
status: Invalid → Won't Fix
summary: - Printing produces broken PDF
+ Printing produces broken PDF (missing images)
Changed in libcairo:
importance: Medium → Unknown
Changed in libcairo:
importance: Unknown → Medium
Rolf Leggewie (r0lf) on 2011-10-19
Changed in cairo (Ubuntu Karmic):
status: Triaged → Won't Fix
madbiologist (me-again) wrote :

Apparently this was a ghostscript problem, which was fixed.

Changed in cairo (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.