by Michael S. Kaplan, published on 2007/04/01 13:24 -07:00, original URI: http://blogs.msdn.com/michkap/archive/2007/04/01/2007543.aspx
People often talk about the "GDI Font Cache" as if it were a real entity.
And those same people may explain how a call to AddFontResource will dynamically update the font cache, session wide.
Some of them may even how explain how the font list under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts isn't monitored for changes at runtime.
Most of this is crap, based on people not really looking at the bigger picture....
The truth is, GDI has nothing to do with the registry or the font folder or any direct use of these things. Ever. Not for drawing with fonts, not for enumerating them. not even for informing people of when they were added (the good old WM_FONTCHANGE message).
All it knows is what people ask it to load (whether via AddFontResource or AddFontResourceEx or AddFontMemResourceEx), and it relies on everyone else to load up fonts, whether at session initialization time when someone goes through that big list in the registry and loads them all or whether someone adds the font file to the folder later, or removes it. Or calls one of the functions to add or remove the font in their own application code.
So what we call the "GDI Font Cache" is just the list of loaded fonts. Like as if we would call the "installed keyboard list" the "USER Keyboard Cache" or the locales that have been accessed within a session the "KERNEL32 Locale Cache." It is just a list of things that have been loaded.
This is why the docs point out how you have to not only call the function to add the font; you also have to add it to the registry so it will keep getting loaded in the future. The same way that LoadKeyboardLayout works for keyboards, since it does not update the registry with the keyboards that the user might want to keep loading in the future.
What it means is that loading a font is good enough within a session, but to see the font in other sessions one would probably have to reboot, or in Vista or in Terminal Server at least logoff and restart the session.
The "GDI Font Cache" has no in-between setting to distinguish between the fonts one uses and the fonts one keeps available for potential future use -- and unfortunately the differentiation between fonts that are available and fonts that are not on a permanent basis requires HKLM registry permissions -- this is why one had to be an admin to install new fonts (well that and the fact that the Fonts folder requires permissions too).
This is in fact why The fonts directory is freaking huge in Vista -- because requiring Admin permissions here is unreasonable but so is not allowing fonts to be available.
But imagine how easy it would be for there to a per-user fonts folder -- all you would need is
So for all the huffing and puffing about how Mac has all of those different fonts folders, discussed in About the Fonts folder in Windows, Part 1 (aka What are we talking about?), and Windows doesn't, there is no massive technology issue here that is beyond the ability of Windows to support. A model to allow all of the following:
is all do-able, whether by someone from Microsoft or someone writing their own Shell extension (or if they want to be less fancy they can do it in a command line application).
The fact that no one ever mentions any of this is further proof that if it ain't in the default install, it ain't there at all as far as users are concerned....
Maybe someone from Microsoft needs to hook up something like the above in a future version and just get everything working here. It would probably make everyone's lives easier....
This post brought to you by ነ (U+1290, a.k.a. ETHIOPIC SYLLABLE NA)
# James on Monday, April 02, 2007 4:43 AM:
What is 'c:\Users\Me\AppData\Local\GDIPFONTCACHEV1.DAT'? I suppose a GDI+ font cache is not a GDI font cache?
Moreover, what has whether there is such a thing as a GDI font cache got to do with your point that a per user font folder would be trivial to implement?