Re: Printer driver UI [proposal]

[Michael Sweet <mike easysw com>]

Robert L Krawitz wrote:
>    Date: Thu, 13 Mar 2003 23:02:20 -0500
>    From: Mike Sweet <mike easysw com>
>
>    Robert L Krawitz wrote:
>    >    Date: Thu, 13 Mar 2003 12:34:07 -0500
>    >    From: Michael Sweet <mike easysw com>
>    > 
>    >    However, to comment specifically on your example - it would be
>    >    impossible to accurately preview the results of changing a color
>    >    channel curve without having a colorimetric (e.g. ICC) profile for
>    >    the output device, at which point such curves are probably not
>    >    needed anyways...
>    > 
>    > As an example of how I think something like this could be useful:
>    > consider a photographer using a hextone inkset, which is usually
>    > black, warm and cool versions of midtone grays, and a light gray.  She
>    > would profile her combination of paper, ink, printer, and resolution,
>    > and then use a slider to control the degree of warmth of the output.
>
>    However, with this example there is no way to generate an accurate
>    preview image without knowing the relationship (i.e. profile) between
>    the inks, media, and screen.
>
> Right, so in addition to the profiling for the inks, media, and such,
> there's also a screen profile, and the previewing application is color
> managed, with the ability to adjust *its* curves.  But what's the
> issue here?

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...)

If GIMP-print does *not* have profile support, or if the profile
does not match the media and ink, then any preview you generated
would be 100% grade A bullshit, making the preview totally useless.

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.

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.

--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com