Barb: What is the advantage of this approach versus what I've done in the past? In either case I'm putting in a character that I have to change via a character style.
It works to HTML.
Pre FM8, ▶ had to be done using a codepage/overlay font. For this glyph, ▶, it would require a font that had it, and the character might be anywhere in the 00h-FFh code space.
In Wingdings 3, it's found at \x75 (aka 75h, 0x75 in hex notation). For workflows that support font declarations, such as PDF, rendering a character byte with a value of 0x75, and with Wingdings3 available, you get a ▶.
For sharing of the FM source to other computers lacking Wingdings3, and/or output to XML/HTML and probably eBook, that 0x75 byte will be treated as: u U+0075 LATIN SMALL LETTER U
Whereas, if you use:
▶ U+25B6 BLACK RIGHT-POINTING TRIANGLE
(which is the triple-byte string 0xE2 0x96 0xB6 as UTF-8) the rendering/display app knows it's supposed to be a ▶, even if the intended/default font doesn't populate it.
If the font in use doesn't populate U+25B6, you can still encounter u, or ?, �, ⍰ alerts, but for HTML, many browsers will do font fallback, and use the ▶ glyph from some other font available on the platform. FM doesn't do font fallback (and you'd want it off most of the time if it did).
For text processing apps that support all of Unicode, use Unicode. In FM, for characters in Unicode BMP (U+0000 to U+FFFF), use the Unicode code point. For glyphs in SMP planes (U+10000 and up), you still have to use legacy overlay in FM8-FM2022, or even uglier hacks
... View more
AdChoices