<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Feb 7, 2011, at 5:54 PM, Leonard Rosenthol wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Feb 7, 2011 at 7:37 PM, Chris Murphy <span dir="ltr"><<a href="mailto:lists@colorremedies.com">lists@colorremedies.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">It's really kinda beyond a solution other than the pro apps running their own pdftoraster RIP and substituting it instead of Apple's. That is a potential support nightmare of its own to rewrite PPDs from other manufacturers.</div> <div class="im"><br></div></blockquote><div><br></div><div>Which is pretty much what the  Adobe Creative apps (and Acrobat) do.  We bypass Quartz and CUPS as much as possible...</div></div></blockquote><br></div><div>Everything eventually goes through Quartz and CUPS if you're printing to a printer with a Mac OS X print driver, except for PostScript which will avoid the Quartz part, but is still managed through the print pipeline with CUPS.</div><div><br></div><div>Photoshop and Lightroom, every single print job goes through Quartz and CUPS, and is subject to the problems with color that Edmund is referring to avoiding on Linux. And on InDesign, every print job to a non-PostScript printer becomes a PDF print spool file that is subject to secondary screening by Quartz and ColorSync.</div><div><br></div><div>So the day that InDesign has to use Cocoa, and isn't allowed to write out PDFs through QuickDraw, it's going to be in a very precarious situation if Apple doesn't get us an API/SPI that behaves better than kPMApplicationColorMatching does today.</div><div><br></div><div><br></div><div>Chris Murphy</div></body></html>