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

[Gerhard Fuernkranz]

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.

I'm also wondering whether such a compatibility information needs to be
recorded in the fixed part of the data structure? As only the driver can
interpret this info and can know, whether it can still cooperate with
the (old) profile, or not, I'd tend to record it in the driver-specific
blob, together with the other driver settings (which may be version
specific as well).

In fact I'm even wondering, which information in the suggested "DevS"
tag needs to be interpreted by an instance != driver? Is there really a
need for all the fixed fields, or would probably even a tuple
[driverID,driverSpecificSettingsBlob] be sufficient?

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

Regards,
Gerhard