On Jan 17, 2011, at 8:14 AM, Leonard Rosenthol wrote: On Mon, Jan 17, 2011 at 9:56 AM, Robert Krawitz <rlk alum mit edu> wrote: Last time I looked at the documentation, which is another Apple weakness, is that it's a color-space bias, not a language bias. So it's actually /DeviceRGB specifically that is disallowed. /DeviceCMYK is allowed. And it just so happens most PostScript/PCL devices default to CMYK, hence /DeviceCMYK is pass-through, and raster-based devices default to RGB, hence /DeviceRGB is called into question, and becomes ICCBased. Where this actually occurs is the Quartz PDFContext, which is what is actually writing out the PDF print spool file. It's the one that refuses to write out /DeviceRGB even if an application asks for it at print time. Downstream, cgpdftoraster simply honors the fact there is a source-destination mismatch in the PDF print spool file, and color manages it, as it was written. So this behavior bites us because it eliminates the one and only reliable means in PDF of saying "this data is prematched, is device-dependent, do nothing." And that lead Apple to create a way to replace that off switch functionality with something else. Which they achieved with the null transform. But their SPI for doing this allows Quartz PDFContext to write out PDF's that contain different source and OutputIntent color spaces, ensuring that cgpdftoraster will do conversions, even though the application called this SPI for the explicit purpose of turning color management off. One bad idea lead to another. Chris Murphy |