It was déjà vu all over again, this time in quite an oymoronic way

by Michael S. Kaplan, published on 2007/03/24 18:08 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/24/1943944.aspx

It was just the other day that I got the message via the contact link:

Michael,

Hi.

I'm a Neurologist in Dallas, TX, and a computer person.

My Internet Explorer 6 (running on Win98) suddenly started using a strange font where the html page coding was PRE{font-family:sans-serif} Text between <PRE> </PRE> was coming out in Noam New Hebrew (file name is _AE4B263.TTF) instead of Arial.

Interestingly, that became the default font for Write 3.1 (old 16 bit Windows 3.1 word processor). As I understand it, IE picks the generic CSS fonts such as serif, sans-serif, etc., and gives you no direct control over which it chooses.

I followed some advise on the internet to:

1. shut down IE
2. uninstall the font from Control Panel (made a copy of the file in another directory)
3. re-start IE and confirmed it has switched to another font (in this case Temp Installer Font, almost as bad)
4. cold boot to make change permanent
5. re-install Noam New Hebrew

Now IE6 and write3.1 use Temp Installer Font

Where is the info kept on what is the system's generic font.

I tracked changes and couldn't find it in the registry, nor ini files. The changes of deleting the ttf file just show in c:\WINDOWS\FONTS\ and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Fonts

I'd like to be able to manually tell it Arial.

It must be a true system object since write3.1 picked it up.

An interesting problem, and not just because I knew what was behind about half of what our neurologist was running into and had a strong hunch about the other half. :-)

First, the half that I knew about....

It is never really fully understood by many people how font selection works on Windows. The truth is that whether one is a programmer calling CreateFont or CreateFontIndirect or CreateFontIndirectEx or the GDI+ System.Drawing.Font class or the WPF/Avalon System.Windows.Medua.FontFamily class or someone font face authoring a web page or even someone using the Shell Font Picker common dialog, the truth is that when pick a font, you are not really picking a font.

What you are actually doing is picking some descriptive attributes that will describe something that the system will try to map to a font.

Now sometimes you can't tell the difference. Like when the descriptive attributes are so specific that you end up right on the money.

And other times, not so much. Like this time.

When you give a generic description for a font, then the first one that the system believes is a good enough match will be the one that you get.

Which kind of leads us to the other half. The half relating to the post from earlier today.

Not since the events of It was déjà vu, man. Pure déjà vu... has the feeling of having been there before been so strong.

You see, the various duplicated font caches built up by the various technologies build up their data from the font list in the registry -- a font list that is read in via an order that is subject to the same less-than-intuitive registry value ordering logic that I was talking about yesterday.

This allows for reasonably deterministic behavior in font selection on a given machine, behavior that is subject to the fonts one adds and removes from the font folder, of course. :-)

As a side point, there are currently only two ways to get the actual order that is in the registry that will be used by the system when looking for fonts:

1. Get it programmatically via a series of RegEnumValue calls
2. Export the registry key in question to text -- the values will be in that same order.

If you try to do this with HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts, then you will see an important change between prior versions of Windows and Vista. And by important I don't mean intentional or feature-filled, I mean significantly different. In a way that can really impact font selection in the new operating system.

As I mentioned, the change was not intentional, it just has to do with the way that the new setup in Vista accomplishes its goals via the installation of different components, and the fact that the ordering of font components was not done with the impact that the order can have in mind. I suspect there may yet be a bug or two reported by customers due to side effects from this change....

So now we know why the behavior is consistent and why it can easily be changed by removing and adding fonts and why adding a font back after removing it does not mean that you will always get back the same behavior. And why you may end up with odd choices if you have been doing a lot of adding and/or removing of fonts.

So now let's look at the last bit and try to explain the actual behavior....

Let's start by taking a closer look at what was being requested in this case.

The PRE Element in HTML is defined quite clearly -- it Renders text in a fixed-width font. Which is clearly something that Arial is not.

The only possible way to get Arial to be selected when a fixed width font is requested is when every better possible choice is unavailable....

So to be honest, if one is looking for Arial, then the PRE Element is the wrong thing to be use anyway. Although other aspects of the element are what often lead people to want to use it, such as the way the text is directly rendered, including spaces which would otherwise be truncated. Which makes it unfortunate that the functionality of these two different attributes are combined into one element, but perhaps understandable why people might want to try....

This post brought to you by й (U+0439, a.k.a. CYRILLIC SMALL LETTER SHORT I)

Björn on 25 Mar 2007 12:02 PM:

go to newer or older post, or back to index or month or day