cupsJobTicket

[Kurt Pfeifle]

Helge Blischke wrote:
> Kurt Pfeifle wrote:
>> franz.pfoertsch.brose wrote:
>>
>>
>>> Please explain the function of the cupsJobTicket features.
>>
>>
>> We are all familiar with the commandline arguments like
>>
>>   -o joboption_1=somevalue -o joboption_2=othervalue
>>
>> that can be passed on an lp or lpr commandline. All CUPS filters and
>> backends will see the collection of job options as argv[5] (the fifth
>> commandline parameter, $5, if you wrote a custom filter or backend as
>> a shell script)
>>
>> cupsJobTicket statements are an alternative way to tell the CUPS pstops
>> filter about desired job options.
>>
>> Hmmm, wait.... it may be *not* pstops which reads and interprets these
>> lines, but the scheduler itself, upon receiving a file via IPP. And
>> then simply translate them into commandline params, and pass them as
>> additional values in argv[5] down the filter chain....
>>
>> cupsJobTicket lines are embedded *into* a PostScript file. They take
>> this form:
>>
>> %cupsJobTicket:  joboption_1=somevalue joboption_2=othervalue
>>
>> and they must appear from the 2nd line, right after the "%!PS-Adobe-3.0"
>> line.
>>
>> To every other PostScript processing software, this line looks like a
>> comment, so it will not care about it. CUPS is expected to handle it in
>> exactly the same way as if it would see a commandline argument as in the
>> first paragraph.
>>
>> (An alternative way is to have each option on a job ticket line of its
>> own:
>>
>> %cupsJobTicket:  joboption_1=somevalue
>> %cupsJobTicket:  joboption_2=othervalue
>>
>> whatever you prefer; just like you could hand over the commandline
>> params in one go as well: '-o "joboption_1=value1 joboption_2=value2"')
>>
>> Next question is: How do I get the cupsJobTicket lines into the Post-
>> Script file in the first place?
>>
>> If your PPD has a section with lines like these, any PPD-using driver
>> (even on Windows) will embed the job ticket lines, using a JCL syntax,
>> but avoid the *PJL* syntax:
>>
>> %%%%%%%%%%%%%%%%%%%%%%%%%
>> *Protocols: PJL
>> *JCLBegin: "%!PS-Adobe-3.0<0A>"
>> *JCLToPSInterpreter: ""
>> *JCLEnd: ""
>> %%%%%%%%%%%%%%%%%%%%%%%%%
>> *JCLOpenUI *kpCustomOption/A Foobar Baz Option: PickOne
>> *OrderDependency: 30 JCLSetup *kpCustomOption
>> *DefaultkpCustomOption: omega
>> *kpCustomOption none:    "%cupsJobTicket: kp-custom-option=none"
>> *kpCustomOption alpha:   "%cupsJobTicket: kp-custom-option=alpha"
>> *kpCustomOption beta:    "%cupsJobTicket: kp-custom-option=beta"
>> *kpCustomOption gamma:   "%cupsJobTicket: kp-custom-option=gamma"
>> *kpCustomOption delta:   "%cupsJobTicket: kp-custom-option=delta"
>> *kpCustomOption epsilon: "%cupsJobTicket: kp-custom-option=epsilon"
>> *kpCustomOption omega:   "%cupsJobTicket: kp-custom-option=omega"
>> *JCLCloseUI: *kpCustomOption
>> %%%%%%%%%%%%%%%%%%%%%%%%%
>> *JCLOpenUI *pfoertschSpinnerei/Champions League Favorites: PickOne
>> *OrderDependency: 34 JCLSetup *pfoertschSpinnerei
>> *DefaultpfoertschSpinnerei: bayern
>> *pfoertschSpinnerei vfb:    "%cupsJobTicket: fp-option=vfb"
>> *pfoertschSpinnerei club:   "%cupsJobTicket: fp-option=club"
>> *pfoertschSpinnerei bayern: "%cupsJobTicket: fp-option=bayern"
>> *pfoertschSpinnerei hsv:    "%cupsJobTicket: fp-option=hsv"
>> *pfoertschSpinnerei werder: "%cupsJobTicket: fp-option=werder"
>> *JCLCloseUI: *pfoertschSpinnerei
>> %%%%%%%%%%%%%%%%%%%%%%%%%
>>
>> then any PPD-interpreting PS-driver should embed *cupsJobTicket lines
>> at the start of the file as a "JCL" section, but a JCL that is *also*
>> PostScript (not PJL); it therefor does not need a specific command to
>> switch the interpreter, and no extra line to indicate the end of the
>> JCL language section.
>>
>> The net effect of above PPD section would be that the PostScript file
>> would look like this:
>>
>> ---------------------------
>> %!PS-Adobe-3.0
>> %cupsJobTicket: kp-custom-option=omega
>> %cupsJobTicket: fp-option=bayern
>> %!PS-Adobe-3.0
>> %%% and from here starts the rest of the PostScript file, with the
>> %%% real page content
>> [....]
>> ---------------------------
>>
>> and the all elements in the downstream filter chain will see the
>> commandline argument no. 5 as
>>
>>   "[....] kp-custom-option=omega fp-option=bayern"
>>
>> (This alternative way was "invented" in order to enable print clients
>> who otherwise suffer from their MS Windows platform-ness to pass IPP
>> job parameters as well as JCL parameters, without needing to use stan-
>> dard *PJL* headers. Standard PJL headers are lost for CUPS, because they
>> cause the auto-typing of MIME types to be regarded as "raw", and there-
>> for by-pass the CUPS filtering. AFAIR, it does only work for print
>> jobs containing a single file, not for multi-file print jobs.)
>>
>>
>>> I try to expand a ppd from a printer, but I don't know which parts of
>>> the different software is using this feature.
>>
>>
>> If you hack stuff into a PPD that uses the cupsJobTicket lines, and if
>> you do define your own options, you also need to write your own filter
>> that is able to understand these options and do something meaningful
>> with them.
>>
>> However, if you put "standard" job options into the cupsJobTicket lines
>> it should be fine for pstops.
>>
>>
>>> Is it only used in cupsaddsmb? I found nothing at pstops ...
>>
>>
>> Right now it is only used by cupsaddsmb to modify the PPD that will be
>> provided to Windows clients.
>>
>> I think it was never Mike's intention to make it used by other parties.
>>
>> We're abusing this nice little trick here.   :-)
>>
>>
>>> regards
>>> Franz
>>
>>
> 
> ... and the scheduler digests these comments only if the
> original print job begins with
>     %!PS-Adobe
> as the very first line, and the job ticket comments
> must follow this line immediately.


Huh? Did I say something different?

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany