Printing from evince (and perhaps other GTK apps) to PostScript printers is broken ("0a" bytes inserted into PostScript output)

I have done some tests and printing with the PPD for the LJ 4100 which you are using works for me on the LJ 3390 and the LJ P3005 (both on the network, CUPS version 1.4.0 from Karmic).

Can you attach the files which you did not succeed to print and can you also create an error_log as described in the "CUPS error_log" section of

https://wiki.ubuntu.com/DebuggingPrintingProblems

If you have CUPS 1.4.0 already, the USB problem is caused by a new USB CUPS backend. For this backend the "usblp" kernel module must be unloaded.

Edit /etc//etc/modprobe.d/blacklist.conf adding a line

blacklist usblp

and then run the command

sudo rmmod usblp

Now CUPS should see your USB printers again.

Attached is a PDF where this error occurs when printing from evince. Printing the same file from okular works perfectly.

Most of my PDFs get this error from evince.

Incidentally, this PDF gets printed correctly (I just picked a random PDF from the ubuntu site):
http://www.ubuntu.com/files/server/UbuntuServerBrochure804LTS.pdf

Attached is the cups error_log with print job 39 from evince (1 page, error) and job 40 from okular (2 pages, correct printout).
The okular printout is duplex although in the okular printing options duplex was set to "none".

Forgot to mention: I'm running the latest cups now
$ apt-cache policy cups
cups:
  Installed: 1.4.0~svn8773-1
  Candidate: 1.4.0~svn8773-1

And regarding USB I just wanted to say that I have no opportunity to plug the printer in the USB (company shared printer), not that I have a problem with USB in this case.

Also adding evince to affects.

I'm seeing this problem on the (networked; not local USB) HP LaserJet 4100 in the office. I suspect it's also going on with the LaserJet 5M in the office, which just silently discards the print job. Unfortunately, that's 0 out of the two printers that I can use.

Attaching a bunch of pdfs that trigger the bug for me. Also, I think that "low" really underestimates the importance of this bug. If people upgrade to Karmic and can no longer print, they are going to be cheesed (not to mention that I suspect that the problem is much more widespread than just this printer).

This bug appears to be fixed in current karmic. Can anybody confirm?

Can everyone who still has problems post his PPD file (/etc/cups/ppd/<printer>.ppd)? Thanks.

Looks that this is a bug in HP's PostScript interpreters. I have tried to print the file XAFSPhoton_estimate.pdf (attached to comment #4) and it does not print on my HP LaserJet 3390 if I use any PostScript PPD file (tried the onr for the LaserJet 4100 and for the LaserJet 3390). Only way to get it printed is setting up a PCL-based print queue ("pxlmono" driver) or not using evince.

Looking into the generated PostScript file it seems that the HP printers are not able to parse the embedded fonts. The offending 0a is in the beginning of the second binary code line of

%%BeginResource: font CairoFont-0-0
%!PS-AdobeFont-1.0: NimbusRomNo9L-Medi 1.06
%%Title: NimbusRomNo9L-Medi
%Version: 1.06
%%CreationDate: Thu Aug 2 13:15:44 2007
%%Creator: frob
%Copyright: Copyright (URW)++,Copyright 1999 by (URW)++ Design &
%Copyright: Development; Cyrillic glyphs added by Valek Filippov (C)
%Copyright: 2001-2005
% Generated by FontForge 20070723 (http://fontforge.sf.net/)
%%EndComments

FontDirectory/NimbusRomNo9L-Medi known{/NimbusRomNo9L-Medi findfont dup/UniqueID known pop false {dup
/UniqueID get 5020933 eq exch/FontType get 1 eq and}{pop false}ifelse
{save true}{false}ifelse}{false}ifelse
11 dict begin
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0 ]readonly def
/FontName /CairoFont-0-0 def
/FontBBox {-168 -341 1093 960 }readonly def

/PaintType 0 def
/FontInfo 9 dict dup begin
 /version (1.06) readonly def
 /Notice (Copyright \050URW\051++,Copyright 1999 by \050URW\051++ Design & Development; Cyrillic glyphs added by Valek Filippov \050C\051 2001-2005) readonly def
 /FullName (Nimbus Roman No9 L Medium) readonly def
 /FamilyName (Nimbus Roman No9 L) readonly def
 /Weight (Bold) readonly def
 /ItalicAngle 0 def
 /isFixedPitch false def
 /UnderlinePosition -100 def
 /UnderlineThickness 50 def
