Closed Bug 33258 Opened 25 years ago Closed 25 years ago

Mac version displaying Symbol font as Greek

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: gerv, Assigned: ftang)

References

(
URL
)

Details

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: erik@netscape.com (from Bug 33127). Gerv
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.
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
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 already.
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 first.
Status: NEW → ASSIGNED
Hardware: PC → Macintosh
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).
Move to M16
Target Milestone: --- → M16
Mark this as M17
Target Milestone: M16 → M17
should be easy to fix. Move it to M16
Target Milestone: M17 → M16
fixed and check in. nsDeviceContextMac.cpp r1.72
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Note: this bug is related to bug 31538.
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.
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.)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You're perfectly right. I didn't know we had Greek Unicode already. Thanks Franck!
Marking verified.
Status: RESOLVED → VERIFIED
*** Bug 172639 has been marked as a duplicate of this bug. ***
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.