Bug 119041
Summary: | zh_* cannot get the best matched font | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Leon Ho <llch> | ||||||
Component: | pango | Assignee: | Owen Taylor <otaylor> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 2 | CC: | eng-i18n-bugs, llim, wtogami | ||||||
Target Milestone: | --- | Keywords: | i18n | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
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: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 114961, 125270 | ||||||||
Attachments: |
|
Description
Leon Ho
2004-03-24 07:31:04 UTC
Created attachment 98819 [details]
screenshot for zh_CN
Submitted the bug to upstream: http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=415 *** Bug 120246 has been marked as a duplicate of this bug. *** Hi Owen, lang is not used in fonts.conf which could cause problems, any reason not using it? 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. Owen, 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 first. 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? Has any progress been made on this? 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? KDE got simliar problem but maybe the bug is different. For reference: bug 123868 The symtoms of Bug 120246 which has been marked as a duplicate of this Bug still exists in RHEL4-alpha3. 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? :) 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[] PANGO_SCRIPT_HAN is empty - 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 compute_derived_language() - 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-*? This is the same as http://bugzilla.gnome.org/show_bug.cgi?id=137334 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? 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! 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? 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) 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. Created attachment 103671 [details]
gedit screenshot
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! FC2-Updates is now pango-1.4.0-2. |