pdftops too slow with certain PDF files

[David Hugh-Jones]

Binary package hint: cups

The attached file won't print either from evince or lpr. Printing via xpdf causes xpdf to hang.
A debug log is attached, the relevant job number is 593.
Maybe relevant: in the document print status, the printer is shown as "Printer not connected?" However, other files print OK.

[David Hugh-Jones (davidhughjones)]

The error log isn't "finished" since the cups job just hangs and never gets printed.

[pinzia (pinzia)]

Try with https://bugs.launchpad.net/ubuntu/+source/foomatic-filters/+bug/463059

[David Hugh-Jones (davidhughjones)]

Still hangs, using today's proposed foomatic-filters (4.0.3-ubuntu2). Sorry!

[Till Kamppeter (till-kamppeter)]

The never-ending story here is the cpdftocps CUPS filter according to your error_log and this filter turns the incoming PDF into PostScript with the help of Poppler's pdftops command line utility.

So I tried to convert your file directly at the command line, using

pdftops cesifo1_wp1249-1.pdf

which takes a very long time using 100% CPU. During that time there is no even data stream, the output file, growing to a final size of around 4 MB, hangs for a long time on 2.2 MB. Perhaps the printer times out the connection while not receiving data for several minutes.

XPDF probably habgs on the same problem as pdftops as both XPDF and Poppler use the same code for rendering, and printing out of XPDF is terning the PDF to PostScript as running pdftops is.

To see whether the process is really infinite for you or simply too slow so that the printer perhaps drops the connection, try the following: Clean the queue with "cancel -a" and assure that it is enabled by enabling it with systenm-config-printer or via "cupsenable <queue>". Make sure that your CUPS logging is still in debug mode. Check also that no disk partition is full ("df -h"). Then print the job again, wait until the process seems to hang (observe your error_log). A sson as this happens, run "top" and see whether there are processes taking all or at least a significant amount of CPU and/or memory. Do "ps auxwww| grep <process number>" to obtain the full command lines of these processes. Post the command lines here.

Do not kill the print job. Leave it in the queue for at least one night. Perhaps it even finishes and prints after some hours.

[David Hugh-Jones (davidhughjones)]

OK. I followed these instructions. pdftops indeed takes 100% of CPU.

The output of ps is here:

dave@dave-laptop:~$ ps auxwww| grep 15451
lp 15451 100 0.3 8312 3476 ? R 16:53 1:32
/usr/bin/pdftops -level2 -origpagesizes /tmp/pdftops.vNPh0X -

I am leaving this to see if it ever prints; I'll get back to you.

[David Hugh-Jones (davidhughjones)]

Yup, it does print after about 8 minutes. This was one-sided.

[Till Kamppeter (till-kamppeter)]

I have done a test on simply running pdftops on the command line to convert your file and it takes more than 3 minutes:

till@till:~/ghostscript/gpl/testfiles$ time /usr/bin/pdftops -level2 -origpagesizes cesifo1_wp1249-1.pdf - > out.ps

real 3m10.118s
user 2m45.060s
sys 0m25.020s
till@till:~/ghostscript/gpl/testfiles$

So pdftops (or Poppler/XPDF in general) is too slow on converting this file. So it is a Poppler bug.

[ottadini (ben-harrison)]

Any known workarounds for this?

I have a series of student papers with many embedded images that simply won't be processed by pdftops. Well, I've waited an hour for a 3MB PDF to be processed, and my CPU is still near 100%. I'm giving up and must use another OS, as I'm not sure what I can do.

[Till Kamppeter (till-kamppeter)]

ottadini, can you attach the PDF files to this bug report?

How did you print your PDFs? From evince? From Adobe Reader? Directly ("lpr file.pdf")? try different PDF viewers and also direct printing to see whether the situation improves.

[ottadini (ben-harrison)]

Till, unfortunately I can't attach the file as it's a student's paper.

Originally I tried printing through evince, which caused the problem.
I have just tried lpr, and the documents print "normally".
I downloaded and installed Adobe Reader 9.3.2, and the documents print "normally".
(Thanks! I didn't think about Adobe Reader on ubuntu.)

[Till Kamppeter (till-kamppeter)]

So this is the known problem of evince blowing the PDF files to 10 times the size when sending them to CUPS. See bug 419143.

[Michael Gilbert (michael-s-gilbert)]

as of xpdf 3.02-9, pdftops is not provided.

[Werner Kuballa (wkuballa)]

I am experiencing the same problem when printing pdf files.

My workaround:

Use evince to "Print to File" and select "Output format: Postscript".
Open the postscript file again with evince and print from there.

[Dean Montgomery (dmonty)]

Resolved this issue by lowering and creating custom DPI values.

Default DPI from foomatic postcript PPDs is usually 600 DPI or 1200 DPI. Ghostscript `pdftops` and `gs` both take a long time converting high DPI values. The 600 DPI also creates a large postscript file which in turn are slow over the network as well as slow spooling on the printer itself. Printers have low RAM & small CPU.

When I lowered DPI to 300 the print jobs were almost instantaneous. However the print quality was degraded.

I modified the PPD files for dozen or so laser printers and found that 400DPI is identical to 600DPI in terms of print quality. With our printers I found the "sweet spot" to be 350DPI for print quality and maximum speed.

To get custom "time/quality sweet spot" DPI values, you will need to edit your PPD file:
cp /etc/cups/ppd/MYPRINTER.ppd $HOME/
Edit MYPRINTER.ppd 'Resolution' section and add 350 and 400 DPI.

*DefaultResolution: 350x350dpi
*Resolution 150x150dpi/150x150 DPI: "<</HWResolution[150 150]>>setpagedevice"
*Resolution 300x300dpi/300x300 DPI: "<</HWResolution[300 300]>>setpagedevice"
*Resolution 350x350dpi/350x350 DPI: "<</HWResolution[350 350]>>setpagedevice"
*Resolution 400x400dpi/400x400 DPI: "<</HWResolution[400 400]>>setpagedevice"
*Resolution 600x600dpi/600x600 DPI: "<</HWResolution[600 600]>>setpagedevice"

You may want to update the ModelName, ShortNickName and NickName to indicate that this file has been modified.

You can then either use the web interface to upload your custom ppd file or copy it to /usr/local/share/ppd/MYPRINTER.ppd
Then restart cups service. Your custom PPD option will then appear in the pick-list when Modify Printer.

Once the PPD is installed then go to the Default Options to set the DPI Resolution. You may want to test the timing/quality for 300, 350, 400, 600. I had 2 printers where 300DPI quality was just as good as the 600 DPI.

If an end-user enjoys the long print delay so they can socialize at the printer - or enjoys burning CPU cycles imagining that their 1200dpi is actually "better quality", then all they have to do is increase the DPI setting on the print dialog before they send their job.

[Till Kamppeter (till-kamppeter)]

Also reported upstream as:

https://bugs.linuxfoundation.org/show_bug.cgi?id=1245

[Till Kamppeter (till-kamppeter)]

Dean, please do not post such things on arbitrary old bugs, better report a new bug for them.

As you have already posted this upstream, it is not needed to post a new bug on Launchpad.

[madbiologist (me-again)]

Seems to be fixed in Ubuntu 14.04 "Trusty Tahr".

time /usr/bin/pdftops -level2 -origpagesizes cesifo1_wp1249-1.pdf - > out.ps

real 0m1.223s
user 0m1.192s
sys 0m0.016s

ls -lh out.ps
-rw-rw-r-- 1 mainuser mainuser 4.2M Sep 22 03:38 out.ps