[Fedora-i18n-bugs] [Bug 572841] New: WQY Zenhei is used on Firefox with ja_JP
bugzilla at redhat.com
bugzilla at redhat.com
Fri Mar 12 07:07:29 UTC 2010
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: WQY Zenhei is used on Firefox with ja_JP
https://bugzilla.redhat.com/show_bug.cgi?id=572841
Summary: WQY Zenhei is used on Firefox with ja_JP
Product: Fedora
Version: 13
Platform: All
URL: http://picasaweb.google.com/fangqq/ProposalForFontconf
igSettingsForCJKLanguages
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: vlgothic-fonts
AssignedTo: extras-orphan at fedoraproject.org
ReportedBy: tagoh at redhat.com
QAContact: extras-qa at fedoraproject.org
CC: tagoh at redhat.com, petersen at redhat.com,
nicolas.mailhot at laposte.net, besfahbo at redhat.com,
extras-orphan at fedoraproject.org, fangqq at gmail.com,
fonts-bugs at lists.fedoraproject.org,
fedora-i18n-bugs at redhat.com
Depends on: 499902
Blocks: 507681,554911
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Clone Of: 499902
+++ This bug was initially created as a clone of Bug #499902 +++
Created an attachment (id=343146)
--> (https://bugzilla.redhat.com/attachment.cgi?id=343146)
language specific fontconfig settings for Japanese
The CJK language fontconfig settings has been a long-standing issue ever since
the beginning of using fontconfig. There hasn't been a good solution yet. The
major difficulties for causing this problem, IMO, include
1. the default 65-nonlatin.conf was badly outdated with unoptimized font orders
2. there are no CJK language-specific fontconfig files, therefore, to override
the default orders, one has to add font prefer list in the fontconfig settings
shipped with individual CJK font package.
3. because these settings were scattered into many font packages, this further
makes the problem complex, and the conflict between different CJK font packages
became more and more frequent.
To solve this issue, I propose the following solution
1. update 65-nonlatin.conf and setup an optimized and up-to-date font list
2. add language specific fontconfig settings, defining font preferred orders
with for a given lang tag, and assign these files a lower number than 65
3. remove all font order settings from all CJK related font packages
For solution step 1, I proposed a completely updated 65-nonlatin.conf at
http://bugs.freedesktop.org/show_bug.cgi?id=20911 . My rationale of the font
orders was also explained in details.
For solution step 2, I created two default settings for ja and zh locales (that
for ko can be done similarly) as examples, and you can find them in the
attachments. Because I used lang tag matching in the rules, these files can be
installed concurrently (in this sense, it is better than the language-selector
in Ubuntu, which needs to run fontconfig-voodoo to link a set of active config
under a given language).
I did the following to test this proposal. From what I saw for zh-*, ja and en
locales, all the wanted features were working properly.
Here are the details of my test:
First, I did this test with rawhide updated this morning. On the system, I
installed chinese-support and japanese-support, including wqy-bitmap-fonts,
wqy-zenhei-fonts, arphic-uming, vlgothic-fonts and some mincho Japanese font.
To clean up all the font config settings, I "su" to root, and run the following
cd /etc/fonts/conf.d/
mkdir cjk
mv *wqy* cjk
mv *vlgo* cjk
mv *arphic* cjk
mv *gothic* cjk
This is just a quick way to get rid of all the font-wise preference settings.
In the future, most of these files can stay, as long as they remove the blocks
to set <prefer> or prepend family names.
The second step is to update (of course, make a backup first) the
65-nonlatin.conf by downloading from the attachment at
http://bugs.freedesktop.org/show_bug.cgi?id=20911
Then, download the 55-language_fonts_ja-jp.conf and
55-language_fonts_zh-cn.conf from this thread and save them under
/etc/fonts/conf.d/ . This completes the settings.
For Chinese users, some of them prefer bitmap glyphs for Han characters (35%),
some prefer vectors (65%). This is controlled by installing wqy-bitmap-fonts or
uninstalling the bitmap fonts.
I tested my proposed settings for English, Japanese and Chinese languages, with
bitmap preferred settings and vector preferred settings. My screenshots for all
combination can be found at this online album:
http://picasaweb.google.com/fangqq/ProposalForFontconfigSettingsForCJKLanguages
When bitmap font is installed, for en and zh desktops, fonts at sizes 9pt ~
12pt will be rendered as bitmaps for all font aliases (sans,serif, mono);
otherwise, it will be rendered by the respective vector fonts. Particularly,
for en desktop, no more font-mosaic problems caused by high priority of
Japanese fonts (such as
http://picasaweb.google.com/fangqq/ConfigScreenshot#5333302146968242258) . When
one remove the bitmap fonts, all Hanzi glyphs were rendered by the preferred
vector fonts, as expected (some remaining ones are from UMing, which I did not
disable).
For ja desktop, all fonts were rendered by their preferred vector fonts, no
matter bitmap Chinese fonts installed or not (please ignore "驿" and "阵" as they
are not defined in JIS).
I believe this approach greatly simplifies the CJK font settings by
centralizing the related settings to language specific files. All the expected
basic rendering order were achieved with the current proposed config files. Of
course one can fine-tune them further. For Korean users, a
55-language-fonts-ko.conf file can be made similarly.
It will be really great if this proposal can be tested and agreed by all CJK
font package maintainers.
--- Additional comment from fangqq at gmail.com on 2009-05-08 15:17:13 EDT ---
Created an attachment (id=343148)
--> (https://bugzilla.redhat.com/attachment.cgi?id=343148)
language specific fontconfig settings for Chinese
--- Additional comment from fedora-triage-list at redhat.com on 2009-06-09
11:29:05 EDT ---
This bug appears to have been reported against 'rawhide' during the Fedora 11
development cycle.
Changing version to '11'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from petersen at redhat.com on 2010-03-03 04:20:46 EST ---
Closing since this issue has been under discussion upstream.
--- Additional comment from petersen at redhat.com on 2010-03-04 05:17:53 EST ---
Reopening since WQY Zenhei is still overriding vlgothic in Japanese
webpages in firefox.
--- Additional comment from fangqq at gmail.com on 2010-03-10 02:10:02 EST ---
I don't see how this can still happen. Please attach your FC_DEBUG output of a
test command, for example
pango-view --waterfall --text='与返骨直' --language=ja
--- Additional comment from tagoh at redhat.com on 2010-03-11 08:41:30 EST ---
(In reply to comment #4)
> Reopening since WQY Zenhei is still overriding vlgothic in Japanese
> webpages in firefox.
That's the "ll v.s. ll-cc" issue. I've tried to run firefox with FC_DEBUG=4 and
have a look at the logs. I see they requested both of lang="ja-jp" and
lang="ja" in the queries of the font. ideally it would be nice to fix this
issue in fontconfig though, we may want to think about a workaround in firefox
for that?
Or add a rule for "ll" in every fonts... dunno.
--- Additional comment from fangqq at gmail.com on 2010-03-11 19:58:24 EST ---
replied from gmail, but never show up, repost.
(In reply to comment #6)
> That's the "ll v.s. ll-cc" issue. I've tried to run firefox with FC_DEBUG=4 and
> have a look at the logs. I see they requested both of lang="ja-jp" and
> lang="ja" in the queries of the font. ideally it would be nice to fix this
> issue in fontconfig though, we may want to think about a workaround in firefox
> for that?
>
> Or add a rule for "ll" in every fonts... dunno.
If I were you, I would use the following construct
<test name="lang" compare="contains"><string>ja</string></test>
to get around this. It is not as dangerous as some of you might think, the
language tags are rather stable in Linux.
Of course, the ideal solution would be to ask fontconfig to support
regular-expression in compare, something like
<test name="lang" compare="regex"><string>^ja(-\w+)*</string></test>
--- Additional comment from tfujiwar at redhat.com on 2010-03-11 21:04:33 EST ---
(In reply to comment #7)
> If I were you, I would use the following construct
> <test name="lang" compare="contains"><string>ja</string></test>
> to get around this. It is not as dangerous as some of you might think, the
> language tags are rather stable in Linux.
Me either.
--- Additional comment from tagoh at redhat.com on 2010-03-12 02:00:36 EST ---
(In reply to comment #7)
> If I were you, I would use the following construct
> <test name="lang" compare="contains"><string>ja</string></test>
> to get around this. It is not as dangerous as some of you might think, the
> language tags are rather stable in Linux.
Sure. it looks good in this case but it may depends. we had experienced a bug
like http://bugs.freedesktop.org/show_bug.cgi?id=23419. it may be too early
saying that is stable in _Linux_.
> Of course, the ideal solution would be to ask fontconfig to support
> regular-expression in compare, something like
> <test name="lang" compare="regex"><string>^ja(-\w+)*</string></test>
FWIW "contains" isn't supposed to check the language name comparison only. it
tries to check the code coverage with orth files first and then compare the
name if it fails.
--- Additional comment from tagoh at redhat.com on 2010-03-12 02:03:46 EST ---
hmm, it may be good to keep this AS IS and close upstream again. I'll make a
clone for vlgothic-fonts specific issue.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the i18n-bugs
mailing list