AW: [Desktop_printing] Role of CUPS and error handling
Robert L Krawitz
rlk at alum.mit.edu
Mon Apr 3 17:14:06 PDT 2006
Date: Mon, 03 Apr 2006 08:38:20 -0400
From: Michael Sweet <mike at easysw.com>
Robert L Krawitz wrote:
> Date: Sun, 02 Apr 2006 20:30:34 -0400
> From: Michael Sweet <mike at easysw.com>
> Apples and oranges. I'm talking about the uses of your custom
> linearization options WRT text documents. IOW, some uses of color
> don't require extreme precision or accuracy.
> That's all well and good, but why not let the *user* decide what does
> or doesn't require extreme accuracy? A text document with embedded
> images may require that kind of extreme accuracy.
I'm not suggesting that we don't let the user decide, however I
*am* suggesting that throwing a complicated dialog in front of the
user isn't the way to do that.
I'm not saying that it is either. There are other ways we could
present it; an "Advanced" button, a preference of some kind that
someone could set, and so forth. I don't claim to be a user interface
expert, but it's fundamentally important to me that power users have a
way to accomplish what they need to.
We have always disagreed on this. You argue for the uber-user that
wants a knob for every parameter used by the driver. I argue for
ordinary users that want something that works and isn't confusing
There *is* a middle ground, we just need to find it.
> Not necessarily. Put an ordinary user in front of
> Illustrator's print panel and they will quickly get lost, yet
> Illustrator needs the more complicated print dialog and not
> the standard one...
> I think the key here is to define a standard print dialog that
> handles most applications, and then define the interfaces/
> extensions that can be used for "advanced" applications that
> require something beyond the standard dialog.
> I see it differently: we need to figure out how to allow the user
> to switch between the simple and advanced dialogs and make it
> easy and obvious for the user to do so.
You want to essentially put a manual color profiler in every
application without having the requirements or use cases to back it
up. *If* we can define these things, we'll have a much better
chance of coming up with something that will work. Otherwise,
you'll just end up with something that works for a small subset of
the whole (users, drivers, etc.)
To my mind, this is backwards.
Printing is a basic operation on any document of any kind. Therefore
I would argue that all document-centered applications should offer a
print dialog with identical behavior. The print dialog in my image
editor should work the same as the print dialog in my word processor
or spreadsheet. So the right test should be for use cases on printing
documents of any kind -- images of all kinds, text documents,
If we provide interfaces and extensions like this so that "advanced"
applications can implement their own extended print dialogs, then
every such application is likely to have its own dialog that behaves
subtly differently. I cannot see how that could possibly be any
better for anyone -- application developers, library developers, or
users -- than a common dialog. The key is to implement them in a way
that's minimally confusing to people who don't need the extensions
while still allowing experts to have access to them.
I don't think that this cuts across application lines. Both basic and
advanced users use image editors and word processors, and I don't
think we can say a priori that the advanced user's printing needs from
a word processor are different from that same person's needs from
printing from an image editor.
There may well be cases where a special print dialog is required --
where the printing needs are inherently different from the normal
document-centric model. For example, an application that generates
bar codes might have unique needs that a general purpose document
processing application doesn't. But for most document-based
applications, I think the print dialog should be the same -- with the
advanced options available for advanced users, but not necessarily for
users with simpler needs.
Now, as for specific use cases for needing extreme color accuracy and
precision when printing from a word processor:
1) A photographer creating an advertising brochure for her business.
She wants samples of her work to be reproduced with extreme
fidelity, on glossy photo paper, in addition to properly set text.
Perhaps said photographer also wants to mail this brochure to a
variety of clients. Rather than using mailing labels on lower
quality paper, she wants to print the mailing label on each
brochure. Therefore, she needs the mail merge capabilities of a
2) An graphic artist producing an album for a client, with a mixture
of text, graphics, and images. For example, a catalog for a swanky
auction might include photographs of the objects for sale along
with textual descriptions of the items, as well as the auction
In general, there seems to be a bit of a misconception that we're only
interested in the needs of high end users. That's not correct -- the
issue is that I don't see too many people in the FOSS community who
*are* interested in catering to very demanding users. There certainly
are exceptions; Argyll, LCMS, Cinepaint are projects that are
interested in this, but most of the FOSS applications appear to be
targeted either at web graphics (which are displayed on all kinds of
hit or miss displays that are at best 8 bits deep) or general business
and personal documents that aren't particularly color critical.
I have no problem at all with making it easier to use Gutenprint, but
that's not going to happen by simply stripping out options because
beginners might be confused by them and even most advanced users will
use them infrequently. Infrequent is not the same as never. I'd
rather focus our energies on how to present the options in ways that
will work for both beginners and advanced users.
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the Printing-summit