A few days ago when I put up the post Is this the Über-font post? No, but it is the teaser for it!, I did sort of promise that I'd deliver on a post explaining about the issues related to fonts on Windows that plague so many application developers, whether they are working on the Windows team, inside of Microsoft, or in the wider world....

Well, today is the first part of that!

To start with, I'll say that DEFAULT_GUI_FONT, MS Shell Dlg, and MS Shell Dlg 2 have one elemental goal in common -- at various times in the life of Windows they were implemented to help give a consistent look and feel to Windows applications running in the Windows Shell.

Now the Windows Shell has some pretty specific, historical characteristics that are relevant here -- like the fact that pretty much all of the UI in Windows (prior to LIPs at least!) would be in a single language. And with a single language kind of makes sense to be trying to use a single font, right? This whole functionality can be thought of as being user interface language based.

Okay, so this functionality is potentially very useful for stuff in the Windows Shell, from control panel applets to the Start menu and so on. But applications like Media Player, MS Office applications, Visual Studio, or other apps inside of Microsoft tend to follow their own look and feel. Which means that in many cases none of those "Shell" fonts are the best choice for these other applications (especially if the list of UI languages they support is different, since it means there is a real possibility that the languages being covered may not be compatible.

What is worse, everything outside of Microsoft has the same issues, but even more so -- because with the possible exception of Shell add-ins, they are even less likely to have a need or even a desire to have a completely consistent language, look and feel with Windows.

The other problem that came up over time is that no one wanted to modify these fonts or their definitions over time, and between versions. Because there would be subtle differences in the metrics when comparing Microsoft Sans Serif to Tahoma to Segoe UI to MS Sans Serif and so on. And that means that if you change the definition of the undrlying font technology used by the Shell that dialogs might start clipping text or looking inorrect.

Which sort of explains why there is no brand new MS Shell Dlg 3 that would support the new Segoe UI. Because after multiple versions of realizing how bad it would be, it has been, and it is to change the definitions of these built-in special fonts, and since the hit to developers of changing to use a different special font for each platform version is roughly equivalent to them having to change to a normal font for each platform version, there really is very little point to having a new MS Shell Dlg # in each new version of Windows that is unknown to prior versions.

Especially when applications whose font changes yet no UI review is done may look really awful in the untested font.

In practice, this affects not only the external customer applications and not only the non-Windows apps in Microsoft, but even applications in Windows do not tend to update their fonts universally to the new version. Which is the main reason that Chris Pirillo can find so much inconsistent font usage in posts of his like Windows Vista Feedback. I know some may consider it nitpicky, but I think Chris has provided the ultimate proof that the current scheme does not even handle the limited scenario of the consistent UI in the Windows Shell all that effectively. So how could it ever hope to help everyone else?

Now while the Shell folks were working on providing a way for Windows Shell applications (which as the above indicates has many flaws, by the way!), the folks in Microsoft Typography and on the GDI/Uniscribe text services teams were working hard to solve a very different problem -- how to make sure that whatever font was chosen for controls, that text would be displayable.

Such a functionality could not be tied to only the UI language; it would need to be able to support languages/scripts outside the narrow scope of the UI language if Windows language support was going to be truly international. Though of course there are problems with these solutions as well, which will be the subject of a future post....

 

This post brought to you by ༃ (U+0f03, a.k.a. TIBETAN MARK GTER YIG MGO -UM TSHEG MA)