<br><br><div class="gmail_quote">On Sun, May 13, 2012 at 12:22 PM, Gerhard Fuernkranz <span dir="ltr"><<a href="mailto:nospam456@gmx.de" target="_blank">nospam456@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 12.05.2012 01:32, schrieb edmund ronald:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why can't every future version of ghostscript for Linux systems have our CM-off switch?<br>
</blockquote>
<br></div>
Well, even older ghostscript versions (e.g. 7.x) already did provide this opportunity (via regular Postscript and PDF mechanisms, i.e. either by turning the UseCIEColor flag off, and/or by setting the DefaultXXX color space resources to /DeviceXXX (i.e. to identity), which disables the remapping of /DeviceXXX colors). Therefore it is rather a matter of the ...toraster print filters to invoke ghostscript correspondingly (granted that they make use of ghostscript at all).<br>
<br>
[ Btw, IIRC, the built-in default value of ghostscript's DefaultXXX color space resources did change in the past, so it may be a good idea anyway if the ...toraster filters would not rely on ghostscript's built-in defaults, but always set up the desired DefaultXXX resources explicitly in oder to get consistent results across different versions of gs (and maybe some other parameters too, whose built-in defaults may change with version, like transfer functions, black generation & UCR functions). ]<br>
<br>
Additionally to "CM-off" it may also be necessary to turn off linearization curves in order to print linearization test charts. As far as I know, linearization curves are in the current print pipeline not applied by ghostscript via transfer functions, but directly applied in the Gutenprint driver. So turning them off is a matter of passing corresponding parameters to the driver.<br>
<br></blockquote><div>We would assume linearisation to be an issue for Gutenprint to deal with. </div><div>And in fact it would be part of the ink-preset XML as this is typically someting established by a domain expert rather than a programmer. </div>
<div>Personally, for output via Gutenprint, I would expect black generation and GCR/UCR to become profile-driven in a not too far future, as Gutenprint has CMYK ability, there is an excellent open-source profiling system available (Argyll), so I see little reason for anything like that to stay hardcoded in the longterm.</div>
<div><br></div><div>Edmund</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best Regards,<br>
Gerhard<div class="HOEnZb"><div class="h5"><br><br></div></div></blockquote></div>