Eastern European text uses Western European font

RESOLVED FIXED in Camino1.0

Status

Camino Graveyard
General
P3
major
RESOLVED FIXED
16 years ago
13 years ago

People

(Reporter: Mark Mentovai, Assigned: Simon Fraser)

Tracking

(Blocks: 1 bug)

unspecified
Camino1.0
PowerPC
Mac OS X

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021202 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021202 Chimera/0.6+

There are a few issues with the way international text works in Chimera.  It's
hard to quantify them all together, so I'll start with this one.

http://www.mentovai.com/tmp/alpha-hu.html displays the Hungarian alphabet, as
encoded with ISO 8859-2 (Latin-2/Eastern European) and HTML � Unicode
character references.  All characters except for the O and U with two acute
diacritics are displayed in the default Western font.  The two characters in
question are displayed in both uppercase and lowercase in Times, or some variant
thereupon.

To see this, it may be useful to adjust Chimera's preferences slightly.  I have
removed all font preferences from prefs.js (the default state) and am testing with:

user_pref("font.name.sans-serif.x-central-euro","Lucida Grande");
user_pref("font.name.sans-serif.x-cyrillic","Helvetica CY");
user_pref("font.name.sans-serif.x-western","Monaco");
user_pref("font.name.serif.x-central-euro","Lucida Grande");
user_pref("font.name.serif.x-cyrillic","Helvetica CY");
user_pref("font.name.serif.x-western","Monaco");

Note that what I refer to as "eastern European" (8859-2, Latin-2) is what most
applications seem to refer to as "central European."

The document in question specifies iso-8859-2 as its character set, and the
expected iso-8859-2 characters are displayed properly, but not in the expected
typefaces.

Compare http://www.mentovai.com/tmp/alpha-ru.html (Russian, in Cyrillic with
iso-8859-5) and http://www.mentovai.com/tmp/alpha-en.html (English, western
European, iso-8859-1).

Is somebody actively working on this stuff?  Is there a better place to discuss
how this should work than Bugzilla?

Mark

Reproducible: Always

Steps to Reproduce:

Comment 1

16 years ago
Be advised that there are many known issues with "international" Unicode text on
Mac that won't be fully addressed until bug 121540 is fixed.
(Assignee)

Comment 2

16 years ago
test pages are gone.
Assignee: saari → sfraser
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

16 years ago
Sorry - new test page at http://www.mentovai.com/tmp/alpha-hu.html.  The
behavior seems a bit different than I initially described, but still buggy.  It
looks like the Western font (try Lucida Grande) is used for most characters, but
not for the characters with double-acutes.  Those seem to want to show up in Times.

On the second glance, this problem looks like it's being imported from Mozilla.

Mark
(Assignee)

Comment 4

16 years ago
Looks fine if I use Times as my default font.
Status: NEW → ASSIGNED
(Reporter)

Comment 5

16 years ago
Sure, you won't notice a problem if everything is set to Times.

Try setting everything to Times, except for the Western proportional font.  Set
that to Lucida Grande.  Hit up the test page, and the O and U with two acute
diacritics will be displayed in Times in the first (proportional) block anyway.

In fact, they seem to be displayed in Times independently of any possibly
relevant setting in the Appearance/Fonts preferences.

So, there are two problems:

 - Western fonts are being used for most text in Central European pages.
 - The O and U characters with double-acutes are being displayed in Times
   regardless of any preference setting.

Note that Lucida Grande was specifically selected in this example because it
contains so may glyphs, including the O and U with double-acutes.  It should be
used to display those characters when the Central European encoding is in effect
and it is selected as the font.  Of course, this is all a little bit messed up
anyway since the first bug makes where to select it unclear.

Mark

Comment 6

15 years ago
Isn't this bug also corelated with bug 184092 bug 201817 ?

Comment 7

15 years ago
Sorry I meant bug 158560, not bug 184092 (that is this one).
Reporter could you test with a nigthly and recent build, because it seems fine
with with 2003090102 on 10.2.6.
(Assignee)

Comment 9

14 years ago
Created attachment 177342 [details]
Capturing testcase
(Assignee)

Comment 10

13 years ago
Still an issue?
Priority: -- → P3
Target Milestone: --- → Camino1.0
(Assignee)

Updated

13 years ago
Blocks: 301740
(Reporter)

Comment 11

13 years ago
This has stopped sucking.  Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.