On Mon, 31 Mar 2008, John Summerfield wrote:
<snip>
It has a proper description of the printer, it gets the definition from cups.
I think it perfectly proper to assume the ppd it gets from cups properly
describes the final printer.
It could indeed, but that would mean replicating lots of the work that the
spooler has to do, e.g. to cope with options like duplexing/collation
along with the N-copies. A print queue may even have n-up printing as the
default which is lots more effort to handle.
Not that I'm saying that spoolers such as cups will *always* get this all
right, but they stand a better chance. [ up to cups-1.3.4 using reverse
printing with n-copies would sometimes cause the pstops filter to generate
N^2 copies. ]
When I saw this bug report that is what jumped into my mind first 'cos we
are (in fact) using cups-1.3.4 so I wasn't sure that bug had actually been
properly fixed...
Spoolers such as cups aside, no program on *x should assume ot has a real
printer out there.
printing to a file doesn't explain anything.
I can, however, confirm the problem so it's worth reporting as a bug. I asked
for two copies of the current page and got four.
I got somewhat confused finding what is going on 'cos evince uses the gtk+
routines for printing which I've never seen before. Presumably that is in
some way backend independent so it can't assume much about the spooler...
In any case there is code to send each page N times and also to attempt to
cope with collate and reverse itself, but the cups jobs I see also seem to
have the copies set in the control file...
What evince *seems* to do is send each page N time itself (there is a loop
in the code which converts to postscript). Quite seperatly it passes the
number of copies through to the cups system so that when the job is
recieved the cups server passed N on the command line of the pstops filter
so it then causes N copies to be printed (either by setting the relevant
postscript options or sending pages multiple times depending on other
options which are set).
In a moment of absolute brilliance I sent off a print job but put on hold so
I can inspect it. There doesn't seem to be anything in the postscript, but in
the associated control file there's this:
0000240: 3030 2100 0663 6f70 6965 7300 0400 0000 00!..copies.....
0000250: 0242 0019 6a6f 622d 6f72 6967 696e 6174 .B..job-originat
which I don't understand, but it looks interesting. Nothing interesting in
the cups log, but you might want to try your hand with tcpdump to see what
the actual traffic is.
We have a print queue called 'capture' which is disabled but accepting
jobs just for this kind of thing, we get sufficiently many print problems
being reported that such a queue is often quite handy in diagnosing what
is going wrong and where... :-(
If you look at the d...... file in the spool then you will see that evince
has attempted it's own N-copies and as you see from the control file it
(well gtk+ print system talking to cups) also passed Copies through which
is why we see N*N copies.
Reversing the page order and asking for 'reverse' will presumably have the
obvious 'null' effect. I'm not sure how collate interacts but the evince
attempt to do it (send pages 1,2,3,1,2,3,1,2,3 will mess up duplexing so
that sort of things really shouldn't be done by a dumb app). The spooler
needs to know when the document really ends for it to be able to reliably
do collation of n-copies with duplex without messing things up.
There are two places in the evince source where it attempts to do the
N-copies itself, though in my tests it only ever seems to use the one in
shell/ev-jobs.c in ev_job_print_run(). I have a simple patch which strips
out the attempts to do anmything clever and so we see documents on the
cups server which just have each page once and then the spooler does the
required magic...
There is another piece of code in shell/ev-print-job.c
idle_print_handler() but I couldn't cause that to get called so maybe that
is only used on systems without the gtk_print methods...
I'll attach my patch to a bug report at TUV as soon as I've tested it
doesn't break things too badly on a couple of test boxes here (I've built
a test rpm with the patch if anyone else is interested in having a copy).
--
Jon Peatfield, Computer Officer, DAMTP, University of Cambridge
Mail: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
