none
How to prevent font substitution on (some) characters in the unicode private use area (PUA) RRS feed

  • Question

  • This is about Word 2016.

    I have created a font "WAG Symbols" that contain characters in the private use area. When I type into a Word document text containing these PUA characters among regular text, select all text and change the font of the selected text to "WAG Symbols" then all text has this font and the symbols are visible. This is good.

    When I change the font of the default style to "WAG Symbols", select again all text and apply the new default style then only the non-PUA characters are changed to the new font and the PUA characters have the font "Calibri". This is really bad.

    The same behavior occurs in my plug-in. The range.font.name property only affects non-PUA characters and the font of PUA characters is set to "Calibri". The whole purpose of my plug-in is to let users insert single PUA characters much like there are plug-ins for inserting emoticons, so this is a let down.

        function insert_gs_symbol(symbol) {
            Word.run(function (context) {
                var range = context.document.getSelection();
    
                range.insertText('symbol: \uE7D1', Word.InsertLocation.end);
                range.font.name = "WAG Symbols";
                range.font.bold = true;
                range.select('End');
    
                return context.sync();
            })
                .catch(errorHandler);
        }
    

    The result of the above code is that "symbol: " has the "WAG Symbols" font and the "\uE7D1" has the "Calibri" font. The only way now to set the font to "WAG Symbols" is by doing it manually. This is how it does look:

    This is how it should look (I manually changed the font to get this result):

    Surprise: while typing this post, I discovered that the bad behavior does not apply for unicode character \uEA53. That symbol is inserted and receives the "WAG Symbols" font.

    How can I get ALL my PUA symbols in the correct font using the javascript api?

    Tom.

    Thursday, April 20, 2017 3:19 PM

Answers

  • Did some trial-and-error and the conclusion so far is: let the font pretend that it supports code page 950 (Traditional Chinese) and then font substitution does no longer happen. To be clear: My font does not contain traditional Chinese characters!

    • Marked as answer by Tom VH Friday, November 3, 2017 7:26 PM
    Friday, April 21, 2017 1:42 PM

All replies

  • >> When I change the font of the default style to "WAG Symbols", select again all text and apply the new default style then only the non-PUA characters are changed to the new font and the PUA characters have the font "Calibri". This is really bad.

    Based on your description, it seems you create a font, and set the font manually, is this issue caused by any add-in? I would suggest you disable all the Word Add-in to check whether this issue still exist.

    >> The same behavior occurs in my plug-in.

    If this issue occurs without add-in, I think it will occur in add-in. This is normal result. Word Add In could not change the built-in behavior.

    >>This is how it should look (I manually changed the font to get this result):

    What is your manually operation?


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Friday, April 21, 2017 5:20 AM
  • Hi, thank you for your reply.

    With manually operation I mean using the mouse or keyboard to select the text in the document and then select "WAG Symbols" on the Home tab.

    Using the old VSTO classes, did not work (see Font does not change when Range.Text contains Unicode private use area (PUA) characters) and that was in 2010.

    The same behavior exists with the javascript api classes.

    And apparently - as I only discovered yesterday - the Word styles have the exact same problem (they substitute the font "WAG Symbols" with "Calibri") when the style is applied to one of the PUA characters. This font substitution is already visible in the preview of the style editor.

    I am convinced that Microsoft has built custom logic that kicks in whenever characters from certain ranges in the PUA appear in the document. I don't think this special treatment is documented in a public document, so it is difficult for me to find a way to make this simple task (setting a font on a character) work.

    Today I was trying to influence this hidden Word custom logic and I thought that settings in the font file might play a role. I am still experimenting so I have no definitive conclusions, but I managed to get the plug-in do what I expect: change the font of all PUA characters to "WAG Symbols". I will come back to this forum to post what exactly needed to be changed in the font to get it to work. It has to do with the list of code pages that the font supports. It still would be valuable if Microsoft could tell me right away what settings in the font play a role. I also noticed that changing the font properties affected the way Windows treats the font, because suddenly in the font preview window I saw that my font lacked the'normal space' character because it was showing my 'missing glyph' character where before a space was displayed (the quick brown ...) meaning that Windows also did some font substitution, in this case for the space character.

    To be continued ...

    Friday, April 21, 2017 8:03 AM
  • Did some trial-and-error and the conclusion so far is: let the font pretend that it supports code page 950 (Traditional Chinese) and then font substitution does no longer happen. To be clear: My font does not contain traditional Chinese characters!

    • Marked as answer by Tom VH Friday, November 3, 2017 7:26 PM
    Friday, April 21, 2017 1:42 PM
  • Probably not very useful but from a very long time ago the Windows "logical" font selection algorithm penalised "wrong character set" more than anything else. (see for example Table 1 in https://msdn.microsoft.com/en-us/library/ms969909.aspx ). Whether any of that stuff is still current I don't know. Even at the time I thought it was bizarre that Windows would favour charset over an explicit typeface choice, especially if that typeface was available, but I guess I never really understood it.

    Peter Jamieson

    Saturday, April 22, 2017 5:00 AM