ANSI Z535.1 Safety Colors in Frame

[Bob_Niland]

Frame 7.1 Solaris (Frame 9 Win7 available).

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.

What is everyone else doing about this?

Z535.1.Blue _________________
ANSI Munsell: 2.5PB 3.5 / 10
Nearest sRGB: 2.5PB 3.5 / 7.9
RGB(255):     000   089   137
RGB(100%)     0.0  34.9  53.7

Z535.1.Orange ________________
ANSI Munsell: 5.0YR 6.0 / 15
Nearest sRGB: 5.0YR 6.0 / 12.7
RGB(255):     222   125   000
RGB(100%)    87.0  49.0   0.0

Z535.1.Red ___________________
ANSI Munsell: 7.5R  4.0 / 14
Nearest sRGB: 7.5R  4.0 / 13.6
RGB(255):     187   039   036
RGB(100%)    73.3  15.3  14.1

Z535.1.Yellow ________________
ANSI Munsell: 5.0Y  8.0 / 12
Nearest sRGB: 5.0Y  8.1 / 11.6
RGB(255):     239   203   000
RGB(100%)    93.7  79.6   0.0
_______

Values harmonized for ISO 3864-1:2002 would be nice too.

[Mike Wickham]

"Tag Everything for Color Management"

I can't tell you anything about the Munsell colors, but you might want

to check that setting for color management. It seems like I had set that

once and all my black text came out as RGB text, instead of K. For the

Web, that would be no big deal, but for printing it sets up fuzzy text

problems from misaligned ink layers. You might want to use "Tag Only

Images for Color Management" instead. In Acrobat X, you can check the

text using View> Tools> Print Production> Output Preview, and then hover

your cursor over the text to see what inks are being used.

[Bob_Niland]

> ... and all my black text came out as RGB text, instead of K.

Sure enough, it's composite black. That might also explain a printing performance problem using that setting.

>  You might want to use "Tag Only Images for Color Management"

I hadn't noticed that option, but since I don't need color managed color text, that's the thing to do.

Thanks. The question about optimal sRGB values for safety colors remains open.

[Bob_Niland]

Continuing to poke around on this, I see that the U.S.DOT, at:
http://phmsa.dot.gov/hazmat/training/publications
suggests:

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.

[Van Kurtz]

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.

[Bob_Niland]

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.

[Van Kurtz]

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.

[Bob_Niland]

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.

Several problems, hinted at above:

1. The Pantone colors are probably specified in CYMK. What is the algorithm for the RGB conversion? Is hue preserved?
2. The Pantone colors may be out of sRGB gamut in either space, so what is the rendering intent when bringing them in? Is hue preserved?
   
3. Was due diligence given to the wandering-hue-when-scaling-chroma problem (the notorious blue-turns-purple problem)?

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.

[Dov Isaacs]

Error7103 wrote:

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.

          - Dov

[Bob_Niland]

Thanks for the reply, Dov.

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.

Using post-processing after-market tools, it probably doesn't matter.

[Bob_Niland]

There may exist professional tables of Munsell/sRGB matchings (rit.edu's Munsell lab seems to have misplaced theirs during their web revamp), ...

RIT's sRGB map has reappeared, at:
http://www.cis.rit.edu/research/mcsl2/online/real_sRGB.xls

...but this has a similar problem: what was the rendering intent during the mapping?

And, alas, the question doesn't arise in their spreadsheet, because they only mapped the Munsell colors that are in gamut for sRGB.

For the ANSI safety colors of interest to me, that only includes red, and the values they give are close enough to what I estimated that I'm staying with my values.

[feline_1973]

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!

[feline_1973]

Also, do Windows 7 and 8 really still use the "GDI" imaging API from Windows 3.0? Still? In the year 2013? I'm skeptical.....

[Bob_Niland]

> I was googling this exact same question today, two years on.

> Disappointed to see that no real definitive answer got given!

Get used to disappointment .

> Why doesn't FrameMaker have built-in presets for these colours?

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:

1. 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.
2. 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

Otherwise, the FM colors get visibly desaturated vs. the EPS colors.

[Matt-Tech Comm Tools]

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.

[feline_1973]

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.

[Bob_Niland]

> ... 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.

[Matt-Tech Comm Tools]

Huh??

Clearly we're discussing different topics. Color management wasn't even mentioned in the post I replied to.

Based on your tone and tenor, I don't feel the need to participate.

Best of luck enticing others.

[feline_1973]

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.

[Matt-Tech Comm Tools]

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

Winning friends, influencing people...

You complained about standardizing colors across 4/c, spot, and online formats. I quite accurately explained why you are out of your depth.

The existence of a mind-boggling number of PANTONE libraries speaks to the fact that color calibration / management are different than color definitions and rendering intent.

What application can you point to that does what you require?

[feline_1973]

If by "mind-boggling number" you mean "about 12", then we agree

[Bob_Niland]

> ... if I'm not allowed to become exasperated at zero lack of progress in improving FrameMaker's colour management in the last 15 years ...

Whine away (with the rest of us), but whining here is even less effective than doing so in the current survey that's running, or in the FM Features forum, which I see you already know about.

Just taking a look at FM's ostensible top competitor, I can't easily tell if it supports CM either. And, of course, there's that nagging question of whether Windows really has real CM, esp. for CMYK.

> ... it's just a few equations!

If it were easy, I'd expect it would have been done by now. But then, if Cross-Ref by $MarkerText was easy, we might expect that to have been done long ago as well.

[FieryPantone]

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

[Bob_Niland]

> ... there are far too many variables to allow Fm to supply "official" colors for those things.

Just to emphasize. This is not a Frame problem.

Even fully color-managed apps can't really provide ANSI or ISO Safety colors.

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).

[Bob_Niland]

re: Values harmonized for ISO 3864-1:2002 would be nice too.

With this old thread revived, it's worth noting that the current ANSI Z535.1 is now ANSI Z535.1-2017. According to their blog, it was revised to harmonize more with ISO, and specifically adopted the 49 CFR §172.407(d)(5) and 172.519(3) Pantone® colors (although as the same numbers "C" (coated) whereas CFR says "U" (uncoated).

The blog also has a document claiming "Annex C contains color cross-reference tables which include the Munsell notation, a PANTONE number, C-M-Y-K percentages, and an RGB formula for each ANSI and ISO safety color."

"RGB", without qualification, is useless. If they meant some color-managed RGB system, like AdobeRGB or sRGB, they might have said so. Anyway, having no projects requiring safety colors, I don't plan to spend US$132.84 to find out that they dropped the ball.

And FM still has no color management, so you must continue to either implement all safety colors as graphics import formats tagged for color management, or use RGB color model, and tag downstream in the PDF workflow.