Font substitution and linking #1

by Michael S. Kaplan, published on 2005/03/20 08:35 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx


Ok, there will be several posts on this topic, starting from the core support in GDI/Windows and moving concentrically outward to information on usage in Uniscribe, MLang, and Office.

I'll start with font substitution.

At the simplest level, this feature is what it sounds like -- simple substitution of one font name with another.

It starts with a registry key (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes). In Windows Server 2003 that key contains the following:

"Arial Baltic,186"="Arial,186"
"Arial CE,238"="Arial,238"
"Arial CYR,204"="Arial,204"
"Arial Greek,161"="Arial,161"
"Arial TUR,162"="Arial,162"
"Courier New Baltic,186"="Courier New,186"
"Courier New CE,238"="Courier New,238"
"Courier New CYR,204"="Courier New,204"
"Courier New Greek,161"="Courier New,161"
"Courier New TUR,162"="Courier New,162"
"Times New Roman Baltic,186"="Times New Roman,186"
"Times New Roman CE,238"="Times New Roman,238"
"Times New Roman CYR,204"="Times New Roman,204"
"Times New Roman Greek,161"="Times New Roman,161"
"Times New Roman TUR,162"="Times New Roman,162"
"Helv"="MS Sans Serif"
"Helvetica"="Arial"
"Times"="Times New Roman"
"Tms Rmn"="MS Serif"

"MS Shell Dlg"="Microsoft Sans Serif"
"MS Shell Dlg 2"="Tahoma"

These entries can be put into three categories (which are color-coded above):

BLACK - these are entries that were formerly used by many applications to combine font family (name) choice with font character set choice (basically the lfFaceName and lfCharSet members of the LOGFONT struct). I'll talk more about lfCharSet and what it used to do (and sometimes still does) another day. But in any case these names are not really used much anymore. When they are used in applications, their presence in the FontSubstitutes subkey makes them work properly.

GREEN - these entries allow some common abbreviated names to work. Their usage is self-explanatory.

BLUE - these entries are the ones behind the huge effort to support MS Shell Dlg as a UI font name (also described here and in article 282187 in the knowledge base). In fact, these two entries are the only ones that can be considered useful for more than just backward compatibility with no longer used methodologies. Raymond Chen also has good advice about getting the right font used via DS_SHELLFONT in the articles What's the deal with the DS_SHELLFONT flag? and What other effects does DS_SHELLFONT have on property sheet pages? for those who are interested.

Of course it seems odd that MS Shell Dlg, documented as a version independent, language independent pseudo-font name seems to be hard coded to use fonts that do not support all languages. Wasn't it designed to get people away from hard-coding Tahoma or Microsoft Sans Serif? And the answer is yes -- it was. Luckily those font names are affected by a different font mapping technology, font linking, which I will describe in a future post in this series....

There is another kind of font substitution that is occasionally seen in documentation, which relates to printer drivers and what they do to substitute fonts built into printer hardware when thay can. My personal belief (with my admitted bias towards good international functionality) is that it is important to not use this feature since even printer fonts that accurately handle the basic glyphs seldom have the  full support for all scripts (not to mention complex scripts!). In fact, one of the first things I do with each new version of Word is find out how to set the Print TrueType Fonts as Graphics setting that allow what is on the screen to be what gets printed rather than using device fonts....

 

This post brought to you by "ڜ" (U+069c, a.k.a. ARABIC LETTER SEEN WITH THREE DOTS BELOW AND THREE DOTS ABOVE)
A character not seen in most device fonts!


# Mike Dunn on 20 Mar 2005 8:27 AM:

One thing that wasn't too clear in the docs about MS Shell Dlg (the last time I looked) is the distinction between using "MS Shell Dlg" in a DIALOG resource and a LOGFONT. On a default setup of English 2K or XP, using it in a DIALOG gets you Tahoma, whereas using it as the face name in a LOGFONT gets you MS Sans Serif.

Until I learned of the reg entries you described here (which was only recently), I never understood this behavior:
* Get a dialog's font with WM_GETFONT and look at the LOGFONT.
* The lfFaceName member is "MS Shell Dlg" as expected, and the font on the screen is Tahoma.
* Create a new font from that LOGFONT and use it to draw some text, and the text will be in MS Sans Serif.

