[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 06:10 +0100 schrieb Kai-Uwe Behrmann:
> Am 14.11.09, 17:11 +1100 schrieb Graeme Gill:
>> Chris Murphy wrote:
>>> filter, and also ColorSync) to not convert the target. Presently on Mac OS the
>>> application of choice is Photoshop, with which we are presently having problems because
>>> the No Color Management based PDF spool file has different profiles set for the profile
>>> target object, and OutputIntent, causing ColorSync to color manage. It autoconfigures
>>> newer print driver settings correctly, but the PDF spool file is malformed, so we get a
>>> converted profile target.
>>
>> Yes, basically this is a really dumb API for turning color management off.
>> The right way to do it is to have a flag that turns color management off,
>> rather than relying on the software to figure out what profile is being
>> used for the end device, and labeling the file as already being in that
>> space. It's easy to demonstrate that this is sematically incorrect -
>> if you were to spool the file and then replay it after the device
>> profile has been changed, it will print incorrectly.
>
> I am not familiar with such a flag. So I may ask, where does this apply to
> which API? The print API while sending data which gets converted to PDF?
> The CMS, which is responsible to do the colour conversion or has in that
> special case to omit a conversion? ... or the spooling system? ...
>
>
> Following  Chris' explanation, a print system "correctly" supporting
> Device(RGB/CMYK/GRAY/N) in PDF/X-3 will have a path to pass all colour
> management conversions unaltered. Could this become a simple means of

--^^^^^^^^^^^^^^^^^^^^^^ should read as colour "values", sorry.

> implementing Mike Sweets less is more scheme of hiding CM controls?
> It would mean generate according targets and send them through CPD as file
> to the selected printer.
>
>
> Still unresolved is the per paper ICC profile selection. To solve that
> point CPD would be in need to add custom entries to non traceable
> variables. These are mainly media and ink types which a driver has
> currently no way to know of in a programatic manner.
>
>
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management
> www.behrmann.name + www.oyranos.org