What about logical fonts?
by Michael S. Kaplan, published on 2006/03/18 05:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/03/18/554308.aspx
I have talked in this blog about a lot of different kind of font mapping features in various Microsoft technologies.
Like Windows Font Substitution.
And GDI's Font Linking.
And MLang's Font Linking.
And Uniscribe's Font Fallback.
And GDI/GDI+ Private Fonts.
This post is going to be about something else though. I am going to talk about logical fonts, specifically MS Shell Dlg and MS Shell Dlg 2, which are documednted in this Platform SDK post.
There are many important details documented there, for example:
- Neither of these is a physical font: instead, each Windows machine maps both MS Shell Dlg and MS Shell Dlg 2 to an appropriate physical font, based on the computer's Language for non-Unicode programs, which is set either at install time or with the Control Panel item Regional and Language Options.
- The actual mappings are stored in the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\FontSubstitutes.
- These logical fonts allow your application to implement dialog boxes, menus, etc., that will display well on all supported Windows operating systems and across all languages. For example, if your application uses MS Shell Dlg or MS Shell Dlg 2 for its dialog boxes, then a localization team creating Greek-language resources for your application can focus on translating text, instead of being concerned with issues like the distinction between MS Sans Serif and MS Sans Serif Greek.
- MS Shell Dlg supports the "classic" Windows desktop look; MS Shell Dlg 2 supports the look that was introduced with Windows 2000.
- On Windows NT 4.0/2000/XP/Server 2003/Vista, both map to Unicode-based TrueType fonts. MS Shell Dlg uses Microsoft Sans Serif (which is distinct from MS Sans Serif) for Latin, Greek, Cyrillic, Arabic, Hebrew, and Thai characters; MS UI Gothic for Japanese; Gulim for Korean; Simsun for Simplified Chinese; PMinglu for Traditional Chinese; etc.
- MS Shell Dlg 2 simply uses the Tahoma font: characters that are not implemented in Tahoma are available through font linking.
- The main advantage of Tahoma over Microsoft Sans Serif is that Tahoma has a native bold font face.
- Its main disadvantage is that older operating systems (Windows 95/98/Me, Windows NT 4.0) may not have it installed, and may substitute a font that does not look as good.
And there are some really important points that are easy to miss:
- Because the font generated using MS Shell Dlg is different on different versions of Windows, you should check that the dialog box looks good on all versions.
- Applications that never intend to run on Windows 95/98/Me can simply use either Microsoft Sans Serif or Tahoma explicitly, and save the level of indirection involved in using MS Shell Dlg or MS Shell Dlg 2. Because of font linking, specifying Microsoft Sans Serif or Tahoma will give you appropriate glyphs for all languages.
The other interesting point is the way the mapping is documented as being one that will be different on other versions of Windows.
Especially since the font mappings underneath are not guaranteed to stay the same.
Add to that the fact that different ways to use them can cause different results, as Raymond pointed out in What's the deal with the DS_SHELLFONT flag?
And then it ends by reminding people that these two logical fonts, which are based in part on the default system locale, are not always the best choice for UI fonts when the system locale changes (since it is the UI language that covers the content language for Windows, any scenario that mixes different combinations of system locale and UI language may end up with unexpected results).
(This is also covered in the MSKB, article 282187 -- an article which highlights the difference between PSS and core development teams, as the latter would never say "You can manually change the font mapping if a single font will suit the needs of both the computer dialogs and the localized programs that are having display problems.")
Another good source of info is this page, which talks mopre about what is easy and what is hard (look at the section on Fonts specifically, for help here in development).
In summary, on the whole, unless you are either
- building a UI component that ships in the Windows box, or
- creating other content that matches the UI language and you do not mind testing the wide array of possible settings and the way they will vary your content
you should probably at least consider using a font other than MS Shell Dlg/MS Shell Dlg 2....
This post brought to you by "‰" (U+2030, a.k.a. PER MILLE SIGN)
# bg on 18 Mar 2006 10:10 AM:
Thats interesting. Some thing to think about.
Thanks.
# Michael Dunn_ on 19 Mar 2006 2:50 AM:
I've always used MS Shell Dlg, mostly because I still support 98/Me, but I also thought MS Shell Dlg was for future-proofing. If I write an app today that has Tahoma in the dialog resources, it will have Tahoma in Longhorn and thus look dated. If I use MS Shell Dlg today, it will have Segoe UI in Longhorn too and fit right in.
# Mihai on 19 Mar 2006 4:43 PM:
Not really related to MS Shell Dlg and MS Shell Dlg 2, but has something to do with logical fonts.
There is no standard way (logical font?) to honor the setting that the user does in "Advanced Appearance" (from "Display properties" dialog, "Appearance" tab, "Advanced" button).
In the resulting dialog change fonts to something visibly different (like a a cursive script, ex "Freestyle Script")
Most of the applications (including MS ones) could not care less.
The only way I know to do the right thing is treat WM_INITDIALOG , call SystemParametersInfo with SPI_GETNONCLIENTMETRICS, get the right font and use it to set the font.
Not internationalization, I know, but I find it rude offering the user a way to set something, then ignoring it completely. Plus, is not about setting fancy fonts, is also about accessibility (if I set a bigger font size).
Maybe a logical font is the answer?
And maybe having that as default font in the dialogs created by Visual Studio?
# Michael S. Kaplan on 19 Mar 2006 6:22 PM:
Hi Mihai,
I do not know of many cases that this setting is not respected, so I am not sure where precisely the bug is here. But virtual fonts have nothing to do with this (an app can ignore a virtual font as readily as an actual one), so this may be a better one for the suggestion box....
# Michael S. Kaplan on 19 Mar 2006 7:06 PM:
Hi Mike --
I am not sure I fully understand what you mean here -- the docs are not too terribly specific about what happens between versions just yet, so I'm not sure that any part of using these font names is future proofing anything....
# PatriotB on 19 Mar 2006 8:47 PM:
Mike -- MS Shell Dlg/2 *won't* map to Segoe UI.
I remember asking about this a while back on the MSDN Forums; here's an excerprt from the reply from Microsoft's Jeff Pettiross:
"Regarding MS Shell Dlg, it was a good idea at the time, but it's also time to retire it. When it was introduced (and followed with MS Shell Dlg 2, and further tricks to support that), we had three font faces with very similar metrics (character sizes and shapes) at 8 points: MS Sans Serif, Microsoft Sans Serif, and Tahoma. Allowing a meta-name like MS Shell Dlg meant that someone could release an application that would look as good as possible on multiple versions of Windows. This solution works as long as you don't change the font's metrics. There are only so many ways you can make a new font by rearranging pixels in the same size rectangles, and we wanted to break out of those rectangles with Segoe UI.
If we tried to extend to MS Shell Dlg 3 (or whatever), long-standing dialog templates would have broken because Segoe UI has different metrics than the other three fonts. So, we will make Segoe UI available for redistribution with applications and applications can look the same regardless of Windows version. (It's slighly different from MS Shell Dlg, where dialogs would have the same layout, but different font faces across versions.)"
[
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=205554&SiteID=1]
An additional complicating factor is that the Vista guidelines say to use Segoe UI at *9* point font rather than 8.
Of course, what the official MSDN docs (and this blog posting) seem to say, is that MS Shell Dlg's purpose was just to support internationalization, and that it wasn't meant to be a way to have dialog boxes take on their OS's preferred font--though that was a side effect.
# Michael S. Kaplan on 19 Mar 2006 8:57 PM:
FWIW, the final figuring out of licensing and other considerations has NOT been figured out, so most of what Jeff said is at best one possibility; the final plan has not been figured out yet.
I had not really moved into the world of hypothesizing about MS Shell Dlg ##, as there are significant issues in that approach, only some of which Jeff mentions....
# Mihai on 20 Mar 2006 12:49 PM:
<<I do not know of many cases that this setting is not respected, so I am not sure where precisely the bug is here.>>
Do you know of any case that this setting IS respected?
http://www.mihai-nita.net/mix/Fonts.gif
Oups, yes, Firefox :-)
# Michael S. Kaplan on 20 Mar 2006 1:07 PM:
Like I said, Mihai -- I would suggest putting more actual details in and getting it in the suggestion box.
# Patrick on 7 Nov 2007 12:28 PM:
Hi Mike,
You say that,
"On Windows NT 4.0/2000/XP/Server 2003/Vista, both map to Unicode-based TrueType fonts. MS Shell Dlg uses Microsoft Sans Serif (which is distinct from MS Sans Serif) for Latin, Greek, Cyrillic, Arabic, Hebrew, and Thai characters; MS UI Gothic for Japanese; Gulim for Korean; Simsun for Simplified Chinese; PMinglu for Traditional Chinese; etc."
Yet when I look at the
key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\FontSubstitutes on a Chinese XP SP2 or Win 2003 R2 SP1, I see that for Chinese these reference MS San Serif and Tahoma not Simsun or PMinglu.
Am I missing something?
Thanks,
Patrick.
Roman on 2 Aug 2009 12:43 PM:
This is a bit old but...
Michael, you said:
>I do not know of many cases that this setting ["Advanced Appearance"] is not respected
But you are explicitly recommending something that completely ignores this setting: "[...] simply use either Microsoft Sans Serif or Tahoma explicitly".
Seems like it isn't exactly easy to always do this propertly due to the amount of history, but for .NET apps at least one can use SystemFonts.MessageBoxFont (NOT DefaultFont) to respect this setting.
Michael S. Kaplan on 3 Aug 2009 2:23 AM:
The MessageBox font is a user changeable one, which can mean a very negative impact on UI if the user changes an unrelated setting -- not a good experience for an application to provide!
Please consider a
donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
referenced by
go to newer or older post, or back to index or month or day