[OpenICC] Device Settings in ICC

[Kai-Uwe Behrmann]

The letter is shortened a bit. Answeres are inside.

Am 04.09.06, 16:28 -0400 schrieb Robert L Krawitz:

> Drivers would need to provide a mechanism to allow querying this
> information.  This, of course, would require the profiler to interact
> directly with the driver.  Gutenprint is already designed for this
> model of interaction; all that would need to be added is a way to
> determine whether a particular setting influences color or not.  I'd
> like a bit more of Kai-Uwe's take on what he sees the driver doing
> here.

The driver reacts mostly passive. It should provide some functions like:
const char* getDriverName                     (size_t*      size)
const char* getDriverVersion                  (size_t*      size)

void*       getDriverColorCalibrationSettings (size_t*      blob_size,
                                               const char** signature,
                                               size_t*      sig_size )

or designed with a custom memory allocator as I prefer in Oyranos to more 
easily free the memory later.

The above functions are needed to feed the tag.

The below one does feed the driver from the tag once it is extracted from 
the profile. I dont think the driver should handle the extraction from the 
profile itself, as there might be more drivers without deeper colour 
management.

int setDriverColorCalibrationSettings         (void*        blob,
                                               size_t       blob_size,
                                               const char*  signature,
                                               size_t       sig_size )
The return value here can indicate errors.

For the possible Oyranos counterpart see:
http://www.oyranos.org/wiki/index.php?title=Device_Settings#Oyranos_API_suggestion

About the ColorCalibrationSettings: They must be selected carefully be the 
driver author. 

I am not shure if this can allways been done with confidence. Therefore I 
suggest to use very static settings for authors which are unshure how to 
handle or what kind of settings to select. A static 
ColorCalibrationSettings mode can be communicated easily in the signature 
string. The settings data blob would be obsolete in this case simplifying 
the whole process. Just add one or more ColorCalibration modes to the 
driver and give them names, which fit into the 12-bit signature string.

> I'm discussing printing here because that's what I care about and it's
> also likely to be the most complex.  In addition, most of the existing
> ways of interacting with printer drivers in Linux/UNIX block any
> direct interaction between the driver and the application (which in
> this case would be the profiler).  Applications basically specify
> options based on static PPD files; there's no back channel, which is
> what this proposal really needs.

Hmm I dont understand, or miss something. The PPD is shown to the user in 
a UI to select options. Am I correct in the assumption the PPD can be a 
displayed in a server side UI (CUPS www-browser dialog) or a user side UI 
(Scribus print dialog).

If the selected profile is laying on the users end, the application 
integrated printing UI should take the fixed colour options into account 
and gray them out. The only problem I see here, merging PPD's with 
priority is possibly not standard.

If the profile is mentioned in the server side PPD and laying on the 
server, the PPD file can be modified during installation of both PPD file 
and ICC profile to not show the fixed optiones for the calibration mode. 
The device settings tag would then only be meaningful during installation. 
One step further, I can think of the corrected PPD file (complete PPD but 
with fixed color options) been integrated in the tag. During installation 
the PPD file would be extracted and separately from the profile installed.

What I could not find is how can the client knows from a given PPD which 
driver/version is used? Is there a standard way to know?

> Another approach here would be to allow the printer driver to specify
> part of the printing dialog.  If the driver owned all parts of the UI
> that pertain to color, this would considerably simplify the high level
> API; all that would be required would be a way for the driver to
> return the required settings (as a blob) to the profiler to stick into
> the profile.  The driver would need access to the profile in order to
> read the blob.  This isn't hard with a locally-attached printer, but
> in a networked environment this whole thing becomes very difficult.
> It requires either some very fancy footwork for the server-side driver
> to specify the UI, or alternatively for the matching driver to be
> installed client-side to provide the UI.
> 
> A possible compromise here would be for the server to supply a dynamic
> PPD file to the client.  We would need to figure out how to tell the
> server what profile is desired so that the server could ask the driver
> to create an appropriate PPD file.
> 
> I'd still like to see a more flexible approach for the driver even if
> we can't solve all of the network issues right away.
 
> -- 
> 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

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name