PDF printing from Evince through CUPS is very slow, sometimes fails

[Louis Bouchard]

When printing a PDF document from Evince using a CUPS defined printer, printing the document takes very long (up to 30 minutes). The ghostscript process runs at 100% CPUTIME.

Here is the captures ghostscript command of one of the print test :

gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDEVICE=pxlmono -r600x600 -sPAPERSIZE=a4 -sOutputFile=- /var/spool/cups/tmp/foomatic-AA6FvH

This is the only evidence that ghostscript is responsible for the problem. Backporting the cups-1.4.5.3 would remove gs out of the equation, hopefully fixing the problem.

Reproducible: 100%

Workaround:

Use the acroread PDF viewer which does not show this problem

Request:

PDF conversions using ghostscripts have been identified by previous bugs (LP#668800 ) and have been fixed in cups 1.4.5.3 by using poppler instead of ghostscript. We believe that a backport of the solution already present in Maverick/Natty to Lucid might solve the problem

[Lars Karlitski (larsu)]

Thanks for reporting this bug. Unfortunately, I can't reproduce it on my machine. Can you please attach the file which causes ghostscript to take this long (if it doesn't contain any sensitive data).

[Louis Bouchard (louis)]

@Lars,
Here is a sample file, encrypted with your GPG key.

[Louis Bouchard (louis)]

For info, I have not been able to reproduce it on my test system, but I have seen it happen on multiple printer types, from multiple systems.

[Lars Karlitski (larsu)]

Ghostscript renders the attached file in less than 200 ms on my system.

I've also tried all of the other output devices of ghostscript, none needed more than a few seconds to produce an output (some produced an error though, because of missing hardware).

Can you remember on which systems (i.e. which printer and driver) you saw this problem on?

[Till Kamppeter (till-kamppeter)]

On the way from Lucid to Oneiric, two bugs have been fixed:

bug 668800: Printing speed problem

Here we switched from Ghostscript to Poppler at first, via cups 1.4.5-3. In Oneiric we got fixes for Ghostscript (9.04) and returned to using Ghostscript.

bug 680628: Unable to print a document with evince, works correctly with Adobe Acrobat Reader

Here fixes in both Cairo and Poppler got applied in Natty.

So a possibility would also be to backport the CUPS change to make Poppler being used or to backport the fixes on Cairo and Poppler. Probably we should start with the CUPS package as this would be the easiest solution.

[Till Kamppeter (till-kamppeter)]

I have checked bug 668800 and the fix on CUPS there only replaces the pdftoraster filter by a Poppler-based one, which means that for a print queue using pxlmono this does not give an improvement. So the possible fixes to try are backporting Ghostscript 9.04 and applying the fixes to Poppler and Cairo.

[Till Kamppeter (till-kamppeter)]

