AW: [Desktop_printing] Role of CUPS and error handling

Robert L Krawitz rlk at
Sun Apr 2 19:21:40 PDT 2006

   Date: Sun, 02 Apr 2006 20:30:34 -0400
   From: Michael Sweet <mike at>
   CC: desktop_printing at, kpfeifle at

   Robert L Krawitz wrote:
   >    Date: Sun, 02 Apr 2006 16:31:42 -0400
   >    From: Michael Sweet <mike at>
   >    Robert L Krawitz wrote:
   >    > ...
   >    >    Both situations do require some specialized UI, but that UI would,
   >    >    IMHO, be inappropriate for a word processor or web browser.
   >    > 
   >    > Perhaps, although there could be an "extended settings" panel or
   >    > the like.  If someone's viewing some kind of tagged image in a
   >    > browser, it might be useful.
   >    > 
   >    > I disagree that it's not useful in a word processor -- maybe not
   >    > as useful, but I wouldn't say it's not useful at all.  Consider
   >    > the case of someone writing a document about color management.
   >    I don't think that someone will be asking for a particular black to
   >    use for the text... :)
   > Uh...isn't that what RGB+K is all about?

   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.

   >    Obviously, there *are* use cases for color management in ordinary
   >    documents, but the question is whether the advanced controls need
   >    to be in every application.
   > The question to me is why different applications (or at least
   > different apps based on the same toolkit) should have different print
   > panels.  Wouldn't it be easier and less error-prone to have the same
   > panel for each app?

   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.

Robert Krawitz                                     <rlk at>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at
Project lead for Gutenprint   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

More information about the Printing-summit mailing list