Here's an oddity.
I use a Unicode typeface (Source Sans Pro) that has a fair number of glyphs in it. Yesterday I wanted to add the "Heavy Check Mark" (U+2714) to a document, and it came in as "??". Applying a number of other Unicode supporting fonts didn't change that, either. Strangely, the regular Check Mark (U+2713) worked just fine. Not the look I wanted, but I can live with it.
I just thought it odd that FM couldn't display the glyph at all. In fact, there are a lot of glyphs in that section that FM can't display.
I'm not super up on Unicode code points (paging @Bob_Niland lol), but isn't that a function of the font vs. the tool (i.e. FM)?
Hmmm. Character Map shows that glyph as being available in Source Sans Pro, but according to the Fileformat.info website, Source Sans Pro does not, in fact, support most of the dingbats. It only supports two in that section: the checkmark (U+2713) and the "Upper right shadowed white square" (U+2752).
I wonder why Character Map included them when I set it to Source Sans Pro? It doesn't for the other fonts, such as Arial or Times New Roman.
Well. There's a fine how-do-you-do.
Source Sans Pro populates \u2713, but not \u2714.
Segoe UI Symbol has both, by the way.
FM knows what both are, internally, because it converts them from \u markup to ✓ and ✔ after creating a Variable to implement them.
But if the font doesn't populate them, you get a ? in edit and output.
I'm using BabelMap to browse glyphs in fonts, incidentally, as both Windows Character Map and FM Character Palette have issues.
At and below codepoint U+FFFF (Unicode BMP), the main issue is whether the font populates the codepoint (and other than ?, FM doesn't have a fallback capability when the font doesn't). At and above U+10000 (Unicode SMP); whole different problem.
Yes, my mistake seems to have been trusting the Windows Character Map application as far as Source Sans Pro goes. I still think it's weird that it shows those glyphs as being populated for Source Sans Pro when it (correctly) does not show them populated for other typefaces. This is obviously a Windows issue, not a FrameMaker one. Also my face feels a bit eggy. 🙂
After Jeff's comment I opened BabelMap and found the correct information. This has led to the addition of a character tag that uses the Segoe UI Symbol font to all my templates.
Windows Char Map is nearly useless when Unicode details matter.
Unfortunately for me, the FrameMaker Character Palatte and Hex Input don't work and haven't since at least FM2017, on multiple computers. After about 10 seconds, something closes them, so I have been using the Windows Character Map application. Below is what it shows me for Source Sans Pro. That heavy check mark is what set this whole thing off, too.
Character Map doesn't do this for any of the other fonts I checked, and I checked about 10. Weird, huh?
At any rate, from now on I use BabelMap and I have it pinned to my taskbar, along with eleventy-other programs ...
FM Character Palette is no longer winking out for me (188.8.131.528), but its issues include:
My general impression of the situation is that SMP support was started at some point, including development of CP and Hex Input, but some major roadblock arose (perhaps with Windows itself), and work was never fully completed. There is at least one feature request open on this, FRMAKER-2628. What to do about \u markup for SMP is also an interesting problem. It cannot safely just be coded to allow 4 or 5 digits.