<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 20, 2013, at 2:02 PM, Gerhard Fuernkranz <<a href="mailto:nospam456@gmx.de">nospam456@gmx.de</a>> wrote:</div><br><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
In particular section 3.3 seems to defeat my intuitive re-targeting
expectations, though :-(<br>
Actually I would expect that re-targeting to another printer does
take the gamut of the other printer into account.<br></div></blockquote><div><br></div><div>PDF/X-1a it would. PDF/X-3 it would not, unless the content is already /DeviceCMYK (i.e. OutputIntent space)</div><div><br></div><div>/ICCBased objects in PDF/X-3 are expected to print differently between OutputIntent and a different actual output device. This is not proofing, and is in that sense a meaningful distinction between retargeting and proofing.</div><div><br></div><div>Section 3.3, Paragraph 1 and 2 of the cited document is highly optimistic if it's considering the embedded OutputIntent profile's tonality, gamut compression, black generation and UCR even remotely discoverable by software other than that which created that profile. So it's a totally closed loop expectation.</div><div><br></div><div>The consequences of prematurely setting the OutputIntent is similar to that of premature binding. In the latter case, the rendering is baked in and there isn't a practical way to unwind it without a totally v4 + PRMG workflow. In the former case, while the original unconverted data is available, there's possibly a rendering expectation already in mind, possibly even physical proofs exist and have been signed off on.</div><div><br></div><div>So it's plausible retargeting means turning the actual press into a proofing device for the Output Intent (i.e two transforms per device independent object); just as it's plausible the wrong OutputIntent is replaced with the correct one, where a single transform is indicated per device independent object, along with new proofs being ordered.</div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
Let's assume I've got a PDF intended for offset printing, and I'm a
dumb user, not knowing anything about output intents, proofing,
etc., and I simply want to print (not proof) this document on my
laser printer on normal office paper (-> which has a rather
limited gamut and cannot reproduce very dark black).<br>
<br>
What was my expectation then? I certainly<br>
<ul>
<li>would not want to get clipped shadows or too strongly clipped
saturated colors (due to the offset print gamut being larger
than my printer's gamut)<br>
<br>
</li>
<li>would not want to get paper color emulation (which at least
absolute colorimetric proofing would do)<br>
<br>
</li>
<li>but I rather would like to get a pleasing reproduction of the
document on _my printer_, which implies that also the gamut must
be remapped according to the needs of my printer</li>
</ul>
An (absolute or relative) colorimetric proof would certainly not
yield the desired results in this case.<br></div></blockquote><div><br></div><div><br></div><div>Is a good example of why the user's expectations need to be established in the print dialog. Do they want it to look good on that printer, or do they want it to simulate the intended printer?</div><div><br></div><div>And of course in this example the offering to simulate the intended printer is possibly very misleading if the local printer can't actually simulate the gamut and/or dynamic range of the OutputIntent. In that case it's really "Closest simulation possible".</div><div><br></div><div><br></div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
How could one, for instance, achieve the desired output?<br>
<ol>
<li>Use perceptual (not colorimetric) rendering intent for the
proofing transformation (but can we call it "proofing" or
"emulation" any more then?)<br></li></ol></div></blockquote><div><br></div>Maybe for v2. But if the OutputIntent were a v4 profile with PRGM, the use of perceptual in effect does gamut expansion back to the PRGM state, then the new output profile does gamut compression from the PRGM state (re-rendering).</div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><ol start="1"><li><br>
</li>
<li>or use the output intent color space only as DefaultCMYK (in
case that there are any DeviceCMYK colors used in the document),
and convert CIE-based colors in the document still directly to
my printer's profile.</li></ol></div></blockquote><br></div><div>The user's expectations are varied. To do the right thing, we'd need to know what they expect.</div><div><br></div><div><br></div><div>Chris Murphy</div></body></html>