end readonly def
/Encoding 256 array
0 1 255 {1 index exch /.notdef put} for
dup 8 /space put
dup 31 /two put
dup 7 /colon put
dup 5 /A put
dup 1 /B put
dup 4 /C put
dup 19 /E put
dup 21 /F put
dup 30 /P put
dup 22 /S put
dup 6 /T put
dup 20 /X put
dup 9 /a put
dup 29 /b put
dup 11 /c put
dup 12 /e put
dup 17 /f put
dup 25 /g put
dup 13 /h put
dup 2 /i put
dup 27 /l put
dup 24 /m put
dup 14 /n put
dup 3 /o put
dup 26 /p put
dup 15 /q put
dup 18 /r put
dup 10 /s put
dup 23 /t put
dup 16 /u put
dup 28 /x put
readonly def
currentdict end
currentfile eexec
f983ef0097ece61cf3a79690d73bfb4b0027b850f3158905fdac1bc024d7276e
0a12b7ddcede59e3601ab4509dfe0977ed5bf624ebc1f818c45f1350d41b052a
72743accb053eb06ed043568d3196a30bed220227e2a15bacef508449221cf33
8a8666e92410a9aa91d5a31900a93c01ec21742cd14dc46bffa111ce10b78ae0
1abaeba7f36cdf79a4733245c63f6d36234d6b0961f1ac295d6177931b9ed554
bb5fc6741a63c493daabf03d753c7d2b8e8c01e3e280898f810da5985212c8c0
[...]

Attaching ppds

I take back the statement that the bug was fixed for me. I thought I had much less printing problems now than before, but maybe it was just coincidence. Trying to print XAFSPhoton_estimate.pdf gives me the same old error.
PPD attached.

I have this error on a Kyocera KM-2560 printer.

And the Kyocera KM-2560 PPD.

This error appears in Karmic only, I can print flawlessly in Jaunty.

The title of this bug report is misleading, should we change it from HP Laserjet 4100 specific to some a general title?

Same problem here, cannot print from evince to a Kyocera FS-1030D.

I think this needs to be higher priority. Businesses are the ones with PostScript printers, and I suspect they'll be upset to have print jobs randomly failing.

In other news, I suspect that the error is related to image (bitmap) data. Scanned text and some articles (not all) fail. I've not sorted out which of the last vjnano articles last week failed to print, but I have a hunch that they're the ones that have bitmap figures.

I thought the problem had been solved for me, but the PDFs posted by GiuseppeVerde still trigger the bug. I attach my PPD.

I do not understand the workaround described by Till Kamppeter in my original bug report ( https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/439384/comments/2 )

Eduard Grebe, note that my comment does not describe a workaround, it only tells that on your printer you can turn on a mode so that the printer prints error messages. You can turn it on on the printer, to see whether you get the same messages as the original poster.

I can confirm this problem on my kyocera fs-c5100dn. I'm getting the same error. (offending command: 0a)
As a workaround I downgraded evince to 2.26.1 (jaunty's evince version).
( what two minor versions can do... :) )

Hi,

I have a similar issue with my Brother HL2070N (which is not a postscript printer I think).

When printing from evince, it fails silently. When printing the same file.ps from gv, it works perfectly. So, I would say it is not a config problem, and probably not a cups bug.

Note that the test page is correctly printed from system-config-printer.

Pascal

I have continued to experience problems printing to HP Laserjet P3005dn. However, the problems seem to disappear when I use a different PPD called "CUPS+Gutenprint v5.2.4" which is one of the 3 options listed in the list of PPDs in the add printer tool. The two others, the default and one labeled "hpljs" do not work.

I suppose, that it's not a bug of evince but a feature... Since version 2.27.4 in ev-print-operation.c the lines

export->fc.format = file_format && g_ascii_strcasecmp (file_format, "pdf") == 0 ?
                        EV_FILE_FORMAT_PDF : EV_FILE_FORMAT_PS;

changed to

if (file_format) {
                export->fc.format = g_ascii_strcasecmp (file_format, "pdf") == 0 ?
                        EV_FILE_FORMAT_PDF : EV_FILE_FORMAT_PS;
        } else {
                export->fc.format = gtk_printer_accepts_pdf (printer) ?
                        EV_FILE_FORMAT_PDF : EV_FILE_FORMAT_PS;
        }

