Although the manuals I work on are print-published only in grayscale (600 dpi bitmap, actually), we make them available on the web as PDFs (which could be in color). At some point in the future, we may publish in color (probably using Xerox or HP laser engines).

For recent works, we've been using color, where convenient, and just leaving it enabled in the PDFs. For lack of a more compelling model, the color space chosen is sRGB. Those users exposed to color are most likely viewing the PDF on a computer, or printing it on their own inkjet or color laser printer.

A portion of the color content is graphic panels for DANGER/WARNING/CAUTION/NOTICE, and representation of product decals and labels of those same hazard classes.

The dominant market is U.S. domestic, so we follow ANSI standards for these admonishments. The ANSI standards include color specifications (ANSI Z535.1-2006) for safety notcies. The colors used in our manuals are only Red, Orange, Yellow, Blue at present.

Z535.1 specifies these colors in Munsell HVC and CIE 1931 xyY illuminant C coordinates. Most of the ANSI colors are out of gamut for sRGB.

The ANSI colors are realisable as printable spot colors on decals and product labels, but ANSI did not address how to render them in typical document printing. (Actually, the spec claims to provide Pantone equivalents, but does not.)

So, the spec colors can't be matched in normal printing from a random PDF viewer to a random color printer.

Well, we can at least pick something and be consistent, so the safety colors all have the same appearance within our documents, and perhaps match hue to safety spec.

Frame's color library, the Munsell Library of Colors or the Munsell High Chroma, has some of the Munsell values for ANSI patches, but they look awful, probably due to the [unspecified] choice of rendering intent in the mapping of library colors to the RGB/CMYK/HLS values actually used. And, of course, Frame has no color management to speak of, so the RGB/CMYK/HLS values are uncalibrated.

