Symbolic fonts do not display properly, need generic solution (mac only)

NEW
Unassigned

Status

()

Core
Internationalization
15 years ago
8 years ago

People

(Reporter: Shanjian Li, Unassigned)

Tracking

Trunk
Future
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
We have similar problem on windows as well, it will be fixed in bug 94319. 
Copied description from 94319:

Currently, when a symbolic font is utilized in a font face tag (ie. <font 
face="wingdings">), the text between the font tags will not be displayed using 
the symbolic font unless that particular font name has been appended to the 
fontencoding.properties file (indicating that the font should be treated as 
though it were utilizing a standard encoding (see Bug 77265)).

This solution is hardcoded and therefore not very adaptible.

If the user adds a new font symbolic font to their system, they will very 
likely expect to be able to utilize it in the browser or email.  Tediously 
adding each new font to this hardcoded list is unwieldy and inelegant.

Is there a way to specify a more generic situation?  Perhaps a flag for 
embedders to indicate that, when a symbolic font is encountered, they would 
just like to default to treating the font as though it utilizes windows-1252 
encoding?


The following is the list of fonts that were not properly displayed during a 
recent test:
Map Symbols 
Marlett 
Monotype Sorts 
MS Outlook 
MT Extra 
Symbol
Wingdings 2
Wingdings 3

The solution is to use win-1252 as default encoding for symbol fonts. But we
only do this for font specified using font tag.  See bug 94319 for detail and
testcase.

Comment 1

15 years ago
This is asking for trouble... Mac versions of Symbol and other symbolic fonts
are usually not encoded in WIN-DOS-1252 but in MacRoman. Thus, there will be the
same old discrepancy as always with older browsers, giving different renderings
depending on who coded the site and how.

Furthermore, will these commercial special branch variants break standards? If I
use "Symbol" in a proper way on a page, utilizing Unicode code points to access
the glyphs, will these Geckos then override Unicode and render it in
WIN-DOS-1252? This sounds as far away from Mozilla's mission as you can get.

Comment 2

15 years ago
Created attachment 106164 [details]
test case

Besides, Mozilla already displays symbol fonts way out of any encoding... the
test case shows the rendering of card symbols using Symbol and Code2000
respectively. These both contain these symbols and are displayed correctly in
ANY other application (BBEdit, TextEdit, ...), but Mozilla doesn't get it right
for the Symbol font.

Seems to me there are much more urgent bugs to squash than this one (which
isn't a bug, but a Big Business request to break standards).

Heh, you really had me believe for a while that Mozilla was independent from
the marketoids of AOL-Time-Warner-Netscape-Microsoft.

Comment 3

15 years ago
mark it as assigned and put into future for now. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 194560
*** Bug 248618 has been marked as a duplicate of this bug. ***
Assignee: ftang → nobody
Status: ASSIGNED → NEW

Comment 5

11 years ago
*** Bug 361323 has been marked as a duplicate of this bug. ***
QA Contact: amyy → i18n
You need to log in before you can comment on or make changes to this bug.