Font Binding Refinement

As discussed in the post RichEdit Font Binding, in a text string when a character appears that isn’t supported by the current font, an appropriate font needs to be used. There are a number of pitfalls in making such font choices. For example, the post Math Font Binding discusses special requirements for font binding in math zones.

This post deals with a problem I’ve had that doesn’t occur with RichEdit font binding, but does happen in Word and Outlook. Often I need to document a particular Unicode character such as ⬚, U+2B1A which is used as a place holder in empty math objects, or <the new blog editor can't handle U+20000>, U+20000 which is the first Unicode plane-2 character. To enter such characters, I type the Unicode hex value followed by alt+x as described in the post Entering Unicode Characters. If you do this in WordPad (which uses RichEdit) and continue typing, the font changes from Calibri to Cambria Math for ⬚ and to SimSun-ExtB for U+20000 and then switches back to Calibri for the subsequent text.

But in Outlook and Word the font switches to these other fonts and then continues to use them as long as the new font has the characters you type. The problem is that ASCII letters are supported in the vast majority of fonts, so invoking the rule “stick with the current font as long as it supports the characters” is insufficient for proper font binding. You can work around this error by using the handy Format Painter tool on the Home tab to restore the original font to subsequent text or more easily by typing on both sides of the character’s hex code before typing the alt+x hot key after the hex code.

Interestingly, if you paste a plain-text string containing such characters into Word, e.g., from NotePad, only the fonts for the special characters change. But relying on NotePad for entering such mixed text isn’t practical since NotePad doesn’t support alt+x. PowerPoint doesn’t have the problem since it doesn’t support alt+x either, sigh. (We might add the alt+x hot key to PowerPoint someday…)

There are a couple of ways to avoid this pitfall. RichEdit has the CHARFORMAT2 attribute CFE_FONTBOUND, which marks a run as being font bound when a different font is used to display a character. As such the font-bound font has lower priority for subsequent font binding than the previous font. Also if the font fix up occurs just as the text is input into the RichEdit backing store, it doesn’t change the selection’s current font. Both of these choices result in the font being restored to the previous font after a special character is font bound.

Another problem with Word’s font binding is that it switches to SimSun or if you enter a right arrow like → (U+2192). This is annoying especially since Calibri and most other Latin fonts support the simple arrows ←↑→↓, so no font binding is needed. This font switch occurs for both alt+x entry and pasting. But at least the font switches back to the Latin font after the arrow symbol is stored. Hopefully we’ll fix these problems before too long.

RichEdit font binding is overruled in the XAML edit controls, TextBox and RichEditBox, partly to maintain consistency with the companion TextBlock and RichTextBlock controls. A similar consistency is desired in Excel spreadsheets. A future post will describe how these approaches work.