Printing produces broken PDF (missing images)

error log with debug mode

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>
---------------------

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.

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.

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.

Martin suggest the following commit may be to blame:
http://git.gnome.org/cgit/evince/commit/?h=gnome-2-28&id=2eedce4d1c281bde50edf87ec00821c1d10bd751

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.

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

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

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

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

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 )

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.

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.

It is a bug in ghostscript

http://bugs.ghostscript.com/show_bug.cgi?id=690823

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?

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.

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.

Apparently this was a ghostscript problem, which was fixed.