[Printing-architecture] Removal of features in CUPS

Michael Sweet msweet at apple.com
Fri Feb 3 16:32:27 UTC 2012

[Sorry, I was just made aware of this message thread or I would have responded sooner since much of this information just isn't correct...]

Till Kamppeter wrote:
> ...
> Here are the dropped features:
> 1. Filters go to the new cups-filters project
> ---------------------------------------------
> All filters and backends not used by Mac OS X are dropped. These 
> filters, together with the filters for the PDF printing workflow are now 
> hosted as the cups-filters project at OpenPrinting. For a first release 
> only bannertopdf needs to get finished (by Lars Uebernickel).

This part is correct and thank you Till for hosting these filters!
> 2. The Linux implementation of the USB backend looses attention
> ---------------------------------------------------------------

We continue to develop and support the USB backend, although my personal development time is (unfortunately) quite limited.  I will be integrating Till's libusb 1.0 patch in the near future, so at least the current functionality will be usable with both the old and new libusb.

For bidirectional printing support, we need to adopt the method used for the Darwin/OS X USB backend where there is a separate read thread that just does a bulk-in every 200ms. That provides good latency for drivers that need it while avoiding the performance hit for printers that just return a copy of their 1284 Device ID with status info every time.

Depending on my time constraints and whether libusb 1.0 has the necessary support (I think so, but it has been a while since I looked), we may be able to get bidi support in CUPS 1.6.  The big hurdle was moving to libusb 1.0, and Till has already done that work.

> 4. PPD concept will be dropped in CUPS
> --------------------------------------
This is just incorrect.  PPDs are being *deprecated* in CUPS 1.6, but this just means that we will no longer be extending support for PPDs in CUPS.  The APIs are still there, and PPD-based drivers will continue to be supported.

That said, the long-term replacement *is* IPP Everywhere, and to support that we are adding new APIs in CUPS 1.6 (many still just stubs in the current trunk) to deal with dynamic printer availability and capabilities.  The goal is to have IPP equivalents for what we currently provide in the PPD APIs, and in 1.6 they will use the information the scheduler (cupsd) already generates from and maps to PPD files since CUPS 1.4.

CUPS 1.6 is just a baby step towards PPD independence, but the new APIs will allow applications (and the common print dialog) to make the transition so that when we are able to pull the plug they won't notice a thing.  And in the meantime we will be able to support things like media sensing for new printers on the market...

Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20120203/73c10eb4/attachment.html>

More information about the Printing-architecture mailing list