CUPS 1.6 shaking up Linux printing

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Developers of the CUPS printing system raised a few eyebrows when it was revealed in February that the impending 1.6 release would drop several features heavily used on Linux systems (and other platforms) in order for the project to focus more on Mac OS X, per the wishes of CUPS's corporate parent, Apple. The Linux community has already adapted to the 1.6 changes, however — in fact, the past year has been an active one for other open source printing projects as well.

Apple purchased CUPS in 2007 by acquiring Easy Software Products, the company headed by CUPS creator Michael Sweet, who still orchestrates the project. On a typical Linux box, CUPS is responsible for multiple pieces of the printing workflow. To a client machine, it provides uniform access to shared printers around the network, and submits print jobs to the user's choice of print queue.

On a machine operating as a print server, CUPS provides filter-chains used to convert the print job to a format suitable for final output on the device (including converting to PostScript or PDF, rasterization, and applying any transformations like 2-up layout), and it runs the backends for many printers — although it can also hand off the final job to another driver, such as one from Gutenprint or a proprietary offering supplied by a device vendor.

CUPS 1.6

The changes landing in CUPS 1.6 affect several points in that client-server workflow, which public attention was drawn to when Red Hat's Tim Waugh posted a summary to the Fedora-devel list in late January.

First, existing versions of CUPS allow client machines to browse for printers accessible on the network. In this system, printers announce their availability using short messages sent on UDP port 631. Mac OS X, however, uses DNS Service Discovery (DNS-SD) to locate network printers instead, a feature introduced with CUPS 1.3 in 2007. CUPS 1.6 will drop the UDP-based CUPS Browsing feature, and make DNS-SD the only method for "automatic" network printer discovery.

This causes several practical challenges for Linux and other non-Apple OSes. For starters, although CUPS already works with Bonjour (Apple's implementation of DNS-SD), the announcements it sends don't work with the Linux equivalent, Avahi. Since both the print server and the client must be running DNS-SD for browsing to work, this prevents Linux print servers from being discoverable by Apple clients, and vice-versa. Waugh has submitted patches to CUPS to enable Avahi support, but they have not yet been integrated.

But the second wrinkle is that reliance on DNS-SD for printer discovery will dictate that Avahi run on all print servers and clients, which amounts to a policy-changing decision for every distribution. This means a new package dependency, but as Waugh discussed in the comments on his blog, it will also mean an adjustment to the default firewall rules, which (at least for Fedora) are accustomed to blocking Avahi.

The second change arriving in 1.6 is the elimination of all CUPS filters that are not of interest to Apple. Obviously, were they to disappear, that would strand non-Apple users. Fortunately, the OpenPrinting project immediately announced that it would maintain the filter set as a separate cups-filters package (which is already available). The filter list includes filters for image-to-PDF, PDF-to-PDF, text-to-PDF, PDF-to-raster, PDF-to-IJS (Hewlett-Packard's InkJet Server format), and PDF-to-OPVP (OpenPrinting's vector format) conversion.

OpenPrinting developments: PDF, IPP, and CPD

OpenPrinting is a vendor- and distribution-neutral workgroup overseen by the Linux Foundation that provides software support and standards for printing on Linux systems. But the adoption of the cups-filters package is not simply an effort to archive valuable code — OpenPrinting is developing the filters as part of its effort to migrate away from PostScript as the standard format for print jobs, and toward PDF. As the project's site explains, the PDF format allows for easier post-processing, newer features like transparency and high bit-depth color, and a simpler printing pipeline (considering the popularity of PDF as a document format).

The major large-scale open source projects — GTK+, Qt, Mozilla, and LibreOffice — all support PDF print queues now (and it became the system-wide default in Ubuntu 11.10), but Apple's disinterest in continuing the PDF-workflow filters led some to speculate that OS X and Linux may be on diverging roads, such that eventually a fork of CUPS will be required. Waugh commented that such a move had been considered, but that "for the time being it isn't beneficial to do that."

Till Kamppeter from Canonical (and currently a Linux Foundation Fellow) manages OpenPrinting, and sent his own email summary of CUPS 1.6's changes to the OpenPrinting printing-architecture list. In it, he cites another significant change, the deprecation of the PostScript Printer Description (PPD) file format.

In previous generations, PPDs served as driver interfaces for PostScript printers. Kamppeter initially said 1.6 would drop support for PPDs in an effort to shift to the IEEE Printer Working Group's IPP Everywhere model, but Sweet later corrected him — existing PPDs will continue to be supported, but new PPDs will not be added. Nevertheless, Sweet said that IPP Everywhere remains the long-term plan, and "the goal is to have IPP equivalents for what we currently provide in the PPD APIs," and thus "when we are able to pull the plug [applications] won't notice a thing."

Regardless of whether OS X and Linux CUPS workflows are diverging, OpenPrinting is also attempting to unify other key pieces of the standard printing job. Right now, the emphasis is on creating a common printing dialog (CPD) so that every application can present the same interface and set of print options to the user. The project has been in development for quite some time, but took steps forward in 2011, with a Google Summer of Code project to implement a color management interface, and the first all-Qt implementation.

Color management

The CPD is not the only Linux printing endeavor to tackle color management: both CUPS and Ghostscript successfully integrated support for reading and processing ICC color profiles during the printing process.

The CUPS support was implemented by Waugh, and uses the colord daemon (we covered colord in September 2011). Colord provides a D-Bus service for applications to look up the color profiles associated with hardware devices. CUPS registers the ICC profile of each available print queue with colord, and the print filters query colord for the appropriate profile when rasterizing a print job for its final output.

Ghostscript, the PostScript interpreter often used by CUPS as the rasterizing filter during that final step, has also improved its ICC color profile support in recent releases. Support for applying a profile when rasterizing a job (which is what makes the CUPS usage of Ghostscript mentioned above function as needed) was already in place, but the recent point releases have added additional capabilities. As Libre Graphics World explained, February's 9.05 added support for soft-proofing (i.e., simulated output), attaching individual profiles to embedded images, and device link profiles, which enable additional transformation options of interest mainly to professional print services.

Printing is one of those services that it can be easy to take for granted while everything runs according to plan. However, as the news of the CUPS 1.6 changes brought to the community's attention, the ease with which complacency can set in does not mean that there is no active development or new work being done. In the past 12 months or so, the Linux printing toolchain has been augmented with several new features (including color management and the ability to use PDF as the default format) that will offer an improved experience. Some of the other changes currently in the pipeline — such as DNS-SD and IPP Everywhere — may make some uncomfortable, but, ultimately, modernizing a workflow always requires pushing forward, even when it feels disruptive.