Closed Bug 599289 Opened 14 years ago Closed 13 years ago

default zh-TW and zh-HK fonts of several years ago should be replaced by the latest ones

Categories

(Core :: Layout: Text and Fonts, defect)

All
macOS
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla14

People

(Reporter: chief+mozilla, Assigned: timdream)

References

Details

(Keywords: fonts)

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; zh-TW; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 GTB7.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; zh-TW; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 GTB7.1

The default Traditional Chinese (zh-TW) sans-serif font on Firefox is now "Apple LiGothic (蘋果儷中黑)". The best known issue of the font is that it does not contain enough Chinese glyphs, "喆 (zhé)", for instance.

"LiHei Pro (儷黑 Pro)" has been used on Traditional Chinese Mac OS X since 2003. Last year (2009) the company has replaced it to a new font called "Heiti TC (黑體-繁)", when the latest Mac OS X Snow Leopard released. By then, considering too many people against it, Firefox did not agree to change the default value to "Heiti TC". When Mac OS X 10.6.3 updated, Apple fixed the problems these people declared of the font, which was reason enough to use the same font as the system's.

Due to the identical styles between "LiHei Pro" and "Apple LiGothic", people could barely tell the differences when the OS default used to use "LiHei Pro" before. Now the OS default sans-serif font is "Heiti TC". The styles are way too distinct from each other.

Since "Apple LiGothic" weren't and is not the default system's sans-serif font from OS X 10.4 to 10.6, we should use the default font of OS X 10.4-10.5(LiHei Pro) and 10.6(Heiti TC) and put "Heiti TC" in the first place other than using "Apple LiGothic".

There are also some problems with Fx's default serif font for zh-TW, "Apple LiSung Light (蘋果儷細宋)". It's an old font without enough glyphs and not the default value that Mac OS X uses too. Currently, Apple uses "LiSong Pro (儷宋 Pro)" for system's default serif font.

Reproducible: Always

Steps to Reproduce:
go to "about:config"; and filter with "serif.zh".

Actual Results:  
We can see the sans-serif of either zh-HK(LiHei Pro) or zh-TW(Apple LiGothic) and the serif of zh-TW(Apple LiSung) are not OS X 10.6 default value.

Expected Results:  
font.name-list.sans-serif.zh-HK: Heiti TC, LiHei Pro
font.name-list.sans-serif.zh-TW: Heiti TC, LiHei Pro
font.name.sans-serif.zh-HK: Heiti TC
font.name.sans-serif.zh-TW: Heiti TC

