Bug 119041

Summary: zh_* cannot get the best matched font
Product: [Fedora] Fedora Reporter: Leon Ho <llch>
Component: pangoAssignee: Owen Taylor <otaylor>
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: eng-i18n-bugs, llim, wtogami
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-21 14:39:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 114961, 125270    
Description Flags
screenshot for zh_CN
gedit screenshot none

Description Leon Ho 2004-03-24 07:31:04 UTC
Description of problem:
With locale of zh_*, it seems match sans with Kochi Gothic and hence
font display is not desirable.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. LANG=zh_{TW,CN}.UTF-8 gedit
Actual results:
Sans matches different fonts like kochi font etc

Expected results:
Match and use AR PL fonts

Additional info:

Comment 1 Leon Ho 2004-03-24 07:31:42 UTC
Created attachment 98819 [details]
screenshot for zh_CN

Comment 2 Leon Ho 2004-04-07 03:29:23 UTC
Submitted the bug to upstream:

Comment 3 Leon Ho 2004-04-07 04:07:46 UTC
*** Bug 120246 has been marked as a duplicate of this bug. ***

Comment 4 Yu Shao 2004-04-07 04:25:29 UTC
Hi Owen, lang is not used in fonts.conf which could cause problems,
any reason not using it?

Comment 5 Yu Shao 2004-04-07 05:05:44 UTC
If asking "Sans" directly to fontconfig, I can get "AR PL SungtiL GB",
but setting "Sans" in gnome-font-properties will get a different one
which is used in Gnome by default right now.

Comment 6 Leon Ho 2004-04-21 05:41:27 UTC

I tried patched on the FcOpContains, and on latest CVS of fontconfig:

When I do "LANG=zh_TW.UTF-8 fc-match --sort 'sans\-serif:lang=zh-tw'"
it returns me with 'bsmi00lp.ttf: "AR PL Mingti2L Big5" "Reguler"' first.

However if I run "LANG=zh_TW.UTF-8 gedit" it still uses Kochi Gothic

If I then move "Kochi Gothic" in fonts.conf to under "AR PL Mingti2L
Big5" first then gedit uses AR PL Mingti2L Big5.

Is it related to pango? Would you give me some tips on where should I
look into?
In the meantime, can we add back the old style that append the font on
top base on the language?

Comment 7 Jeremy Katz 2004-05-07 03:58:29 UTC
Has any progress been made on this?

Comment 8 Nakai 2004-05-07 14:31:37 UTC
Chinese environment absolutely should not get dirty with Japanese font.
And current Kochi fonts quality is something like Pablo Picasso,
far from reliable productivity even for Japanese.

Sounds like severity high, and not critical for Chinese users?

Comment 9 Leon Ho 2004-05-21 04:52:07 UTC
KDE got simliar problem but maybe the bug is different. For reference:
bug 123868

Comment 10 Lawrence Lim 2004-06-11 03:49:27 UTC
The symtoms of Bug 120246 which has been marked as a duplicate of this
Bug still exists in RHEL4-alpha3. 

Comment 11 Leon Ho 2004-06-11 05:11:56 UTC
llim, those KDE bugs seems different. I can able to pinpoint and patch
it on qt level. Please see bug 123868, so seems fontconfig is okay.

Any pango expert wanna have a go on this bug? :)

Comment 12 Leon Ho 2004-06-21 07:10:48 UTC
I spent more time onto this bug, here is my findings:
- debugged that for any glyphs that's han unicode range (zh_TW,
zh_CN), it returns lang as "xx" for fontconfig
- it is in compute_derived_language() that
pango_script_get_sample_language() returns NULL on PangoLanguage which
then compute_derived_language() will use "xx" as lang
- in pango_script_get_sample_language()'s sample_languages[]
- if that entry has "zh" then it get the correct font before it passes
lang='zh' to fontconfig again
- maybe there is a reason for emptying it because zh-tw and zh-cn
shares with same script range, and both pass "zh" in that case, but it
should pass zh-tw and zh-cn for different locale.

- however there aren't any other cases for getting language initially
as pango_itemize_with_base_dir() passes (ItemizeState *)stage to
itemize_state_process_run() and passes stage to
itemize_state_update_for_new_run() passes stage->lang into

- pango_itemize_with_base_dir() is just initialized ItemizeState
*state with stage->lang = NULL and passed immediately

- So the only way is get PangoLanguage from
pango_script_get_sample_language() initially. 

Owen, should sample_languages[] PANGO_SCRIPT_HAN entry have 'zh' or
there is another routine should be introduce to handle zh-*?

Comment 13 Owen Taylor 2004-06-21 19:56:48 UTC
This is the same as

The bug here turned out to be really embarassing. We were never
taking the language tag from the environment into account at all.
I'm going to make a Pango-1.5.0 release in the next few days
and build that into fc3. Do you think that we should do a 
fc2 update for this as well?

Comment 14 Leon Ho 2004-06-21 22:48:30 UTC
Yes, it would be great to update fc2 for this bug as well, as several
users from the community have apporached me and worry about this bug.
Thank you!

Comment 15 Leon Ho 2004-09-06 07:34:37 UTC
Confirmed it is fixed in rawhide. Is it still okay to update this on
fc2-updates? Anything that we can help to make that happen?

Comment 16 Owen Taylor 2004-09-09 18:56:45 UTC
There is now a Pango-1.4.1 package in FC2 testing; testing of that
package would be useful.

(Removing from FC3Target bug, this is a pango-1.4.0 specific issue)

Comment 17 Leon Ho 2004-09-10 05:46:16 UTC
I have a brief test on CJK.

zh_TW: Good
zh_CN: Good
ko_KR: Good
ja_JP: Seems it is mixed with Mincho and Gothic. Attaching the
screenshot now.

Comment 18 Leon Ho 2004-09-10 05:47:03 UTC
Created attachment 103671 [details]
gedit screenshot

Comment 19 Leon Ho 2004-09-10 05:50:45 UTC
Sorry wrong alarm - it was my environment (I have exported LC_CTYPE).

Confirmed ja_JP is okay. Please close this bug when you have moved to
fc2-updates. Thanks!

Comment 20 Lawrence Lim 2004-09-13 07:35:22 UTC
FC2-Updates is now pango-1.4.0-2.