by Michael S. Kaplan, published on 2008/07/11 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/11/8720555.aspx
Previous blogs in this series:
So far in this series I have glossed over the actual installation and uninstallation tasks that have to happen.
This blog will talk about the installation half.
Basically there are two main groups of steps:
First of all, the font has to be placed in a nice shared location everyone/thing else on the machine can get to, and an AddFontResource function call has to be made on the font so that the font is available to everyone, and the WM_FONTCHANGE message should be sent around so that others within the session will know about it.
This takes care of the HERE and NOW.
For the moment we will ignore all the problems I talked about related to replacing existing fonts in Part 2 and with folks running on the machine outside the scope of the current session and security level that made up so much of Part 3. We'll talk more about them later.
Second of all, the font has to be listed in the appropriate registry key so that future sessions can pick up the font. The system will then call AddFontResource for all of sessions created in the future and they will all wok and everyone can be happy and joyful.
This takes care of the EVERYWHERE and LATER.
The registry location is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
on NT-based platforms, and
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts
on Win9x-based ones.
And a pox on the crops of whoever decided to make these two keys different. :-)
Once upon a time, the best practices for what to put in the registry was something like this:
The registry key will look like this for Arial Bold “Arial Bold (TrueType) = arialbd.ttf’. In the font, the face and style may be localized and that localized name is what should be used on a system with that given locale. When determining what string to use the setup program should look at the locale id of the system was localized to. The system function to get the system locale and user locale are changeable on a system. The actual locale stamped into gdi32.dll or another system component should be used to determine what language name string to use.
Though of course the issues of localized font names are much simpler now, as I mentioned in blogs like East Asian Font Names and Getting all of the localized names of a font and Is Font.FontFamily localized? and Getting all of the localized names of a font[.NET]. You no longer have to care as much about the name you put in the registry, as GDI now does the extra work to register multiple versions of the font under he different language names in the fonts themselves.
At this point, starting with Windows 2000, the name in the registry is not nearly as important as just having the font file name in there correctly.
Remember this point, we are going to talk about this later when we start looking into solutions in future blogs in this series....
Anyway, install that simple.
To the extent that the above is simple?
It certainly seems much less troubling than earlier parts of the series!
This blog brought to you by Ѳ (U+0472, aka CYRILLIC CAPITAL LETTER FITA)
referenced by