[Printing-summit] [OpenICC] Device Settings in ICC

Robert L Krawitz rlk at alum.mit.edu
Mon Sep 4 15:52:56 PDT 2006

   Date: Tue, 05 Sep 2006 00:13:45 +0200
   From: Gerhard Fuernkranz <nospam456 at gmx.de>

   Robert L Krawitz wrote:
   > 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!)

   Why the highest allowable driver version? For instance, when I
   create now a profile for 4.2.7, how can I know in advance, which
   future driver versions will exist at all, and which future version
   will be the highest color-compatible "allowable" one? IMO it must
   work vice versa, i.e.  rather the driver version used to create the
   profile should be recorded, and future driver versions should know
   about older driver versions, and they should know, whether they are
   still "color-compatible" to particular earlier driver versions or
   not (note, even if the native color rendering has changed in a new
   driver version, the new driver still may support legacy rendering
   modes for backwards compatibility).  Only the (new) driver can know
   whether it can still cooperate with the (old) profile, or whether
   it needs to refuse the profile.

You're correct.

   I also tend not to use a fixed structure as suggested, but rather a
   tagged format, which allows variable length parameters, and which
   can be easily extended in the future with new tags if
   needed. Personally, I'd even prefer an ASCII format for the whole
   contents of the "DevS" tag, for instance simple identifier=value\n
   pairs, or XML, etc. For maintaining the tag in profiles there could
   be a simple utility program which dumps the DevS tag to a file, or
   vice versa, reads a file and adds its contents as DevS tag to a
   profile (or replaces an existing tag).  This would give the
   opportunity to maintain the DevS tag, even if the profiler is not
   aware of this tag (for instance, if an arbitrary commercial
   profiler is used). And if the contents of the tag is ASCII text, a
   file with the DevS contents can be easily edited with a text

We can handle any format, although in general I'd prefer that it be
treated as opaque (some of the Gutenprint options, such as curves, are
structurally quite complex).

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

More information about the Printing-summit mailing list