Hi,<br><br>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:// <br><br>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.<br>
<br>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. <br>
<br>This is a sample argv[5] string with job options (local printing):<br> <br>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<br>
<br>Options are also shown and passed when printing IPP from Windows (XP) with this url: <a href="http://myubuntu:631/printers/MyPrinter">http://myubuntu:631/printers/MyPrinter</a> (using MYDRIVER.PPD with a special MYDRIVER.inf file).<br>
<br>This is a sample argv[5] string with Windows XP job options:<br><br>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<br>
<br>However, when printing IPP from Mac OS X Leopard (or from any other GNU/Linux CUPS based IPP client), with the MYDRIVER.PPD to <a href="http://myubuntu:631/printers/MyPrinter">http://myubuntu:631/printers/MyPrinter</a> options are correctly shown in the Printing Dialog but NOT passed to the mybackend.<br>
<br>This is a sample argv[5] string with the Mac OS X job options:<br><br>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=<br>
<br>Why is that?<br><br>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.<br><br>Note: these filter statement in MYDRIVER..drv make sure PDF is passed to the backend unfiltered:<br>
<br>Filter application/vnd.cups-postscript 100 -<br>Filter application/vnd.cups-pdf 0 -<br><br>Looking at the PostScript file you can see how the PPD options are embedded with %%BeginFeature tags.<br><br>See this snippet:<br>
<br>featurebegin{<br>%%BeginFeature: *PageRegion A4<br><</PageSize[595 842]/ImagingBBox null>>setpagedevice<br>%%EndFeature<br>}featurecleanup<br>featurebegin{<br>%%BeginFeature: *ColorModel RGB<br><</cupsColorSpace 1/cupsColorOrder 0/cupsCompression 0>>setpagedevice<br>
%%EndFeature<br>}featurecleanup<br>featurebegin{<br>%%BeginFeature: *InputSlot middle<br><</MediaPosition 2>>setpagedevice<br>%%EndFeature<br>}featurecleanup<br>featurebegin{<br>%%BeginFeature: *Resolution 300dpi<br>
<</HWResolution[300 300]/cupsBitsPerColor 8/cupsRowCount 0/cupsRowFeed 0/cupsRowStep 0>>setpagedevice<br>%%EndFeature<br>}featurecleanup<br><br>Obviously CUPS server is able to retrieve these options (pstopdf filter) and put them on the argv[5] mybackend parameter. <br>
<br>On the other hand it looks like when CUPS gets a PDF file as input it has no way to retrieve the selected options.<br><br>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"?<br>
<br>Windows, Ubuntu and Mac OS IPP clients indeed do NOT provide any Job attributes, as is confirmed by my WireShark captures.<br><br>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: <br>
<br>E.g. MYDRIVER.PPD contains these instructions:<br><br>*OpenUI *InputSlot/Media Source: PickOne<br>*OrderDependency: 10 AnySetup *InputSlot<br>*DefaultInputSlot: main<br>*InputSlot main/Main: "<</MediaPosition 0>>setpagedevice"<br>
*InputSlot top/Top: "<</MediaPosition 1>>setpagedevice"<br>*InputSlot middle/Middle: "<</MediaPosition 2>>setpagedevice"<br>*InputSlot bottom/Bottom: "<</MediaPosition 3>>setpagedevice"<br>
*InputSlot side/Side: "<</MediaPosition 4>>setpagedevice"<br>*CloseUI: *InputSlot<br><br>At the same time the IPP Get-Printer-Attributes Response contain the 'xxx-supported' attributes.<br><br>
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. <br><br>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.<br>
<br>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".<br>
<br>PPD stands for 'PostScript Printer Description', but how do the IPP Printer Description attributes relate to that?<br><br>Is there a way to map PPD options to IPP attributes?<br><br>What does IPP intend to achieve by defining numerous IPP Printer and Job Template attributes?<br>
<br>-- Rijk Ravestein<br><br>