Back in 2007 CUPS became an Apple project.  Now the parts that are not relevant on Mac OS are being dropped, with some of the Linux-relevant parts being gathered together in a separate project, cups-filters.

The main part that is being dropped completely is CUPS Browsing. This is currently the primary mechanism for CUPS-to-CUPS printer queue discovery on Linux. It works by having each CUPS server periodically broadcast UDP packets on port 631 announcing its available queues, and listening for broadcasts from other CUPS servers.

This discovery method is being dropped because DNS-SD is preferred upstream. Support for it has been upstream in CUPS for a while, and it is what CUPS uses on Mac OS X, but it uses Apple’s libdns_sd library and not Avahi. I have added support for this in Fedora, and the patch is submitted upstream.

So in CUPS 1.6, automatic CUPS queue discovery will require Avahi to be running on both the server (i.e. the system hosting the CUPS queue) and the clients (i.e. the systems wanting to print to it).

Of course, you will be able to run CUPS without having Avahi running — but you won’t have automatic CUPS queue discovery in that case.  Clients will have to have queues explicitly configured, or else use the BrowsePoll configuration setting to periodically query a particular CUPS server for its queues.

Several other filters will be dropped from CUPS in 1.6, to be picked up by the new cups-filters package. Information about this package is on the OpenPrinting web site and a beta release is now available.

This new package restores the filters that will be dropped in CUPS 1.6 and also adds new filters to support PDF as the baseline document format rather than PostScript.

This has already been reported in Bugzilla, and a test update is available.

There is also an Ask Fedora answer about it.

The Test Day page has instructions on what you need and how to test.

I recently added support in system-config-printer for determining the best driver to use for a particular printer.  This is an expensive operation, largely because of the time it takes to get a list of available drivers from CUPS, and the Python program providing the D-Bus service also provides other services.  I wanted the program to be able to deal with other callers while the CUPS operation was in progress.  Here’s how that was done.

Firstly, I already had a class for asynchronous communication with CUPS.  When using PolicyKit to talk to CUPS, the calls use D-Bus which provides an asynchronous API for method calls anyway.  For calls not provided that way the fallback is to queue requests for a worker thread to deal with.

Asynchronous D-Bus calls are made in Python by supplying “reply_handler” and “error_handler” named options in the method call, like this:

self._cupsconn.getPPDs2 (reply_handler=self._cups_getppds_reply,
                         error_handler=self._cups_error)

That call returns right away, but the getPPDs2 operation continues in the background.  When it is done, my reply_handler function is called.  Alternatively, if there is an error, the error_handler function is called.  One or the other will be called, at which point the operation is finished with.

So far so good from the client side, but the question is how to implement a D-Bus service in an asynchronous manner.  Here is a reminder of what a synchronous D-Bus service implementation looks like.

#!/usr/bin/python
import gobject
import dbus.service
import time

BUS='com.example.Timer'
PATH='/com/example/Timer'
IFACE='com.example.Timer'
START_TIME=time.time ()

class Timer(dbus.service.Object):
    def __init__ (self):
        self.bus = dbus.SessionBus ()
        bus_name = dbus.service.BusName (BUS, bus=self.bus)
        dbus.service.Object.__init__ (self, bus_name, PATH)

    @dbus.service.method(dbus_interface=IFACE,
                         in_signature='i',
                         out_signature='i')
    def Delay (self, seconds):
        print "Sleeping for %ds" % seconds
        time.sleep (seconds)
        return seconds

def heartbeat():
    print "Still alive at", time.time () - START_TIME
    return True

from dbus.glib import DBusGMainLoop
DBusGMainLoop (set_as_default=True)
loop = gobject.MainLoop ()
# Start the heartbeat
handle = gobject.timeout_add_seconds (1, heartbeat)
# Start the D-Bus service
timer = Timer ()
loop.run ()

The Timer class is the D-Bus service.  It has a single method, Delay, which delays for a number of seconds and returns that same number.  The program sets a repeating 1-second timer to print “Still alive”, and the D-Bus calls into the Timer service are handled by the D-Bus main loop.

How does this program behave?  Here is its output.  While it was running I used D-Feet to call Delay(3).

Still alive at 1.02512407303
Still alive at 2.0262401104
Still alive at 3.02633500099
Still alive at 4.02575397491
Sleeping for 3s
Still alive at 7.0756611824
Still alive at 8.02573609352
Still alive at 9.02583909035
Still alive at 10.0259339809
^CTraceback (most recent call last):
  File "/tmp/demo.py", line 36, in <module>
    loop.run ()
KeyboardInterrupt

As you can see, while it was handling the call to the Delay method it could not do anything else.  Here is a new version of the Delay function, this time implemented using asynchronous callbacks.

    @dbus.service.method(dbus_interface=IFACE,
                         in_signature='i',
                         out_signature='i',
                         async_callbacks=('reply_handler',
                                          'error_handler'))
    def Delay (self, seconds, reply_handler, error_handler):
        print "Sleeping for %ds" % seconds
        gobject.timeout_add_seconds (seconds,
                                     lambda: reply_handler (seconds))

