Re: Printer driver UI [proposal]

[Robert L Krawitz <rlk alum mit edu>]

   Date: Fri, 14 Mar 2003 10:18:01 -0500
   From: Michael Sweet <mike easysw com>

   The issue is that the example doesn't make any sense.  If
   GIMP-print has ICC (or whatever) color profile support, then users
   will be able to print a profile page, run it through a DTP41 (or
   whatever), and generate a profile specific to their combination of
   ink, paper, etc.  Presumably, no manual adjustment should be needed
   (at least not for the purpose of profiling - other kinds of changes
   in the source image can be done before the image ever gets to the
   driver...)

What I had in mind was a bit different.  The concept here is that a
user is using special non-CMYK inks, where the profiling is to ensure
correct tonality and warmth.  But perhaps the "warmth" would simply be
an input setting.  Obviously, this would require Gimp-print to have
profile (not ICC profile in this case, but something else), and the
profile would have had to been done correctly.

   The *issue* is that the example was put forward to show why you
   might need to tie object files to a printer for the purposes of UI.
   Not only is the example bogus, but the whole object file issue is
   the reason why Windows printer drivers can't be networked easily
   between platforms.  How would you like to maintain a list of object
   files for N operating systems, M architectures, and L GUI
   toolkits?!?  It won't scale (and doesn't scale on Windows), and
   will be a nightmare to support.

I missed this part of it.  This I agree with; platform-dependent
binary modules are asking for trouble.  However, that doesn't mean
that the only alternative is static descriptions (much less PPD
files); there are other ways around the problem, such as a
client-server architecture, or Java components.

   In short, I believe we should concentrate on providing support for
   the various data types needed by drivers, and to standardize the
   naming of specific options that might need special handling (such
   as a preview image, etc.)  That will allow for platform-independent
   printing and full support of extended printer options.
   Applications or toolkits that are aware of the "special purpose"
   options that we define will be able to provide an enhanced UI,
   while the "worst case" scenario will have a dumbed-down UI with
   predefined choices that the driver developer (or user) has defined.

We may not be that far apart on this after all; that's more or less
what libgimpprintui does.  What libgimpprintui (and libgimpprint) do
in addition is that rather than use a completely flat namespace for
options, they attach a few other tags (such as the class -- output
control, printer feature -- and level -- standard, advanced, more
advanced, etc.) to the option, to give the UI a hint about organizing
the interface.  This could be useful even for genppd.

-- 
Robert Krawitz                                     <rlk 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 uunet uu net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

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