User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1 When symbolic fonts get priority, text blocks consisting only plain ASCII characters are rendered using glyphs from those fonts, instead of plain alphabets from some other fallback font. The cause of this issue is the behavior of nsRenderingContextMac::DrawString(const char *aString... that renders plain chars using the current font, without checking whether it is for u0020-u007F characters. Affected fonts include: Symbol, Math1 ... Math5 and Wingdings. Note that "Symbol" does not take effect until the fix for bug 213702 is checked in. Reproducible: Always Steps to Reproduce: 1. render an HTML containing <span style="font-family:Math1">a</span> 2. 3. Actual Results: 'alpha' glyph rendered Expected Results: 'a' glyph from the fallback font

Ironically, we actually _want_ this behavior in some cases. But we want it to be under our control. Specifically in the case of <font face="Symbol">. See bug 194560 and bug 179945. FYI, the way it works in Gfx:Win is this (see bug 195038): - the Style System flags <font face> with nsFont.familyNameQuirks, - Gfx:Win uses the internal name "1Symbol", while the non-quirky name is "0Symbol". In this way, we support both situations without the risk of mismatch. - "0Symbol" always gets its map from the fontEncoding.properties, while "1Symbol" and other symbolic fonts get a bogus Latin map (bug 94319) which actually allows 'a' to be misused as an index to become &alpha;.

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]