There may exist professional tables of Munsell/sRGB matchings (rit.edu's Munsell lab seems to have misplaced theirs during their web revamp), but this has a similar problem: what was the rendering intent during the mapping? Typically, conversions try to preserve some color difference between nearby out-of-gamut colors. I don't care about that. I want to get as close as possible to the ANSI colors in sRGB space, and I want to at least match hue (no "blue turns purple").

Any number of web sites purport to have RGB values for these colors, but they are even more vague about how they arrived at them, so they usually disagree from one site to the next.

There are lots of tools that perform CIE to sRGB conversions, but they are similarly challenged in the matter of intent (plus whether they accounted for the wandering of hue as you attempt to scale chroma in models other than Munsell).

What I probably need is the limiting sRGB value of the same hue as the Munsell value for the ANSI spec color.

Using BabelColor, I experimented with sRGB values until I could obtain:

* a match for the Hue

* a match (or a within-ANSI-tolerance) for Value.

* as close as possible for Chroma.

What I came up with is at the end of this post.

These colors will be entering the manuals as objects from Photoshop and Illustrator primarily, typically RGB EPS images, tagged as sRGB with embedded profiles. Some might be created in Frame directly, and as long as:

"Tag Everything for Color Management"

with a working space of: sRGB IEC61966-2.1

is specified during Distiller, the resulting colors in PDF seem to match regardless of source.

Therefore, printed copies of the DOT Chart 14 from your laser printer may not accurately represent the required colors of markings and hazard warning labels and placard set forth in 49 CFR §172.407(d)(5) and 172.519(3).

Pantone® Color matching System (PMS) may be used to achieve the required colors:

Red, PMS 186U;

Orange, PMS 151U;

Yellow, PMS 109U;

Green, PMS 335U;

Blue, PMS 285U; and

Purple, PMS 259U.

I haven't yet experimented to see if Frame's CVU library gets closer to ANSI spec than my earlier empirical sRGBs.

A few sites, such as DOT and NFPA, do make some attempt to mimic true safety colors in their documents, but they rarely match each other.

Most authors seem to just jam the colors to RGB or CYMK primaries, which means the hues are not correct (apart from being out of gamut for some rendering paths). Safety hues are very carefully selected colors. To train the correct recognition and response in users, getting as close as possible to treu safety colors is a worthwhile effort.

Internally, FrameMaker uses RGB (CMYK colors created in FrameMaker are converted to RGB), but only for the things it creates, such as text. If your color is in the graphics, create them in Illustrator (or other drawing program) in CMYK, using the PMS as needed. THen save them in eps. When FrameMaker prints a document with imported by reference eps files, it simply passes them through to the print output. Then you can deal with the color in the PDF.

If you need colored text in FrameMaker that matches the CMYK, you can try creating your own inks for FrameMaker to use. Even though you have to specify the RGB, you can do it to a high degree of accuracy. If you search this forum, there should be some discussions about it.

Internally, FrameMaker uses RGB (CMYK colors created in FrameMaker are converted to RGB), but only for the things it creates, such as text. If your color is in the graphics, create them in Illustrator (or other drawing program) in CMYK, using the PMS as needed. Then save them in eps.

Thanks, but I'm very familiar with the difficulty of matching Frame CMYK colors to imported CMYK colors on pre-Vista Windows. Is Frame still jamming to RGB in later versions on Windows that support CMYK?

In this case, however, CMYK is not the target. sRGB is the target, since we don't print in color, and the main place users will see the color is on-screen. It does appear to be possible to get EPS RGB and Frame RGB colors to match using certain workflow settings. The main question in the thread is how to mimic the various ANSI colors in sRGB space.

If you need colored text in FrameMaker that matches the CMYK, ...

Fortunately, I don't.

In the case of the DOT, the safety colors specified in the regulations match the ANSI colors exactly in Munsell values (for central colors; the tolerance colors are specified differently). In the DOT “Chart 14” PDF, for example, they are using their own Pantone equivalents mentioned above.

The document appears to have been created in Quark. The label/placard images are specified as named Pantone spot colors. When opened for edit in Illustrator, they come up as CMYK, but I don't seem to have a tool that reports what, if any profile is used. So obtaining an sRGB readout introduces the variables of the CMYK-RGB conversion being done, and whether any profile is being applied or preserved.

Using the Frame Pantone CVU numbers has similar problems. So for the moment, I'm staying with the sRGB values created experimentally by approaching the Munsell values in sRGB space in BabelColor.

I do not use color management, so am not conversant in all its particulars. But how about using a program such as Illustrator or Photoshop. Set its RGB to sRGB. Then pick a Pantone color and use the program's conversion to convert to RGB. Presumably these programs know how to manage color.

Yes, but the details of how they do it aren't always given. The result is that pretty much everyone who has looked at the problem of mapping safety colors into sRGB has come up with a different answer (mine are likely yet another variation, and not necessarily optimal).

The ANSI-to-sRGB issue, by the way, is not a Frame-specific problem. The answer would be applicable to any image editor or DTP app. I just happen to be using Frame to deliver the content, and Frame adds the challenge of having deminimus color management.

Is Frame still jamming to RGB in later versions on Windows that support CMYK?

There really is no version that supports CMYK directly. The GDI imaging model is totally RGB (and actually a make believe sRGB which is really monitor RGB). Don't confuse support of CMYK in XPS as Windows really supporting CMYK and spot colors.

Also, internally, FrameMaker does indeed support both RGB and CMYK color definitions. The problem is that for the traditional output path using Windows drivers, it must do an internal conversion of CMYK and spot colors to RGB.

There really is no version [of Windows] that supports CMYK directly. The GDI imaging model is [still] totally RGB (and actually a make believe sRGB which is really monitor RGB). Don't confuse support of CMYK in XPS as Windows really supporting CMYK and spot colors.

Like the parrot said in the movie:

Why am I not surprised.

Also, internally, FrameMaker does indeed support both RGB and CMYK color definitions. The problem is that for the traditional output path using Windows drivers, it must do an internal conversion of CMYK and spot colors to RGB.

So for matching colors of imported objects and Frame graphics, it's probably dramatically easier to stay in the RGB color model, using standard capabilities, particularly if sRGB is the target delivery space.

I was googling this exact same question today, two years on. Disappointed to see that no real definitive answer got given! Why doesn't FrameMaker have built-in presets for these colours? It's such a basic requirement!

Too many ANSI (and ISO) Safety Colors are out-of-gamut for common color systems, including the sRGB I use. Bringing them in has two problems:

What's the rendering intent?I'm using Absolute Colormetric, because I know all my other colors are in gamut for sRGB. User.Random might need Perceptual, Relative Colormetric or Saturation.

What's the tri-stimulus priority?My choice (using Munsell terms) is match Hue, get within ANSI tolerance for Value, do what I can for Chroma. Some people might prefer to just get into, or as close as possible, to the ANSI tolerance box.

Even after working out a local solution, it is all extremely fragile, due to the near complete lack of color management in Frame - and we've been told that FM is never going to get CM.

I had to re-learn just today that, in Unix FM, to get my FM RGB color text to match my sRGB-tagged RGB EPS imports, have have to select at Print:[*] Convert CMYK Colors to RGB

It sounds like you've got definitions like that for applications other than Fm... is that correct?

As Error mentioned, there are far too many variables to allow Fm to supply "official" colors for those things.

Among the problems are the screen representations, which differ based upon *your* choice of paper (if indeed you're outputting to paper), or your end user's choice of paper to print upon. I'm sure you already know that you'll never get online and print representations to match, simply due to the different gamuts used for different color models.

I'd wager that your industry has "official" Pantone or other color model definitions for things, which allow you to define colors as needed from Fm's supplied color models.

If you want to include *your* perfect definitions for *your* application, you could always add those definitions to the maker.ini file.

matt, if all Adobe's other Creative Suite applications can do colour management, why can't FrameMaker? Is £1800 for a Tech Comm Suite license not enough?

Also, nobody prints onto paper *from* FrameMaker: they author in it and publish to PDF and all the rest. That being the case, all I want is a way to specify a standard colour definition (e.g. a Pantone or whatever) in FrameMaker that is going to make it straight into the PDF without being d1cked about with, and then it's up to Acrobat and the printer driver to fight it out if and when ink ever hits paper. The vast majority of FrameMaker users are producing tech docs for businesses who have a marketing team who specify branding colours in that kind of way, or (as in this example) they're specified by a standards body such as the IEC. It's a no brainer.

Personally I lost patience with all this "colour management" voodoo about a decade ago already. Like many tech writers, I'm not dumb - I have a science background. Colour management just involves applying a transfer function to a bunch of numbers, to get a reasonable answer. Time and again, the transfer function they're using is obfuscated under the hood and it patently gives stoopid results (blue turning purple, etc etc) Am sick of Adobe mumbling about how it's complicated in an attempt to cover the fact that their software sucks.

Color libraries might be able to provide these colors, but only if using a color model whose gamut is large enough that all safety colors are within it. I haven't really studied any, like Adobe RGB or Wide Gamut RGB, to see if they can encompass. With any lesser color models, like SWOP, the colors have to be re-scaled or clipped to bring them in, but using whose choices?

And it doesn't much matter if some notional 53-bit HyperRGB color model can swallow all of Munsell, because when your HyperRGB-encoded PDF is viewed, pressed or convenience printed, that gamut is going to be squashed or clipped to fit the display/print gamut limitations. How the safety colors will get converted to in-gamut will be out of your control, possibly not even constant hue. Odds are the final renderings of the safety colors are going to be seriously sub-optimal, possibly even hazardously misleading if not flat out illegible.

Frame just adds the joy of being an uncalibrated CYMK or RGB engine, with some challenges in getting native and imported color content to match each other (much less any absolute color standard).

> ... if all Adobe's other Creative Suite applications can do colour management, why can't FrameMaker?

It apparently needs a whole new internal color engine to do that, and I'll bet all the graphics filters would need to be re-written to support it. The starting code is really old, and although we might interpret the official story as being "CM is not part of the strategic plan for FM", I wouldn't rule out the possibility that the source is too fragile to mess with, or has even been lost for some of it (having worked for a company that had that happen for a released and supported product).

> That being the case, all I want is a way to specify a standard colour definition (e.g. a Pantone or whatever) in FrameMaker that is going to make it straight into the PDF without being d1cked about with, ...

You already have that with the color libraries. The text string of the library name (e.g. "PANTONE 441 CVC") is encoded into the color def, and survives into the PS or PDF for any Pantone print shop or Pantone-compliant RIP. The actual CMYK values are probably completely ignored in such workflows, other than for FM edit display and local convenience printing.

The problems arise when either the final rendering target does not handle named library colors, or the color is just a CMYK or RGB coordinate to begin with.

> Time and again, the transfer function they're using is obfuscated under the hood and it patently gives stoopid results (blue turning purple, etc etc) Am sick of Adobe mumbling about how it's complicated ...

Because it is complicated. Last I looked, only in the Munsel system is Hue invariant with Value or Chroma changes. Most of the model-to-model transforms extant apparently do not account for this problem. And yes, most engines don't tell you what transform they are using, and that would include how FM decides what RGB maps to what CMYK or HLS.

That's OK matt, if you can't even reply to the right thread, I doubt you were going to be much help in re-writing FrameMaker's entire codebase anyways

Meanwhile, if I'm not allowed to become exasperated at zero lack of progress in improving FrameMaker's colour management in the last 15 years, then I'll go to the foot of our stairs.

Error7103, I don't really see how "complicated" it can be, it's just a few equations! A few radio buttons on a well-worded dialog somewhere to let us choose the right equations wouldn't break the bank, would it?

I mean, I just want to be be able to enter a colour and it stay the same in the PDF. Can you imagine if things were like this with text? "Sorry, I know you typed 'bread', we we've changed it to 'bagel' in the PDF. It's complicated. You have to realise some of the people reading the output might be Canadian. Some of them might even be *French* Canadian. And the people in No.12 have never even sat on CHAIRS before!" etc etc. Oh dear.

off-thread link specially for feline_1973 – prompted by a phrase in this eloquent posting – but perhaps of use/interest to others who want to brighten up a dull layout test. I like the text substitution idea! Breadcake, barm-cake, bap, stottie … t'Lipsum