font.name-list.serif.zh-TW: LiSong Pro
font.name.serif.zh-TW: LiSong Pro
Keywords: fonts
Attached image expected settings
We (MozTW) have designed a questionnaire to get opinions from the large. Details to come, We could start the discussion based on the result.
Status: UNCONFIRMED → NEW
Ever confirmed: true
John- can you take a look at this please?
Is there anybody can take over this issue?
We'd forget it longer than half year...
Adding Jonathan Kew.  Can you or jdaggett please triage this bug?
(In reply to CH'EN YI-CHÜN from comment #0)

Ethan, would you contribute a patch for this?
I'll do it if you don't want to.


We would need feedback{?/+/-} and review{?/+/-} though.
Could someone attach "before vs. after" screenshots?
(In reply to Kan-Ru Chen [:kanru] from comment #9)
> Could someone attach "before vs. after" screenshots?

I'd got a lot on my flickr, 

Yahoo
Before: http://www.flickr.com/photos/irvin/5519949040/
After: http://www.flickr.com/photos/irvin/5519358373/

Mozilla Links zh
B: http://www.flickr.com/photos/irvin/5519948770/
A: http://www.flickr.com/photos/irvin/5519358779/

Our release notes
B: http://www.flickr.com/photos/irvin/5519948540/
A: http://www.flickr.com/photos/irvin/5519948144/
Also we're going to provide an instruction on how to set back the settings on moztw.org on shipping, the reserve url is http://moztw.org/firefox/macfont
Dear all,

Heiti TC is included in the name-list with fixes in bug 705594

http://hg.mozilla.org/mozilla-central/diff/be0b61e0ed53/modules/libpref/src/init/all.js#l1.186

Please verify if this is the desired change. If not please attach a patch in this bug and I will work on it.

If so we will close this bug.
Attached patch Patch v1 (obsolete) — Splinter Review
Just realized the mentioned change does not fix this issue.

So here is the patch.
Attachment #606108 - Flags: review?(jdaggett)
Comment on attachment 606108 [details] [diff] [review]
Patch v1

Your changes seem good except this one:

> -pref("font.name.sans-serif.zh-TW", "Apple LiGothic");  
> +pref("font.name.sans-serif.zh-TW", "Heiti TC");  
> 
> -pref("font.name.sans-serif.zh-HK", "LiHei Pro");
> +pref("font.name.sans-serif.zh-HK", "Heiti TC");

Looking at this a little closer, I'm not sure I agree with the change
from Apple LiGothic to HeitiTC.  I think LiHei Pro might be a better
choice as a default font.

I think there are two interrelated but slightly different problems,
the appearance of the default font and it's glyph coverage.  The glyph
coverage is actually determined by the union of the 'font.name.xxx'
font *and* 'font.name-list.xxx', so including a font in the
'font.name-list.xxx' will increase the coverage without affecting the
look of the default font.

My major concern is that the design of Latin glyphs in HeitiTC seems
very poor, the glyphs are less readable than those of LiHei Pro and
they don't work well when rendered at the same size as the surrounding
Chinese text:

http://people.mozilla.org/~jdaggett/tests/zhtwfonts.html

To some degree I imagine many sites effectively mask this problem by
using normal Latin fonts by default (e.g.
"arial,helvetica,clean,sans-serif" on http://tw.yahoo.com/).  Apple
does this also, Lucida Grande is specified at the front of the font
list so the Latin text is effectively much more readable.

From the discussion within the Taiwan community, are there specific
sites that definitely look better with HeitiTC when compared to LiHei
Pro, given the recent changes to the fallback fonts that should fix
some of the glyph coverage problems?  If so, could you list them in
the bug here?
(In reply to John Daggett (:jtd) from comment #15)
> Comment on attachment 606108 [details] [diff] [review]
> Patch v1
> 
> Your changes seem good except this one:
> 
> > -pref("font.name.sans-serif.zh-TW", "Apple LiGothic");  
> > +pref("font.name.sans-serif.zh-TW", "Heiti TC");  
> > 
> > -pref("font.name.sans-serif.zh-HK", "LiHei Pro");
> > +pref("font.name.sans-serif.zh-HK", "Heiti TC");
> 
> Looking at this a little closer, I'm not sure I agree with the change
> from Apple LiGothic to HeitiTC.  I think LiHei Pro might be a better
> choice as a default font.
> 
> I think there are two interrelated but slightly different problems,
> the appearance of the default font and it's glyph coverage.  The glyph
> coverage is actually determined by the union of the 'font.name.xxx'
> font *and* 'font.name-list.xxx', so including a font in the
> 'font.name-list.xxx' will increase the coverage without affecting the
> look of the default font.
> 
> My major concern is that the design of Latin glyphs in HeitiTC seems
> very poor, the glyphs are less readable than those of LiHei Pro and
> they don't work well when rendered at the same size as the surrounding
> Chinese text:
> 
> http://people.mozilla.org/~jdaggett/tests/zhtwfonts.html
> 
> To some degree I imagine many sites effectively mask this problem by
> using normal Latin fonts by default (e.g.
> "arial,helvetica,clean,sans-serif" on http://tw.yahoo.com/).  Apple
> does this also, Lucida Grande is specified at the front of the font
> list so the Latin text is effectively much more readable.
> 
> From the discussion within the Taiwan community, are there specific
> sites that definitely look better with HeitiTC when compared to LiHei
> Pro, given the recent changes to the fallback fonts that should fix
> some of the glyph coverage problems?  If so, could you list them in
> the bug here?
Almost every sites looks better in Heiti TC then LiHei Pro, 
the main problem is that LiHei Pro is too heavy, 
and if you add another weight to the paragraph, 
it's far more heavy then we desired.

And another argue is that we'd to respect the system's default font (that's many user's opinion on the issue),
and OSX had been transfer zhtw default fonts to Heiti TC for almost 2.5 years.
most of the web designer and users is familiar and desire to Heitit TC then LiHei Pro these days.
(In reply to John Daggett (:jtd) from comment #15)
> My major concern is that the design of Latin glyphs in HeitiTC seems
> very poor, the glyphs are less readable than those of LiHei Pro and
> they don't work well when rendered at the same size as the surrounding
> Chinese text:
> 
> http://people.mozilla.org/~jdaggett/tests/zhtwfonts.html
> 
> To some degree I imagine many sites effectively mask this problem by
> using normal Latin fonts by default (e.g.
> "arial,helvetica,clean,sans-serif" on http://tw.yahoo.com/).  Apple
> does this also, Lucida Grande is specified at the front of the font
> list so the Latin text is effectively much more readable.

Thanks for review the patch!

To address your concern, on Windows platform we use Latin fonts as the default font, and move on to Chinese fonts in name-lists:

http://hg.mozilla.org/mozilla-central/diff/be0b61e0ed53/modules/libpref/src/init/all.js#l1.42

If that works for you we should also do this on Mac. IMO it's better.
I will submit another patch that uses Latin font as default if you agree we should use the Windows approach.

As of the first Chinese font on name-list, the community want it change to Heiti TC (and LiSong Pro for serif), staying away from LiHei Pro and LiGothic. Please specify the reason of objection (if any). Thanks.
What does Safari render with when 'font-family: sans-serif' is used for Chinese text, both with and without a proper lang tag?  On my machine it appears to use Hiragino Kaku Gothic Pro as the default but it might be somehow sniffing that my machine is in a Japanese locale.
(In reply to John Daggett (:jtd) from comment #19)
> What does Safari render with when 'font-family: sans-serif' is used for
> Chinese text, both with and without a proper lang tag?  On my machine it
> appears to use Hiragino Kaku Gothic Pro as the default but it might be
> somehow sniffing that my machine is in a Japanese locale.

From your test case (i.e. with a lang tag), Safari renders the text in Heiti TC on my machine.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #20)
 
> From your test case (i.e. with a lang tag), Safari renders the text in Heiti
> TC on my machine.

I just tweaked the testcase to include an example that only uses "font-family: sans-serif'.  Could you attach a screenshot the 'sans-serif' case from Safari on your machine?  I just want to confirm that it's using the Latin glyphs from Heiti TC.
Safari does not render Latin glyths in Heiti TC. Sorry for the confusion.

http://cl.ly/033C1v2J1J2W3B380h0y

In parity with this behavior, we should use the forementioned "Windows approach".
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #22)
> Safari does not render Latin glyths in Heiti TC. Sorry for the confusion.
> 
> http://cl.ly/033C1v2J1J2W3B380h0y
> 
> In parity with this behavior, we should use the forementioned "Windows
> approach".

Yeah, setting Helvetica as the default font (font.name.sans-serif.zh-TW) with font.name-list.sans-serif.zh set to 'Helvetica,Heiti TC,Apple LiGothic' should do the right thing in all cases (including on 10.5).
To replicate the behavior of zh-TW users under OSX:

1. Open Settings > Languages & Text
2. Drag [繁體中文] so that it is the second language in the list
3. Quit and restart Safari

Result: Safari uses Helvetia/Heiti TC as the default font for Chinese.

This is necessary since by default Japanese [日本語] may be above Traditional Chinese in the list, in which case Hiragino Kaku Gothic is used instead.
Attached patch Patch v2Splinter Review
New patch.

Is there any reason preferring LiGothic over LiHei Pro in 10.5? If not I will use LiHei Pro for both zh-TW and zh-HK.
Attachment #606108 - Attachment is obsolete: true
Attachment #606138 - Flags: review?(jdaggett)
Attachment #606108 - Flags: review?(jdaggett)
Ok, working on the new patch right now.

Is there a reason to prefer LiGothic over LiHei Pro for 10.5? If not I will use LiHei Pro for 10.5 for both zh-TW and zh-HK.
Component: Preferences → Layout: Text
Product: Firefox → Core
QA Contact: preferences → layout.fonts-and-text
Comment on attachment 606138 [details] [diff] [review]
Patch v2

I think this makes sense, I like the fact that we're making the
Traditional Chinese settings consistent for the zh-TW and zh-HK cases.
Attachment #606138 - Flags: review?(jdaggett) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #26)
> Ok, working on the new patch right now.
> 
> Is there a reason to prefer LiGothic over LiHei Pro for 10.5? If not I will
> use LiHei Pro for 10.5 for both zh-TW and zh-HK.

No, LiGothic is far more older then LiHei Pro, 
we should have replaced them several years ago.

HeiTi TC is better then both anyway.
Attachment #606147 - Attachment description: Patch to commit → Patch to checkin
Target Milestone: --- → mozilla14
Thank you very much :)
Target Milestone: mozilla14 → ---
Target Milestone: --- → mozilla14
By the way, is there any change for this patch land on beta and aurora also? Should I turn on the review flags for that?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #33)
> By the way, is there any change for this patch land on beta and aurora also?
> Should I turn on the review flags for that?

I could easily see the argument for landing this on aurora, I don't see the case for landing this on the beta branch.  The changes are small and localized, it's not necessary to generate another patch specifically for aurora.
(In reply to John Daggett (:jtd) from comment #34)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #33)
> > By the way, is there any change for this patch land on beta and aurora also?
> > Should I turn on the review flags for that?
> 
> I could easily see the argument for landing this on aurora, I don't see the
> case for landing this on the beta branch.  The changes are small and
> localized, it's not necessary to generate another patch specifically for
> aurora.

Right. I was meant to say "any chances". What should I do to have this landed to Aurora?
https://hg.mozilla.org/mozilla-central/rev/4a13ae950538
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee: nobody → timdream
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: