Why is FrameMaker using different CYMK/RGB values for Pantone library colours compared with Illustrator?

ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGH

OK, here's what I tried this time:

I used Arnis' template to create a .acf file in Notepad, containing CMYK and RGB definitions of my Spruce Green colour. (FWIW I set "preferred" mode to RGB, not sure what practical difference it makes).

I restarted Frame and lo and behold, there in the Color Definitions dialog was now my very own library with my one colour in it. I could add it to the document's color definitions, and switch between CMYK and RGB mode, and it had the right definitions and colour for both of them. I could color some text with my new colour, and make PDFs in both CMYK and RGB output modes, and they both looked very similar in Acrobat (the CMYK one was, unsurprisingly, sliiiiiightly different to what I saw on screen in Frame, as Frame had been displaying me the RGB definitions, but Acrobat was converting the CMYK to RGB on the fly to display on screen.)

But then the facepalming moment:

I tried CHM output via the Publish command.

ARRRRRRRRRRRRRRRGH.

I get the horrible lime green again.

Frame totally disregards the RGB definition in has for the colour, and does bogus maths on the CYMK version, resulting in a totally wrong hue.

It's beginning to look like this is a bit of a no win situation.

There's no way I can have a single set of colour definitions across Illustrator and Frame that will output reliably to both CYMK print and on-screen HTML Help.
Any time a colour definition possesses numbers for CYMK, it ruins the CHM output's colour, even if a valid RGB definition is also present.

The only way to get reliable colour in CHM output is to have a purely RGB definition of a library.

This is, of course, conversely, no use for creating PDFs for print.

I basically just need two different swatches: one RGB one and one Pantone one,

Frame documents that will end up as CHMs have the RGB EPS added to a reference page;

Frame documents that will end up as PDFs and might get printed have the CMYK EPS added to their reference page.

Or, another solution is just to keep everything in RGB mode. That way, PDFs look OK on screen and match my CHMs exactly. When printed on paper, the printer will just have to convert RGB > CMYK themselves, which will probably give perfectly acceptable results anyways.

OK, I did some experimenting.
I made a swatch in Illustrator CC, with Pantones define as spot LAB values.

I saved this as an EPS and imported it onto a new Reference Page in Frame 12.

Arnis, it works PERFECTLY in CYMK mode!   The colours in the swatch all appear in the my Frame colour definitions, and if I examine their CYMK values, they match exactly the CYMK equivalents Illustrator uses if I take the Pantone out of spot LAB mode and view the CYMK equivalent. Given that Frame doesn't support LAB, we can't really ask for better.

However, it all goes belly up in RGB mode

As per the definitions in the Frame11 Maker.ini reference, in my maker.ini [Preferences] section, I have GetLibraryColorRGBFromCMYK=None, which is meant to "Display and print the RGB values from the library color description."

However Frame12 isn't doing this - it is using its own bogus algorithm to convert the CYMK value to RGB, the same broken behaviour we saw in this thread here https://forums.adobe.com/thread/1485020
when text colour in CHM output was all wrong.

For instance, compare this "Spruce Green" (Pantone 355C) - in Illustrator (right hand side), if I take it out of Spot LAB mode and ask for an RGB equivalent, I get 0-148-77.

Frame obfuscates this a little by expressing the values as percentages, but converting it to values out of 255, we get 0-220-0 (that lurid lime green colour)

Now I don't think I'm being unreasonable in asking how on EARTH is that supposed to be a good equivalent to the original Pantone?!? It's zeroed the blue channel!!!    Truely bizarre.

Thanks Arnis!

Arnis Gubins wrote You can get new(er) Pantone colours into FM ...  by creating a swatch set of the project colours in AI or Photoshop and saving those to an EPS or PDF file. Then import that file onto a Reference page and FM will automatically add those swatch colours to the document color catalog.

Aha! Brilliant. I should've thought of that! (As I'm was well aware that my Colour Definitions list often gets full of spurious entries from imported graphics... some of us may well remember all those RGB colours from paletted PNGs, for instance).

I wonder what Frame will do with these definitions if I defined the Pantone in Illustrator as an L*A*B spot colour though? (I will experiment!)

Understanding colour management is sort of like trying to always get the same colour of light-brown on a piece of toast everywhere. ...

Now come on, don't start going into the "Wooo, colour management! It's complicated!" thing. It's not exactly quantum mechanics. There is nothing "complicated" about how Adobe hasn't deigned to update FrameMaker's Pantone libraries since 1988. (Indeed, since Adobe only acquired Frame in 1995 (?), Adobe have NEVER updated its Pantone libraries!!) I'm struggling to see how this is acceptable, really? What are they playing at?!  To me, this is just yet another example of where colour "management" doesn't work properly because of poor quality software, but the vendor hopes to get around it by going "wooo! colour management! complicated!!" and obfuscating the actual problem.

But anyways, enough moaning - I shall fill in that bug report/feature request form suggesting that they might like to update those libraries. But Arnis' workaround will do very nicely in the meantime