On 30/08/10 22:47, Jeremias Maerki wrote: > FOP doesn't have such an option. The PDF 1.4 spec says in chapter 6.2.1: > "A gray level is equivalent to an RGB value with all three components > the same." > > And therefore we render gray values in the DeviceGray color space. That > this doesn't work in your case is a bit surprising. But I've heard > something similar just two weeks ago from a company that does photo > books with FOP/Batik. But they had to do strange things like using CMYK > and adding Magenta in addition to the K=1.0 value. They still just get > an approximate black. I guess that's an issue of the printer they use. I > suspect your case may be similar: a printer issue.
It's often an issue with the RIP or preflight tools, rather than the printer/press its self. ICC-aware RIPs will use ICC color space transforms to convert RGB colours in a given space to the output device space - usually a custom CMYK profile for the printer/press. /DeviceGray is a different colour space to /DeviceRGB and the /DeviceGray to CMYK conversion is a different mapping to the RGB one, potentially done with different profiles. Some RIPs just convert /DeviceGray to /DeviceRGB then do the transform from RGB, but that's not necessarily correct, especially in a tagged document where there are mulitiple colour spaces in the same co-ordinate system, like sRGB and AdobeRGB. A proper configuration will use a greyscale profile that matches the RGB profile. That's not very common, though, and really only works out where the assumed greyscale curve happens to match the chosen or assumed RGB profile. If the RGB profile being used to interpret input RGB values has neutral greys on the same curve as the profile being used for DeviceGray you'll get the same CMYK result (barring colour manager quirks) - but if the RGB profile doesn't have neutral grays, has a different gamma, etc then you'll get different results. This is particularly the case where GCR or UCR settings are involved on the output side; it's not uncommon to see "rich" CMYK blacks produced for RGB input, but pure-K channel blacks produced for greyscale input. Unsurprisingly, this looks horrid. While proper RIP configuration - in particular, supplying a greyscale profile that matches the RGB profile - will fix this, in practice it's often best to stick to using one colour space in your document, generally tagged RGB. So, honestly, I don't think it's at all ideal to emit /DeviceGray in an otherwise colour document. I'd certainly want the option to specify the colour co-ordinate system(s) used - /DeviceGray only, /DeviceGray+/DeviceRGB, or /DeviceRGB only. I wasn't aware that fop did RGB to greyscale replacement, and I'm mildly concerned about it, as I'm working on software that'll be producing PDFs for pre-press consumption. I can always fix it up with some PitStop rules in preflight, but I'd rather not need to. Some time later I'd like to go head down in the FOP code to see if I can extend it to support multiple colour spaces and CMYK profiles. I'm just a bit wary about that, given the rather hostile reception I've seen to contributed changes here; I can't afford to throw that much time away and can't afford to maintain a parallel branch. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
