13.7.6 Understanding CMYK-to-RGB conversion anomalies
CMYK and RGB are fundamentally different. CMYK is subtractive. It defines a color in terms of how the color reflects or absorbs light (most useful for printing). RGB is additive. It defines a color in terms of the light that is emitted (most useful for monitors). Any conversion from one to the other is bound to be an approximation.
However, Mif2Go encounters a bizarre CMYK-to-RGB conversion problem with colors defined in color libraries. HTML requires RGB. FrameMaker uses CMYK internally, though RGB is used for the screen display in Windows. The values that FrameMaker uses for CMYK do not always convert to the same RGB values as those FrameMaker displays; often, nowhere near the same.
If you choose a Pantone color, for example, and view it in RGB in FrameMaker, the percentages you see are not always the correct computed value (which is what Mif2Go uses). Also, you can define two visually very different colors that appear to have the same CMYK value in FrameMaker, but different RGB values.
This is different from what happens if you define a new color based, say, on black; you can work in either RGB or CMYK, and when you flip back and forth, FrameMaker uses the correct conversion (the same conversion Mif2Go uses).
But FrameMaker’s color databases do something
very odd. If you look at a CMYK color that has no blacK, such as PANTONE
528 CVC (a maroon), and note the Cyan, Magenta, and Yellow percentages;
then change to RGB, and note the Red, Green, and Blue percentages; each
matching pair (Cyan-Red, Magenta-Green, Yellow-Blue) should total 100%,
because aside from blacK, the two color models are mathematical complements.
However, what you see instead are the percentages shown under FrameMaker RGB in Table 13
With model RGB
selected, choose Black, then choose
New Color, and enter the computed values, from the Computed
RGB column in Table 13
Table 13
