[cups.development] cupsFilter need to parse PPD file to get user

[anonymous]

Thanks for all the response.

Actually what I intended to do is a "post-filter" that insert some PJL 
commands after CUPS last filter. (e.g. add PJL for Duplex after 
rastertoprinter driver)

As CUPS doesn't support post-filter directly, I have to make a wrapper for 
*cupsFilter. I probably need to customize the PPD file to include all 
finishing options and I need to know which option user has chosen. (by 
command line, cups web gui or kprinter etc)

If I'm using scripting language, there's no CUPS API to use. Is there an 
existing model already to parse user options? (including PPD file, command 
line and kprinter's IPP attributes)?

BTW, how does CUPS utilize IPP attributes? I thought CUPS will insert all 
control command into print file and let backend to send print file to 
printer. If backend is a usb/parallel printer, how IPP attribute handled?

Thanks

"Kurt Pfeifle" <k1pfeifle at gmx.net> wrote in message 
news:1751-cups.development at news.easysw.com...
> On Tuesday 21 December 2004 00:24, anonymous wrote:
>
>> I'm writing my own *cupsFilter. Do I have to parse both the ppd file and 
>> the
>> user option list to support all user options?
>
> That depends.
>
> It depends entirely upon what your cupsFilter is supposed to do. A drop-in
> replacement for any other filter? An additional downstream-filter, that
> processes the result of the previious filters? Actual manipulation of the
> visual appearance of the printed image on the paper? Or just some other
> stuff?
>
> But you don't tell what your filter is supposed to do, so you can be given
> detailed advice.
>
> Be aware that your naming it "*cupsFilter" seems to imply that you want
> to enumerated it as such in the printqueue's PPD. That also implies that
> your filter will be the *last* in the CUPS filtering chain. After this
> filter the job goes straight to the backend, and then to the printer.
>
> Saying it is the "last" filter, doesnt tell us how many, and which filters
> come before yours. It doesnt tell us which mime-type it likes to take as
> input. It doesnt tell us how you set up your mime.convs file for that
> mime.type either.
>
>> After setting up queue options and print a test page, command line 
>> arguments
>> #6 (options) to the filter is an empty list.
>
> Are you sure you started to count from "$0" (the filter itself), via "$1"
> (the first parameter, which is the job-id), through to "$5" (the job 
> options)
> and "$6" (the optional file to be processed, otherwise it is stdin to be
> processed)?
>
>> So I suppose I have to parse
>> PPD file to get options.
>>
>> User might submit job through command line and overwrite options set in 
>> PPD
>> file, so I have to parse that as well?
>
> It depends.
>
>> How about kprinter. I saw some strange options like 
>> orientation-requested=4
>> multiple-document-handling=separate-documents-collated-copies, how am I
>> supposed to do with it?
>
> Please read about the IPP specifications, as laid down in the IPP RFCs.
> "orientation-requested" and "multiple-document-handling" are official IPP
> job attributes.
>
> CUPS understands all (or nearly all?) IPP job attributes and supports most
> of the values they can be given.
>
>> Thanks
>
> Cheers,
> Kurt
>