<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-15" http-equiv="Content-Type"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <tt>Am 10.02.2011 21:03, schrieb Hal V. Engel:</tt> <blockquote cite="mid:201102101203.46530.hvengel@gmail.com" type="cite"> <meta name="qrichtext" content="1"> <style type="text/css"> p, li { white-space: pre-wrap; }</style> <tt> </tt> <tt>GhostScript has provisions for device links</tt> </blockquote> <tt> My understanding is that -sDeviceLinkProfile=... is intended for proofing, i.e. the given device link is applied after any other color transformation in order to carry out the the proofing transformation (e.g. from an emulated printing press color space to an inkjet printer color space). The handbook also says that it's not fully supported yet, whatever this may mean. </tt> <blockquote cite="mid:201102101203.46530.hvengel@gmail.com" type="cite"> <tt>and I think it might be possible to use it's command line args to force null transforms since it allows for substitutions on the command line for what profiles will be used with DeviceXXX objects. </tt> <tt> </tt> <tt>Also GhostScript appears to use a set of default profiles for DeviceXXX objects which can be over ridden by command line args. So it will be nessary to force these settings for things like profiling charts.</tt> </blockquote> <tt> You need to override the the DefaultXXX ColorSpace resources anyway, according to your needs (not just when printing profiling charts). It seems that the gs 9.0 built-in DefaultRGB and DefaultCMYK are sRGB and SWOP. These are certainly reasonable defaults, but still they don't fit any use case. For instance, when printing a PDF documented that was intended for a ISOcoated, and which uses DeviceCMYK colors, then you need of course DefaultCMYK set to ISOcoated and not to SWOP (i.e. DeviceCMYK should be interpreted as ISOcoated then). I'm not sure either whether gs when used as PDF "reader" derives DefaultXXX from the output intents (if present in the document). I rather guess it does not, so it's likeley still necessary to set </tt><tt>DefaultXXX explicitly. Quote from the PDF 1.7 spec:</tt><tt> </tt> <blockquote><tt>"The ICC profile information in an output intent dictionary supplements rather than replaces that in an ICCBased or default colour space (see 8.6.5.5, “ICCBased Colour Spaces,” and 8.6.5.6, “Default Colour Spaces”). [...] The data in an output intent dictionary shall be provided for informational purposes only, and conforming readers are free to disregard it" </tt></blockquote> <tt>When printing profiling charts, the DefaultRGB(CMYK/Gray) resource (depending on the device's process color model) should be set to /DeviceRGB(CMYK/Gray), in order to avoid remapping of DeviceRGB(CMYK/Gray) to CIE-based default color spaces. A PDF document to be printed also has the opportunity to override the DefaultXXX colorspace resources, i.e. the document can either enforce e.g. a particular colorimetric interpretation of DeviceXXX colors, or prevent a special interpretation of DeviceXXX colors appearing in the document (e.g. for profiling charts). Of course this works only, if the document explicitly makes use of this opportunity. I'm not sure whether -dUseCIEColor=true/false is honored by gs when rendering PDF documents. For PostScript it should be honored for compliance with the PLRM and is supposed to turn the remapping of DeviceXXX to DefaultXXX on or off, but the PDF spec does not define a "UseCIEColor" flag at all, and DeviceXXX colors in PDF documents are generally supposed to be remapped to the color space associated with DefaultXXX if the latter is defined in the ColorSpace resource dictionary. Regards, Gerhard </tt> </body> </html>