LWN.net Logo

CUPS 1.6 shaking up Linux printing

March 7, 2012

This article was contributed by Nathan Willis

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.


(Log in to post comments)

CUPS 1.6 shaking up Linux printing

Posted Mar 8, 2012 11:30 UTC (Thu) by cortana (subscriber, #24596) [Link]

I'm apprehensive about the hard dependency on avahi for printer discovery given that it doesn't work properly on VirtualBox virtual machines, nor on systems using the incredibly popular RTL-8169 network interface. It's going to make my life a bit more painful than it needs to be in the future.

CUPS 1.6 shaking up Linux printing

Posted Mar 8, 2012 15:53 UTC (Thu) by gioele (subscriber, #61675) [Link]

> systems using the incredibly popular RTL-8169 network interface.

It looks like that was a bug in the rtl driver and has been closed in 2010: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407217#223>, <https://git.kernel.org/?p=linux/kernel/git/torvalds/linux...>.

CUPS 1.6 shaking up Linux printing

Posted Mar 8, 2012 16:16 UTC (Thu) by cortana (subscriber, #24596) [Link]

Unfortunately I've not had any luck, even with Linux 3.2. It's been on my 'to debug' list for ages. I'll just have to bump it up once I have to start using CUPS 1.6.

CUPS 1.6 shaking up Linux printing

Posted Mar 9, 2012 4:11 UTC (Fri) by klevin (subscriber, #36526) [Link]

Gah. Avahi. The source of more crappy weirdness on my Linux systems than anything else I can remember at the moment. As I rarely use networked printers, removing/disabling avahi has become a default action following upgrades and new installs.

CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 8:57 UTC (Sat) by marcH (subscriber, #57642) [Link]

I'm sorry avahi does not work for you. For me, it allows zeroconf peer to peer networking using hostnames instead of IP addresses, something proprietary network protocols were achieving more 20 years ago. TCP/IP is really a poor joke in terms of user-friendliness.

And by the way, the concept of "personal firewall" borrowed from Windows does not make any sense. Why are blocked ports opened in the first place?
Let's assume for instance avahi is a security risk that Fedora blocks: then why is it listening to the network it in the first place? This is bordering on stupidity.

Security's worst enemy is useless complexity and "personal firewalls" are exactly that: a failure to keep it simple.

Firewalls are of course useful in some complex network configurations where... "default rules" are very unlikely to make any sense either and where a real network administrator is required.

Coming soon: Linux antiruses.

CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 13:15 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

TCP/IP is so horrible that all the 20 year old proprietary networking systems have all been replaced by TCP/IP

auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

auto-discovery is great for small environments, but horrible for large ones.

TCP/IP and the rest

Posted Mar 10, 2012 17:44 UTC (Sat) by marcH (subscriber, #57642) [Link]

> TCP/IP is so horrible that all the 20 year old proprietary networking systems have all been replaced by TCP/IP

What a technical and convincing argument. Of course TCP/IP is not horrible; it's horribly not user-friendly.

TCP/IP won because it was NOT proprietary. In networking more than anywhere else interoperability is key (see Metcalfe's law) so, proprietary protocols did not stand a single chance against consensus and text-based RFCs available for free. User-friendless played practically no role in the fight.

> auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

There are so many other things just as likely to "break the entire network". Like manual configuration from casual users for instance.

Most alternatives to TCP/IP featured BOTH auto-discovery and centralized configurations. In fact every good and new thing in IPv6 was more or less stolen from something older - and rightly so.

I strongly recommend "Interconnections" by Radia Perlman. It's a fantastic book for anyone interested in Ethernet/IP design choices and comparing them with alternatives. This book gives perspective very difficult to get otherwise since alternatives are dead.

CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 19:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates. A misconfigured node should just be silently ignored.

I assume you're not talking about DHCP/RA.

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 5:01 UTC (Sun) by khim (subscriber, #9252) [Link]

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates.

Exactly.

A misconfigured node should just be silently ignored.

Only if you disable autodiscovery (how else can you prevent flood organized by misconfigured node from affection configuration of the rest of the network) - but then what's the point of the whole exercise?

I assume you're not talking about DHCP/RA.

Actually DHCP is not any different: if a single node hogs all available IPs from a DHCP pool then other nodes will be unusable.

All autodiscovery mechanisms have this problems - and DHCP is not an exception. It also shows that on practice problems are rare: sure, DHCP autodiscovery may fail too and it even happens from time to time but if you'll consider how ubiquitous it is and how rare are such failures… I think we should not fear autodiscovery mechanisms all that much. 99% of users use [limited] version of autodiscovery with TCP/IP and sky have not fallen so why can't we use somewhat more advanced version and get the convenience offered by proprietary networks 20 years ago?

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 6:24 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

I don't consider DHCP an autodiscovery mechanism.

That's a server that responds to queries (although very bad things can happen if you end up with unexpected DHCP servers on a network)

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network. In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 7:31 UTC (Sun) by khim (subscriber, #9252) [Link]

I don't consider DHCP an autodiscovery mechanism.

Just like I don't consider reference-counting schemes “real GC”, heh. Well, true it's “autodiscovery lite” mechanism: it's more limited and thus more tolerant to problems with clients… but it introduced “single point of failure” so it's also not ideal.

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network.

This is not a requirement. Devices on network can play different games. For example they can choose single master which then arbitrates everything. Of course this implies some level of trust which may or may not be appropriate for real world.

In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

Right, but in large network you probably have a dedicated sysadmin which can setup everything as is needed. But for something like home network autodiscovery may be invaluable.

P.S. Interesting twist in the GC debate: iOS5 added ARC and a lot of guys viewed it as an “incremental step on the road to real GC”, but looks like Apple shares my POV: beginning in OS X v10.8, garbage collection is deprecated (if favor of ARC if I understand correctly).

CUPS 1.6 shaking up Linux printing

Posted Mar 19, 2012 14:33 UTC (Mon) by abacus (guest, #49001) [Link]

auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.
A buggy client can cause a lot of trouble too. See e.g. Workarounds for "iOS 4.1 - 5.0.1 Allows DHCP Lease to Expire, Keeps Using IP Address" Bug .

CUPS 1.6 shaking up Linux printing

Posted Mar 19, 2012 16:49 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

in a full autodiscovery environment, every system is both a client and a potential server, that's why I said if any _node_ is misconfigured rather than any _server_

Avahi

Posted Mar 12, 2012 21:06 UTC (Mon) by kleptog (subscriber, #1183) [Link]

At my work we have to disable Avahi because it uses *.local and the companies servers use that too. Anyway, as long as the print via SMB works it should be ok.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds