Update:

Looking in about:config font.name-list.* entries, I find lists of font names instead of the single configured font name in the Language Options. They include

• Installed fonts: SimSun, MingLiu, MingLiu_HKSCS, PMingLiu
• Uninstalled fonts: MS Song, Ming(for ISO 10646)

None of the installed fonts have the previously specified three CJK radical glyphs. I found and installed Ming(for ISO 10646) but it also does not have those glyphs.

I do have other CJK fonts that do have those glyphs but none appear in these configurations or are an exact match to what Firefox displays. Adobe Kaiti Std R is the closest visual match but the spacing is wrong. I'm using OpenOffice Writer to check for glyphs in specific fonts.

I really need to know from where Firefox is getting these font glyphs. Can anyone help or direct me?

You can see the hex code of a character with a bookmarklet like this.

javascript:(function(){var p='?';while(p=prompt('0x'+p.charCodeAt(0).toString(16),p));})();

???!!!

I'm asking about where Firefox is getting the glyph for the quoted CJK radical codepoints. Since I quoted the codepoints (⽹ U+2F79 ⺲ U+2EB2 ⺱ U+2EB1), I obviously already know what they are.

The point is that the configured fonts for the language used do not include glyphs for those codepoints, but Firefox is displaying correct glyphs it is getting from some unknown font. I need to know what that font is and how Firefox knows where to get it.

I've created a concrete example in a web page at

• http://www.thesnakepitdev.com/example.../LanguageFontTest.html

Your installed fonts will vary from mine so I've also attached an image to this post of what I see rendered.

The default Firefox language/font configuration in my installation for Simplified Chinese is:

• Proportional - Sans Serif
• Serif - SimSun
• Sans-Serif - SimSun
• Monospaced - SimSun

Firefox produces a rendering shown in the attached image. The Han codepoints are actual Han characters, while the Radical codepoints are not characters but pieces that are used to compose characters. While the Han and Radicals I've chosen look the same, they have different codepoints because they are not the same thing. All Han and Radicals are specified in spans with the zh language attribute.

There are three sets of examples. The first does not specify a font so is rendered with the default fonts, the second specifies the SimSun font family, and the third specifies a font called "Adobe Kaiti Std R".

As you can see in the attached image, the first and second render the Han characters and the last Radical in the expected SimSun font, but the first three Radicals are rendered in something completely different. When I use the SimSun font in another application, like OpenOffice Writer, there are no glyphs for those three Radical codepoints.

The closest match I've found in a font installed on my computer to what Firefox renders is the "Adobe Kaiti Std R" font. The third example uses this and, while the glyph images match exactly, the spacing between glyphs does not.

I can find no documentation so far on how Firefox is finding a font for glyphs that are missing from the default or specified fonts. Can anyone shed any light on this?

I believe I have this sussed now. My example web page shows the details at

• http://www.thesnakepitdev.com/example.../LanguageFontTest.html

When I specified the "Adobe Kaiti Std R" font for the list of Radicals, the glyphs matched what Firefox was rendering but the spacing was wrong. When I put each individual codepoints in separate spans, leaving the spaces to be rendered in the default SimSun font, the rendering then exactly matches the default rendering. The SimSun spaces are a little wider than the Kaiti spaces.

Apparently when Firefox discovers that there is no glyph in the current font for a codepoint, it searches the OS installed fonts for one that does. The "Adobe Kaiti Std R" font is the first one in the OS provided list of fonts that has glyphs for those three Radical codepoints. It seems Firefox just searches sequentially through the list until it finds a font with those glyphs. However, it only uses the font for the individual codepoints and not any intervening spaces.

Well, at least now it makes sense. However, it means that when you want to render codepoints that might not have glyphs in the user's default font, Firefox will search out an uncontrollably unknown font to supply the missing glyphs. The unknown size and style of those glyphs can cause layout and readability problems. Something to keep in mind.

You know, it is really annoying that, when you solve the question yourself, you can not then mark it solved. <chuckle>