It isn't a FONTSIGNATURE, darn it!
by Michael S. Kaplan, published on 2005/12/19 17:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/12/19/505576.aspx
I keep old Platform SDK doc versions around for the NLS API.
It does take up some space, but it also lets me look at what used to be in the documentation so I can know where mistaken impressions might have come from. It makes me slower to judge people when they are wrong. :-)
If I go back to the version that shipped with Visual Studio 6.0, the Platform SDK mention of LOCALE_FONTSIGNATURE is absent.
If I go back to the version that shipped with the October 2001 MSDN, the following text is there:
- Windows 95/98/Me, Windows NT 4.0 and later: A bit pattern used to determine the relationship between character coverage needed to support the locale and the font contents. For more information, see FONTSIGNATURE.
The biggest problem with this topic is that the bits returned by the LOCALE_FONTSIGNATURE are not a FONTSIGNATURE.
What is actually returned is a slightly different object: a LOCALESIGNATURE.
I talked about this a little in Parameter confusion #2a (where you can also see more recent doc text!), when I was talking about the confusing story about the value to pass in the length parameter of GetLocaleInfo. But I did not really explain what these two structures do.
Basically, the FONTSIGNATURE is designed as a huge bitfield that is designed to contain all of the information about what scripts a particular font supports. You can even return this infro from a font by using the GetTextCharsetInfo function.
And the LOCALESIGNATURE (which basically has a FONTSIGNATURE inside of it) includes the scripts that the locale in question should have to be adequately represented, plus extra information on the defaulte code page bitfields that the font needs to support.
Obviously the combination of fonts describing what they have and locales describing what they need theoretically make for a very powerful font linking/fallback/selection mechanism.
Unfortunately, it does not work in practice, for many reasons:
- For years the docs were wrong in their description of the locale side of this functionality
- No good samples on using this functionaslity were ever really put together
- The data quality in the LOCALESIGNATURE has not always been accurate across all locales and all versions of Windows
- The data quality in the FONTSIGNATURE provided by fonts (both those shipped by Microsoft and by external font foundries) has not always been 100% truthful
Now this last point is the fault of neither the fonts nor their creators, it highlights a limitation in the whole structure.
Because it is perfectly reasonable too create (for example) a font that will support Russian OR Ukranian OR Belarusian OR Bosnian, but not the letters needed by the other three. And it would still set bit 9 (Cyrillic and Cyrillic supplementary) in the Unicode subset bitfields and the appropriate bits in the Codepage bitfields, even though the language may support characters outside the various Cyrillic code pages. And in this case the four different fonts for the four languages that have different levels of support for the Cyrillic script would all return the same information!
In the end, the LOCALESIGNATURE/FONTSIGNATURE means of description of script/codepage support within fonts never ended up being too widely used. It is still used in some cases, but this is becoming more and more rare as other more automatic methods of font linking/fallback have proven to cover scenarios more effectively....
This post brought to you by "Җ" (U+0496, a.k.a. CYRILLIC CAPITAL LETTER ZHE WITH DESCENDER)
# Mihai on 19 Dec 2005 8:32 PM:
I have a small application using the FONTSIGNATURE and doing automatic font fallback and font selection.
Nothing special, you will say.
Only that it was written in 1997 on Windows 95 (and still running ok on XP).
Now I am thinking about filing a suit against MS :-)
# Michael S. Kaplan on 19 Dec 2005 8:48 PM:
Fling a suit? What is the basis of that, exactly? :-)
# Mihai on 19 Dec 2005 9:39 PM:
Not sure. But it seems to be a very popular sport in this country :-)
# Nick Lamb on 20 Dec 2005 4:53 AM:
This makes it sound as if, on Windows, ordinary Win32 application programmers are expected to do their own fallback. Is that really true? I mean, let's take an illustrative example. Firstly, suppose you have a perfectly ordinary application with a label, maybe it's the label for a checkbox, or in a menu or something. Suppose the text of this label is an arbitrary name (like 毛澤東 or Nick Lamb) - Are you expected to write code to choose a font for this label that has all the necessary glyphs?
Or is this just for people who always have to do things the hard way, the Raymond Chens of this world who like to know how things work under the hood ? "Unfortunately, it does not work in practice, for many reasons" sounds like you were hoping to see widespread uptake of this facility.
# Michael S. Kaplan on 20 Dec 2005 8:33 AM:
No, this method was never intended for ordinary users, it is definitely a fairly advanced GDI technique for picking fonts.
(But then, so is Uniscribe!)
When I say unfortunately, it is not really because I wanted to see more people use it; it is because it is as fsirly elaborate mechanism which in the end flls short of its implied promise of usefulness....
# Jerry Pisk on 20 Dec 2005 5:54 PM:
Do any of the older PSDK releases work when used under a LUA? The latest does not, the Readme link is completely broken and the documentation (and any other documentation using Microsoft Document Explorer) tries to "fix" PSDK four times on each page load, eventually ending up with an Error 1706. It works fine when you use it as an administrator.
# Michael S. Kaplan on 20 Dec 2005 6:13 PM:
Yikes, that is bad.
I will forward this on to some people over here.
# Jerry Pisk on 20 Dec 2005 9:04 PM:
Thanks, I was not able to find any way to actually raise an issue with the PSDK team. It's not listed as a product on support.microsoft.com and it has no support options on its MSDN site. So here goes - I installed .Net framework SDKs first, 1.1, then 2.0 and then the PSDK. All running under a LUE using RunAs. I never actually ran those docs as the user that installed them, just under my limited account. PSDK's Readme link just runs MSI installation that fails and .Net 1.1's SDK tries to do the same on most pages (method descriptions do it all the time). If you cancel it few times it goes away until the docs are restarted, if you let it fail it will try to install several (3 or 4) times on each page. The actual PSDK documentation is working fine as far as I can tell.
# Michael S. Kaplan on 21 Dec 2005 3:59 AM:
No worries, I made sure to get the issue in front of both them and the folks who are concerned about 'non-admin' issues (including this last comment of yours).
# derek on 21 Dec 2005 3:16 PM:
please feel free to email both of us, we are on the SDK test team and would like to look into the issue you are having.
go to newer or older post, or back to index or month or day