On Tue, Jan 18, 2011 at 4:15 AM, Alastair M. Robinson <span dir="ltr">&lt;<a href="mailto:blackfive@fakenhamweb.co.uk">blackfive@fakenhamweb.co.uk</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">On 18/01/11 02:46, Leonard Rosenthol wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
EXCEPT that in the case of PDF processing, there is NO SUCH THING as &quot;no<br>
color management&quot;.  The standard itself goes into detail about how<br>
(ICC-based) color management is used as part of the rendering pipeline.<br>
  For PDF/X (and PDF/A), this is even more significant.<br>
</blockquote>
<br></div>
Hmmmm, that&#39;s rather worrying actually.  Is there no &quot;escape hatch&quot; of any kind to ensure that, for instance, pure-black items don&#39;t get converted to a rich black by being run through a needless conversion? Profiling is far from the only situation where I need a printer to receive the *exact* CMYK value I specified in the application, and not some other CMYK combination that, in theory, amounts to the same thing.<div>
<div></div><div class="h5"><br></div></div></blockquote><div><br></div>Oh, it is certainly possible to produce documents that are explicitly targeted to a specific device - that&#39;s exactly what PDF/X-1a is all about!   And in a pure PDF/X-1a workflow, you&#39;d get what you want - device specific values being sent as such to the device.  Only if the &quot;Output Intent&quot; of the document is different (for some definition of different) than the actual device profile does it need to be converted.   BUT that also assumes a CMYK-only PDF/X-1a file - which isn&#39;t the norm coming out of your authoring applications.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">In addition, in a more modern PDF workflow, you no longer have PDF/X-1a with CMYK+Spot colors and no transparency.  You have various color models and profiles integrated together with the presence of transparency blending - the end result, PDF/X-4 (for printing).  BUT if you could assume that all incoming PDFs complied with PDF/X-4, then you could at least have consistent output since everything is defined for the &quot;output device&quot;.<br>
<div><br></div><div>In addition, you have a two pass workflow - first the rasterization of the PDF AND THEN the printing system - and they don&#39;t talk to each other :(.   You need to (as discussed elsewhere in this thread) get much more information being passed back and forth between the rasterizer and the printer driver/system.</div>
<div><br></div></div><div class="gmail_quote"><div><br></div><div>Leonard </div></div>