Original colors of graphic objects are lost when saving as MIF

Affects: FrameMaker 5.5/Windows or higher

Description:

"We are having a problem converting a FM file from FM7.1 to mif. All graphics that have been drawn in FM, turn black when saved as mif. Object properties retain the original color definitions. All objects exist. WMF graphics that also exist in the file did not turn black. Grouping / ungrouping makes no difference. Different colors make no difference either."

Workaround:

This problem occurs when a FrameMaker file has "auto-generated" RGB nnn,nnn,nnn colors, typically added to the Color catalog as a result of a bug when importing 256-color (8-bit) PNG files (or if colors are imported from a document which already has such colors).

These colors are deleted automatically when saving as .mif, even if the colors are assigned to different items. As these colors are no longer present in the .mif file, all objects and text which used these "RGB..." colors are assigned the default black colors (similar to what happens to objects which use a color deleted manually from the color catalog in FrameMaker).

Such "auto-generated" colors should therefore not be applied or used in FrameMaker.

If you have files which have references to these colors, you may reapply colors using "normal" colors (add as many as necessary), and then saving as .mif won't involve loss of color. If you have many files and a lot of work is involved, you may create these colors with identical names in a separate .fm file, then import the colors into your files (and then they will survive .mif export). If you have many colors involved, it may be worthwhile to define these colors through a script/program..

Available Fix:

 

Additional Info:

A sample file (FM7) which demonstrates this loss of color info.

 

Version 1.0, November 15, 2005