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

   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

Reply via email to