Today a user reported that printing from evince requesting N copies
results in N^2 copies comming out of the printer.
Now a quick check shows that doesn't happen for trivial ps files but does
for trivial pdf files.
What seems to be happening is that evince is converting the pdf to ps and
doing the N copies itself but also passing the copies option into cups so
the cups server then multiplies it again.
I can find code in evince (evince-0.6.0-8.el5 srpm) which while converting
to postscript for printing sends each page N times. I can't find where it
is actually sending the job to the printer specifying #copies but my logs
on out print server show that the server is getting requests with copies
set.
e.g. here are the cups page_log entries for printing a 1 page pdf using
evince with #copies set to 4:
bcopy jp107 409322 [28/Mar/2008:19:15:55 +0000] 1 4 - zax.damtp.cam.ac.uk
bcopy jp107 409322 [28/Mar/2008:19:15:55 +0000] 2 4 - zax.damtp.cam.ac.uk
bcopy jp107 409322 [28/Mar/2008:19:15:55 +0000] 3 4 - zax.damtp.cam.ac.uk
bcopy jp107 409322 [28/Mar/2008:19:15:55 +0000] 4 4 - zax.damtp.cam.ac.uk
so that produces 16 pages while for a 1 page ps document with #copies set
to 3 I just see:
bcopy jp107 409328 [28/Mar/2008:19:41:46 +0000] 1 3 - zax.damtp.cam.ac.uk
so we get just the expected 3 pages.
Before I spend any longer blaming evince and trying to find a solution
there I should perhaps point out that the printing setup here is somewhat
different from the sl defaults. We have updated to cups-1.3.x and added a
pile of hacks to try to work round various problems - with pdf documents
sent from MacOSX for example.
[ Our printing hacks have reached the point where I'm a bit scared to
touch anything in case I break it again. ]
Can someone with a clean plain sl5 using cups printing setup check if the
evince pdf printing problem is real or an accident caused by our many
layers of printing hackery?
--
Jon Peatfield, Computer Officer, DAMTP, University of Cambridge
Mail: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
