2) should a text renderer such as a browser favor the specific font face? or should it fall back and try to render from another font that promises to ‘display a donut-shaped o where `o` was in the text’?

for a vast range of applications, falling back character by character to something ‘probably correct’ is, i think, indeed they way to go. i work a lot with chinese characters from unicode astral planes, and most fonts don’t have those characters. additionaly, the very few fonts that do have those astral characters lack huge parts of the (16bit) bmp characters (for reasons of file size). also, a LOT of chinese fonts only have the most frequent characters as glyphs, for the sheer number of them (almost 21 thousand chinese characters in the bmp alone), so failure on a character-by-character base is as frequent as a leaf blowing in the autumn wind as far as chinese typesetting is concerned. only those applications that are apt at font substitution are future-proof; others will fail when going beyond basic western needs.

3) it would be nice if applications could make configuring character substitutions more configurable, and provide more diagnostics. the only software that i am aware of that allows me to specify which font to use, unicode block for unicode block, is BabelMap (of http://www.babelstone.co.uk/Software/BabelMap.html).

the font configuration menu of all browsers i know of is a joke—you are expected to configure fonts *by language* and have no way to specify unicode code blocks. now what webpage contains a proper language markup? who in this world actually produces html that marks language switches for each paragraph? this would be important for chinese character variant selection (see http://en.wikipedia.org/wiki/Han_unification#Examples_of_some_non-unified_Han_ideographs), but even then it requires an informed user intervention (to be sure, the unicode consortium did the wrong thing here and embraced the technologically wrong kind of solution—code points are the only reliable way to distinguish character forms. you might differ, but looking at said table you will see that it is only *some* important characters that have their variants *not* reflected in unicode; when you go into detail, its a royal mess.)

4) sometimes you have the need to display elements of writing that are not encoded by unicode (i have hundreds of examples). well, unicode will never have a codepoint for everything that people want to write. but, it does provide a private use area—a vast array of codepoints that are meant to be free of interpretation, so you can put there whatever you like. i currently work a lot with typeface (of http://typeface.neocracy.org) to make sure i get exactly the outlines i intended. if downloadable fonts were a reality, then maybe browsers would actually honor the css font-family *when rendering material from a private use area*, for in those cases it is impossible to assume any other intended rendering. of course, that leaves accessibility in the open (but no screenreader today will help you to translate astral plane characters or major parts of non-western unicode anyway).

(@Sebastian Redl: the subject “is unicode an encoding? is utf-8?’ has been discussed in depth over at http://www.artima.com/forums/flat.jsp?forum=106&thread=230157)

& #x21;

(I’m leaving a space between the & and the #x21 character code on purpose because of the way this comments form is parsing it – pretend it’s not there)

This is a simple, and obviously non-standard example set, but this line:

<font face="Arial">& #x21;</font>

produces an exclamation point in Arial. This one:

<font face="Trebuchet MS">& #x21;</font>

produces a differently-styled exclamation point in Trebuchet. This line, however:

<font face="Webdings">& #x21;</font>

which should produce the Webdings font’s version of the exclamation point (which, per the font designer’s choice, just happens to look a lot like a spider), does not. Instead it falls back to Times (default font) and renders that font’s version of the exclamation point.

What gives?

First of all: I’m using Firefox 3, final release, on Ubuntu 8.04, and the Webdings font on your test page renders as you expected, in the way Philippe described as a bug. That is: I see the ear, Death Star and spider.

Second, the explanation doesn’t make sense to me. Sure, the Unicode behaviour is completely logical: if the font doesn’t have this Chinese glyph, find a font that does. However, Webdings actually has the glyphs your are asking for: they just don’t look the way they should, but as Randy pointed out, the browser doesn’t know that… A font should not represent the letter “o” as an ear, but apparently for historical reasons, it does.

Why does it work a certain way on my Ubuntu Linux, and another way on other computers/systems, including my brother’s Windows XP box? Is my Firefox different? (Could be, since it’s from Ubuntu’s official repositories) Or are our Webdings fonts different? Or does it depend on some configuration?

Okay, I’m lost.

If you start using random characters such as “y” to mean “Death Star” how will non-visual interfaces ever be able to deal with that other than implementing some weird hack to cope with the madness that is Webdings?

Very true Anne. Accessibility goes out the window. Another fine example of propriety standards which destroys interoperability and accessibility.

@Eric

May I suggest using an image with alt text for your ear-Death Star-spider combo. Sounds like some name for a hack.

Prince 6.0r6, interestingly enough, displays “Oy [spider]“