On Mon, Jan 17, 2011 at 7:41 PM, Graeme Gill <span dir="ltr">&lt;<a href="mailto:graeme@argyllcms.com">graeme@argyllcms.com</a>&gt;</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">Alastair M. Robinson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In that case the rendering pipeline needs to detect when source and<br>
destination profiles are identical, and bypass the transform completely.<br>
Allowing the CM engine to transform the data between two CMYK profiles<br>
would be disastrous for profiling - even if they&#39;re identical - because<br>
it would mess up the GCR.<br>
</blockquote>
<br></div>
But this is exactly the root cause of the Apple profiling problems !<br>
<br>
They treat matching profiles as a null transform, and as a side<br>
effect use it to pass unmodified numbers to the device.<br>
<br></blockquote><div><br></div><div>the other issue is that you&#39;d have to potentially do this test on an object by object basis, since each object in PDF can be profiled separately.  There is also the possibility for profiles as part of the transparency blending spaces, etc.</div>
<div><br></div><div>This complexity is significantly(!!) reduced with PDF/X and PDF/A!  If there were some way to ensure that all PDFs that came through CUPS were PDF/X-4 compliant, you&#39;d be able to better optimize the entire process.  But I don&#39;t think you have that level of control :(.</div>
<div><br></div><div> Leonard</div></div>