[Openicc] - CM Framework - Printer Driver -

[edmund ronald]

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

Edmund

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.
> Jan-Peter
>
> 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
>
>   http://www.color.org/ICC1v42_2006-05.pdf
>
>
>  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
> written.
>
> Edmund
>
>
>
> 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.
>>
>>   Till
>>
>>
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>
>
>
>
> --
> ----------  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...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110621/5970cfdc/attachment-0001.htm>