Comment 117 for bug 419143

Karl Frisk, problem are file conversions which blow up your file more and more so that the PostScript sent to the printer is to big for the printer's memory. I have a LaserJet P3005 with extended memory and this printer prints the file but needs several minutes per page, probably due to the huge Postscript being sent. One can easily reproduce the problem without using CUPS:

First, your file:

till@till:~/ghostscript/gpl/testfiles$ ll 10.1.1.65.8661-1.pdf
-rw-r--r-- 1 till till 2256496 2010-03-04 12:49 10.1.1.65.8661-1.pdf
till@till:~/ghostscript/gpl/testfiles$

Then I print into a PDF file with evince:

till@till:~/ghostscript/gpl/testfiles$ ll x.pdf
-rw-r--r-- 1 till till 25530177 2010-03-04 13:15 x.pdf
till@till:~/ghostscript/gpl/testfiles$

This is 10 times bigger than the original. Now I convert this to PostScrip, using Poppler's pdftops utility (CUPS uses it, too):

till@till:~/ghostscript/gpl/testfiles$ ll x.ps
-rw-r--r-- 1 till till 103784255 2010-03-04 13:15 x.ps
till@till:~/ghostscript/gpl/testfiles$

This is another 4 times bigger. 100 MB are a lot for the memory PostScript printers usually have.

What has to be done here is the following:

evince should not re-render PDF (and also PostScript) files when printing, but simply send them to CUPS. If the user requests, N-up, reverse order, ... evince should send appropriate IPP attributes alog with the job instead of doing these actions by itself.

Sending the PDF file directly to CUPS ("lpr 10.1.1.65.8661-1.pdf") or only doing "pdftops 10.1.1.65.8661-1.pdf" leads to a much faster printout for me.