AW: [Desktop_printing] Role of CUPS and error handling

[Robert L Krawitz]

   Date: Mon, 03 Apr 2006 21:32:50 -0400
   From: Michael Sweet <mike at easysw.com>

   Robert L Krawitz wrote:
   > ...
   > 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 do agree that a common dialog is a good thing, and I think when
   applications support a paged/preview view of their documents (or
   whatever it is you are manipulating) the common dialog *is*
   sufficient.

   That said, there are applications (typically the "professional"
   ones...) which do not follow this model.  On the Mac you get a
   semi-standard print dialog with a separate application-specific
   option pane.  On Windows, you get a custom print dialog with a
   "setup" button which displays one of the two standard print dialogs
   with a button that confusingly says "Print" on it (but doesn't
   print, it just returns control back to the application's print
   dialog).

   Take what you will from this...

Doesn't sound to me like that's a very "easy to use" kind of thing.  I
can see why there might be additional application-specific printer
settings, but the settings I'm thinking of are properties of the
driver, not the application.

   > 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
   >    word processor.

   OK, my gut thinks this is a bogus use scenario - if quality is an
   issue, you won't mail your photo brochures printed on an inkjet
   printer without putting them in an envelope, otherwise they *will*
   get destroyed on the way to your potential clients.  If they are in
   an envelope, then you won't be printing the address on the brochure...

Fine.  Suppose it's an invitation-only reception, and each invitee is
being given this kind of personal brochure.  No address, but each
client is given one personalized by name.

Yes, this is hypothetical, but the point is simply that there's a
*plausible* use case here.

   > 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
   >    house logo.

   It is unlikely that you'd use a word processor for this - word
   processors typically only provide limited layout capabilities and
   are not optimized for documents with large numbers of
   high-resolution images.  On Windows or MacOS you'd probably use
   InDesign or Quark to do the layout, both of which are considered to
   be "pro" apps.

Or Pagemaker, as I used way back when :-) But it would feel very
strange to me that Scribus, say, would allow you access to curves that
are part of the printer driver while OpenOffice.org wouldn't.

-- 
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."
--Eric Crampton