Dubious Logic

Here's an explanation of why Mozilla handles the Symbol font the way that it does. First a bit of background: The ASCII (or ISO Latin 1) 8-bit character set uses 97 for "a". The Symbol font has a lower-case alpha character at glyph index 97.

Historically, character numbers and glyph indices were identical (possibly with a choice of "code pages"). So an old application, when attempting to display "a" in the Symbol font will display an alpha.

This was useful behaviour before the wide acceptance of unicode, although limited to people with the same Symbol font, with the same characters at the same indices. In a unicode world, the direct link between character numbers and font glyph indices no longer holds, mainly because very few fonts support all unicode characters.

A unicode-aware application can easily display an alpha by requesting the glyph for entity α (unicode &#03B1;). The entity α can be correctly processed by any unicode application.

So if a unicode-aware application is processing a document with the entity a (which corresponds to lower case "a") and the current font is Symbol, what should it do? The backward compatible behaviour is to display glyph 97 from the Symbol font, which is a lower case alpha. The forward-looking behaviour is to attempt to display a latin lower case "a". Since Symbol does not have such a character, a replacement will have to be found from a visually-similar font. This is what Mozilla does when rendering HTML.

Although it can (and is) argued that the Mozilla approach is unhelpful, it is certainly the case that using α (finally – α) and the like is the way to go.