Just to clarify, Chris - I was talking about during PDF GENERATION.  You are talking about printing...<div><br></div><div>Leonard<br><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 8:01 PM, Chris Murphy <span dir="ltr">&lt;<a href="mailto:lists@colorremedies.com">lists@colorremedies.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div class="im"><div>On Feb 7, 2011, at 5:51 PM, Leonard Rosenthol wrote:</div></div>
<div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div bgcolor="#ffffff" text="#000000">
    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...)<br>
    <br></div></blockquote><div><br></div><div>Apple/Quartz/ColorSync doesn&#39;t change anything UNLESS you explicitly ask it to.  </div></div></blockquote><div><br></div></div><div>I suppose that&#39;s a matter of perspective. If it&#39;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&#39;s /DeviceCMYK to a CMYK device (or PostScript file) and in that case it is pass through.</div>
<div><br></div><div>In the case of professional photo printing with RGB output devices like inkjet printers, we&#39;re constantly getting hosed by Apple&#39;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&#39;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.</div>
<div><br></div><div>From another perspective, Core Graphics is only doing what it&#39;s told to do in the PDF. So arguably the PDF is written incorrectly, in that it&#39;s going to ask for a conversion that we don&#39;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&#39;s written out by Quartz PDFContext contain object source profiles that match the OutputIntent.</div>
<div><br></div><font color="#888888"><div><br></div><div>Chris Murphy</div></font></div></div></blockquote></div><br></div>