AW: [Desktop_printing] Role of CUPS and error handling
Robert L Krawitz
rlk at alum.mit.edu
Sat Apr 1 14:17:47 PST 2006
Date: Sat, 01 Apr 2006 16:31:52 -0500
From: Michael Sweet <mike at easysw.com>
Robert L Krawitz wrote:
> 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
OK, that answers my question.
> * 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
I think we're going to continue to disagree :-)
Linearization and profiling complement each other. At least as I
understand it, trying to profile a non-linear device will not produce
very good results. The idea is to adjust the per-channel curves to
get a good linear ramp, and then you profile the device.
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.
Interesting thought that...
> * 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... :(
Life isn't always perfect, but I do sympathize with users who don't
want to have to sort through a few dozen options. At the same time, I
don't think it's acceptable to not provide useful options just because
new users won't understand 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.
I'm thinking of offering three sets of margins for Epson printers:
normal, zero margin, and full bleed (so that full bleed can be used
when it's really essential for there to be absolutely no margin, even
if the paper's slightly out of alignment). That would make the
problem even worse. This is something we should discuss.
More information about the Printing-summit