[Openicc] - CM Framework - Printer Driver -

[edmund ronald]

On Fri, Jun 24, 2011 at 8:01 PM, Till Kamppeter <till.kamppeter at gmail.com>wrote:

> I do not want to make the option settings embedded in an ICC profile
> modifiable, I only want that the format for them is a general format which
> can be used with all CUPS drivers and not only Gutenprint.
>

Obviously, Gutenprint settings will be meaningless to another driver.
Gutenprint settings -now already being used in an experimental prototype-
are in an XML container, and of course any other driver could do the same as
being a nested container is what XML does best. Other metadata, eg paper
size selections and profiles could also be nested in this container.



>
> If a job with embedded profile reaches the CPD or if a user selects a
> profile within the CPD, and afterwards the user changes individual options
> and the changes conflict with the CPD, the CPD should tell the user that his
> setting change will deactivate the ICC profile and whether he really want to
> do it. Or the option setting should be grayed out and only changeable if the
> user deselects the profile at first. So changing embedded option setting
> info in ICC profiles is never needed during the print process.
>
> This is complicated. Actually, ink settings allow to derive a profile, but
then in usage the ink settings and the profile may get misused: For instance
a 2880 dpi setting may use the same profile in a pinch as the 720 dpi
setting but need some density tuning; or a user who gets some new media miay
decide to use ink settings that are available and redo a profile; or the
user may decide to keep the profile but do some manual tuning, eg add some
reds. I'd say that profile and ink settings will usually be made available
together to the user, but she may have good reasons to want to access them
independently - overrides can be useful but can also be suicidal.

Edmund


>   Till
>
>
>
> On 06/21/2011 10:52 PM, edmund ronald wrote:
>
>> 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<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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110625/1ee73740/attachment.html>