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

Till Kamppeter till.kamppeter at gmail.com
Fri Jun 16 09:18:30 PDT 2017


Sahil,

also take into account that you are working for cups-filters and as the 
project is named the filters are for CUPS, and as CUPS is working 
internally with PPDs and the filters are for the internal working of 
CUPSyou can use the PPD API. If you had worked on the print dialog (or 
any other CUPS client) you were supposed to get rid of the PPD API.

Mike, so what happens if we reach a world of 100% driverless printing, 
CUPS will go away and be replaced by ippserver and ippserver manages PDL 
conversion in a PPD-free way?

    Till

On 06/16/2017 12:28 PM, Michael Sweet wrote:
> 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
> 
> _______________________________________________
> cups-devel mailing list
> cups-devel at cups.org
> https://lists.cups.org/mailman/listinfo/cups-devel
> 



More information about the cups-devel mailing list