[cups-devel] Removing deprecated PPD API with new CUPS API in Cups Filter Programming

[Michael Sweet]

Sahil,

> On Jun 16, 2017, at 9:55 AM, Sahil Arora <sahilarora.535 at gmail.com> wrote:
> 
> Michael,
> Thank you for confirming. So basically, my understanding on how IPP
> printers work is:
> 1. The printing software(cups) polls for the IPP printer attributes.
> 2. A PPD file is generated with respect to the attributes received from the
> printer.

This is an implementation detail of the current release of CUPS.  Other solutions (like ippserver in the PWG's sample code) don't use PPDs at all.

> 3. The print software then calls the respective filter required to convert
> the print file to the printer supported PDL.

Again, for CUPS.

> 4. The filter reads the auto-generated PPD and converts to the required
> format.

Essentially correct, and this works just like the existing PPD-based driver mechanism - same raster filters, etc.  But also if we are printing a PDF or JPEG file we can often just send the print document to the printer without any filtering (this is accounted for in the cupsFilter lines that we add to the generated PPD).

> 5. The print job is submitted to the printer with the converted data
> produced from the filter.

Correct.

> Please correct me if I am wrong. Also, it would be great if you could throw
> some light on why the PPD API has been deprecated in the new CUPS API, even
> when CUPS printing still depends largely on PPDs.

Only drivers depend on PPDs in the current releases of CUPS.

Applications have no need to deal with PPDs as PPDs only offer a subset of the functionality offered by IPP and often use a wide variety of different, incompatible options for the same functionality.  CUPS has (since CUPS 1.4) mapped PPD options (including many vendor-specific options) to standard IPP attributes and values.  The longer applications depend on PPDs the longer we cannot move forward to support things like media-specific margins, advanced finishing capabilities, and so forth, not to mention getting rid of printer drivers entirely.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer