Scott wrote: < However, why didn't Microsoft make it easy on everyone in the first place, since on inception of their OS printing was the major output? >
It's not my business to defend or accuse Microsoft or Adobe in any way. My business is to speak out loud that CMYK and SPOT color support in FrameMaker, even in 9.X, is undeniably poor -- in particular with composite output. Scott wrote: < Why in the past 20 years didn't they correct their arrogant assumption that RGB was the only color output scheme that was needed? > MS have provided means that make it fairly easy to accommodate special output needs, and have actually been doing so since 32-bit Windows was born. To begin with the documentation about it was extremely poor, but since Windows 2000 the printer escapes PASSTHROUGH and POSTSCRIPT_PASSTHROUGH have been quite well-documented (a good place to start reading about this would be http://msdn.microsoft.com/en-us/library/dd162843(VS.85).aspx). Since using these escapes is not at all comparable to rocket science one can only wonder why these are not adopted into the FrameMaker output kernel. Remember that FrameMaker actually CAN read CMYK bitmaps *and* output them correctly when creating separations. Hence, FrameMaker already contain code that goes beyond Windows GDI capabilities and proactively makes decisions about which color plate to send. Why not implement support for composite output as well? Scott wrote: < A hack is a hack. Not an acceptable way to do business. > How do you think the "Generate Acrobat Data" functionality works when you print to PDF? A qualified guess is that FrameMaker injects PDFMark PostScript code into the output stream. Implementing full support for CMYK bitmaps wouldn't require much -- as I see it. For example, FrameMaker could write a temporary file in EPS format for each CMYK bitmap (e.g. ASCII85 encoded for TIFF images and DTC encoded for JPG images), and then use the already existing EPS injection method to inject this temporary file as a substitute for the CMYK->RGB ruined version. CMYK bitmaps wrapped into EPS format are already fully supported by FrameMaker, hacks or not :-) Again, why not implement support for it when it could be done quite easily? One argument could be that implementing support for CMYK and SPOT colors applied to text and vector elements would require a substantial effort. And that's may be why things are as they are. The argument may also appear reasonable as a whole. But I don't agree with this argument when it comes to CMYK bitmaps. As of today FrameMaker directly *spoil* CMYK bitmaps upon composite output in a very destructive way, and that doesn't count to the same extend for text and vector elements, which actually can be fixed downstream. The CMYK bitmaps can *not* be fixed downstream, and that makes the *huge* difference. Hence, I still find it highly unacceptable that FrameMaker didn't implement support for composite outputting CMYK bitmaps many, many years ago -- Windows GDI or not. The technology to implement it is already largely available in the FrameMaker source code !!! Best regards / Med venlig hilsen Jacob Sch?ffer | Chief Developer ---------------------------------- Grafikhuset (House of Graphics) Paradis All? 22, Raml?se DK-3200 Helsinge, Denmark Phone: +45 4439 4400 Email: js at grafikhuset.dk Web: www.grafikhuset.net
