Closed Bug 315199 Opened 19 years ago Closed 10 years ago

symbolic fonts are misused for plain ASCII characters

Categories

(Core Graveyard :: GFX: Mac, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: makotoy, Unassigned)

References

()

Details

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;.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: joshmoz → nobody
Product: Core → Core Graveyard
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]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.