Open
Bug 179945
Opened 23 years ago
Updated 3 years ago
Symbolic fonts do not display properly, need generic solution (mac only)
Categories
(Core :: Internationalization, defect)
Tracking
()
NEW
Future
People
(Reporter: shanjian, Unassigned)
References
Details
Attachments
(1 file)
828 bytes,
text/html
|
Details |
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•23 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•23 years ago
|
||
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•23 years ago
|
||
mark it as assigned and put into future for now.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 194560
Comment 4•21 years ago
|
||
*** Bug 248618 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Assignee: ftang → nobody
Status: ASSIGNED → NEW
Comment 5•19 years ago
|
||
*** Bug 361323 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
QA Contact: amyy → i18n
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•