I can reproduce this bug after installing the Lucid desktop CD image in a virtual machine (kvm-qemu, see https://help.ubuntu.com/community/KVM) with the GUI virt-manager. In this environment I have created a printer printing to a file (I have run "cupsctl FileDevice=yes" before), using the URI file:/tmp/printout. As model I have selected the "Generic PCL-6/XL printer" and as driver "Foomatic/pxlmono". Then I have opened the file from comment #2 with evince and printed it to said print queue. I have done this 10 minutes ago and Ghostscript is still running with 100% CPU. The Ghostscript command line is practically the same as in the initial description of this bug.

[Till Kamppeter (till-kamppeter)]

I have done some tests by using different combinations of Lucid and Oneiric for the two steps evince creating the print job (it is already PDF in Lucid) and Ghostscript rendering the PDF to PCL-XL using the command line shown in the initial description of this bug.

First off, adding "-dNOINTERPOLATE" does not give any speed advantage for the "pxlmono" driver which is a vector driver. It seems only to accelerate rastering as it is done for raster drivers like "cups" or "ljet4". This is valid for both Lucid and Oneiric.

Then I have let evince generate PDF print output (can be done as described in "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems or by selecting "Print to file" as the printer and PDF as output format) on both Lucid and Oneiric. In Lucid the file is huge compared to the original PDF:

till@till:~/ghostscript/testfiles$ ll M170931*
-rw-r----- 1 till till 1649229 2011-11-25 12:13 M170931-evince-lucid.pdf
-rw-r--r-- 1 till till 63510 2011-11-25 12:13 M170931-evince-oneiric.pdf
-rw-rw-r-- 1 till till 61019 2011-11-24 18:36 M170931.pdf
till@till:~/ghostscript/testfiles$

Then I ran the resulting PDF of Lucid through the command line of the bug description on both Lucid and Oneiric. Under Lucid Ghostscript errored out after around 12 minutes, probably running out of memory (virtual machine is 64-bit with 2G of RAM). On Oneiric (on the host of the virtual Lucid machine) the PDF was correctly rendered in around 4 minutes, also not very fast, but one sees at least some acceleration and higher reliability with the new Ghostscript.

Next step was running Oneiric's print job through Ghostscript on both systems. The rendering of Ghostscript was significantly faster, on Lucid I got correct rendering in around five seconds and on Oneiric it took less than 1/10 of a second.

This means that the best effect will be reached by backporting Oneiric's Cairo and Poppler. Perhaps it is even enough to only apply the patches of bug 680628 to the Lucid packages. This could even be issued as an SRU for all users. It must be tested whether these changes are the only fixes for output file size and rendering speed issues or whether there are more fixes in evince/cairo/poppler.

[Louis Bouchard (louis)]

@Till

Thank to your description of how you setup your test printer, I'm now also able to reproduce the behavior and get a gs process running at 100% cpu.

I tested the Oneiric backported Ghostscript packages that I was able to create but I still get the same behavior.

Last test was to use pdftops (from poppler-utils) to convert to PS. Then the .ps file prints in seconds.

HTH,

...Louis

[Till Kamppeter (till-kamppeter)]

I have tried to backport the patches of bug 680628. The patch on Poppler applies and so the backport would most probably work, but the patch on Cairo does not work. The part where the patch has to be applied seems to be completely rearchitectured and and also a backport of the whole Cairo package from Natty was not possible as the Natty package needs a lot of newer libraries and so the backport attempt could lead to major parts of Lucid being replaced by Natty ...

If I try to build the Cairo package of Natty on Lucid I get:

dpkg-checkbuilddeps: Unmet build dependencies: dh-autoreconf libxrender-dev (>= 1:0.9.5-2) libx11-dev (>= 2:1.3.3-2) libpixman-1-dev (>= 0.18.4)

dh-autoreconf is a new concept introduced after Lucid, the other versioned dependencies are most probably new libraries with new APIs.

As the real fix would be to somehow introduce the Cairo and Poppler fixes of bug 680628 into Lucid, I move this bug to Cairo and Poppler. Perhaps someone more expert in Cairo can solve the problem.

[Till Kamppeter (till-kamppeter)]

Adrian, can you try to get the patches which you have found for bug 680628 backported to Lucid (or Cairo from Natty)? Thanks.

[Chris J Arges (arges)]

I have been able to reproduce inside of a Lucid VM. Attached is the error_log file from /var/log/cups/error_log .

[Chris J Arges (arges)]

Is this bug related: https://bugzilla.redhat.com/show_bug.cgi?id=633848 ?

[Till Kamppeter (till-kamppeter)]

Please try the following:

Comment out the line

*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip"

in the PPD file of your print queue and restart CUPS after editing the PPD file. Does printing now work?

[Till Kamppeter (till-kamppeter)]

If the problem does not go away following the instructions of the comment above, please attach a new error_log to see what is going wrong now.

[Chris J Arges (arges)]

Per Till's suggestion, I commented out a line in /etc/cups/ppd/Generic-PCL-6-PCL-XL-Printer.ppd:

*%cupsFIlter: "application/vnd.cups-pdf 0 foomatic-rip"

error_log_2 shows the error log when printing from this method.
This also seems to give me an error when printing.

[Till Kamppeter (till-kamppeter)]

According to the attached error_log this time your print job got done correctly. Ghostscript did not error out. If something is wrong on the printout, you will probably need to install the backport of Ghostscript 9.04 (with all SRUs or current Precise version). This solves a lot of rendering problems.

[madbiologist (me-again)]

Official support for Ubuntu 10.04 "Lucid Lynx" has ended.