[Openicc] Is CUPS the right place... (CUPS and ColorSync)

[Kai-Uwe Behrmann]

Am 07.02.11, 16:00 -0700 schrieb Chris Murphy:
> On Feb 7, 2011, at 3:31 PM, Jan-Peter Homann wrote:
>> But we still should consider, that the described workflow has some critical points.
>> If all parts of the PDF should be converted to the profile of the printer setting by embedding this profile as Output Intent into the PDF file, it is mandatory, that every PDF-object is a ICCbasedRGB or ICCbasedCMYK object.
>
> It's not required they be ICCBased. Leonard's flow chart describes the alternatives if the objects are not ICCBased. The user can specify working spaces (defaults) in e.g. Gnome Color Manager, and then colord makes this available to GhostScript, which would then use an assumed profile workflow to convert the objects from source to OutputIntent.

But again, that is very fuzzy and unrelyable - developers call it a hack.

>> The main problem here is the role of the Output Intent
>>
>> In "classic" Graphic Arts workflows, the Output Intent is the same as the document color space.
>> E.g. SWOP or ISOcoatedv2 is the intended output. If such a PDF file should be printed on a inkjet, the user wants to simulate SWOP or ISOcoatedv2 on his inkjet. This is solved by using the output intent as source profile and printer setting profile as target profile during printing. (daily business in proof printers).
>
> The document color space on a home computer is not the same as it is for 
> Graphic Arts. I think we'd need to re-evaluate the idea that people have 
> printing presses in their living rooms.

I highly agree. The implicite assumption to repurpose the PDF OutputIntent 
cuts off a lot of useful cases for a much broader audience. Proofing and 
repurposing can be done explicitly.

> If people want to implement a graphic arts workflow on Linux, I think it 
> is the realm of some other application to do soft proofing and hard 
> proofing, with the help of Ghostscript. The system doesn't need to be 
> designed to do this because it's a workflow for a tiny market. All the 
> system should do is be helpful and enable such a workflow to be possible 
> for other applications, rather than hinder it.

Agreed. Thats transparent and more flexible.

>> Because of such experiences, I suggest for the first steps with PDF and colormanagement a "Flat color approach" where the output Intent represents the document color space.
>
> This is certainly a worse option for PDF export.
>
> 1. It requires that the application producing the PDF normalize to a single color mode. Because you can't have /DeviceRGB and /DeviceCMYK in the same PDF with OutputIntent. (Most basic applications would write out such a PDF as /DeviceRGB only.)
>
> 2. Such a PDF that is either only /DeviceRGB or /DeviceCMYK will certainly not preview correctly on any workstation since the OutputIntent is routinely ignored by applications that have no idea what an OutputIntent is.
>
> You're much better off properly building PDF/X-4 documents, honoring the original color space of the objects, until the actual output condition is determined. Objects need to be properly tagged, not set in device space unless the application producing those objects really understands what it's doing, and needs to preserve device channel integrity for some reason.

Agreed. For most applications the editing space will be simply sRGB. So 
its sane to set sRGB as the ICCbasedRGB space, as was pointed by Chris.

Applications, which do not care about colour management, will naturally 
adhere to sRGB as their paradigm. This is already a single flat colour 
space for blending and I guess what Jan-Peter primarily wanted.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org