Printing problems with Firefox

[jpakko]

I'm having a problem (sometimes, not always) printing from Firefox. But it's not really a Firefox problem, it's a case of incompatibility between cairo and ghostscript. From reading CUPS error logs and source code and massive amounts of googling, I have an idea where the problem is:

When Firefox prints, it first uses cairo to generate a PDF file, then CUPS invokes ghostscript's pdf2ps filter to create a postscript file. It processes the postscript file some more before it sends anything to the printer. Unfortunately, in some cases, cairo creates a PDF file that ghostscript can't understand, and it bombs. Then you wait in vain for your printout.

I can test this theory by printing to a PDF file, then trying to print it with lp. It doesn't work. Running pdf2ps on the file produces a segmentation fault. However, if I print to a PS file, lp works fine.

This printing method is not at all unique to Firefox; in fact it's standard, so the problem may not be limited to Firefox, though I haven't had problems with anything else.

I can think of several things that could be done, that may or may not solve the problem:

1. Update the ghostscript extension to the latest version (9.04). This may work, but it may not. It's probably a good idea anyway. Please.

2. Recompile cairo, using options to tell it to create PDF-1.4 files instead of PDF-1.5. I think this is possible, but I'm not sure. I'm not sure if it would work either.

3. Recompile the CUPS filters to use pdftops from the poppler-bin package instead of ghostscript. I'm sure this is possible, and I'm also pretty sure it would work. Files that gs segfaults on, pdftops handles fine. CUPS would then depend on poppler-bin though, and I think you would still need ghostscript.

I've attached one of the PDF files that causes trouble.

[Juanito]

Yeah ... this whole cups thing was always difficult, but lately it's been getting really, really painful.

If you take Debian as an example:

http://packages.debian.org/wheezy/cups

..they seem to take a scatter-gun approach and include (or recommend) absolutely everything that might be even remotely necessary 

I'll look at updating ghostscript in the next few days <sigh>

[SamK]

Yeah ... this whole cups thing was always difficult, but lately it's been getting really, really painful.

If you take Debian as an example:

http://packages.debian.org/wheezy/cups

..they seem to take a scatter-gun approach and include (or recommend) absolutely everything that might be even remotely necessary 

An undeveloped idea...

How about submitting a CUPS meta package to the repository? 

It might operate in a similar manner to multicore v4.1, i.e. provide everything that might be needed to obtain a successful printing set-up.  Perhaps guidance might be given in  the meta info file on how to remove unnecessary dependencies once printing is working OK.

It might help reduce the number of support requests.

[netnomad]

hi friends,

How about submitting a CUPS meta package to the repository? 

It might operate in a similar manner to multicore v4.1, i.e. provide everything that might be needed to obtain a successful printing set-up.  Perhaps guidance might be given in  the meta info file on how to remove unnecessary dependencies once printing is working OK.

It might help reduce the number of support requests.

i agree to samk that it would be good to offer a cups_meta-package that includes a set of standard configurations.
i packaged a cups_meta.tcz for me personally,
because i had some trouble with unrecognized dependencies in a minimal environment.
that means always when i loaded only a few basic packages, i experienced cups-problem that
disappeared when i loaded packages with lots of dependencies.
f.e. a lean desktop only with firefox or only with thunderbird or only with a image-viewer had print problems.
after loading more packages these problems vanished...
finally i noticed that i need in a very lean environment with few packages poppler-bin as a not mentioned dependency:
so for me many hardly to solve problems disappeared after i added poppler-bin as a dependency!

the dep-list for my cups_meta looks like that:
poppler-bin.tcz
foomatic-rip.tcz
ghostscript_common.tcz
ghostscript.tcz
gutenprint.tcz
cups.tcz
cups-pdf.tcz

perhaps these hints offer you some success for your problems!?

[jpakko]

Just to be clear, I don't think my problem is that I don't have enough dependencies loaded. Printing works most of the time. I have loaded:

poppler-bin.tcz
foomatic-rip.tcz
ghostscript_common.tcz
ghostscript.tcz
cups.tcz

CUPS doesn't use poppler-bin as it's currently configured, but it will if HAVE_PDFTOPS is defined at compile time. I tried loading cups-pdf.tcz but that didn't solve the problem, and since I can still print to PDF or PS files without it, I couldn't quite figure out what it's supposed to do.

I've learned a couple of things that seem like they might be relevant. Using PDF as the standard input format for CUPS is a fairly recent thing. It used to be postscript. Also, cairo has created PDF-1.5 files only since vers. 1.10.0. It used to make PDF-1.4 files. This seems to have caused some pain; search the ghostscript bug reports for "cairo".

[Juanito]

I've attached one of the PDF files that causes trouble.

I updated ghostscript, ghostscript_common, libgs, libgs-dev to 9.04

pdf2ps will convert your stuck0.pdf and cups will print it without problems - maybe you could give it a try?

[jpakko]

Yes, everything works well now. Thank you very much.