http://bugs.winehq.org/show_bug.cgi?id=18044
Summary: System Font Linking fails with MS Shell Dlg Product: Wine Version: 1.1.19 Platform: All OS/Version: All Status: UNCONFIRMED Severity: trivial Priority: P2 Component: gdi32 AssignedTo: wine-bugs@winehq.org ReportedBy: Paul.Hampson@Pobox.com
If MS Shell Dlg (or presumably any other font named in HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes is used to render text, the system font linking support provided by HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink fails.
What happens is that the substitution list in SystemLink is stored by real font name, such that putting an entry for MS Shell Dlg in that list will actually store an entry in the system_links list (in gdi32/freetype.c) for the font that points to (Tahoma under en-US codepage). This means it is possible to have two entrys for one real font in this list, as it happens.
However, when create_child_font_list (also in gdi32/freetype.c) goes searching for entries in system_links, it searches by virtual name (ie MS Shell Dlg if that is what the program asked for) and so fails to find any matches.
This causes get_glyph_index_linked to not have any children to search, and hence return FALSE, causing the glyphs in question to be replaced with glyph 0.
This affects uTorrent 1.8. uTorrent 1.7 used Tahoma as its GUI font, so simply enabling SystemLink for Tahoma (as per bug 10864 comment 4) would allow non-local-codepage characters to display correctly. Under uTorrent 1.8 however, this fails.
It looks to me like the problem is that create_child_font_list should be searching the system_links list by real font name, not virtual font name, for best consistency with Windows.