[OpenICC] Device Settings in ICC

[Robert L Krawitz]

(Cross-posting to printing-summit at freestandards.org)

   Date: Mon, 4 Sep 2006 18:18:39 +0200 (CEST)
   From: Kai-Uwe Behrmann <ku.b at gmx.de>

   as discussed some time ago and prepared on the ColourWiki pages I
   finally created a specification on how I imagine a ICC profile
   could include device driver specific settings.

   Goal is to allow easy checking of profile to device/driver matching
   and correct configuring of the device driver. The best matching
   profile can be filtered for a given device/driver combo. Thus the
   installation of a profile, including the new tag, becomes a simple
   file copy. Everything else is configured automatic by the tag.

   Technically it is a hybrid approach of well known and interpreted
   settings and a thumb part to keep the structure flexible.

   http://www.oyranos.org/wiki/index.php?title=Device_Settings_in_ICC_0.1

   I would, as allways, be interessted in opinions and suggestions.

   Target is to create an API in Oyranos to support the tag (writing,
   manipulation, searching), and to encourage device driver authors to
   provide the necessary counterpart API's (Gutenprint, Sane, dcraw
   ...).  Possibly there is room to standardize corresponding driver
   API's for uniformity?  Finally applications can adopt the system.

If I understand this correctly, the "driver-specific configuration
data" is intended to be a blob of driver-specific data specifying the
settings that this profile corresponds to.  In Gutenprint terms, it
might specify paper type, color correction method, resolution,
density, and so forth.

A printing (for example) dialog would then lock the settings for these
particular adjustments if the user specifies a profile containing this
tag, and allow the user to modify other settings that the driver
doesn't specify to be locked.  This is why I've copied it to
printing-summit -- there's a discussion taking place right now about
printing dialogs.

One complexity is that most printing dialogs are currently controlled
by PPD files; it's hard to see how this would be integrated in any
general way with PPD files.  The alternative would be to break from
PPD files and move toward a more programmatic interface, which I would
personally prefer but which will make life more complicated for
applications that provide their own PPD-based printing dialogs.

I'd suggest adding a field specifying the highest allowable driver
version also.  For example, a profile made against Gimp-Print 4.2.7
should not be used with Gutenprint 5.0.0 (of course, these can be
disambiguated by name, but that's only because we renamed the package
-- we certainly won't be making a habit of that!)

As a minor point, I'd suggest including a field specifying the length
of the driver-specific configuration data.  I understand that the
total length of the tag implies the length of the driver-specific
configuration data, but storing the field length is more clear.  It
also allows multiple records within the same tag.  I'm not quite sure
exactly what use that would be, but I think it would be desirable (and
cost only 4 bytes) to anticipate the future.

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