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.

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

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.

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.

You can help put this right, whether you are running Fedora 13 Alpha, or Fedora 11/12.

Information on collecting Device IDs is given on the Printing Test Day page but here is a good way of doing it:

1. Make sure you have the foomatic, gutenprint-cups, and hpijs packages installed
2. Connect and switch on your printer(s) — yes, even network ones

3. git clone http://git.fedoraproject.org/git/system-config-printer.git
   cd system-config-printer
   su -c ./check-device-ids.py

4. If you see “MISSING” in the output, file a bug in Bugzilla against the relevant driver

Incidentally, some statistics on Device IDs in Fedora 13:

• We have at least 10,100 drivers
• Of those, over 6,200 have Device IDs associated with them
• That means we’re missing Device IDs for nearly 40% of all our printer drivers

$ lpinfo -l -m | grep 'device-id = ' | wc -l
10135
$ lpinfo -l -m | grep 'device-id = $' | wc -l
3922

UPDATED: Changed instructions to run check-device-ids.py using su.

One of the new features in Fedora 13 is the automatic installation of printer drivers when USB printers are connected.  For this feature to work, specific information about each printer model needs to be stored in the relevant driver packages.  Some of this is done but we need your help to test it and to collect more Device ID strings.

Please come along and join in!

Before PolicyKit awareness was added there was already adjustable policy controlling IPP operations.  This ‘CUPS policy’ mechanism is provided by the CUPS scheduler, cupsd, and its configuration is in the file /etc/cups/cupsd.conf.  This controls which IP addresses are allowed to access various HTTP locations corresponding to the CUPS configuration actions (such as http://cups-server:631/admin), and which IP address, users, groups, and classes of users can carry out the various IPP operations such as cancelling jobs.  It also specifies whether and how users must authenticate themselves.

This CUPS policy is great for managing CUPS servers remotely but is not consistent with the method used by the rest of the desktop environment, PolicyKit.  Although the CUPS policy can be adjusted using a fairly easy to use list of check-boxes (available in both the CUPS web interface and via System→Administration→Printing), it is not fine-grained enough to be as useful as PolicyKit can be.  The CUPS policy itself is very fine-grained, but this power is only unleashed by editing configuration files.

With PolicyKit the policy can be adjusted easily using a graphical tool, to make it easier to perform certain tasks for those needing to do so.  The intention is for Fedora “spins” to have appropriate default policies depending on their target audience, so that a desktop spin might allow the active console user to perform all administration tasks without asking for authentication for example.

We have two types of policy then, CUPS policy and PolicyKit policy, for controlling print administration tasks.  The CUPS policy in Fedora is unmodified from the upstream CUPS releases, and is fairly restrictive.  The default PolicyKit policy for printing administration in Fedora is also fairly restrictive, and the overall policy is only as restrictive as the most relaxed of the two.

The implementation consists of a package called cups-pk-helper (created by Vincent Untz) which provides the D-Bus system service which is the mechanism for the policy — it performs the administration tasks on behalf of its clients by talking to the CUPS scheduler using IPP.  It runs as root so the default CUPS policy allows it to perform all administration tasks.  It can authenticate itself as root by connecting over a UNIX domain socket (CUPS will use peer credentials to discover the requesting user) or, if that is not possible, by proving that it can read a certificate file only readable by root.

At present the only client for this system service is the printer configuration tool accessible from System→Administration→Printing.  The CUPS web interface and command line tools only use IPP directly.

How fine-grained is the policy?  Here are the defined operations:

• Set a printer as system default printer
• Enable/disable a printer
• Add/remove/edit a local printer
• Add/remove/edit a remote printer
• Add/remove/edit a class
• Get/set server settings
• Restart/cancel/edit a job you own
• Restart/cancel/edit a job owned by another user
• Get the list of available devices (available in Fedora 11 soon)

For each of these operations, the policy depends on who is attempting to carry out the operation:

• Someone on the active console
• Someone on the console but inactive
• Anyone else

For each of these groups of users, the policy can be that they are disallowed altogether, that they are allowed without authentication, or that they require authentication either as themselves or with the root password.  If authentication is required it can be:

• Required every time
• Required once but not needed for the rest of the time the configuration program is running
• Required once per session
• Required once and not again

Here is a screenshot of the program used for editing this policy, accessible from System→Preferences→Authorizations:

For me the most annoying problem is that the printing troubleshooter does not work in Fedora 11 as shipped. This is fixed in the test update for system-config-printer. Using the troubleshooter can be very valuable when tracking down problems, but most especially when reporting printing bugs. Please install the update and try the troubleshooter (Help->Administration from the system-config-printer window) before reporting bugs. This updates system-config-printer to 1.1.8, released on Thursday, which has lots of fixes.

The other test update I’ve pushed in the last week is for cups. Fedora 11 was released with beta 3 of CUPS 1.4. The current upstream version is 1.4rc1, and there is a test update for that out now. Please try it out if you are having problems with printing. I will update it to 1.4.0 when it is released.

I am slowly working my way through the backlog of bugs that have been reported, both in Bugzilla and on mailing lists. Please be patient!

I’ve taken some screenshots of system-config-printer 1.1, and this version will be in Fedora 11 when it is released this year.

Screenshots below.  As an aside, I have to say that taking screenshots is one of the most rapid methods of finding bugs I know!

Adding New Printers

Connecting a new USB printer causes it a queue to be created for it automatically.  There is now an option to print a test page at that point.

Printing Jobs

When a print job is submitted, the printer icon appears in the notification area.  For queues that require a user name and password to print jobs, this is collected now.

The “Remember password” check-box enables gnome-keyring support so that printing documents to that printer in future will not need to ask you for a password.

There might be a problem with the printer, such as lack of paper or ink — the user needs to know about this too.

Hopefully there won’t be any problems with the filters or the backend, but in that unlikely event the user is given the opportunity to troubleshoot it.

When the job finishes the user is told about it.  This notification is new in 1.1.

Clicking on the icon shows the jobs you currently have in the queue for printing.  This jobs list is also available from the printer configuration window by right-clicking on a printer and selecting View Print Queue — in that case, jobs from all users are shown.  Completed jobs can also be included, as shown below.

Printer Configuration Window

Now let’s take a look at the main window containing the available printers.  Network printers are shown with a different icon than locally-connected printers, and the default printer for this user is shown with an emblem.  The list of printers can be filtered (a new feature in 1.1).

Printer Properties

Double-clicking on a printer shows its properties, things such as its description and location which appear in print dialogs, as well as the device and driver to be used.  For native CUPS drivers it is possible to perform maintenance commands such as cleaning print heads.

From this dialog you can set whether the printer is enabled (i.e. processing jobs in its queue), whether new jobs are accepted into the queue, and whether jobs can be accepted from other machines.

Access can be limited to certain users.

Lots of printers have optional accessories, and the PPD options relating to those are gathered together.  In CUPS 1.4 it will be possible to add a button to gather this information from the printer itself if it speaks PostScript (but what to name the button?  “Scan”?).

The other printer-specific options can also be examined and changed.  For PPDs that support it, translations for the option names are shown.

There are other CUPS options that are not specific to any particular printer.

Information from the printer is shown on this last screen, which is entirely new in 1.1.  Ink level reporting is currently only available for printers that do so using SNMP, but hopefully drivers such as HPLIP and Gutenprint will add this capability soon.

Server Settings

That’s the printer properties dialog as it currently stands.  So, back to the main window.  Selecting Server→Settings allows alteration of system-wide print server settings.  It’s a bit awkward at the moment because it’s split into two dialogs, Basic and Advanced.  This will get better in future.

Clicking Advanced allows you to adjust some other settings:

The CUPS web interface has improved a lot in CUPS 1.4 and I would like to improve the system-config-printer server settings dialog to match.  I think that will have to wait until system-config-printer 1.2 though.

See the roadmap in the trac instance on fedorahosted.org for information on other things that are planned for this version and future versions.