multiple files in one job -- changed (for the better) behaviour of CUPS 1.2.x

[Kurt Pfeifle]

CUPS 1.2.x does have a changed behaviour for multiple files printed
as one job, as compared to CUPS 1.1.x. 

The main purpose for the change was (I believe) to gain a reliable
order for outputting the files belonging to the same job (and to
prevent them getting mixed with output from another user's job).
However, this has changes (as a side effect?) also other job result
characteristics.

Look for example at this commandline:

  lp -d printername \
     -o scaling=100 \
     -o sides=two-sided-long-edge \
     -o page-left=48 \
     -o page-top=36 \
     -o cpi=10 \
     /path/to/pdf/1.pdf \
     /path/to/jpeg/2.jpg \
     /path/to/text/3.txt \
     /path/to/tiff/4.tif

1.1.x did start the backend multiple times (once for each file), and
hence options like "duplex" or "stapling" where applied to each file
individually. The printout appeared just as if each file was printed
as a separate job.

1.2.x does start the backend only once, and pipes the result of each
file's filtering through that one backend process. Hence job options 
such as duplexing or stapling are also applied to the job in toto --
the printout appears as if the individual job files were "merged"
before printing, and then sent to the printer as one file.

1.2.x does make one staple binding together all 4 files. Also, when
duplexing is chosen, the second jobfile is on the backside of the 
first one

I like the new behaviour very much. Most of my customers did like it
as well (only one I had to convince it is a better thing even for his
purposes).

I just to make sure this behaviour is intended, and stays as is - and
will not be removed in the near future, since I will be using scripts
relying on this new behaviour.

So, question is: is this new feature here to stay?

Cheers,
Kurt