You’ll notice that the D-Bus function decorator now contains an async_callbacks keyword.  This keyword declares the method keywords that the function uses for reply and error handlers.  Here, I’ve stuck with the usual “reply_handler” and “error_handler” names, and added those same names to the definition of the Delay function on the next line.

This time, when the D-Bus main loop calls the Delay method it will also provide the reply and error callbacks.  When the Delay method returns, its return value is ignored.  The D-Bus call is only ended by calling one of the callbacks.  In this very simple implementation, I’ve arranged for that to happen by setting a timeout.

How does the program behave now?

Still alive at 1.07246303558
Still alive at 2.07272696495
Still alive at 3.07237696648
Still alive at 4.07276511192
Sleeping for 3s
Still alive at 5.07263112068
Still alive at 6.07277011871
Still alive at 7.07274699211
Still alive at 8.07311701775
Still alive at 9.07332015038
Still alive at 10.0734181404
Still alive at 11.0735199451
^CTraceback (most recent call last):
  File "/tmp/demo-async.py", line 38, in <module>
    loop.run ()
KeyboardInterrupt

Much better.

Fedora packages for F-16 and rawhide have been built.

Fedora 15 has been released for a little while now, including GNOME 3.  One of the great new features in this release of GNOME is the System Settings window.  It is easily accessed from the system menu in the top right corner of the desktop.

This shows a System Settings window containing an overview of all the various tweakable settings for the system, including personal preferences.  They are shown as icons, such as “Keyboard”, “Background”, “Printers” etc, organised into groups: Personal, Hardware, System, and Other.  Clicking on one of them changes the window so it shows the settings relating to that topic.  So if you click on Printers, you get this:

It’s great to have printer configuration in GNOME, and this interface is nice and simple.  There are a couple of things that it needs to learn to do though.

One of them is choosing a good driver when adding a printer.  This is something that is not easy, and system-config-printer has a fair amount of logic to deal with it.  Now that logic is exposed via D-Bus, so the GNOME System Settings program will be able to use it in future.

node "/org/fedoraproject/Config/Printing" {
  interface "org.fedoraproject.Config.Printing" {
    method "GetBestDrivers"      (
      in s device_id
      in s device_make_and_model
      in s device_uri
      out a(ss) drivers
    )
  }
}

Given the IEEE 1284 Device ID of the printer, and/or a string describing the make and model, and the CUPS device URI to be used, this method returns a list of drivers that should work.  They are ordered with the “best” choice first, and with descriptions of how good a fit each driver is for this model (e.g. exact, close, etc).

Two other methods have been exposed using D-Bus.  The first is a method for examining a PPD and deciding whether it has unmet requirements.  Often a PPD will containing information about what commands to run to convert from various different formats into the format required for the printer.  This method parses those and returns a list of executables that are missing.

node "/org/fedoraproject/Config/Printing" {
  interface "org.fedoraproject.Config.Printing" {
    method "MissingExecutables"      (
      in s ppd_filename
      out as missing_executables
    )
  }
}

The final method is for grouping together CUPS device URIs that address the same physical device.  It is often the case that there is a choice of backends to use for a printer, and this method helps to sort out which devices are just different choices for the same printer.

node "/org/fedoraproject/Config/Printing" {
  interface "org.fedoraproject.Config.Printing" {
    method "GroupPhysicalDevices"      (
      in a{sa{ss}} devices
      out aas grouped_devices
    )
  }
}

It takes a dictionary (keyed by device URI) of IPP attribute dictionaries describing devices, and returns a list of physical devices, each one represented by a list of device URIs that refer to it.

These methods will be in system-config-printer 1.3.5.

The general idea is that new instances of the New Printer and Printer Properties dialogs, as well as a single instance of the Job Applet, can be requested, and these are given their own object paths.  Each has its own simple interface.

In this way, it would be fairly easy for an application to present a dialog for adjusting the printer properties for a queue, and also for starting a job applet.

Here are some more details:

Bus name: org.fedoraproject.Config.Printing
Object path: /org/fedoraproject/Config/Printing

Interface: org.fedoraproject.Config.Printing

Method NewPrinterDialog

Creates a new instance of the New Printer dialog and returns its object path.

Method PrinterPropertiesDialog

Creates a new instance of the Printer Properties dialog for a given printer name and returns its object path.

Method JobApplet

If a Job Applet (system tray icon) instance is already active, returns its object path; otherwise creates a new one and returns its object path.

Interface: org.fedoraproject.Config.Printing.NewPrinterDialog

Method NewPrinterFromDevice

Show a dialog for creating a new printer, given a device URI and an IEEE 1284 Device ID.

Method ChangePPD

Show a dialog for changing the PPD for an existing printer.

Signal PrinterAdded

The printer has now been added.

Signal PrinterModified

The PPD has now been changed.

Signal DialogCanceled

The dialog has been cancelled by the user.

