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)