Re: Printer driver UI [proposal]
- From: Robert L Krawitz <rlk alum mit edu>
- To: mike easysw com
- Cc: goffioul imec be, kpfeifle danka de, kde-print kde org, till kamppeter gmx net, foomatic-devel linuxprinting org, gimp-print-devel lists sourceforge net, gnome-print-list gnome org
- Subject: Re: Printer driver UI [proposal]
- Date: Mon Mar 17 12:17:00 2003
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
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."
] [Thread Prev