Interface: org.fedoraproject.Config.Printing.PrinterPropertiesDialog

Method PrintTestPage

Print a test page to this printer.

Signal Finished

The dialog has now closed.

Interface: org.fedoraproject.Config.Printing.JobViewer

Method Quit

Stops the applet.

Signal Finished

The applet is no longer running.

This test day is for testing all aspects of printing, including setting up the printer, sharing printers on the network, and printing jobs.

If you have access to a printer, please come along and help test things out!

For those unfamiliar with printing, this sounds easy enough. To make the user interface as easy to use as that takes more work than you would think at first glance. It’s the direction I’ve been moving towards in system-config-printer.

Here is a description of the issues involved.

1. Once you’ve found a printer, you then have to choose a driver for it.
2. Once you have a driver, it may need adjusting so that the installable
   options are correct.

Choosing a driver

The thing to know about choosing a driver is that it is not well-defined. CUPS takes care not to take sides or pick favourites, and leaves it to the client application to decide which driver to use and indeed which drivers are likely to work for the printer.

There is no way to be certain you have a complete list of drivers that will work for a given printer. The most reliable way of matching up printers and drivers is to have each PPD file list all of the IEEE 1284 Device IDs for devices that it supports. This practice is not wide-spread, although there has been progress towards this in Fedora.

In response to a CUPS-Get-Devices IPP request, CUPS will have given you attributes describing the device: device-id, device-make-and-model, device-info and so on. Likewise, each driver has attributes in the response to CUPS-Get-PPDs describing itself, including ppd-make-and-model. However, device-make-and-model is not quite the same type of thing as ppd-make-and-model.

The device-make-and-model describes the make and model of the device. The ppd-make-and-model describes the make and model of the printer that the driver is written for, as well as the driver itself.

There is no canonical list of printer manufacturer names, and printer manufacturers routinely write their names differently, e.g. HP, Hewlett-Packard, Hewlett Packard, HEWLETT PACKARD, etc.

There are very often discrepancies between how the device describes its model name and how PPDs describe it, especially when it comes to drivers that support a range of models.

Since Fedora 13 we’ve had special RPM tags on driver packages which can be used to give the user the opportunity to install any packages containing drivers that are known to support this device, once we know the device-id. They are tagged with the make and model of the device as reported in its Device ID.

There isn’t really an easy way to pick the right driver. What system-config-printer does is filter the available drivers using a variety of methods to find a list of the drivers that might support the printer, and then sort them into a preference order based on some XML-coded rules.  Ways of finding candidate drivers include:

• Matching MFG and MDL fields of the Device ID (but not all PPDs contain Device IDs)
• Converting the ppd- and device-make-and-model strings at runtime into semi-canonical representations in hopes of getting a match that way (but this will not always be successful)
• Looking for what look like model numbers and making this successively generic, e.g. 2215… 2210… 2200… 2000 (but the driver stands less chance of working the more generic the match)
• Matching CMD fields of the Device ID (but this is only good for finding “generic” drivers, e.g. PCL)

After this, some PPDs are eliminated: those that seem to match but which depend on an optional PostScript module which is not present in this device. If the Device IDs match in the MFG and MDL fields, but the PPD’s CMD field has POSTSCRIPT and the device’s CMD field does not, the PPD is likely no good. (This is a recent convention but has been adopted by Ricoh.)

The reason for sorting PPDs into a preference order is that there are lots of situations where one driver is most likely better than another.  The situations are numerous but include:

• If the manufacturer has supplied a driver, use that.
• Otherwise, if we can send PostScript straight to the printer, we should probably do that rather than sending raster data.
• …except if the printer does not come with a large amount of memory, in which case raster drivers may be more reliable.
• Gutenprint is usually a high quality driver to use, so use that when possible.
• …except if we’re printing to a colour laserjet, because Gutenrprint only provides black and white output at the moment.
• Native CUPS drivers are generally preferred to the older-style Foomatic drivers.

…and so on.  I wrote about the mechanism used in system-config-printer a while ago.  The current rules are here.

Note that there may not be any driver you can choose that will work. There is no “fail-safe” driver that will work for all printers — not even sending them ASCII text or some sort of bitmap.

Setting installable options

Now, assuming you have chosen the right driver it may need some tweaking once it has been assigned. This is because printers have optional parts, e.g. extra memory, duplexer units, binders, staplers etc.

CUPS provides a way to ask the printer to tell CUPS what those settings are: it’s a special print job of type CUPS-Command that says “AutoConfigure”. There are attributes that will tell you whether CUPS-Command jobs are accepted, and if so whether the AutoConfigure command job is accepted. If this is the case, sending this small job should complete the set-up of the PPD.

Most (if not all) non-PostScript printer drivers do not support the CUPS-Command format, however. If there are installable options in this case (which you can detect by seeing if there is an InstallableOptions group in the PPD), the only way to avoid asking the user about them is to hope the defaults are safe to use as they are.

The package with this patch is cups-1.4.5-9.fc15.

Merry Christmas!