Let me start out by saying that I am not sure if this is a common issue, or a rare issue. My current workstation has been upgraded from Windows 7 > 8 > 8.1 > 10 and I have had a some strange issues crop up, so there is a good chance this problem is somewhat unique. To summarize the problem:
Certain Unicode font glyphs were not showing up in certain programs, but displaying fine in others. An example would be that Chrome/Firefox worked fine, but MobaXTerm and Notepad++ did not. The issue was related to Windows Font Fallback and/or Font Linking.
The way the issue manifests itself is when you attempt to display Unicode characters that do not exist in the now selected font, they display as missing characters, either a ? or a box. The correct/desired functionality is for windows to fallback to another font which can display the missing glyphs based on a list of which fonts have the missing glyphs.
For example, when I was customizing my WeeChat configuration, using Notepad++ the glyphs I wanted to use were displaying as missing, a snippet of that configuration is below:
# Unicode characters for coolness
/set weechat.look.bar_more_down "▼"
/set weechat.look.bar_more_left "◀"
/set weechat.look.bar_more_right "▶"
/set weechat.look.bar_more_up "▲"
/set weechat.look.buffer_notify_default message
/set weechat.look.buffer_time_format "${color:252}%H:${color:245}%M:${color:240}%S"
/set weechat.look.item_buffer_filter "⚑"
/set weechat.look.prefix_action "⚡"
/set weechat.look.prefix_align_max 15
/set weechat.look.prefix_error "⚠"
/set weechat.look.prefix_join "→"
/set weechat.look.prefix_network "ℹ "
/set weechat.look.prefix_quit "←"
/set weechat.look.prefix_same_nick "⤷"
/set weechat.look.prefix_suffix "│"
/set weechat.look.read_marker_string "─"
/set buffers.look.indenting on
/set buffers.look.suffix_bufname " "
Many of the special glyphs in this snippet were not showing up in any of the usual mono space fonts on my system including: Consolas, Source Code Pro, Inconsolata, Deja Vu, but only in a few programs. If I viewed them in Firefox or Chrome, they showed up fine. Upon further investigation I figured out that the missing glyphs are not in the base mono space font, but are provided by the Segoe fonts on windows, specifically Segoe UI, Segou UI Symbol, Segoe UI Emoji, Segoe UI Historic, Segoe MDL2 Assets. Some programs would do this fallback, others would not.
A specific example of this issue, in Notepad++ can be found in this github issue.
It appears that perhaps some programs have built-in special ways to handle this situation, and others have not. In the programs which do not support this, you would think the OS would deal with it a bit better but unless my registry is messed up as noted in the first paragraph of this post, it seems that some manual workaround is needed.
The way I wound up resolving the issue was found in this article on Windows Globalization. Basically I defined registry entries for my mono space fonts and defined the linked fallbacks manually. The path to these keys in the registry is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
Within that part of the registry you create a new key of type Multi-String Value, the name of the key should be the name of the font as is found in the list of system fonts:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
Remove the font type from the name, for example “Consolas (True Type)” would become “Consolas”
Set the value of the key created to the list of fonts you want to use as fallback, in the order you want them to fallback, for example:
SEGOEUI.TTF,Segoe UI,110,82 SEGOEUI.TTF,Segoe UI SEGUISYM.TTF,Segoe UI Symbol SEGUIEMJ.TTF,Segoe UI Emoji SEGUIHIS.TTF,Segoe UI Historic SEGMDL2.TTF,Segoe MDL2 Assets
I have attached a .reg file you can use to create entries for Consolas, Source Code Pro, Deja Vu, and Inconsolata with Segoe fallbacks, use at your own risk!
RSS - Posts
Bit of an Update,I came across this very same problem which is still present on a windows 10 fresh install, I found your post via a google search on the subject, the solution to your problem is not the font linking scenario, which did not fix the problem for me, which i will tell you in a second why.
The problem has to do with the GDI+ rendering of fonts of the Edit Control in the windows system.
If you are not aware, the Edit Control, is a internal windows native system – API control (Window Class) which handles all text input in Windows,It’s Used and re-used for about every windows Text Box and Text rendering and editing native to windows, This includes the Windows Notepad and almost every Windows based application created with this Natively Inherent API, that is unless is a custom version where someone paid some real $$$$ to MS for the license to use and modified this crap.Any MS Visual C++ and Visual Basic Programmers know all about this crappy integration that has been around for 30 years(since win 3.1).The guys from Notepad ++ created there own control (Scintilla editor component), and so have many other people because of the bad integration and the limitations (PROBLEMS!).
Browsers like Chrome and Firefox are dependant on there own created text rendering platforms, so it doesn’t shock me that it worked there quite well.The solution is to avoid Using any application which relies on the Natively Crappy Windows Edit Control to Render Unicode fonts or Monospaced fonts.There are .Net applications that use a new type of customizable Edit Control exclusively to the .Net framework, but if the programs you are using does not work, it’s that nasty crappy 30 year old problem.
Microsoft itself gave up using the Edit Control for serious matters, when they created RichTexT, for the same reasons (PROBLEMS!).
Just change the font on Notepad++