so that evince > 2.27.3 sends pdf-file (if print system supports pdf-input) even if file_format is NULL what ever - I don't understand it completely...
In the case of the problematic files evince sends pdf-files since version 2.27.4 and ps-files in earlier versions. This change causes the problem. But the bug probably lies not in evince?!?

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.

As workaround for bug 443026 a new evince package got uploaded which returns to sending PostScript and not PDF to CUPS when printing. Please try this version and tell whether it also solves the problem described here.

Well, it worked for me ! It's probably better to have such a temporary
workaround than a non functional evince. Thanks for your work !

Pascal

2009/10/15 Till Kamppeter <email address hidden>

> As workaround for bug 443026 a new evince package got uploaded which
> returns to sending PostScript and not PDF to CUPS when printing. Please
> try this version and tell whether it also solves the problem described
> here.
>
> --
> Printing from evince (and perhaps other GTK apps) to PostScript printers is
> broken
> https://bugs.launchpad.net/bugs/419143
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Pascal, thank you, good to know that the workaround for Karmic works. So I am closing this bug for Karmic. I hope for Lucid we will get a real fix.

todays updates (2.28.0ubuntu4) doesnt seem to help the issue (was the fix reverted ?!?).
*photon* and some of my pdfs still will fail to print with ps "error undefined command 0a" on my brother dcp-8065n - otoh okular will print them without issues.
laymans question: doesnt this hint that indeed evince/gtk/gnome etc is faulty and neither gs nor cups ?

