by Michael S. Kaplan, published on 2008/05/17 20:04 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/05/17/8517829.aspx
Over in the Suggestion Box, regular reader Andrew West asked:
Hi Michael,
Here's another weird bug with the IE font configuration dialog that I've just found.
I've been creating a suite of Ogham fonts, and I've been finding that some of them show up in the Ogham font list of Internet Explorer, and some quite unexplicably do not. It has taken me all morning, and I've finally worked out that it is nothing whatsoever to do with the font internally, but depends entirely on the length of the font's filename. If the filename (including extension) is 31 characters or less then the font is added to the Ogham font list, but if it is 32 characters or more then it is not. So "BabelStone_Ogham_0123456789.ttf" is OK, but if I rename the file to "BabelStone_Ogham_0123456789X.ttf" and reinstall it, then it does not show up in the Ogham font list. But the really strange thing is that all the fonts always show up in the Latin font list, regardless of the length of their filename.
I don't suppose that there is much you can do or say about this, but I thought it might amuse you.
Andrew
My goodness.
You'd think by now that there is little that I couldn't say something about. :-)
The number 32. To borrow a phrase from The Church Lady, isn't that convenient?, if you know what I mean.
In computers, a numerologist could spend his or her time in ecstasy, knowing that their belief that the numbers behind what happens are significant is actually proven fact.
In this case, I mean given the following definition in wingdi.h from the Platform SDK:
/* Logical Font */
#define LF_FACESIZE 32
This constant is the size limit of the lpFaceName member of the LOGFONT structure, and the reason behind the documented 32-character limit of the lpszFace parameter of the CreateFont function.
Without even looking at the code, I would be more than willing to bet that the code in the MLang font link code that stores the name is incorrectly making use of that same limit, possibly even that same constant.
It would be a bug of course, but an explanation, at least. :-)
The net effect would be that MLang never enumerates the font and thus IE never displays it.
Right after I wrote this, I took a look at the code. and it does indeed appear that LF_FACESIZE buffers and specified lengths are gumming up the works here....
An interesting bug for the owners of MLang to look into (though the need to verify that none of the clients of MLang are making similar assumptions might make the cost of the fix a bit too high!).
And a pleasant distraction on a Saturday afternoon while I am nursing too much of hangover to do anything more productive than that. :-)
This blog brought to you by ≐ (U+2250, aka APPROACHES THE LIMIT)
Andrew West on 18 May 2008 12:18 PM:
I'm not sure that I've explained the problem clearly enough. It is not the length of the font's face name, but the length of the font's filename. So, if I have two identical fonts that support Latin and Ogham, one with the face name "BabelStone Ogham A" and filename "BabelStone_Ogham_0123456789.ttf" (31 characters), and the other with the face name "BabelStone Ogham B" and filename "BabelStone_Ogham_0123456789X.ttf" (32 characters). Both "BabelStone Ogham A" and "BabelStone Ogham B" are listed under "Latin based" fonts, but only "BabelStone Ogham A" is listed under "Ogham" fonts, so for Latin based fonts the length of the font's filename does not matter, but it does for Ogham fonts -- but why is it even looking at the font's filename?
I've just done an experiment with Code2000, which is listed in every "Language script" in the IE Font Configuration dialog except for Mongolian, Myanmar, Sinhala and Tibetan (of course, Sinhala and Tibetan are the only scripts it is really missing). I deleted Code2000 from the Fonts folder, then renamed its *filename* to "CodeTwoThousand_by_James_Kass.ttf" (33 characters), and reinstalled it. Then when I reopen the IE font configuration dialog, "Code2000" is only listed under Arabic, Chinese Simplified, Chinese Traditional, Cyrillic, Greek, Hebrew, Japanese, Korean, Latin based, Thai and User Defined; but no longer appears under any other script (disappeared from Armenian, Bengali, Braille, Canadian Syllabic, Cherokee, Devanagari, Ethiopic, Georgian, Gujarati, Gurmukhi, Kannada, Khmer, Lao, Malayalam, Ogham, Oriya, Runic, Syriac, Tamil, Telugu, Thaana and Yi). I wonder what these scripts have in common ...
Michael S. Kaplan on 18 May 2008 2:55 PM:
Actually, I understood you just fine -- there is code in MLang's super-super "what script for what characters" font linking that assumes that LF_FACENAME is appropriate for the font file name just as much as the font face name. That code is wrong -- and would be a bug.
Note that it is not the only code that runs here -- code for script detection expected to be in lots of fonts because it is such on the MS-provided OS goes through a different code path.
It is a bug, sure. But is a pretty central misunderstanding in this code that might be too risky to touch....
referenced by
2008/06/12 Truly a font of absolute last resort