You can also replace the first step with GetStockObject(DEFAULT_GUI_FONT).

So not only is "MS Shell Dlg" replaced with something else, the something else can vary depending on where it's being used. What I do now is, on 2K+, if I have a LOGFONT and the face name is "MS Shell Dlg" I change it to "MS Shell Dlg 2". Is that kosher, or will that conflict with some other font magic the system does?

# Michael Kaplan on 20 Mar 2005 10:03 AM:

I thought none of them gave MS Sans Serif (a bitmap font); they all gave Microsoft Sans Serif (an unfortunately named font that most believe give superios glyphs for Arabic script to Tahoma and others).

It is never a problem to change which is used (though beware the points Raymone Chen makes about what such changes can do in order to avoid unintentionally messing things up).

# Mike Dunn on 20 Mar 2005 12:44 PM:

I didn't look to see if the actual font was MS Sans Serif or Microsoft Sans Serif. I meant to say that the text looks like MS Sans Serif, which is the part I cared about since I wanted Tahoma.

# Eric on 21 Mar 2005 6:33 AM:

"In fact, one of the first things I do with each new version of Word is find out how to set the Print TrueType Fonts as Graphics setting that allow what is on the screen to be what gets printed rather than using device fonts...."

Is there a drawback to this (slower printing, perhaps)?

# Michael Kaplan on 21 Mar 2005 6:45 AM:

Indeed, Eric. But the loss of WYSIWYG is obviously worth some perf to get back, and for those of us who lose not only WYSIWYG but even basic character fidelity, there is no question which is better. :-)

# Michael Kaplan on 21 Mar 2005 7:52 AM:

Mike -- there are other Raymond Chen links that help make this topic and the behavior make more sense: http://blogs.msdn.com/oldnewthing/archive/2005/02/07/368423.aspx (Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?) and http://blogs.msdn.com/oldnewthing/archive/2005/02/08/369090.aspx (What other effects does DS_SHELLFONT have on property sheet pages?).

The eventual meanings of the flags can get quite convoluted at times....

# Mike Dimmick on 21 Mar 2005 10:38 AM:

Actually I think your green entries are for Windows 3.0 compatibility. "Helv" and "Tms Rmn" were renamed to MS Sans Serif and MS Serif for Windows 3.1, IIRC.

# Michael Kaplan on 21 Mar 2005 8:48 PM:

Well, that is scary for all kinds of reasons. :-)

# Aidan Corey on 7 Apr 2005 6:16 AM:

"for those of us who lose not only WYSIWYG but even basic character fidelity, there is no question which is better. :-)"

Sometimes a device font is essential for fidelity. Label printers often have barcode fonts. A TrueType barcode may have bars with irregular widths if they don't line up with the printer pixels (a thermal label printer might only be 200dpi).

Another example is a control font for sending commands like "activate label cutter".

Unfortunately the .NET Framework doesn't seem to provide any support for device fonts. So my question is: is there a way to make use of the printer font substitution you refer to above?

# Michael S. Kaplan on 7 Apr 2005 6:51 AM:

Unfortunately, GDI+ can only work with TrueType/OpenType fonts; it cannot work with bitmap or device fonts....

# Jai on 9 May 2005 7:49 AM:

You have said u will put light on certain other topics in this post. I hope that one comes soon. Waiting for it to come. Is it possible to put some light on how the font substitution works internally ??

referenced by

2012/01/26 If font linking doesn't fit the text to a T (or ț!), a Romanian letter may be right but not quite look it

2010/07/12 Making a font fetish a bit more mainstream

2007/08/18 You look so familiar; I think you're my type....

2007/07/11 Any sufficiently confusing technology is indistinguishable from magic

2007/06/09 Guilt by [font ]association (aka The consequences of picking the wrong font #3)

2006/06/06 Is this the Über-font post? No, but it is the teaser for it!

2006/05/05 UI language of the LocalSystem account (which almost never shows UI)

2006/03/18 What about logical fonts?

2006/01/22 Questions about font linking, etc.

2005/06/18 Font substitution and linking #3

2005/05/16 Font substitution and linking #2

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