Why the Windows Shell can't provide the ultimate font solution for everyone (or even anyone!)

by Michael S. Kaplan, published on 2006/06/11 05:45 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/11/626100.aspx

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....

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)

"But applications like Media Player, MS Office applications, Visual Studio, or other apps inside of Microsoft tend to follow their own look and feel."

Why? If I want my UI to use MS Comic Sans all over, applications should respect that. What's the point in having a customisable UI if no-one's going to respect the settings? Very few applications should be picking specific fonts at all, and all that do should *only* be doing so in their client areas (e.g. Word picking document fonts, Explorer picking document fonts, etc...)

"What is worse, everything outside of Microsoft has the same issues, but even more so [...]"

So? Lead by example. Oh, wait a minute - that would require MS to follow their own UI guidelines and not reinvent their own menu bars, etc..., for each application first.

"The [problem] is that no one wanted to modify these fonts [because] there would be subtle differences in the metrics when comparing [them]. [If] you change the [underlying font then] dialogs might start clipping text or looking inorrect. [...] The folks in Microsoft Typography and on the GDI/Uniscribe text services teams [are working hard] to make sure that whatever font was chosen for controls, that text would be displayable."

Right. And how is that not entirely due to Windows' pixel-based layout engine?

I'll agree that all the problems you've mentioned are very visibly triggered by changing fonts/text/sizes as part of the l10n process, but I don't see how that can be considered the _cause_. If controls dynamically changed their size based on their content (including fonts) then none of these problems would exist.

I'm looking forward to the next post in this series though...

Hi Adam --

Applications are not always about taking on the user's 'skin' preferences. If you do not like their look, then you don't have to use that application. But it isn ot a requirement that people follow those settings.

We will have to agree to disagree on the other issue, as what you claim is not entirely true (the Windows dialog unit scheme is not a completely pixel-based layout, and it is not always reasonable to assume applications want to be as dynamic a you imply).

But I will be covering these issues soon. These first two posts are explaining why certain "solutions" are not the answer. Stay tuned. :-)

The problem with automatically resizing controls is that you can't get it to be "pixel perfect" - it's always just going to be a sort of "approximately right" (except when displayed with exactly the same settings as the original designer, hopefully).

Which may or may not be better than having text clipped or not sized properly, depending on the situation.

But do believe that it is the way to go. Especially in these days of high-resolution displays. The chances that a dialog will be displayed at exactly the same size as the original designer's is getting smaller anyway (for example, you might design your application at 96 DPI but display it on a 144 DPI display). While it may be practical to review/re-layout your dialogs for each supported OS version (and possibly also for each OS version + language supported, but even then you're moving into the realms of you-must-be-a-large-company-with-lots-of-designers-to-be-able-to-write-good-looking-apps) but it's impossible to expect anyone to review their dialog layouts on all OS versions, all languages AND all possible DPI-settings (simply because there's an infinite number of DPI settings).

So if you need some sort of dynamic resizing for high-DPI displays, then it seems to make sense to extend that for different fonts as well.

Which is why I'm welcoming Avalon/WPF. I don't know if it handles resizing based on what font is being used (though I hope it does) it certainly automatically handles the high-DPI issue well.

As much as I appreciate everyone's efforts to continue to steer things off topic, I would love it if (at this point) everyone thinking about layout controls could simply bite their tongue for the moment. It will be much easier to steer through this complex topic if we can keep the issues of each topic where they belong so we can focus things a bit.....

This post and the one that followed it are about the attempts at "Shell" font solutions and why they do not work.

In future posts I will be talking about the solutions in GDI and Uniscribe.

And then I will talk about Avalon (WPF) and composite fonts -- both the good and the bad. At that point I will talk about some of the general features and also some of problems with other solutions involving dynamic layouts....

This would be a great point to bring up the great feelings everyone has about this type of solution -- rather than spreading their (obviously) strong feelings haphazardly across other posts that are not about dynamic layouts. :-)

So basically if my application is required to support all Windows version out there I must use one of the fonts avilable with Windows 95 (Microsoft Sans Serif most likely). If I want my application to fit in Vista I have two options:

1. Create multiple versions of my resources, one for each versions of Windows, with that version's fonts (Microsoft Sans Serif, Tahoma, Segoe UI) and then load thr appropriate one. This would get harder if my application creates fonts of the fly (not that it should).

2. Tell all my users to upgrade to Vista or replace me.

Am I missing something here? Maybe we should all just follow what Microsoft is doing with their applications and completely disregard all UI recomendations and just develop our own UI. I mean, Office has been doing it ever since I have been using Office. Why does Windows even have UI API? Not even Microsoft is using it.

Hi Jerry --

It really is a problem, one that (if there were a setting that was documeneted as changing with each version) you would have to test in each version to avoid clipping, each time. Since no one likes that idea, moving to a new font has to be a conscious choice that does involve reviewing the results -- or it has to be an explicit decision to pick the font you want....

I do agree with the set of problems that shell font substitution comes with. What I was wondering is how do you actually write an application that follows the look of the platform it runs on. Looks to me that creating separate resources for each known platform seems to be the only option. And at that point it's probably just easier to do what Office has been doing - ignore the platform's look and feel and use your own. Which makes a mockery of Microsoft's published UI guidelines (not necessarily a bad thing).