Maybe the bug you encountered is different from mine, because in my case
evince failed silently to print, and now it works again. I never had an
error message (but the printer made its caracteristic "heating noise" each
time, as it probably received something, just didn't know how to deal with).

Pascal

2009/10/16 Thomas Jagoditsch <email address hidden>

> todays updates (2.28.0ubuntu4) doesnt seem to help the issue (was the fix
> reverted ?!?).
> *photon* and some of my pdfs still will fail to print with ps "error
> undefined command 0a" on my brother dcp-8065n - otoh okular will print them
> without issues.
> laymans question: doesnt this hint that indeed evince/gtk/gnome etc is
> faulty and neither gs nor cups ?
>
> --
> Printing from evince (and perhaps other GTK apps) to PostScript printers is
> broken
> https://bugs.launchpad.net/bugs/419143
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@pascal:
i dont think so, it seems that some printers will print an error page while others are just sitting quietly or give some error on their displays.
but i cant understand that your problem is gone while mine (and others like https://bugs.launchpad.net/ubuntu/+source/cups/+bug/443026/comments/14 suggests) are still around.

Yes, you must be right, I did actually have a blinking led on the printer
(but as the printer isn't in the same room I had to run to see it).

Pascal

2009/10/16 Thomas Jagoditsch <email address hidden>

> @pascal:
> i dont think so, it seems that some printers will print an error page while
> others are just sitting quietly or give some error on their displays.
> but i cant understand that your problem is gone while mine (and others like
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/443026/comments/14suggests) are still around.
>
> --
> Printing from evince (and perhaps other GTK apps) to PostScript printers is
> broken
> https://bugs.launchpad.net/bugs/419143
> You received this bug notification because you are a direct subscriber
> of the bug.
>

XAFSPhoton...pdf from comment 4 still does not work with my HP Laserjet 4100 (PPD in comment 15) and Postscript drivers. Same error as originally reported.

It's a bug in evince, closing cups task.

In Karmic we got the workaround to produce PostScript instead of PDF from evince, which should mitigate the situation.

What does this mean?
It still does not work for me (as the bug reporter). Or is there something I'm missing? (i.e. I have to use a specific driver or other settings to make it work)

I have checked the output and both the PostScript directly generated by evince and the PostScript which is generated when converting evince's PDF to PostScript generates the offending embedded font code. This means that this bug is not covered by switching evince from outputting PDF to outputting PostScript.

Wwe need a real fix of GTK's or Cairo's PDF AND PostScript output.

A good workaround would be to make evince simply passing through the input files to the print queue if they are PDF or PostScript.

It's claimed here that the bug is in evince, but I don't actually see the evidence. The "bad" PDFs produced by evince display render perfectly in evince, xpdf, and gs; the output of pstopdf on those files also renders perfectly in evince and gs. It's just the printer that is complaining.

It seems to me that *if* the PDF/PS files evince is generating are legal, and just happen to trigger a printer bug, then it's really cups' job to work around that printer bug, not evince's to somehow intuit what sort of printer the file will eventually be sent to after being passed through some set of filters they have no control over.

Of course, it maybe be that evince/xpdf/gs are in just lenient when displaying stuff, and evince is actually generating buggy PDF/PS, in which case it should be fixed. But to make that argument surely we need someone to actually look at the postscript spec and figure things out.

Hello

I just want to confirm this bug in the latest release of lucid (x86), with:

cups 1.4.3-1ubuntu1.2
libpoppler-glib4 0.12.4-0ubuntu5
libpoppler5 0.12.4-0ubuntu5
poppler-utils 0.12.4-0ubuntu5
ievince 2.30.3-0ubuntu1.1

using acroread as an alternative (although its non-free) solves the problem.

Greets Thomas

Thomy23, can you post files which did not print out of evince for you?

Hi

Unfortunately i can't do this because the documents contain confidential information. Can i help you in some other way to solve the problem?

I have the same problem; my printer prints out a page when trying to print an affected PDF which reads:

PCL XL Error

        Subsystem: KERNEL

        Error: MissingData

        Operator: ReadImage

        Position: 15

This is with a Brother HL-2170W laser printer, with the PPD generated by foomatic. I'm also running lucid, and can reproduce the issue on both x86 and x86_64 systems (netbook and workstation, respectively).

Also, as others mentioned, the same documents print perfectly via Adobe Acrobat Reader.

Derrik, your problem is bug 570027. I have already prepared the fix (in foomatic-db). I will upload it as soon as the beta freeze is over. For the time being set up an additional print queue using the "Generic PCL-5e printer" as make and model and hpijs-pcl5e as the driver.

Derrik, bug 570027 is fixed now.

Thomy23, can you take the application with which you created the confidential documents and create non-confidential sample documents? Or can you modify the confidential documents to remove the confidential data?

Although it's not this bug (the solution to the remainder of this bug lies in the info in comment #109), the file size blowing up issue should be fixed with Ubuntu 10.10 "Maverick Meerkat", which contains libcairo2 1.10.0-1ubuntu2. Karl, Eero and steba, can you test?

Having 1.8.10-2ubuntu1 installed, this bug still affects me. I had no problem printing with Ubuntu 9.04, but 10.04 refuses to print some PDFs from evince. The hp LaserJet 2200 tells "getting data" all the time, but does not start printing - even for a 28 kb PDF.

smarf, can you attach the files which do not print?

Can you print these files using Maverick (try a live CD if you do not want to update).

If this get's fixed in 10.10, can the fix be back-ported to 10.04 LTS?

I am in charge of a business deployment where we are experiencing this bug but we are sticking with the LTS release for obvious reasons.

I don't see this issue anymore with Ubuntu 10.10.

I would like to confirm the above mentioned problem in 10.10 issue. I have x64 version installed and I use Samsung ML 2010 printer.

Regards

MH

Everyone who has still problems, do the following:

1. Attach the file which does not print.
2. Follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems
3. Convert the captured print data to PostScript with the "pdftops" command.
4. Tell us the size of the original file, the captured print data, and the resulting PostScript file.
5. Attach all files. Do not hesitate to attach big files. Attach the files one by one, do not package them together and do not compress them. Only if the resulting PostScript file is so big that it takes you hours or days to upload, do not upload it.
6. Naturally tell us which printer and driver you are using.

Note that this bug is only about the spurious "0a" in Cairo-generated PDF. It is only still open because there are still "0a" cases in Cairo. See comment #109.

If you have other problems with Cairo-generated PDF, please continue in bug 680628. Especially answer the questions of my previous comment there.

If there are still cases of cairo causing "0a" errors I will need to see the PDF file to fix. Looking back over the comments there were a few comments saying they still had the "0a" error after the update but none of them supplied the PDF file that reproduces the problem.

Four days ago I unsubscribed to this list as I hadn't had this problem in months and assumed it was fixed. Today, I tried printing a calendar and discovered the bug still exists.
I'm running Ubuntu 10.10, fully patched as of this afternoon (Dec. 11, 2010).
The problem surfaces when I try to this PDF from Document Viewer. I've had to resort to using Okular.

When I print it from Document viewer, the printer light flashes to indicate that it is receiving data, but nothing ever prints. Printing from Okular works fine.

For what it's worth, the calendar is formatted for 11x17" paper but I was trying to print it to legal size pages. I'm not sure if it's the printer or the computer that does the appropriate scaling, in case that has anything to do with it.

calendar.pdf works for me on all the printers I have.

- What sort of printer do you have?
- Do you have problems printing other PDF files?
- Have you tried any of the steps in comment 95. Attaching the PS file that does not print with "lpr -o raw" would be helpful
- Is your printer configured to print PS errors?

Are you able to print PDFs created with gedit that use the same fonts as calendar.pdf? ie open gedit, enter some text, print to PDF ensuring that in the "Text Editor" tab of the print dialog the fonts used are NimbusSanL-Regular and NimbusSanL-Bold.

I'm using a Laserjet 2605dn. The problem was happening consistently (6 attempts) and continued after a reboot of the printer. I was also using Document Viewer 2.32.0 to view and print the calendar.

When Okular worked, I chalked it up to a problem with Document Viewer or some component thereof.

It's now about 5 hours later and I just tested it again but this time I *can* print it from Document Viewer.

I hate intermittent problems.

If it is intermittent it is not this bug. I had intermittent problems with printing to my LaserJet 4050 after upgrading to 10.10. It turned out to be bug 229981 which I fixed by changing the connection type to AppSocket/HP JetDirect.

LEGOManiac, also note that this bug is only about spurious insertions of "0a" into the PostScript output. You can most easily find out about that if you activate error page printing in your printer, but this problem should always occur and not disappear after some hours as you have observed. So your problem is not the one described here.

"0a" bug for pdf with embedded .jpg image

present in 9.10 (my computer)
NOT present in 10.04 (coworkers computer)

good job guys! (And I need a new computer)

I'm having a similiar bug with a Brother HL 5270DN, regardless whether configured as USB or network printer. Printing PDFs with GTK applications, or printing from firefox, both sometimes result in one page being printed with the following content:

--8<--8<--8<--
ERROR NAME;
         undefined
COMMAND;
          Q
OPERAND STACK;
-->8-->8-->8--

This bug happens both on up-to-date Debian unstable and Ubuntu Natty. I already discover this bug with Debian for years, and unfortunately I now discovered it on Ubuntu Natty as well.

Forgot to mention, that same PDF documents that print this error with evince, print fine with okular.

Reseting triage states

I'm also seeing this in Ubuntu Natty (11.04) when printing _some_ pages from Firefox to a Brother HL-5250DN. Other pages work OK. This may or may not be related to a long-standing problem with this printer whereby the 2nd and subsequent jobs sent to the printer without a printer power-cycle or printer reset will result in garbled text.

In Oneiric we will switch to Ghostscript for the pdftops filter, so the 0a byte contamnination should stop there.

Everyone who has still problem on Natty, please give exact instructions to reproduce the problem. Especially follow the instructiopns in the section "Capturing print job data" in https://wiki.ubuntu.com/DebuggingPrintingProblems.

AFAIK Firefox prints via Cairo, so no extra task needed.

I'm experiencing this problem on Ubuntu 11.10 oneiric with a PDF file printed from evince:

ERROR:
undefined
OFFENDING COMMAND:
 0
STACK:
-mark-
-mark-
-mark-
-mark-

The same file printed with Okular works fine.

svenmeier, can you post the PDF file with which you experience this problem? Can you also follow the instructions in the sections "CUPS error_log" and "Capturing print job data" of https://wiki.ubuntu.com/DebuggingPrintingProblems? Thanks.

PDF causing the issure.

printout as requested

Error log as requested.

svenmeier, the original bug reported here was that Poppler's pdftops is generating broken PostScript in your case foomatic-rip calls Ghostscript to turn PDF into PostScript. So I tried to isolate the problem with

pdf2ps printout

where pdf2ps is a simple wrapper script which comes with Ghostscript to turn PDF into PostScript and printout is your "printout" file. The resulting PostScript is broken, easy to see with

gs printout.ps

This is a bug in Ghostscript upstream which I have reported now as

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

Please subscribe to that bug report and supply additional information if the Ghostscript develkopers ask for it.

Hi Till, thanks for your analysis and forwarding the bug :).

I have reported Sven Meier's bug also on Launchpad as bug 890270 now, for an Oneiric SRU.

Official support for Ubuntu 11.04 "Natty Narwhal" has ended. Can we close this bug?

Yes, let us close this ...