cupsJobTicket

[Helge Blischke]

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.

Helge

-- 
Helge Blischke
Softwareentwicklung

H.Blischke at acm.org