Closed Bug 244498 Opened 21 years ago Closed 20 years ago

Unicode Greek (& Cyrillic & probably other) pages don't render fonts correctly

Categories

(Camino Graveyard :: Page Layout, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 208037

People

(Reporter: mlheureux, Assigned: mikepinkerton)

References

()

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-ca) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1 Build Identifier: On Greek UTF-8 pages that don't specify a font (like Google, for example), a CJK font that has Greek characters is used, which doesn't look good, despite having specified a font in the preferences (Times New Roman [TTF from Windows w/ extended glyph set] in my case) for Greek, Western and Unicode. Also, Greek characters aren't smoothed with Quartz text smoothing, even though surrounding western characters are (with the exception of ?, which has the same mapping in Western encodings). Reproducible: Always Steps to Reproduce: 1. 2. 3.
That's supposed to be a pi...
*** Bug 244497 has been marked as a duplicate of this bug. ***
WFM using 2004102008 (v0.8+) NB on 10.3.4. Camino has the same behaviour as Safari, both have the exact same characters showing. Reopen as needed.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Notice the letter pi, which is rendered correctly (since it is also part of the Western character set), and contrast the way the rest of the Greek letters are rendered & smoothed to the way the Roman letters are.
Notice how the Greek & Roman letters are all in the same font & all rendered the same way.
Firefox renders the page differently than Camino, but still not properly. Notice how the pi's are replaced by Cyrillic e's... I presume this is a problem with the way Carbon apps handle Unicode, since my Verdana font is the Unicode TTF version (as opposed to the Mac FFIL version), and other Carbon programs, like AppleWorks, have the same problem, replacing French accents with Cyrillic characters.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Just because Safari displays all the text in bold doesn't mean Camino is at fault. On my Machine Safari display the http://moz.sourceforge.net/ page exactly the same as FF and Camino do (regular and bold letters). As far as I can tell this has to do with your font settings. I can still WFM.
I'm with Jasper on this one; I think the problem is with the font and the page's css. The CSS specifies Verdana and sans-serif. Verdana on Mac OS X (at least the version that ships with 10.3) contains four Greek characters in the mathematical operators range (lowercase pi, both deltas, and uppercase sigma). Since lower-case pi is found in Verdana, it's displayed. The rest of the Greek text is pulled from the fallback font (whether this font is set in Gecko or chosen by the OS I don't know). If MS had a (Mac) version of Verdana that contained a set of glyphs to cover Greek and let Apple ship it with OS X, or if the page's CSS specified a font with a full set of Greek glyphs first (say, Lucida Grande), there would be no issue here.
(In reply to comment #9) MS does have a Mac version of Verdana, it comes with Office 2004. I've been using it lately, but before, I was actually using the Windows TTF version, which works fine in all of my other apps.
Can reproduce with <moz.sourceforge.net> with 2005032508 on 10.3.8. Text is not anti-aliased.
WFM on 2005032108. I can't reproduce the look you have with Camino. I think you need to reset your font settings (create a new user maybe) and try again. Safari renders this page incorrectly. Looking at the source, neither the CSS nor the (X)HTML suggest that the text should be bold.
There are a half-dozen bugs covering various manifestations of the same poor font substitution/wrong font used/etc. problem scattered throughout various Core components, so I'm simply going to dupe this to the bug Greg suggested in comment 3, since it seems an appropriate dupe. *** This bug has been marked as a duplicate of 208037 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: