ANSI Z535.1 Safety Colors in Frame

Question

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.

Answer 1

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