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

Status: RESOLVED DUPLICATE of bug 208037

(Camino Graveyard :: Page Layout, defect)

Description

[mlheureux]

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.

Comment 1

[mlheureux]

That's supposed to be a pi...

Comment 2

[Stuart Morgan]

*** Bug 244497 has been marked as a duplicate of this bug. ***

Comment 3

[Greg K.]

See also bug 208037.

Comment 4

[Jasper]

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.

Comment 5

[mlheureux]

Attachment: Screenshot of moz.sourceforge.net in Camino

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.

Comment 6

[mlheureux]

Attachment: Screenshot of moz.sourceforge.net in Safari

Notice how the Greek & Roman letters are all in the same font & all rendered
the same way.

Comment 7

[mlheureux]

Attachment: Screenshot of moz.sourceforge.net in FireFox

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.

Comment 8

[Jasper]

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.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 10

[mlheureux]

(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.

Comment 11

[Jamie Diamond]

Can reproduce with <moz.sourceforge.net> with 2005032508 on 10.3.8. Text is not
anti-aliased.

Comment 12

[Samuel Sidler (old account; do not CC)]

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.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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 ***