AW: [Desktop_printing] Role of CUPS and error handling

[Michael Sweet]

Robert L Krawitz wrote:
>  ...
>    I was only talking about the scope of the technical task. And that
>    is the same for each: provide a compiled "raster-to-myprinter"
>    filter (source or not), drop it into the standard CUPS directory,
>    and povide a PPD that calls this filter. Everything else will be
>    taken care of by CUPS.
> 
> Does CUPS (1.2) automatically detect that the new PPD file has been
> installed and automatically create the printer queue (or even better,
> detect that you've inserted a CD in the drive, that the drive contains
> a printer driver, and install the driver first), and perhaps pop up a
> window offering to do a test print to make sure that the printer is
> installed correctly?  Tyler Blessing, our OS X developer, wrote a tool
> to do a lot of that stuff, and it seems to be important to a lot of
> users.

This isn't something that CUPS does (we don't have access to the user's
desktop), but it *is* something that KDE/GNOME/whatever could support,
and very easily.  Right now the user would just need to open the CUPS
admin page and click on the "Add This Printer" button.

> ...
> Last I was aware, not all Linux distributions had settled on udev for
> device hotplugging, and BSD uses something different, Solaris uses
> something different yet again, and so forth.  CUPS would have to be
> awfully smart to deal with all of this.  Maybe it is.

There is a difference between hotplug support (notification that a
new device is available), and device discovery (finding devices that
are available).  CUPS does device discovery.

Hotplug makes sense for desktops - user plugs a printer in, desktop
asks user if they want to add the printer.  This could also be made
completely automatic, at least for locally connected printers.

> ...
> The problem here is that "most" means "everything but the more
> interesting things".
> 
> * Ability to "turn off" certain options.  Some of our floating point
>   options allow a value within a certain range, or the option can be
>   turned off.  For example, we support GCR upper and lower bound
>   points and gamma value.  The GCR lower bound can range between 0 and
>   1 (if the total gray value is less than the lower bound, the gray is
>   printed entirely with color ink).  It can also be turned off,
>   allowing the driver to select an appropriate value.

Well, then provide an "Auto" or "None" choice, in addition to the
presets and (presumably) the custom option slider.  The beauty (if
you can call it that ;) of PPD options is that they can be of mixed
type.

> * Curves (arbitrary piecewise linear or dense or what have you).  If
>   you want to do your own linearization -- and I've had recent
>   requests about this -- you need control at that level.  Gamma curves
>   aren't enough.  Again, the CUPS 1.2 extensions don't have this.

We've disagreed on this for many years now.  I don't see this as a
major issue.  In my experience, this kind of control is only used
by so-called power users - I say "so-called" because there are
better ways to do it than passing raw lookup tables.

The most obvious replacement for arbitrary lookup table options are
ICC profiles.  The framework (but not all of the implementation) is
already in place for CUPS to allow a user to select a profile for
printing (cupsICCProfile=foo).

You also have the option of defining your own PPD attributes that
image processing apps can look for.  The LUT can then be passed
in as an option/attribute that the driver can decode on its own.

> * Ability to hide certain options depending upon the values of other
>   options.  For example, if the output mode is set to black and white,
>   hide all of the color options.  We're doing a somewhat crude hack by
>   offering two sets of PPD files (simplified and full-featured), but
>   I'm sure the usability folks will be all over us for that.

The problem with this is that you can end up hiding options from
users and they have no way to find them... :(

> * Ability to change imageable area based on other option values
>   (e. g. if you select full bleed the imageable area should change).
>   That can be done by duplicating the paper sizes, but given that we
>   already blew up some older versions of CUPS with more than 100 paper
>   sizes I doubt that this would be very popular.

There are definitely usability issues with huge numbers of choices.

This, in particular, is one of the things I'd like to talk about
for CUPS 1.3.

> In any event, the CUPS 1.2 extensions don't help applications that
> don't know about them.

No, but assuming you have generated your PPD files right, users will
still be able to access the major functionality of your driver.

Also, as long as applications use the CUPS API, they will get most
things "for free"...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com