Wow.  I missed out on a nice conversation.  <br><br>Just a few comments so that everyone understands how ghostscript deals with color management for PS and PDF.   Every color is defined in terms of an ICC profile.   If the source color is DeviceRGB, DeviceGray or DeviceCMYK it will be assigned an ICC profile, which can be specified on the command line.  If one is not specified then a default one will be used (sRGB, SWOPCMYK, sgray).<br>
<br>If we have a PS color space that is CIEA, CIEABC, CIEDEF(G) an equivalent ICC profile is created so that the same CMM can handle all color management and need not worry about PS color management.  The same occurs for CalGray and CalRGB PDF color spaces.  Shortly, I will be adding the ability to specify device profiles based upon object types.  In this case, different device profiles can be used for images, text, and graphic objects.  This makes it easier to maintain nice black text and nice images.  <br>
<br>Michael<br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 5:11 PM, Graeme Gill <span dir="ltr">&lt;<a href="mailto:graeme@argyllcms.com">graeme@argyllcms.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Chris Murphy wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I admit this is unique on Linux. On Mac OS and Windows, the legacy RGB path is not<br>
PostScript but QuickDraw and GDI, and for Mac OS today now that QuickDraw is deprecated<br>
it is Quartz which can do either RGB or CMYK.<br>
</blockquote>
<br></div>
This may be so for color unsophisticated applications, but anything sophisticated<br>
has used &quot;PostScript Bypass&quot; to inject its own PS into the print job on MSWin and Mac.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
it in the first place. If the application is seriously producing untagged data across<br>
the board including saving out its own document format, then neither that developer nor<br>
its users really care one bit about color. I am not opposed to the idea of building<br>
</blockquote>
<br></div>
This isn&#39;t strictly true. They expect DeviceXXX to be a &quot;reasonable&quot; color space,<br>
not the actual device colorspace. For RGB that means something that compares<br>
to what they see on their display. For CMYK, that means something that compares<br>
to a standard printing press or the Pantone CMYK swatches. Any system that is to be<br>
regarded as having satisfactory color, meets these expectations. (Take that as a<br>
lesson from spending 10 years developing PS RIPS).<br><font color="#888888">
<br>
Graeme Gill.</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
openicc mailing list<br>
<a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br>
</div></div></blockquote></div><br>