[cups.general] Printing multiple copies when file comes from

[Steve Bergman]

Michael Sweet wrote:

> Steve Bergman wrote:
>
>> ...
>> Oddly, if a filename is specified to lpr, the backend gets called 
>> with that filename.
>
>
> Actually, no.  It gets the job-name attribute in argv[3], which by
> default is the basename of the file you are printing.
>
> > However, if lpr is getting its input from stdin, the backend is
> > told to read from stdin as well,
>
> Not true; printing from stdin is the same from the scheduler's
> perspective - you are sending a file (lpr just creates a temp file
> when spooling from stdin) and that gets sent to cupsd, which puts
> a copy in the spool directory.
>
> > meaning that multiple copies can never work to a dot matrix, or
> > band printer, or any other printer that does not support multiple
> > copies internally, when lpr gets it's input from stdin.
>
>>
>> This is quite broken behavior and not documented.
>
>
> Your understanding is completely, totally wrong.
>
> What happens is this:
>
>     1. If you are printing a "raw" (application/vnd.cups-raw)
>        file or printing to a queue with no interface script or
>        PPD file, then the backend gets the file directly and no
>        filtering is done.  The backend is responsible for copy
>        generation.
>
>        If the raw file is gzip'd, then CUPS will run the "gziptoany"
>        filter which takes care of copy generation, but only for raw
>        files.
>
>     2. If you are printing a non-raw file or printing to a queue
>        with an interface script or PPD file, then the corresponding
>        filters are run and the output is piped into the backend.
>        The filters are responsible for copy generation.
>
> This API is, in fact, 99.9% compatible with the traditional SysV lp
> interface script mechanism - the 0.1% incompatibility is that we
> require the #! stuff on the first line of scripts, but that is a
> trivial change to make if you want to use a SysV interface script.
>
> Anyways, copy generation will always work for raw queues, but it
> is your responsibility to do copies in your own filters and/or
> drivers if the printer doesn't support it.
>
Thanks for the clarification, but I'm still not quite sure I 
understand.  If I have an application that insists upon sending the job 
to lp or lpr via stdin, and I need a form feed added to the end of the 
job and also between copies and the printer is serial, is there a way to 
make all that work with the filters and backends included in the stock 
cups implementation?  Or do I need to write my own filter?  My current  
configuration does use the text only PPD. And the only filtering  I want 
done is the addition of the formfeed(s).

Any further clarification would be greatly appreciated.

Thanks,
Steve Bergman