> I think CMYK support in tools used early in the publishing chain > is somewhat overrated.
Right, but FOP _MUST_ not be early in the publishing chain! It could in fact be the only and therefore even the last step in a publishing chain... > I can only think of the following use cases for XSLFO: > - Avoid round-off errors and other numerical problems in the > conversion CMYK->sRGB->CMYK, perhaps in order to match exactly > colors of embedded CMYK bitmap images in text, borders and > background. Conversion CMYK -> RGB is nearly always lossy. And for print sRGB is also not that perfect (because of it's small gammut (nearly the smalest gammut of all RGB colorspaces)). > - Get color values into the document which can't be expressed > as RGB. I don't know whether this can even happen. If you create PDFs for print, you nearly always want CMYK! Okay, RGB and colorspace would be great but nowaday not all print- companys now how to handle colorspaces (for example PDF/X-3). > > As far as round-off goes, AFAIK the transformation from CMYK to > RGB and vice versa is linear and numerically well behaved with > the exception of some extreme saturated colors, in particular > very dark colors. I've never heard of anyone noticing these > kind of problem without deliberately using a somewhat braindamaged > tool for colorspace conversion which rounded all values to two > significant digits *and* both a quite expensive printing kit and > a well trained eye. 100% c 83% c 0% m 5% m 0% y --> sRGB --> 2% y 0% k 0% k So in fact, CMYK -> sRGB -> CMYK is not linear. If you convert the result to sRGB and again back the values will even be more bad. > > J.Pietschmann > > Christian Beer > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
