FrameMaker 2020 Unicode support

[LinSims]

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. 

[Jeff_Coatsworth]

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

[LinSims]

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.

[Bob_Niland]

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.

[LinSims]

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. 

[Bob_Niland]

Windows Char Map is nearly useless when Unicode details matter.

1. CM doesn't show any SMP (U+10000 and higher) at all, making it useless for SMP-aware apps. This isn't yet a big deal for FM, because FM has no SMP rendering support yet (although FM Char Palette, oddly, does show SMP code points).
2. CM collapses out unpopulated code points. So if you seek 2713 for Source Sans Pro, it finds it, and the next box to the right has a glyph it, but it's not 2714, it's 2752.
3. For some legacy overlay fonts, CM shows legacy overlay glyphs at both their \xA0 to \xFF positions, and at the Unicode code point for that glyph, or perhaps some entirely incorrect glyph (T1 Zapf Dingbats is riddled with these, and this may be more about that old font than Windows). What is this supposed to imply for apps using the font or embedding it downstream?

[LinSims]

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

[Bob_Niland]

FM Character Palette is no longer winking out for me (15.0.5.838), but its issues include:

1. As soon as you do anything else in FM, the CP vanishes, and has to be re-invoked to get it back. Even dragging it outside the main FM window won't keep it up.
2. Navigation is tedious. No search.
3. Character selection either unobvious or impossible. Building a character string definitely not provided.
4. CP has the same defect as Windows CM on this particular Source Sans Pro issue. The U+2700 block in CP shows all sorts of glyphs that are not actually populated in the font.
5. CP does not display the Unicode formal name string for the characters.
6. As a mirror image of issue #4 here, CP is also showing SMP range for fonts that populate it (such as Segoe UI Symbol), but you can't actually use those yet in FM.

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.