cupsJobTicket

[Kurt Pfeifle]

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

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