[cups.general] How do PPD options relate to IPP Printer/Job attributes?

[Rijk Ravestein]

Hi,

I experimented on Ubuntu 11.10 (CUPS 1.5.0) with a simple CUPS backend
called 'mybackend' and created a CUPS printer called 'MyPrinter' with
Device URI: mybackend://

I also created a printer driver mydriver.drv with options for InputSlot,
ColorModel, PageSize and Resolution, and generated a PPD file with the CUPS
PPD compiler (ppdc), and used the MYDRIVER.PPD file for MyPrinter.

Now indeed, when printing to the LOCAL MyPrinter the mydriver options
appear as Printer Options in the Common Printing Dialog, and my selected
options are passed in the argv[5] command line parameter of mybackend.

This is a sample argv[5] string with job options (local printing):

InputSlot=bottom PageSize=A4 number-up=1 Resolution=300dpi ColorModel=RGB
job-uuid=urn:uuid:f8203f67-7cd9-3f91-6a73-01f36b251178
job-originating-host-name=localhost time-at-creation=1338823905
time-at-processing=1338823905

Options are also shown and passed when printing IPP from Windows (XP) with
this url: http://myubuntu:631/printers/MyPrinter (using MYDRIVER.PPD with a
special MYDRIVER.inf file).

This is a sample argv[5] string with Windows XP job options:

ColorModel=RGB InputSlot=middle JobTimeout=0 PageRegion=A4
Resolution=300dpi WaitTimeout=300
job-uuid=urn:uuid:925fe20f-9763-3407-503e-7b2106fa90b6
job-originating-host-name=192.168.1.42 time-at-creation=1338824123
time-at-processing=1338824123

However, when printing IPP from Mac OS X Leopard (or from any other
GNU/Linux CUPS based IPP client), with the MYDRIVER.PPD to
http://myubuntu:631/printers/MyPrinter options are correctly shown in the
Printing Dialog but NOT passed to the mybackend.

This is a sample argv[5] string with the Mac OS X job options:

job-uuid=urn:uuid:3831045a-2888-361a-5b6f-a49c4c54bee5
job-originating-host-name=192.168.1.41 time-at-creation=1338823837
time-at-processing=1338823837 AP_D_InputSlot=

Why is that?

Inspecting the stdin from Windows XP on the backend, it turns out to be
PostScript. Mac OS X delivers PDF, just like other modern IPP clients using
CUPS.

Note: these filter statement in MYDRIVER.drv make sure PDF is passed to the
backend unfiltered:

Filter application/vnd.cups-postscript 100 -
Filter application/vnd.cups-pdf 0 -

Looking at the PostScript file you can see how the PPD options are embedded
with %%BeginFeature tags.

See this snippet:

featurebegin{
%%BeginFeature: *PageRegion A4
<</PageSize[595 842]/ImagingBBox null>>setpagedevice
%%EndFeature
}featurecleanup
featurebegin{
%%BeginFeature: *ColorModel RGB
<</cupsColorSpace 1/cupsColorOrder 0/cupsCompression 0>>setpagedevice
%%EndFeature
}featurecleanup
featurebegin{
%%BeginFeature: *InputSlot middle
<</MediaPosition 2>>setpagedevice
%%EndFeature
}featurecleanup
featurebegin{
%%BeginFeature: *Resolution 300dpi
<</HWResolution[300 300]/cupsBitsPerColor 8/cupsRowCount 0/cupsRowFeed
0/cupsRowStep 0>>setpagedevice
%%EndFeature
}featurecleanup

Obviously CUPS server is able to retrieve these options (pstopdf filter)
and put them on the argv[5] mybackend parameter.

On the other hand it looks like when CUPS gets a PDF file as input it has
no way to retrieve the selected options.

But wait, why doesn't the IPP client pass the attributes of the Job Object
in Group 2 of the Print-Job Request? Is that because RFC2711 states that
"The client OPTIONALLY supplies a set of Job Template attributes"?

Windows, Ubuntu and Mac OS IPP clients indeed do NOT provide any Job
attributes, as is confirmed by my WireShark captures.

There are some lose ends here. The options in the PPD file are displayed in
the printing dialogs of the IPP clients, because of the PPD OpenUI
instructions:

E.g. MYDRIVER.PPD contains these instructions:

*OpenUI *InputSlot/Media Source: PickOne
*OrderDependency: 10 AnySetup *InputSlot
*DefaultInputSlot: main
*InputSlot main/Main: "<</MediaPosition 0>>setpagedevice"
*InputSlot top/Top: "<</MediaPosition 1>>setpagedevice"
*InputSlot middle/Middle: "<</MediaPosition 2>>setpagedevice"
*InputSlot bottom/Bottom: "<</MediaPosition 3>>setpagedevice"
*InputSlot side/Side: "<</MediaPosition 4>>setpagedevice"
*CloseUI: *InputSlot

At the same time the IPP Get-Printer-Attributes Response contain the
'xxx-supported' attributes.

So what about these 'xxx-supported' attributes which are passed to the
client? Looks they are just ignored by the Printing Dialog, since the
dialog is not IPP aware.

As an example: despite the IPP attributes 'copies-supported' with
rangeOfInteger (1:1) and 'copies-default' with Integer(1), passed to the
IPP client, multiple copies can still be selected in the Print Dialog.

Probably for the same reason, on Mac OS and Ubuntu, output cannot be forced
to PostScript by the setting the Get-Printer-Attributes Response attributes
"document-format-default" and "document-format-supported" to just
"application/postscript".

PPD stands for 'PostScript Printer Description', but how do the IPP Printer
Description attributes relate to that?

Is there a way to map PPD options to IPP attributes?

What does IPP intend to achieve by defining numerous IPP Printer and Job
Template attributes?

-- Rijk Ravestein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cups.org/pipermail/cups/attachments/20120604/1cacd9b8/attachment-0001.html>