Wrong font choice for japanese in Unicode

VERIFIED FIXED

Status

()

Core
Internationalization
--
major
VERIFIED FIXED
15 years ago
12 years ago

People

(Reporter: Erwan Loisant, Assigned: rbs)

Tracking

({intl})

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

It concerns any page displaying Japanese using unicode. I don't know how Mozilla
chooses the font used for Japanese when displaying Unicode, but it usually
chooses a fantasy font I installed that is very hard to read on a webpage
(imagine an english webpage using a "script" font with size 10).

In the prefs, I choosed non-japanese fonts for Unicode. In fact I need to
display other languages so choosing a japanese font will not change anything.

Maybe the Unicode font selection should be richer, like choosing the font for
each language.

I noticed the same problem in the messenger, and with Phoenix (version 0.5).


Reproducible: Always

Steps to Reproduce:
1. Install a bunch of fantasy japanese font
2. Open a japanese unicode page, like http://www.google.co.jp

Actual Results:  
A fantasy font is used.

Expected Results:  
Use a more common font, doing like most windows app do (I don't know how they
choose the font) or by making richer the unicode font selection preference box.
(Reporter)

Comment 1

15 years ago
Created attachment 109027 [details]
Google on Mozilla

The font is not appropriate for this size, it is a fantasy font. It is ugly and
hard to read.
language group stuff -> i18n
Assignee: font → smontagu
Component: Layout: Fonts and Text → Internationalization
QA Contact: ian → ylong
(Reporter)

Comment 3

15 years ago
Created attachment 109028 [details]
Google on IE

IE choosed an appropriate font (probably MS Gothic) and the rendering is nice
and readable. This is what Mozilla was supposed to display.
(Reporter)

Comment 4

15 years ago
Note: I filled the bug with Phoenix so this is the Phoenix string displayed.
However, I noticed the bug on the following Mozilla build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

Note that the bug is present in Phoenix also (the build string being precised in
the report), as well as olders Mozilla versions.
Do you have the same problem with sites that declare that they are in Japanese?
Try http://www.unicode.org/unicode/standard/translations/japanese.html, which
has <meta http-equiv="Content-Language" content="ja">, and
http://www.unicode.org/iuc/iuc10/x-utf8.html, which has a Japanese section with
lang="ja".

Comment 6

15 years ago
Which system language locale are you using?
(Reporter)

Comment 7

15 years ago
- I notice the same problem with websites that precise that they are in Japanese
- Although my Windows is an English version, the locale is set to Japanese (to
use non-unicode english applications).
(Reporter)

Comment 8

15 years ago
(Sorry, I mean: it is set to Japanese to use Japanese non-unicode applications,
of course...)
(Reporter)

Comment 9

15 years ago
Still present with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
(Assignee)

Comment 10

15 years ago
The page has the CSS:

body,td,a,p,.h{font-family:arial,sans-serif;}

As far as I can tell, 'Arial' includes Japanese glyphs, and Mozilla may be
picking the glyphs from there.

Try to UNCHECK 'Allow documents to use other fonts', and choose another font of
your liking. (remember to CHECK it back...)
(Reporter)

Comment 11

15 years ago
Unchecking "allow document to use other fonts" works, I can display the page
with the font I choosed.

I don't think Arial includes Japanese glyphs, but Mozilla/Windows automatically
uses another font to display Japanese. I can identify the fantasy font used (in
the screenshot it is a "stamp-like" font), if I delete this font another one is
choosed.

MS software as well as OpenOffice.org 1.0 choose appriopriate alternate font to
display Japanese when the glyphs are not available. However I have no idea how
the "choose alternate font to display when glyph is not available" is implemented.
(Assignee)

Comment 12

15 years ago
The prefs below (which you can see with about:confing or in winpref.js) are the
default fonts used for Japanese. Unfortunately, Google is not using lang="ja"
and the page isn't being detected as a Japanese page. It is instead detected as
a vanilla Unicode page (see View -> Character Coding). You will probably get a
better result if you save the page locally and add:

<html lang="ja">
...
</html>

pref("font.name.serif.ja", "MS P明朝"); // "MS PMincho"
pref("font.name.sans-serif.ja", "MS Pゴシック"); // "MS PGothic"
pref("font.name.monospace.ja", "MS ゴシック"); // "MS Gothic"
pref("font.name-list.serif.ja", "MS PMincho, MS PGothic, MS Mincho, MS Gothic");
pref("font.name-list.sans-serif.ja", "MS PGothic, MS PMincho, MS Gothic, MS
Mincho");
pref("font.name-list.monospace.ja", "MS Gothic, MS Mincho, MS PGothic, MS PMincho");
(Assignee)

Comment 13

15 years ago
In fact, Mozilla's font code tries hard to detect the language from the
character itself. Indeed bug 116030 was aimed at identifying the language group
for a unicode char, and to use that to find the preferred fonts. I wonder if/why
that code isn't kicking in here.
(Reporter)

Comment 14

15 years ago
Right, adding lang="ja" in the body of the page solves the problem.

However, if we can blame Google for not precising the language for this Japanese
page, a unicode page may be mostly in English and have only some strings in
Japanese. Make multilingual pages is the main advantage of unicode :). In this
case, a recognition of Japanese characters would be appropriate.

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
(Assignee)

Comment 15

15 years ago
> a recognition of Japanese characters would be appropriate.

Indeed, and that's what bug 116030 intended to do. Which is why I am wondering
if there isn't a bug somewhere.
(Assignee)

Comment 16

15 years ago
Created attachment 120757 [details] [diff] [review]
fix

There was a little oversight when addressing bug 116030 comment 12. C.f. the
'<' in the first line of that comment.
(Assignee)

Comment 17

15 years ago
Taking to checkin.
Assignee: smontagu → rbs
(Assignee)

Updated

15 years ago
Attachment #120757 - Flags: superreview?(bzbarsky)
Attachment #120757 - Flags: review?(smontagu)
Comment on attachment 120757 [details] [diff] [review]
fix

r=smontagu
Attachment #120757 - Flags: review?(smontagu) → review+
Attachment #120757 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Comment 19

15 years ago
Checked in.
(Assignee)

Comment 20

15 years ago
Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 21

15 years ago
Tried this on 05-08 trunk build, seems it won't use fantasy font.  Mark as
verified as fix, please re-open if still see the problem.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

12 years ago
Blocks: 116030
You need to log in before you can comment on or make changes to this bug.