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

Sahil Arora sahilarora.535 at gmail.com
Fri Jun 16 06:55:08 PDT 2017


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.
3. The print software then calls the respective filter required to convert
the print file to the printer supported PDL.
4. The filter reads the auto-generated PPD and converts to the required
format.
5. The print job is submitted to the printer with the converted data
produced from the filter.

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.

--
Sahil

On Fri, 16 Jun 2017 at 05:17 Michael Sweet <msweet at apple.com> wrote:

> Sahil,
>
> Printer drivers must still use PPD files.  CUPS internally converts IPP
> attributes to PPD options and values, so from your driver's standpoint the
> world still revolves around PPDs.
>
> The future of printing is based on standard PDLs and IPP attributes, with
> things like AirPrint, IPP Everywhere, IPP USB, and Wi-Fi Direct Print
> Services.  Those do not require printer-specific driver software and
> instead use common (generic) software with the information reported by the
> printer when converting to a raster format.
>
> (most printers sold since 2010 support the necessary protocols and PDLs to
> work with CUPS directly...)
>
>
> > On Jun 15, 2017, at 5:02 PM, Sahil Arora <sahilarora.535 at gmail.com>
> wrote:
> >
> > Hi there,
> > In cups filter programming, the currently implemented filters use the
> > "Deprecated" CUPS PPD API to get the PPD file of the current printer
> using
> > the environment variable "PPD" which is set by the printing system.
> > However, in the new CUPS API, the PPD API has been dropped, and so are
> > functions such as `cupsMarkOptions` which mark options parsed from the
> > command line. Also, there are some special keywords in the printer PPD
> > which hold printer capabilities (like max size of a band). What do you
> > recommend in that case? Should the old PPD API in the filter be removed?
> If
> > yes, then how, keeping in mind all these keywords, and functions such as
> > `cupsMarkOptions`? Or is it safe to go on with the old PPD API?
> >
> > Thanks.
> > --
> > Sahil Arora
> > 3rd year B.Tech Undergrad | Indian Institute of Technology Mandi
> > Web: http://sahilarora535.me
> > LinkedIn: sahilarora535 <https://www.linkedin.com/in/sahilarora535/>
> > Ph: +91-8130506047 <+91%2081305%2006047> <+91%2081305%2006047>
> > _______________________________________________
> > cups-devel mailing list
> > cups-devel at cups.org
> > https://lists.cups.org/mailman/listinfo/cups-devel
>
> _________________________________________________________
> 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