Confusion on the copies attribute

[Michael Sweet]

Helge Blischke wrote:
> I'm confused about the semantics of the copies attribute when printing
> PostScript files.
> There are two completely different methods to specify the number of
> copies:
> (1) in the PostScript job itself, by the application which creates
>     the PostScript file, e.g.:
> 	<</NumCopies 5>> setpagedevice

This isn't recommended, since technically you are making the PS
device-dependent.  Furthermore, you also have:

     /#Copies N def

> (2) as an option to the lp or lpr command, by the app/person 
>     issuing the command.

Actually, there is a third way:

     (3) as a cupsJobTicket comment in the PS file:

         %!PS-Adobe-3.0
         %cupsJobTicket: copies=N

> As a "naive" user, I would assume to have a choice which method to 
> use and, if I select method (1), I'd assume CUPS not to interfere
> with this setting.

Actually, only #2 and #3 are guaranteed to work.  #1 is printer-
specific and might have side-effects.

> But, even if I don't specify a number of copies on the command line,
> the CUPS scheduler defaults the number of copies to 1. This may lead
> to queer results:
> 
> a) with "normal" printing (i.e. no "raw" option specified) the job
>    is fed through the pstops filter, which results in the PS job
>    containing - in the following order - both the statements
> 	<</NumCopies 1>> setpagedevice		% inserted by pstops
> 	% ... some more stuff in the setup section
> 	<</NumCopies 5>> setpagedevice		% the original
>    This causes no harm, as the original setting gets active
>    before any marks are put onto the first page.

Depending on where the copy count is specified, the CUPS value
may actually override the file value.

>    In addition, the copies value of 1 faked by the scheduler is
>    passed as a command line option to all filters and the backend,
>    and that is where the confusion starts:
> 
>    The IPP backend adds the copies attribute with value 1 to the
>    print request. The actual number of copies printed is then
>    implementation dependent:
>    with some printers the copies value submitted in the IPP request
>    takes precedence over the specification in the PS job itself,
>    other printers treat both values as completely independent of
>    each other, which results the total number of copies to be
>    the product of both values.
> 
>    Other backends seem not to be affected, since they feed the
>    print data only once to the printer.
> 
> b) with raw printing (no filters involved) the situation gets
>    worse:  "conventional" backends then copy the print data 
>    as many times to the printer as the copies value from the
>    command line.
> 
> What I think would be needed is to completely ignore the 
> copies attribute if not specified in the lp or lpr command.
> 
> As the IPP RFCs do not adress this issue (at least I didn't
> find any hints), I'd like some other opinions before I start
> filing a STR.

As I mentioned above, embedding the copy count in a PS file makes
it device-dependent and will lead to undefined behavior.  CUPS 1.2
will make it possible for CUPS to detect this via back-channel
data (so the accounting info will be more accurate),

In any case, there is no reliable way for us to detect this at
job submission time, and we have no plans of changing the current
copy behavior for CUPS 1.2.x.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com