[Openicc] - CM Framework - Printer Driver -
edmundronald at gmail.com
Tue Jun 21 14:45:54 PDT 2011
I don't think we all have a robust infrastructure yet. What we do have is a
debate about container data formats for settings. We already had one of
these debates, with XML and JSON :)
On Tue, Jun 21, 2011 at 11:17 PM, Jan-Peter Homann <
homann at colormanagement.de> wrote:
> Hello Edmund and all,
> The driver metadata should be embedded in the ICC-profile at the moment of
> the profile creation. If we than generate a MDF5 Hash, we can be shure, that
> nothing can be changed secretly after.
> So far as I know embedding and extracting of dictType Metadata is part of
> littleCMS and also handled through Oyranos and g-c-m / colord and CPD.
> So we have already a quite robust infrastructure to work with printer a
> ICC-profile containing driver settings in a standardized way compliant to
> the ICC specs.
> We are all going big step forward.
> Am 21.06.11 22:52, schrieb edmund ronald:
> Till, I disagree with this. At that point we are tied to a complex
> externally managed data format which is similar to the Tiff format. It is a
> pain to modify a tag in the native (binary) version of an ICC profile,
> because you need to compute and write back the new tag offsets for all the
> fields behind your own, if I remember correctly See page 14 of
> The other problem is that the legal issues of circulating modified copies
> of an ICC profile is harder than the issue of just circulating the profile -
> imagine that I carefully make a copyrighted but creative commons licensed
> profile for eg. Epson Premium Luster on the 4900 after determining inking.
> And now President Obama, while playing with a Linux distribution in his
> spare time :) changes the inking condtions because he thinks prints need to
> be denser, and passes the modified profile around, without modifying the
> copyright tag (which it is usually forbidden to modify). Now a lot of people
> may start writing me to say that my profile prints very densely on some
> environments. I may get angry that my work has developed a behavior which I
> did not put into it. The simplest way of preventing such issues is to accept
> the idea that profiles are not intended to be changed *EVER* after being
> On Tue, Jun 21, 2011 at 5:35 PM, Till Kamppeter <till.kamppeter at gmail.com>wrote:
>> On 06/21/2011 05:30 PM, Jan-Peter Homann wrote:
>>> Hello Richard,
>>> I would recommend to embed the driver informations into CUPS raster file
>>> as IPP attribute. like Till described it for CPD.
>>> we may should also consider to register at the ICC a Metdata Type for
>>> Gutenprint driver settings.
>>> I will ask at the ICC about the necessary steps, that we are prepared to
>>> do in near future.
>> You should ask for a Metadata type for general driver settings. This
>> could simply be an ASCII string with undetermined length. It then can
>> contain the settings as "opt1=choice1 opt2=choice2 ...". Note that not only
>> Gutenprint but also other printer drivers can benefit from this.
>> openicc mailing list
>> openicc at lists.freedesktop.org
> ---------- Please note the new adress --------------
> homann colormanagement --------- fon +49 30 611 075 18
> Jan-Peter Homann ------------ mobile +49 171 54 70 358
> Cotheniusstr. 3 -------- http://www.colormanagement.de
> 10407 Berlin -------- mailto:homann at colormanagement.de <homann at colormanagement.de>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc