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

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:

The biggest problem with this topic is that the bits returned by the LOCALE_FONTSIGNATURE are not a FONTSIGNATURE.

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.

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)

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 :-)

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.

Hi Nick,

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....

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.

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.

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).

Jerry,

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.

thanks
derekn@microsoft.com
chrishu@microsot.com

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.