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:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/