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

[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.

> If a PDF file contains DeviceRGB or DeviceCMYK objects, ColorSync will change such PDF objects automatically and without warning to ICCbased mainly by embedding e.g. the ColorSync standard profiles in every PDF object (images, vector graphics, text...)

It's true for the most part the objects are ICCBased. There are some legacy behaviors that still cause /DeviceRGB, which is then later assumed to be sRGB now on 10.6. /DeviceCMYK is always allowed as a pass through and in the case of an OutputIntent, that means the object is not converted. But really few devices product CMYK in the PDF print spool file so it's not really a big issue.


> Especially in Graphic Arts workflow, which use e.g. PDF/X-1a workflow, where all PDF content is e.g. DeviceCMYK, such automatic conversion without warning can make a PDF file unusable by just importing it into a ColorSync environment and save it again.

That should not happen. Any application that asks for Quartz PDFContext to produce PDF print spool files containing CMYK objects that are /DeviceCMYK, remain /DeviceCMYK.


> Because of this, graphic art users under Mac OSX avoid the Mac OSX function "Save as PDF" from the Apple printing dialogue.

That is because the system knows a desktop inkjet printer is RGB-based, and reports this to the OS. The OS is then required to normalize to an RGB space when doing such a handoff to the system. Well, at least they used to be required, I don't know that they are still required. But they still do it. So it's actually not the system that's converting everything to RGB, it's actually the application. That's why Save as PDF is avoided.

> 
> 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.

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.


> If we use the ColorSync approach of tagging every PDF object only for the print pipeline, it may can work quite well. But using the same approach also for PDF Export can lead to results, the user don´t wants.

That's up to the application producing the PDF Export. That very well will be a different sort of PDF than a PDF print spool file that is not meant for outside consumption.


> 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.

We definitely don't need, by default, a bunch of PDFs floating around that claim their intended output is a printing press, or some fictional display that doesn't exist. That's not really the intended output. Maybe there isn't an intended output yet, so the OutputIntent is probably not even necessary the vast majority of the time for a PDF Export.

> If we can manage such workflows both for printing and PDF-Export, we can move to more complex workflow dealing with ICC-profiles both on PDF object level and output intent.

Yeah but they're not the same contexts at all so we really shouldn't be forcing them to be the same thing. An exported PDF is probably 95% more likely to go to an ebook reader than a press.


Chris Muprhy