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

[Chris Murphy]

OK still that's not entirely true if the application makes system calls that causes Quartz PDFContext to make the PDF. That's the case again with InDesign, Photoshop, and Lightroom and pretty sure Illustrator as well. Those PDF print spool files are not directly produced by the apps, Quartz does it, and if you don't tag your data (you think you're asking for /DeviceRGB), Quartz PDFContext writes those objects out as ICCBased sRGB on 10.6.x and Generic RGB on 10.5.x. /DeviceRGB is persona non grata on OS X.


Chris

On Feb 7, 2011, at 8:38 PM, Leonard Rosenthol wrote:

> Just to clarify, Chris - I was talking about during PDF GENERATION.  You are talking about printing...
> 
> Leonard
> 
> On Mon, Feb 7, 2011 at 8:01 PM, Chris Murphy <lists at colorremedies.com> wrote:
> On Feb 7, 2011, at 5:51 PM, Leonard Rosenthol wrote:
> 
>> 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...)
>> 
>> 
>> Apple/Quartz/ColorSync doesn't change anything UNLESS you explicitly ask it to.  
> 
> I suppose that's a matter of perspective. If it's a high level, then this is not true. Apple/Quartz/ColorSync is an opt-out color management system, not opt-in. It will do conversions unless you explicitly tell it not to, with one exception and that's /DeviceCMYK to a CMYK device (or PostScript file) and in that case it is pass through.
> 
> In the case of professional photo printing with RGB output devices like inkjet printers, we're constantly getting hosed by Apple's system because Adobe products keep having to ask Quartz to do NO MORE CONVERSIONS and yet routinely Quartz persists in converting in cases where we don't want it to. And a big part of why that happens is because the application correctly sets the OutputIntent, but the SPI provided by Apple does not guarantee that all objects in the PDF have ICCBased spaces that match the OutputIntent. Because of this, Quartz *WILL* do conversions on those objects when there is a mismatch between source and destination, even though the application that asked for that PDF to be written out with an SPI calling for NO MORE CONVERSIONS.
> 
> From another perspective, Core Graphics is only doing what it's told to do in the PDF. So arguably the PDF is written incorrectly, in that it's going to ask for a conversion that we don't want to have happen. And my argument has been that if Apple is going to depend on null transforms as the only means of disabling ColorSync in the print pipeline, then they need to provide a robust API that ensures PDF's written out by Quartz PDFContext contain object source profiles that match the OutputIntent.
> 
> 
> Chris Murphy
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110208/c1653428/attachment.htm>