Mac version displaying Symbol font as Greek




19 years ago
14 years ago


(Reporter: gerv, Assigned: ftang)


Mac System 9.x

Firefox Tracking Flags

(Not tracked)



From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (Win95; U)
BuildID:    20000324

I was told in Bug 33127 that if Mozilla renders any text in Font "symbol" using 
Greek glyphs, as Navigator does, then it's a bug. Moz does this on Mac, so 
here's the bug report :-) 

Reproducible: Always
Steps to Reproduce:
1. Open URL in Mac Moz.

Actual Results:  Word "Opaque" (pink opaque background) is in Greek text

Expected Results:  Word in English text
CC: (from Bug 33127).


Comment 2

19 years ago
If the word "Opaque" is rendered using the Greek glyphs from the Symbol font on
the Mac, I wonder whether MathML works on that platform. Roger, see bug 33127.

Comment 3

19 years ago
In bug 33127, rbs wrote:
There shouldn't been greek letters. The rendering of
<font face="symbol">Opaque</font> should give the word "Opaque" on all 
platforms. This is the correct behavior I see on Windows. If it is not
the behavior observed on the Mac then there is a bug on that platform

If I understand correctly, Windows doesn't display the word "Opaque" in greek 
letters because it can tell that the word "Opaque" can't be displayed with the 
greek glyphs from the Symbol font so it gets the glyphs from another font (the 
default one, I guess).

Maybe that's what is happening in bug 31538 too. Windows sees that the letters 
'A' through 'Z' can't be rendered with the gibberish from Webdings so it uses 
Times instead. If that's the case, I'd say that Windows is smart and maybe even 
too smart because it doesn't display as we expect.

Anyhow, we are not that smart on Mac. When we are told to display some characters 
with a certain font, we just do it and if the font maps "A-Z" to greek letters or 
funny icons, so be it. I'm not even sure the OS can make us as smart as on 
Windows. Reassigned to ftang: maybe ATSUI can help.
Assignee: pierre → ftang

Comment 4

19 years ago
Look for more comments in bug 22031. We may decide to continue to interpret chars 
as glyph indices (ie. display greek characters in the example above) in quirks 
mode. In strict mode, we would interpret them as glyphs, like Windows does 

Comment 5

19 years ago
This is a hard problem because on Macintosh 'Symbol' font is in the MacRoman 
script range of resources Id. To fix this, we may need to compare the font name 
Hardware: PC → Macintosh

Comment 6

19 years ago
I am relunctant to work around a bug with that particular font based on its name. 
We should instead develop a similar testcase with another font and make sure - in 
strict mode only - that we interpret characters as glyphs instead of glyph 
indices (see my comments from 2000-03-25 05:39).

Comment 7

19 years ago
Move to M16
Target Milestone: --- → M16

Comment 8

19 years ago
Mark this as M17
Target Milestone: M16 → M17

Comment 9

19 years ago
should be easy to fix. Move it to M16
Target Milestone: M17 → M16

Comment 10

19 years ago
fixed and check in. nsDeviceContextMac.cpp r1.72
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 11

19 years ago
Reopening. This is the wrong fix, please back it out. You are preventing the use 
of the Symbol font altogether, it's not what we want.
Resolution: FIXED → ---

Comment 12

19 years ago
Note: this bug is related to bug 31538.

Comment 13

19 years ago
There is a consensus in bug 31538 to not interpret characters as glyph indices, 
and thus to not display fonts like Symbol and WebDings. Problem: this is possible 
on Windows but maybe not on the Mac.

We have 2 cases on the Mac:
1) If we can programmatically determine that a font doesn't contain a particular 
glyph and if "Symbol" is the only exception to that algorithm (because, as you 
wrote, it is in the MacRoman script range of resource IDs), then we can leave 
your change in place and implement the rest.
2) If it doesn't work, ie. if there is no way on the Mac to tell whether a font 
has a particular glyph, we should opt for the compatibility with Nav4x and a 
consistency between fonts, and thus back out your change.
Fixing this bug is related to partially fixing bug 7951.

Comment 15

19 years ago
1. this fix have nothing to do with 7951. The sybmol font will still be used by 
ATSUI to render Greek Unicode. The QucikDraw code never use Symbol font except 
we put symbol in the font face. So it is not related at all. Before my fix, 
Mozilla use ASTSUI to render greek by using Symbol font. After my fix, same 
thing happen. There fore 7951 is not related to this at all
2. "You are preventing the use of the Symbol font altogether, it's not what we 
want.". False statement, we only prevent people to use symbol font in <FONT 
face="symbol"> here. If user specify unicode code point which the symbol font 
have the character (for example, visit 
http://warp/employees/erik/tests/cers/html40/charset-alpha.cgi?iso-8859-1  )
You will see we use Symbol font to rendert &alpha; &Alpha; or even &spades; 

3. This bug is 33258 but not 31538. In turn of the scope of this bug, it is 
already been fixed. Mark this fix again. (Please deal with other fonts in bug 
31538, but not here.)
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 16

19 years ago
You're perfectly right. I didn't know we had Greek Unicode already.
Thanks Franck!

Comment 17

19 years ago
Marking verified.

Comment 18

16 years ago
*** Bug 172639 has been marked as a duplicate of this bug. ***


14 years ago
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.