A NEW PRINTER ADMINISTRATION TOOL
=================================
Draft 2, Feb 9th 2006
Tim Waugh
1. PROBLEMS
--------
1.1. Alchemist
---------
There are various reasons for redesigning the current
system-config-printer configuration tool. A brief summary is:
* the XML file format it uses is inflexible
* the configuration options are limited to those common to both
spoolers we were shipping at the time the XML format was decided
* it is VERY SLOW: you can't *modify* configuration, only write out
entirely new configurations (i.e. trigger the back-end)
* again, due to the XML format chosen, we are tied to the foomatic
database in such as way that we absolutely require foomatic to know
about the printer before we can configure it.
Even if you have the manufacturer's PPD file, there is very little
you can do to get your printer working.
* changes made using the CUPS configuration interface
(http://localhost:631/), or any other method external to
system-config-printer, are not reflected in the XML file and so
cannot be modified and often get overwritten.
1.2. Stateless Linux
---------------
An extra consideration to take into account when re-designing the
administration tool is Stateless Linux. The requirement from that
project is that users may specify their own (private) queues for
submitting jobs to.
For example, a particular user may want to print to an SMB printer,
with certain default settings such as which input tray to use. With
Stateless Linux, this queue definition will be tied to the user's home
directory so that they can log in on any stateless workstation and be
able to print to their queue.
2. SOLUTIONS
---------
2.1. Stateless Linux
---------------
A Stateless Linux configuration has /etc read-only. This causes a
problem with local printers: automatic detection of a local printer
needs to add a queue. This runtime configuration means that the CUPS
configuration files, currently stored in /etc/cups, should be moved to
/var/run. Since /var/run does not preserve data over a reboot, this
should only be done for stateless configurations. One possible
trigger for this special stateless behaviour would be for CUPS to
detect that /etc is read-only -- or else, it could be a configuration
option.
2.1.2. (intentionally left blank)
2.1.3. Per-user queues in system CUPS daemon
-------------------------------------
At session start, for each per-user queue defined by the user, the
CUPS daemon is notified that a per-user queue needs to be created (if
it does not already exist). This could be done using D-BUS.
Firstly, the CUPS daemon is told to remove all per-user queues for
this user IF they are not processing jobs. Then, for each per-user
queue the CUPS daemon is given the PPD file from the user's home
directory, and the URI for the printer, as well as the queue name.
Given this information, the CUPS daemon will then:
* copy the PPD into its ppd directory
* set up a queue if it does not already exist
This new queue will NOT be advertised in IPP "browse" broadcasts.
Jobs may only be submitted to this queue by the owning user at the
local machine, i.e.:
cupsd.conf: -----------
| Allow from localhost |
| AuthClass Basic |
----------------------
printers.conf: ------
| AllowUser the_user |
--------------------
In addition to the current "certificates" method of
avoiding the need to type in a password when submitting jobs, we could
patch CUPS to use D-BUS for the same purpose.
REMAINING QUESTIONS:
Should steps be taken to avoid accidentally forming round-robin
classes with other per-user or remote queues of the same name as the
user-defined queue? One suggestion is to use 'user-$uid-$queue' as
the real name, but present it to the user as '$queue'.
2.2. Better configuration method
---------------------------
It will solve many of the configuration issues mentioned in 1.1 if a
new printer administration tool would configure CUPS directly rather
than maintaining a separate configuration file. There are two main
ways of doing this:
* using the command-line tools such as lpadmin and lpoptions
* using IPP to communicate with the CUPS daemon directly
Using IPP directly will offer more flexibility. Some of the more
subtle changes we will need to make may not be possible using
command-line tools alone. Additionally, using IPP for configuration
allows the possibility of configuring remote CUPS instances using the
graphical tool, and this will be important for print servers that do
not have a full graphical interface installed.
Additionally, the user interface must provide a method for the
administrator to enable and disable queues. Some queues can get
disabled as a result of an error detected by the backend, and there is
currently no means of re-enabling the queue using the existing
graphical interface.
2.3. IPP authentication
------------------
There are two options:
* The admin tool runs with user privileges. An authentication dialog
box will appear when configuring the CUPS daemon using IPP. Some
mechanism similar to consolehelper needs to be devised in order to
avoid the need to keep asking for passwords. (This is my preferred
alternative.)
-or-
* The admin tool uses consolehelper as before, but can run in
unprivileged mode in order to configure only per-user queues.
2.4. Modifying PPD options
---------------------
The new printer administration tool will be responsible for providing
a graphical interface for changing default queue options. These are
options such as duplexing, page size, and print quality. All of these
options are stored in the PPD file representing the queue, and this is
modified by the CUPS daemon when it receives the IPP request to do so.
The GTK+ print dialog will also allow these settings to be over-ridden
on a per-job basis. The user interface will be largely the same, and
there is opportunity for code-sharing here. Some aspects of PPD
option representation (such as grouping and constraints) require
careful implementation in the user interface, and so it would be
better not to duplicate this work.
REMAINING QUESTIONS:
Perhaps the administration tool needn't provide a method for
changing default options at all? After all, the applications will
be remembering their job settings between prints.
2.5. Page size as a special case
---------------------------
When adding a new queue for an automatically detected printer, an
appropriate default page size should be chosen based on the system
locale.
CUPS will already do this for us when a new queue is created, so there
is no action to be taken.
2.6. Persistent settings
-------------------
Unplugging a USB printer and re-attaching it must retain the settings
it had prior to unplugging. This needs to be handled by HAL.
One easy method is to avoid automatically removing queues at all.
Instead, the queue could be disabled (i.e. cupsdisable) when the
device is unplugged, and enabled when inserted.
For this to be feasible, it must be possible to identify a
newly-inserted printer as being the same one that had been unplugged
previously. Many USB printers provide a serial number in their IEEE
1284 Device ID string which can be used for this purpose.
If there is no serial number available, the manufacturer and model
strings could be used to identify the correct queue to act upon.
The proposal that persistent settings be handled by simply
disabling/enabling queues rather than removing queues altogether means
that persistent settings can be managed entirely by HAL.
2.7. Automatic detection
-------------------
A local printer will be automatically detected by HAL and an
appropriate queue created for it.
2.7.2. Remote discovery
----------------
For remote printers, the common types are: SMB, JetDirect, and
IPP/CUPS. IPP/CUPS instances can broadcast browse packets to
facilitate automatic detection for clients. We already make use of
this.
For JetDirect printers there is no way of automatically finding them
other than probing each address on the subnet.
For SMB printers there may very well be a means of actively
discovering remote queues automatically, perhaps by querying the
domain server and then each named SMB host in turn. However, I think
authentication details (such as username/password) need to be
configured when you create a queue, rather than when a job is
submitted -- the information is placed into the URI for the queue.
I am not aware of a passive discovery method for SMB.
It has been suggested that UPnP could be used for remote discovery of
some newer network printers.
2.7.1. Method for creating a queue
---------------------------
The vast majority of printers provide IEEE 1284 Device ID strings to
identify themselves. These strings provide: manufacturer name, model
name, description, and command sets understood by the device. For
example:
MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo
830U;CLS:PRINTER;DES:EPSON Stylus Photo 830U;
or:
MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet
1200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 1200;MEM:8MB
The foomatic RPM package provides a database of printers and printer
drivers. It stores IEEE 1284 Device ID strings for a large number of
printers. It also stores information about which drivers may be used
with a given device, and which of those is recommended.
When a local printer is detected, its IEEE 1284 Device ID string
should be retrieved. For parallel port printers,
/proc/sys/dev/parport/*/autoprobe provides this; for USB printers,
/sys/devices/*/*/usb*/*/*/ieee1284_id provides it in newer kernels (>=
2.6.15-1.1826.2.6.FC5).
The foomatic database should then be consulted to look up a printer
model based on the manufacturer and model IEEE 1284 Device ID
fields. (NB: printconf currently uses some tricks to match printer
models for those whose IEEE 1284 Device IDs are not known to
foomatic).
If no printer is found, the command set field should be examined. If
"POSTSCRIPT" is found, the generic PostScript driver can be used. If
"PCLXL" is found, the generic PCL 6/PCL XL driver can be used. If
"PCL" is found, the generic PCL 3 driver can be used. Otherwise, a
manufacturer's PPD is required from the user.
If the printer was found, and there is a manufacturer-provided PPD
available for the recommended driver for it (a PPD is specific to a
printer model and driver combination), the queue is set up
automatically and needs no user intervention.
If there was no manufacturer-provided PPD (including the case where
the printer was not found in the database), the user should be asked
to see if they have a manufacturer-provided PPD file.
On creating the queue, the page size needs to be adjusted
appropriately for the locale.
2.7.2. Code sharing
------------
IEEE 1284 Device ID strings may also be provided by remote printers
that are SNMP-capable. There are some subtleties in creating a new
queue, such as altering the page size.
As a result, the mechanism for creating a queue outlined in 2.7.1
needs to be used for:
a) automatically detected printers
b) adding printers using the admin tool
c) adding per-user remote queues
2.8. Admin tool for creating system queues and per-user queues
---------------------------------------------------------
If it makes sense from a user interface perspective, it would be
useful to combine the facility for creating and editing per-user
queues into the admin tool, since a lot of the same functionality is
needed.
Additionally, in order to keep the queue creation logic in one place,
it might very well make sense for HAL to hand off the IEEE 1284
information from a detected local printer to the admin tool rather
than trying to configure a queue on its own.
(NB: This bit needs someone with some user interface sense:)
Perhaps the interface could have two tabs, one for "System print
queues" and another for "My print queues". Browsed queues would not
be shown.
For each tab, the queues could be listed exactly as they are in the
GTK+ print dialog (including number of jobs in queue, and the
location).
Queue sharing will be allowed for "System queues" (as currently) but
not for "My queues".
Editing a queue will allow the same things to be edited as currently:
which driver to use; driver options; queue options such as banner
pages.
This combined printer administration tool would be launched by the
GTK+ print dialog's "Add printer" button.
2.9. Error handling
--------------
The foomatic we are shipping for Fedora Core 5 provides a special CUPS
backend: beh (backend error handler). It allows the administrator to
modify the behaviour of the backends when errors are encountered:
whether to try again, how many times to do that, and so on.
It would be useful to be able to offer this in a user interface. The
per-user queues would mean that an unprivileged user would even be
able to modify error handling for their own jobs.
2.10. Ink levels and maintenance functions
------------------------------------
Although there is no unified way of doing so yet, a future enhancement
to the administration tool would be to allow the administrator to
check ink levels and perform functions like aligning/changing
cartridges, for printers that have such a facility.
2.11. Beyond scope
------------
There are other things that need fixing with printing, such as status
feedback to find out if the ink has hit the paper. These are beyond
the scope of the administration tool.
Attachment:
pgpi101QCYpgP.pgp
Description: PGP signature
