[Openicc] Assigning icc profiles to driver settings

[edmund ronald]

Kai-Uwe,


If I may be more explicit, you cannot get a print out of an inkjet
driver like Gutenprint without its knowing about ink curves etc.- and
the idea is to move this printing data into a place where it is
visible to all users.

I see no reason to make this in any way dependent on the ICC, and
ICC-sanctioned formats apart from the fact that one "setting" may be
an ICC profile and other CMS stuff. In most cases the printer driver
itself will never and should never see the actual profile.

Edmund


On Tue, Jan 18, 2011 at 7:04 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Hello edmund,
>
> I can not share your thoughts completly. Maybe my poor english helps me not
> enough to understand you. I was very early engaged in the development of the
> meta tag and my concerns where discussed and adressed.
> I have seen input from others too.
> My own ICC tag proposal for device settings embeding and the early
> implementetation in Oyranos show that it is not a large company behind
> closed doors standard. At least not only in that pure combination.
>
>
> Btw. I work as a consultant and free lancer with up to now, no affiliation
> to print solution providers.
>
> hope this helps,
> Kai-Uwe Behrmann
> --
> developing for colour management www.behrmann.name + www.oyranos.org
>
>
> Am 18.01.11, 17:39 +0100 schrieb edmund ronald:
>>
>> Jan Peter,
>>
>> This a problem which directly concerns all who deal with the print
>> process. Your position on ICC-related issues has been that there
>> should not be a direct public engagement of the ICC with outside
>> developers ; in that context -even as an ICC member - I would say that
>> it is counterproductive to use an ICC-standardised format for the
>> various settings values related to setting up a printer.
>>
>> Decide whether you want to engage in a public debate before
>> standardisation, with all parties on an equal footing or whether you
>> want a private club to run things - but if it is a private club, don't
>> expect us to follow.
>>
>> Edmund
>