[Fedora-i18n-bugs] [Bug 492510] New: Regression: wqy-bitmap-fonts preferred font over truetype fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Regression: wqy-bitmap-fonts preferred font over truetype fonts
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Summary: Regression: wqy-bitmap-fonts preferred font over truetype fonts Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: wqy-bitmap-fonts AssignedTo: fangqq@gmail.com ReportedBy: wtogami@redhat.com QAContact: extras-qa@fedoraproject.org CC: petersen@redhat.com, fangqq@gmail.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-bugs@redhat.com Estimated Hours: 0.0 Classification: Fedora Target Release: ---
Failure Case 1: gramps PDF generation ===================================== gramps is a genealogy application that generates PDF charts. It seems to ask pango to choose fonts for it based upon given glyphs.
* In Fedora 10, it successfully output charts using entirely truetype fonts. * In Fedora 11 however, the UTF-8 Chinese characters are rendered in PDF as bitmap fonts, which do not scale properly and are ugly compared to the truetype equivalents.
http://bugzilla.gnome.org/show_bug.cgi?id=576890 Behdad proposes this bug upstream, which would workaround this type of issue at least for vector rendering cases like PDF generation. I am uncertain if this is correct though, and it creates possibly inconsistent behavior?
Failure Case 2: pango-view ========================== Here is a similar way to reproduce this bug: LANG=en_US.utf8 pango-view --text "日本語 test" --font "100" LANG=zh_CN.utf8 pango-view --text "日本語 test" --font "100"
English pango renders the Chinese characters as ugly bitmap. Chinese pango renders the Chinese characters as truetype.
Workaround: uninstall wqy-bitmap-fonts ====================================== Both of the above problems go away if you uninstall wqy-bitmap-fonts. But this should not be necessary.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #1 from Akira TAGOH tagoh@redhat.com 2009-03-27 02:58:29 EDT --- Created an attachment (id=336970) --> (https://bugzilla.redhat.com/attachment.cgi?id=336970) new fontconfig conf for wqy-bitmap-fonts
I think I managed to get this fixed with this proposed fontconfig config for wqy-bitmap-fonts. we may need to do more review for this new fontconfig. I'll post this to fedora-fonts-list later. anyway, you can test it if you like.
Please let me know if I'm missing something.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tagoh@redhat.com
--- Comment #2 from Akira TAGOH tagoh@redhat.com 2009-03-27 03:08:50 EDT --- erm, totally broken config.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #3 from Akira TAGOH tagoh@redhat.com 2009-03-27 04:33:15 EDT --- Created an attachment (id=336973) --> (https://bugzilla.redhat.com/attachment.cgi?id=336973) new fontconfig conf for wqy-bitmap-fonts (2nd try)
Note that "priority list" rules in 65-nonlatin.conf also breaks this order of the font. you need to remove an entity from there first.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #336970|0 |1 is obsolete| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #4 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-03-27 05:02:25 EDT --- Some feedback (but I'm *not* a CJK user so my opinion does not count much) :
1. our current practice is to forbid CJK fontconfig rules bellow 65. The current package violates this by putting stuff at 61
2. IMHO the fontconfig rules in a package should never declare rules for fonts not included in this package. So I'd dump all the rules not dealing with "WenQuanYi Bitmap Song". If someone wants "AR PL ShanHeiSun Uni" rules he can ask to have them added to the Fedora package that ships "AR PL ShanHeiSun Uni" (if any)
3. IMHO it's also bad practice to declare a font in several generic families choose serif, sans-serif or monospace but not all of them
4. what's the point of <match> <test name="lang" compare="contains"> <string>zh</string> </test> <test name="family"> <string>monospace</string> </test> <test name="pixelsize" compare="more"> <double>16</double> </test> </match> ???
So to sum up, you've simplified a bit but it needs to be simplified a lot more, this file tries to be too clever by half and only succeeds in confusing apps and users
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #5 from Akira TAGOH tagoh@redhat.com 2009-03-27 06:11:50 EDT --- Well, I'm not a good person to answer all of questions but just tried to keep alive as much as possible and get rid of issue only there. and this fontconfig rule should be argued on bugzilla and the maling list before as far as I can read a bugzilla in changelog but anyway. so with thinking of that:
(In reply to comment #4)
- IMHO the fontconfig rules in a package should never declare rules for fonts
not included in this package. So I'd dump all the rules not dealing with "WenQuanYi Bitmap Song". If someone wants "AR PL ShanHeiSun Uni" rules he can ask to have them added to the Fedora package that ships "AR PL ShanHeiSun Uni" (if any)
In that sense, adding them to a package that has "AR PL ShanHeiSunUni" and "AR PL ZenKai Uni" also violates that rule, yes? Current rules might breaks applications (or just nothing happens and fallback next then though) if no "AR PL ShanHeiSun Uni" package is installed and vice versa. I don't know how much needs there are to have such rules though.
- what's the point of
<match> <test name="lang" compare="contains"> <string>zh</string> </test> <test name="family"> <string>monospace</string> </test> <test name="pixelsize" compare="more"> <double>16</double> </test> </match> ???
My understanding was, they want to have a outlined font instead of bitmap font if the pixel size is out of range what the font support. the original fontconfig conf didn't have a testing of lang though, just added it so that the font has to be added to the list instead of using the priority list.
So to sum up, you've simplified a bit but it needs to be simplified a lot more, this file tries to be too clever by half and only succeeds in confusing apps and users
Personally we should add all of bitmap fonts to the black list for fontconfig because mixing up the bitmap font and the outlined font looks ugly and they only support limited sizes. that would be highly likely to see such situation. particularly for CJK bitmap fonts. when gathering fonts for different sizes to use enough, the designs among different sizes aren't necessarily consolidated well because they have a lot of glyphs and different authors may has made it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #6 from Qianqian Fang fangqq@gmail.com 2009-03-27 10:10:01 EDT --- (In reply to comment #0)
Failure Case 1: gramps PDF generation
This looks to me really should be a cairo bug, as Behdad reported in his upstream bug. Bitmaps are only preferred when rendering on-screen font sizes, i.e. 11px~16px, as defined in 61-wqy-bitmapfont.conf. But for printing, the font sizes should be way bigger than that, and should by-pass bitmap rendering.
Failure Case 2: pango-view
Here is a similar way to reproduce this bug: LANG=en_US.utf8 pango-view --text "日本語 test" --font "100" LANG=zh_CN.utf8 pango-view --text "日本語 test" --font "100"
English pango renders the Chinese characters as ugly bitmap. Chinese pango renders the Chinese characters as truetype.
Again, I think this is not an issue for wqy-bitmap-fonts, rather, this is an old problem associated with the absence of preferred language (i.e. PANGO_LANGUAGE) when rendering CJK characters under non-CJK locales.
Indeed, there are two issues tangled together:
First, pango can not tell if "日本語" are Japanese Kanji or Chinese Hanzi, while PANGU_LANGUAGE is not defined under non-CJK language, so, pango will not mark the character with the proper language tags, and some CJK specific fontconfig rules will be bypassed.
Second, as a result of the above, the font rendering is now handled to fontconfig without proper language tag, while the default font orders in fontconfig 65-non-latin is very outdated. Mixed with proprietary fonts with free fonts, low quality fonts with small Unicode coverage were placed in front of more complete and polished fonts. In this case, the rendering of Chinese is horrible, mixed by Japanese Gothic, Mincho and Chinese Song/Kai glyphs, see
http://wenq.org/gallery/albums/userpics/10002/confopt_F8_no_wqy-bitmap_en-us...
In order to display Chinese properly under non-CJK fonts, I proposed using wqy-bitmap-fonts as the default CJK fonts for en locales, (many friends and I myself work under en_US locales but want to use Chinese):
http://markmail.org/message/waeyjb3hqkpglfgk
To solve this issue, I suggest to correct two things:
1. define default PANGO_LANGUAGE definition for non-CJK locales, preferably "zh". Because zh contains more complete unicode coverage (20000 characters vs. 6000 for ja and ko) which will give a more uniform look of the rendering; and there are several default Chinese fonts support large char set, such as wqy-bitmap-fonts (>27000 Hanzi), wqy-unibit-fonts(>27000 Hanzi), wqy-zenhei-fonts (=20932), and all the Arphic fonts (>20000 Hanzi). In comparison, Japanese fonts contains too little Han glyphs, and the quality is not impressive.
2. update 65-non-latin.conf. it is too old and only makes more troubles if it stay the way it is.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #7 from Qianqian Fang fangqq@gmail.com 2009-03-27 10:18:40 EDT --- (In reply to comment #4)
Some feedback (but I'm *not* a CJK user so my opinion does not count much) :
- our current practice is to forbid CJK fontconfig rules bellow 65. The
current package violates this by putting stuff at 61
As I said, because 65-non-latin is extremely outdated, and no one try to chance this situation, plus that you told me it is not good to use prepend_first in the fontconfig files, then, the only way to by-pass the default font rendering order is to use a lower number. That's why I named 85-wqy-bitmapfont.conf to 61-wqy-bitmapfont.conf.
It is really 65-non-latin should be fixed, not wqy-bitmap-fonts.
- IMHO the fontconfig rules in a package should never declare rules for fonts
not included in this package. So I'd dump all the rules not dealing with "WenQuanYi Bitmap Song". If someone wants "AR PL ShanHeiSun Uni" rules he can ask to have them added to the Fedora package that ships "AR PL ShanHeiSun Uni" (if any)
same as above.
- IMHO it's also bad practice to declare a font in several generic families
choose serif, sans-serif or monospace but not all of them
because wqy-bitmap-fonts is not monospaced.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Warren Togami wtogami@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(fangqq@gmail.com)
--- Comment #8 from Warren Togami wtogami@redhat.com 2009-03-27 10:29:06 EDT --- Do statements like "quality is not impressive" have agreement from our Japanese developers? This might very well be true, but we need to avoid the appearance of cultural favoritism.
First, pango can not tell if "日本語" are Japanese Kanji or Chinese Hanzi, while PANGU_LANGUAGE is not defined under non-CJK language, so, pango will not mark the character with the proper language tags, and some CJK specific fontconfig rules will be bypassed.
What is the purpose of CJK specific fontconfig rules, and why is it necessary for CJK to behave differently than non-CJK when dealing with CJK-glyphs?
Do C, J and K fontconfig rules differ from each other?
- update 65-non-latin.conf. it is too old and only makes more troubles if it
stay the way it is.
What do you suggest for this?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #9 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-03-27 10:47:27 EDT --- (In reply to comment #8)
What is the purpose of CJK specific fontconfig rules, and why is it necessary for CJK to behave differently than non-CJK when dealing with CJK-glyphs?
Do C, J and K fontconfig rules differ from each other?
CJK is a mess because Chinese, Japanese and Korean use the same codepoints, but the expected glyphs shapes are different depending on the language you type.
The problem exists to a lesser extent for arabic.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(fangqq@gmail.com) |
--- Comment #10 from Qianqian Fang fangqq@gmail.com 2009-03-27 12:16:58 EDT --- (In reply to comment #8)
- update 65-non-latin.conf. it is too old and only makes more troubles if it
stay the way it is.
What do you suggest for this?
filed a bug to fontconfig: https://bugs.freedesktop.org/show_bug.cgi?id=20911
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |446452(F11Blocker)
--- Comment #11 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-03-27 12:24:38 EDT --- Setting F11blocker, fontconfig order issue is really a blocker for CJK people.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #12 from Akira TAGOH tagoh@redhat.com 2009-03-29 21:36:45 EDT --- (In reply to comment #6)
To solve this issue, I suggest to correct two things:
- define default PANGO_LANGUAGE definition for non-CJK locales, preferably
"zh". Because zh contains more complete unicode coverage (20000 characters vs. 6000 for ja and ko) which will give a more uniform look of the rendering; and there are several default Chinese fonts support large char set, such as wqy-bitmap-fonts (>27000 Hanzi), wqy-unibit-fonts(>27000 Hanzi), wqy-zenhei-fonts (=20932), and all the Arphic fonts (>20000 Hanzi). In comparison, Japanese fonts contains too little Han glyphs, and the quality is not impressive.
This won't solves anything due to the priority list as I said. for example:
% LANG=en_US.utf8 pango-view --text '<span lang="ja">日本語</span> test' --markup --font "100"
This doesn't make any difference of result with/without lang tag if wqy-bitmap-fonts is installed.
- update 65-non-latin.conf. it is too old and only makes more troubles if it
stay the way it is.
I agree with this. we should add it in own fontconfig conf for specific languages.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #13 from Qianqian Fang fangqq@gmail.com 2009-03-29 23:40:50 EDT --- (In reply to comment #12)
This won't solves anything due to the priority list as I said. for example:
% LANG=en_US.utf8 pango-view --text '<span lang="ja">日本語</span> test' --markup --font "100"
This doesn't make any difference of result with/without lang tag if wqy-bitmap-fonts is installed.
I tried this on F10, it worked fine. However, when I tried to upgrade F10 to rawhide via yum, it aborted due to some dependency problem (missing dependency: python(abi)). I haven't figured out how to get around.
If you are seeing magnified bitmaps rather than vector fonts, there must be something else broken in rawhide, likely cairo as suspected in my first reply. Since nothing was changed for wqy-bitmap-fonts from F10 to F11, I have to know what else caused the problem in order to fix the fontconfig settings, if needed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #14 from Akira TAGOH tagoh@redhat.com 2009-03-30 01:13:30 EDT --- It's not magnified but drawing different size of glyphs for "日本語" and "test". As Warren said, this strange behavior is gone if uninstalling wqy-bitmap-fonts package, or removing "WenQuanYi Bitmap Song" from 65-nonlatin.conf and the priority list rule from 61-wqy-bitmapsong.conf.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Warren Togami wtogami@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?
--- Comment #15 from Warren Togami wtogami@redhat.com 2009-04-12 23:08:02 EDT --- Is this going to be fixable before F-11?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo? |
--- Comment #16 from Jens Petersen petersen@redhat.com 2009-04-14 01:39:46 EDT --- Warren, how are you installing wqy-bitmap-fonts? Through @chinese-support?
Given that the font is not installed by default for non-Chinese users, I am not certain this is a blocker but it would certainly be nice to improve the longing standing CJK-related fontconfig problems.
I guess one workaround may be to install wqy-zenhei-fonts in addition to wqy-bitmap-fonts.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #17 from Jens Petersen petersen@redhat.com 2009-04-14 03:42:08 EDT --- (In reply to comment #16)
Warren, how are you installing wqy-bitmap-fonts? Through @chinese-support?
(Apparently)
I guess one workaround may be to install wqy-zenhei-fonts in addition to [or instead of??] wqy-bitmap-fonts.
Unfortunately wqt-zenhei overrides ja default font on ja desktop even... so needs fixing too IMHO.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #18 from Akira TAGOH tagoh@redhat.com 2009-04-14 09:23:12 EDT --- still happens on current rawhide with packages:
cjkuni-ukai-fonts-0.2.20080216.1-23.fc11 cjkuni-uming-fonts-0.2.20080216.1-23.fc11 fontconfig-2.6.99.behdad.20090318-1.fc11 vlgothic-fonts-20090204-3.fc11 vlgothic-p-fonts-20090204-3.fc11 wqy-bitmap-fonts-0.9.9-9.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #19 from Jens Petersen petersen@redhat.com 2009-04-15 02:51:29 EDT --- It is not something I want to do but another easier workaround for this issue would be not to install wqy-bitmap-fonts by default in @chinese-support.
In the longer term I would prefer really just to install outline fonts for languages by default.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(wtogami@redhat.co | |m)
--- Comment #20 from Qianqian Fang fangqq@gmail.com 2009-04-15 23:42:27 EDT --- but you are requesting to display fonts at 100pt, and the bitmaps shall not be used for this in the first place!
I seriously don't believe this is the problem of wqy-bitmap-fonts (and the fontconfig orders), there must be something wrong for choosing fonts at larger font sizes. I highly suspect this is related to what reported in http://bugzilla.gnome.org/show_bug.cgi?id=576890
since wqy-bitmap-fonts has been fine for F9 and F10, and nothing has been changed, why would it suddenly became a problem?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Warren Togami wtogami@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(wtogami@redhat.co | |m) |
--- Comment #21 from Warren Togami wtogami@redhat.com 2009-04-16 01:53:16 EDT --- 100pt is not desired, 100pt only demonstrates easily that one is bitmap, the other truetype.
It uses bitmap + truetype at ANY size.
I don't know the answers to this. I only know that the behavior changed since F-10 and it is now worse.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #22 from Qianqian Fang fangqq@gmail.com 2009-04-17 00:07:26 EDT --- then I think the best strategy would be check those packages that got updated from F10 to F11. My biggest suspicion is still cairo, the next biggest one is the font matching algorithm in fontconfig.
Again, the expected behavior should be: when there exist vector fonts, bitmap fonts shall never be used at a size it does not cover unless someone explicitly re-specify the font-size in the fontconfig. F11 was the first case that I heard this rule was broken.
CJK fonts, particularly bitmap fonts, are the easiest one to be blamed, if anything in the chain of font-rendering got wrong. But this can not be the reason to abandon all the past effort for making them to work in order to cover the mistakes of other pieces in the chain.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #23 from Akira TAGOH tagoh@redhat.com 2009-04-17 01:56:32 EDT --- I'm afraid current fontconfig config from wqy-bitmap-fonts are totally broken as well as 65-nonlatin.conf. apparently the priority list affects everything. we don't have to use it for the language specific font. we have to use the language specific overrides rule at http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Locale-specific_over... to apply it for specific languages.
After getting rid of it from both of wqy-bitmapsong.conf and 65-nonlatin.conf on rawhide, WenQuanYi Bitmap Song won't appears with requesting 100pt. and this issue looks gone then.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #336973|0 |1 is obsolete| |
--- Comment #24 from Akira TAGOH tagoh@redhat.com 2009-04-17 02:55:00 EDT --- Created an attachment (id=339961) --> (https://bugzilla.redhat.com/attachment.cgi?id=339961) proposed fontconfig config
I've polished a lot from my previous proposal. it won't depends on other fonts. just works for the desired situation. this should be valid for current our policy as well.
I've tested it on rawhide and it works as expected.
1. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> rendering is ok with Japanese font
2. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> rendering is ok with Japanese font
3. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> rendering is ok with Chinese outlined font
4. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> WenQuanYi Bitmap Song is used to render 日本語
5. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 100"
--> rendering is ok with Japanese font
6. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 12"
--> rendering is ok with Japanese font
7. LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> rendering all is ok with outlined font
8. (bonus)PANGO_LANGUAGE=zh LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> WenQuanYi Bitmap Song is used to render 日本語
Which fonts are used on English locale to display non-latin characters really depends on lang tag or PANGO_LANGUAGE. so case 8 is to confirm it, but anyway.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #25 from Akira TAGOH tagoh@redhat.com 2009-04-17 03:05:57 EDT --- Oh, please update the config as needed if it's close to serif rather than sans-serif. just reading https://bugzilla.redhat.com/show_bug.cgi?id=476459#c3 and realized it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #26 from Qianqian Fang fangqq@gmail.com 2009-04-19 08:18:30 EDT --- (In reply to comment #24)
Created an attachment (id=339961)
--> (https://bugzilla.redhat.com/attachment.cgi?id=339961) [details]
proposed fontconfig config
I've polished a lot from my previous proposal. it won't depends on other fonts. just works for the desired situation. this should be valid for current our policy as well.
hi Akira
unfortunately, I could not upgrade my F10 to rawhide due to some dependency error, so I can not test it. But just from reading the fontconfig file, I am pretty sure it will lose most of the desired features this font was designed for, please read:
http://markmail.org/message/waeyjb3hqkpglfgk
and indeed, the current version of 61-wqy-bitmapsong.conf [1] contains the following block:
<match target="pattern"> <test equal="any" compare="eq" name="family"> <string>WenQuanYi Bitmap Song</string> </test> <test equal="any" compare="eq" name="family"> <string>sans-serif</string> </test> <test compare="more" name="pixelsize"> <double>16</double> </test> <edit name="family" mode="prepend" binding="same"> <string>AR PL ShanHeiSun Uni</string> </edit> </match>
in another word, if the font size requested is greater than 16px, it SHOULD be replaced by ShanHeiSun (Uming). Thus, the behavior you reported should not happen with this conf file per se (force bitmaps at 100pt). So, I am not convinced that 61-wqy-bitmapsong.conf needs to be changed to correct the error you reported.
(In reply to comment #25)
Oh, please update the config as needed if it's close to serif rather than sans-serif. just reading https://bugzilla.redhat.com/show_bug.cgi?id=476459#c3 and realized it.
as acknowledged by other Chinese font designers, it is not really proper to assign a "serif" or "sans-serif" tag for bitmap glyphs optimized for small sizes as all the "serif" features are degenerated. The purpose of these bitmaps are for screen display of Chinese, no matter what font styles they are, to reduce blurry. That's why I put bitmaps in the first place for both aliases in https://bugs.freedesktop.org/show_bug.cgi?id=20911
But one thing I can update, which is the fall-back font names. Currently, if the pixel size is >16px or <10px, it will fallback to Ukai for serif, and Uming for sans-serif. If it is more proper to use Uming for serif and ZenHei as the fallback sans-serif. I can make this change if you want.
[1] https://cvs.fedoraproject.org/viewvc/rpms/wqy-bitmap-fonts/F-10/61-wqy-bitma...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tagoh@redhat.com)
--- Comment #27 from Qianqian Fang fangqq@gmail.com 2009-04-19 08:43:20 EDT --- just realized that "AR PL ShanHeiSun Uni" was renamed to "AR PL UMing CN". So, the replacement rules I mentioned above may not valid.
Can you please do the following test on your system:
1. install wqy-bitmap-fonts, uming, wqy-zenhei-fonts (make sure you use the original package) 2. download the attached new 61-wqy-bitmapfonts.conf and replace the /usr/share/fontconfig/conf.avail/61-wqy* (or /etc/fonts/conf.d/61-wqy*, they should be the same file) 3. do your test and tell me the results for Sans and Serif.
here are my changes:
--- 61-wqy-bitmapsong.conf 2009-04-19 08:35:49.000000000 -0400 +++ 61-wqy-bitmapsong.conf.orig 2009-04-19 08:35:36.000000000 -0400 @@ -67,7 +67,7 @@ <double>16</double> </test> <edit name="family" mode="prepend" binding="same"> - <string>AR PL UMing CN</string> + <string>AR PL ZenKai Uni</string> </edit> </match> <match target="pattern"> @@ -81,7 +81,7 @@ <double>10</double> </test> <edit name="family" mode="prepend" binding="same"> - <string>AR PL UMing CN</string> + <string>AR PL ZenKai Uni</string> </edit> </match>
@@ -100,7 +100,7 @@ <double>16</double> </test> <edit name="family" mode="prepend" binding="same"> - <string>WenQuanYi Zen Hei</string> + <string>AR PL ShanHeiSun Uni</string> </edit> </match> <match target="pattern"> @@ -114,7 +114,7 @@ <double>10</double> </test> <edit name="family" mode="prepend" binding="same"> - <string>WenQuanYi Zen Hei</string> + <string>AR PL ShanHeiSun Uni</string> </edit> </match>
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(tagoh@redhat.com) |
--- Comment #28 from Qianqian Fang fangqq@gmail.com 2009-04-19 08:44:24 EDT --- Created an attachment (id=340232) --> (https://bugzilla.redhat.com/attachment.cgi?id=340232) update Uming font name for F11
use Uming as serif fallback and ZenHei as sans fallback
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?
--- Comment #29 from Qianqian Fang fangqq@gmail.com 2009-04-19 15:09:10 EDT --- Finally, I upgraded my F10 to F11. I believe the changed "ShanHeiSun" font name caused the problem you have seen (in this case, it wasn't cairo, I take back my previous suspicions).
Here were my tests:
1. edit 61-wqy-bitmapfonts.conf, replace line#100 and #114 from "AR PL ShanHeiSun Uni" to "AR PL UMing CN" (Uming should have been installed for chinese-support), and make sure "wqy-zenhei-fonts" was NOT installed.
2. do your pango-view tests, everything should work as expected, no more bitmaps: when LANG=en_US.UTF-8 and <span lang=ja>, the Han glyphs were rendered with VL Gothic; without specifying <span lang=ja> under en_US locale, it will use UMing, as I explained previously; if LANG=ja or LANG=zh, they will use the preferred fonts for the respective locale.
@Akira:
can you repeat the test above and let me know if you think the results are ok with you? I will commit this change when I get your confirmation.
<start off-topic to Bug476459> Now, things are getting a little bit complicated if I install wqy-zenhei-fonts. As I said, for Chinese, UMing is a serif font, and ZenHei is a sans-serif font. So, ideally, I should use the patch I posted earlier this morning. However, this is related to Bug#476459: if I install wqy-zenhei-fonts, VL Gothic will be replaced by ZenHei. Looking into the settings, I realized that it wasn't 44-wqy-zenhei.conf, as Jens originally suspected; the problem was caused by 65-nonlatin.conf.
Actually, I think the font order in the current 65-nonlatin.conf is fine: as it does not assume specific language, I believe it is a good idea to put large-coverage fonts in front of small ones (see https://bugs.freedesktop.org/show_bug.cgi?id=20911). The only problem is, there is no Japanese specific font priority settings to boost VL Gothic for ja locale!
Here is Ubuntu's way to solve this: a list of language specific (CJK only) fontconfig settings are stored in conf.avail, named with "{29,69,99}-language-selector-xxxx.conf" where xxxx include zh-cn, zh-hk, zh-..., ja-jp and ko-kr. For a given desktop locale, it will link the corresponding conf file to conf.d. Although it is a little bit messy, but I think it serves the purpose well: 65-nonlatin is the default font order without assuming any specific lang, if you want to overwrite that for a specific locale, you have to add a lang-specific conf file.
@Jens: if you want to take a look at language-selector, you can download the tar ball at http://packages.ubuntu.com/jaunty/language-selector , untar it and check out the fontconfig folder.
If we are short of time for F11, I can temporarily add a xx-wqy-zenhei.conf and set VL Gothic in front of ZenHei when lang=ja; in that case, we can still install Zen Hei for Chinese-support.
please let me know how you want to proceed. <end off-topic to Bug476459>
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo? |
--- Comment #30 from Akira TAGOH tagoh@redhat.com 2009-04-19 23:08:14 EDT --- I'd prefer not describing other font name there, particularly when happening the font name changed like this case or one prefers other fonts etc. they could override their .fonts.conf though, it's not convenient. ideally a common config should be applied by just installing the package. my proposed config would reasonably works for even that case and is simply enough.
Anyway I'll try your proposal here.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #31 from Akira TAGOH tagoh@redhat.com 2009-04-19 23:14:23 EDT --- (In reply to comment #26)
and indeed, the current version of 61-wqy-bitmapsong.conf [1] contains the following block:
<match target="pattern"> <test equal="any" compare="eq" name="family"> <string>WenQuanYi Bitmap Song</string> </test> <test equal="any" compare="eq" name="family"> <string>sans-serif</string> </test> <test compare="more" name="pixelsize"> <double>16</double> </test> <edit name="family" mode="prepend" binding="same"> <string>AR PL ShanHeiSun Uni</string> </edit> </match>in another word, if the font size requested is greater than 16px, it SHOULD be replaced by ShanHeiSun (Uming). Thus, the behavior you reported should not happen with this conf file per se (force bitmaps at 100pt). So, I am not convinced that 61-wqy-bitmapsong.conf needs to be changed to correct the error you reported.
Is it something you mentioned the above comment my proposal is missing? my proposal just leaves it to other config but ensure to use WenQuanYi Bitmap Song for requesting a pixelsize between 10px and 16px. it would works as long as users installs preferred Chinese fonts.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #32 from Fedora Update System updates@fedoraproject.org 2009-04-25 17:59:26 EDT --- wqy-bitmap-fonts-0.9.9-10.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/wqy-bitmap-fonts-0.9.9-10.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #33 from Qianqian Fang fangqq@gmail.com 2009-04-25 18:43:32 EDT --- (In reply to comment #31)
Is it something you mentioned the above comment my proposal is missing? my proposal just leaves it to other config but ensure to use WenQuanYi Bitmap Song for requesting a pixelsize between 10px and 16px. it would works as long as users installs preferred Chinese fonts.
I need more tests on your config files. But at least from what I saw at this point, the replacement only happens for Sans, not for serif and mono.
Generally speaking, users who like bitmaps also prefer to use bitmap Han glyphs for all alias (sans, serif and mono). Also, because the Latin fonts are lot better than the Latin glyphs in this bitmap, synthesizing the Latin fonts with the bitmap Han glyphs are also preferred. In addition, I noticed that you used "zh" as lang filter, this limits the use of this font for zh only, which does not solve the font-mosaic problems under non-cjk locales while the original 61-wqy-bitmapfonts.conf does. Before 61-nonlatin gets updated, I prefer to have these rules active for all non-ja and non-ko locales (at least en).
In order to use your config file, the above points need to be addressed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #34 from Akira TAGOH tagoh@redhat.com 2009-04-26 23:37:18 EDT --- (In reply to comment #33)
Generally speaking, users who like bitmaps also prefer to use bitmap Han glyphs for all alias (sans, serif and mono).
Sure. I was just following 3rd at comment #4 which makes sense to me. it may be hard to categorize Chinese fonts to those three and I don't know how much difference of the bitmap fonts in the design among Song, Ming, Kai and so on. but IMHO it should be aligned to one of them as they are, no matter how much sizes those fonts are available since it's named like so. because they should/could more or less contains any difference defining in the design regardless of the font size.
In addition, I noticed that you used"zh" as lang filter, this limits the use of this font for zh only, which does not solve the font-mosaic problems under non-cjk locales while the original 61-wqy-bitmapfonts.conf does. Before 61-nonlatin gets updated, I prefer to have these rules active for all non-ja and non-ko locales (at least en).
I'm not sure if I hear what you mean. at least that rule will be applied as long as you run applications under Chinese locale or rendering engine requires it to display a text tagged <span lang="zh">blahblahblah</span> in the pango markup say. which cases are you really concerned? do you prefer to use the Chinese outlined fonts for English as well but the bitmap fonts from Latin fonts if the size available?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(fangqq@gmail.com)
--- Comment #35 from Jens Petersen petersen@redhat.com 2009-04-28 01:11:32 EDT --- Does this build
http://koji.fedoraproject.org/koji/buildinfo?buildID=99342
address this issue also?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #36 from Akira TAGOH tagoh@redhat.com 2009-04-28 09:26:25 EDT --- just tried the proposed package at comment #32. and I don't see anything better than current version of the package regardless of modifying 65-nonlatin.conf. have you ever tried to test everything at comment #24 before pushing the update?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(fangqq@gmail.com) |
--- Comment #37 from Qianqian Fang fangqq@gmail.com 2009-04-28 23:40:38 EDT --- this update is basically identical to the patch posted in comment #27 (in #27, the diff was made reversed). And the behavior should match what I described in comment #29. In short, this patch by itself will not solve the problem you reported, because it depends on the solution to Bug#476459. I assume Jens is going to add a separate config file for VL Gothic to specify it as the default ja sans font. With this file in place, both Bug#476459 and this bug should be solved.
I will mark this Bug#476459 as dependent to this bug.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |476459
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tagoh@redhat.com)
--- Comment #38 from Qianqian Fang fangqq@gmail.com 2009-04-29 00:02:07 EDT --- Akira, I reassigned Bug#476459 since you are the maintainer of vlgothic-fonts.
I want to make sure you understand my rationales for solving these two bugs: first of all, 65-nolatin sets the default font orders for cjk fonts, it does not, and perhaps should not, assume which locale is preferred, therefore, it won't solve the font variant issues for CJK. The solution is to introduce language-specific font config files. Unfortunately, Fedora does not have language-selector settings as in Ubuntu. Currently, the language specific font orders for Chinese is done by the fontconfig files associated with the default Chinese font (Zen Hei and Bitmap Song). However, Japanese does not have such config files, and completely relies on 65-nonlatin (which is not only out-dated, but also giving zh locale a lower priority).
Therefore, either you want to introduce a Japanese specific font config file to set the preferred font orders for lang=ja, or you simply define VL Gothic as the default Sans for ja in the vlgothic-fonts config files, just like the file you proposed for this bug (you do need to replace zh to ja and reset the font names).
I believe that a better solution would be the first one in the long run, but for now, the second solution is not bad either (in the future, this file can directly renamed to language-selector-ja_JP.conf or something like that).
Let me know if this is making sense to you.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(tagoh@redhat.com) |
--- Comment #39 from Akira TAGOH tagoh@redhat.com 2009-04-29 23:30:54 EDT --- (In reply to comment #38)
Akira, I reassigned Bug#476459 since you are the maintainer of vlgothic-fonts.
So what? that's not a bug in vlgothic-fonts though ;)
I want to make sure you understand my rationales for solving these two bugs: first of all, 65-nolatin sets the default font orders for cjk fonts, it does not, and perhaps should not, assume which locale is preferred, therefore, it won't solve the font variant issues for CJK. The solution is to introduce language-specific font config files. Unfortunately, Fedora does not have language-selector settings as in Ubuntu. Currently, the language specific font orders for Chinese is done by the fontconfig files associated with the default Chinese font (Zen Hei and Bitmap Song). However, Japanese does not have such config files, and completely relies on 65-nonlatin (which is not only out-dated, but also giving zh locale a lower priority).
Not really. I have looked at language-selector though, basically what they have done is same to what we do. only difference is, they've done to switch the config physically outside fontconfig, but we do in fontconfig with checking the language.
I don't think Ubuntu way is the right thing since it doesn't use the expected fonts for the language. i.e. if select -zh-cn.conf, even Japanese text will be rendered with Chinese font.
Therefore, either you want to introduce a Japanese specific font config file to set the preferred font orders for lang=ja, or you simply define VL Gothic as the default Sans for ja in the vlgothic-fonts config files, just like the file you proposed for this bug (you do need to replace zh to ja and reset the font names).
I'm not sure what you mean. the language-specific overrides rule is to do that. but it really conflicts to the simple priority list. actually getting rid of it makes the language-specific overrides rule working and this issue is also gone. Since we've sometimes ever seen the font order issue between Chinese and Japanese desktop/installer etc, I'm beginning to think that the simple priority list is evil.
I believe that a better solution would be the first one in the long run, but for now, the second solution is not bad either (in the future, this file can directly renamed to language-selector-ja_JP.conf or something like that).
I don't like the language-selector idea, because it may be hard to get rid of that feature once we've implemented. people may gets confused with it. That would be good to update all of fonts in F-12 which has the simple priority list and are supposed to work for the specific language.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #40 from Akira TAGOH tagoh@redhat.com 2009-04-29 23:41:02 EDT --- (In reply to comment #37)
this update is basically identical to the patch posted in comment #27 (in #27, the diff was made reversed). And the behavior should match what I described in comment #29. In short, this patch by itself will not solve the problem you reported, because it depends on the solution to Bug#476459.
No. I've tried the new package /without/ wqy-zenhei-fonts to be sane. you should get rid of the bug number from the errata if that isn't supposed to fix this bug.
going to add a separate config file for VL Gothic to specify it as the default ja sans font. With this file in place, both Bug#476459 and this bug should be solved.
I'm afraid not. it won't helps. relying on the simple priority list only depends on the order of the config files to work as expected. we have to stop the priority race shortly and make happy for all of languages which would conflicts.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #41 from Qianqian Fang fangqq@gmail.com 2009-04-29 23:56:14 EDT --- (In reply to comment #39)
So what? that's not a bug in vlgothic-fonts though ;)
I am just pointing out a solution to these two issues, you like to call it a bug or "feature request", it does not matter.
Not really. I have looked at language-selector though, basically what they have done is same to what we do. only difference is, they've done to switch the config physically outside fontconfig, but we do in fontconfig with checking the language.
the key difference is not to separate them from the standard fontconfig files, but to make only one set of files linked under a given locale. sure you probably don't not necessarily follow ubuntu's way, but the idea, a (set of) locale-specific fontconfig settings is missing for cjk in fedora (at least for ja).
I don't think Ubuntu way is the right thing since it doesn't use the expected fonts for the language. i.e. if select -zh-cn.conf, even Japanese text will be rendered with Chinese font.
then please propose a better solution, which can avoid overriding in both ways.
I'm not sure what you mean. the language-specific overrides rule is to do that. but it really conflicts to the simple priority list. actually getting rid of it makes the language-specific overrides rule working and this issue is also gone. Since we've sometimes ever seen the font order issue between Chinese and Japanese desktop/installer etc, I'm beginning to think that the simple priority list is evil.
can you explain what do you mean by "simple priority list"? are you referring to 65-nonlatin? or are you referring to font-specific config files? if it is the latter case, we are talking about the same thing.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tagoh@redhat.com)
--- Comment #42 from Qianqian Fang fangqq@gmail.com 2009-04-30 00:06:12 EDT --- and also can you tell me why you can not the following config file to vlgothic-fonts to make it a preferred fonts for ja locale?
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <!-- Generic names --> <alias> <family>VL PGothic</family> <default> <family>sans-serif</family> </default> </alias> <alias> <family>VL Gothic</family> <default> <family>monospace</family> </default> </alias>
<!-- Locale-specific overrides --> <match> <test name="lang" compare="contains"> <string>ja</string> </test> <edit name="family" mode="prepend" binding="same"> <string>VL PGothic</string>
</edit> </match> </fontconfig>
if VL Gothic is only installed when selecting ja language, you can even use this
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias> <family>sans-serif</family> <prefer> <family>DejaVu Sans</family> <family>Bitstream Vera Sans</family> <family>VL PGothic</family> </prefer> </alias> <alias> <family>monospace</family> <prefer> <family>DejaVu Sans Mono</family> <family>Bitstream Vera Sans Mono</family> <family>VL Gothic</family> </prefer> </alias> </fontconfig>
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(tagoh@redhat.com) |
--- Comment #43 from Akira TAGOH tagoh@redhat.com 2009-04-30 01:08:51 EDT --- (In reply to comment #41)
the key difference is not to separate them from the standard fontconfig files, but to make only one set of files linked under a given locale. sure you probably don't not necessarily follow ubuntu's way, but the idea, a (set of) locale-specific fontconfig settings is missing for cjk in fedora (at least for ja).
Yes, I know. and fontconfig is capable to do that with the language-specific overrides rule. it can constructs the font list from them and works similarly unless the simple priority list rule prevents.
then please propose a better solution, which can avoid overriding in both ways.
I do ;) can you point out any cases that the language-specific overrides rule doesn't work instead? I should asked you same question but I didn't get the certain reply for my comment #34 yet though.
can you explain what do you mean by "simple priority list"? are you referring to 65-nonlatin? or are you referring to font-specific config files? if it is the latter case, we are talking about the same thing.
http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Simple_priority_list...
We are talking about the same thing? I don't think so since you apparently dislikes it and you are proposing to do that outside fontconfig for single language but not to make happier with all of CJK and non-CJK languages with English locale say at once.
(In reply to comment #42)
and also can you tell me why you can not the following config file to vlgothic-fonts to make it a preferred fonts for ja locale?
Sorry? can you point out what's difference between the above and current vlgothic-fonts' config? it looks similar to me except it's provided separately because those are subpackaged. and I don't really like to contain the font name not owned.
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig> <alias> <family>sans-serif</family> <prefer> <family>DejaVu Sans</family> <family>Bitstream Vera Sans</family> <family>VL PGothic</family> </prefer> </alias> <alias> <family>monospace</family> <prefer> <family>DejaVu Sans Mono</family> <family>Bitstream Vera Sans Mono</family> <family>VL Gothic</family> </prefer> </alias> </fontconfig>
Whether or not this works properly really depends on the order of the config files, which isn't the right direction to go.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #44 from Akira TAGOH tagoh@redhat.com 2009-05-01 04:44:21 EDT --- Sorry, there was wrong caches here. and I can see the different result with the test cases at Comment #24 now:
1. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [GOOD] rendering is ok with Japanese font
2. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
3. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [BAD] WenQuanYi Bitmap Song is used to render 日本語
4. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] WenQuanYi Bitmap Song is used to render 日本語
5. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 100"
--> [GOOD] rendering is ok with Japanese font
6. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
7. LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [BAD] WenQuanYi Bitmap Song is used to render 日本語
8. (bonus)PANGO_LANGUAGE=zh LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] WenQuanYi Bitmap Song is used to render 日本語
9. (bonus)PANGO_LANGUAGE=ja LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #45 from Jens Petersen petersen@redhat.com 2009-05-01 04:48:14 EDT --- I just tested also with wqy-bitmap-fonts-0.9.9-9.fc11 and 0.9.9-10.fc11 and got exactly the result as comment 44 both testcases 3 and 7 in comment 24 still fail.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #46 from Jens Petersen petersen@redhat.com 2009-05-01 05:03:33 EDT --- (In reply to comment #38)
Therefore, either you want to introduce a Japanese specific font config file to set the preferred font orders for lang=ja, or you simply define VL Gothic as the default Sans for ja in the vlgothic-fonts config files, just like the file you proposed for this bug (you do need to replace zh to ja and reset the font names).
Sounds like different things are being talked about: vlgothic-fonts and vlgothic-p-fonts already provide
/etc/fonts/conf.d/66-vlgothic-gothic.conf /usr/share/fontconfig/conf.avail/66-vlgothic-pgothic.conf
which prepend it as the default for Japanese AFAICT.
Qianqian, what more is it that you wish vlgothic's conf to do?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #339961|application/octet-stream |text/plain mime type| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #47 from Jens Petersen petersen@redhat.com 2009-05-01 05:19:08 EDT --- (In reply to comment #24)
Created an attachment (id=339961)
--> (https://bugzilla.redhat.com/attachment.cgi?id=339961) [details]
proposed fontconfig config
I've polished a lot from my previous proposal. it won't depends on other fonts. just works for the desired situation. this should be valid for current our policy as well.
Looks good, clean and simple to me too.
Qianqian, could you test it and tell us what problems it causes for you? :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #48 from Akira TAGOH tagoh@redhat.com 2009-05-01 05:23:19 EDT --- Aside from adding any rules for the fonts not owned, a rule to fall back the font to AR PL UMing CN for the request out of the supported pixel in WenQuanYi Bitmap Song is broken. basically any expressions in match tag is a AND operation. thus,
<match target="pattern"> <test equal="any" compare="eq" name="family"> <string>WenQuanYi Bitmap Song</string> </test> <test equal="any" compare="eq" name="family"> <string>serif</string> </test> <test compare="more" name="pixelsize"> <double>16</double> </test> <edit name="family" more="prepend" binding="same"> <string>AR PL UMing CN</string> </edit> </match>
would means something like:
if (pattern.family.compare("WenQuanYi Bitmap Song") && pattern.family.compare("serif") && pattern.pixelsize > 16.0) { pattern.family.prepend("AR PL UMing CN"); }
which never happens. that's why case 3 and 7 didn't work FWIW.
I don't understand why you prefer this complex rule rather than my simplest proposal though.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #49 from Qianqian Fang fangqq@gmail.com 2009-05-07 19:34:32 EDT --- sorry, have been working on a bunch of things. I will look into these config files and confirm on all the tests.
From what you wrote, the results looks normal to me. If wqy-zenhei-fonts is not
installed, wqy-bitmap-song is perhaps the best candidate for Sans anyway.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #50 from Qianqian Fang fangqq@gmail.com 2009-05-07 19:48:08 EDT --- (In reply to comment #46)
Sounds like different things are being talked about: vlgothic-fonts and vlgothic-p-fonts already provide
/etc/fonts/conf.d/66-vlgothic-gothic.conf /usr/share/fontconfig/conf.avail/66-vlgothic-pgothic.conf
which prepend it as the default for Japanese AFAICT.
Qianqian, what more is it that you wish vlgothic's conf to do?
I think I misread your comment#21 in Big#476459, and did not check if vlgothic have conf files or not.
I think the key problem is when wqy-zenhei is installed, the vlgothic rules are overwritten.
I believe a fair test for this and Bug#476459 would be to have all Uming, wqy-zenhei and wqy-bitmapfont installed, where uming is expected to be the default serif, zenhei is the default sans, and bitmapsong (Han glyphs) should overwrite both at smaller sizes. Most of the tests above do not have zenhei installed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #51 from Qianqian Fang fangqq@gmail.com 2009-05-07 19:51:40 EDT --- Indeed, I don't mind taking wqy-bitmap-fonts out from the default Chinese font list, and replaced by wqy-zenhei-fonts instead, since zenhei already embedded all the bitmaps and is smaller in size (disabled by default).
Then the key question is how to fix the overwritten problem between wqy-zenhei and vlgothic config files.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #52 from Akira TAGOH tagoh@redhat.com 2009-05-07 22:55:36 EDT --- (In reply to comment #49)
sorry, have been working on a bunch of things. I will look into these config files and confirm on all the tests.
From what you wrote, the results looks normal to me. If wqy-zenhei-fonts is not installed, wqy-bitmap-song is perhaps the best candidate for Sans anyway.
You better read the above comments carefully. wqy-zenhei-fonts is irrelevant for this issue and either of fonts shouldn't affects anything else. that's why adding no own fonts to the fontconfig rule is a bad idea. actually my simpler rule works fine with the above testcases.
To be sane, here is a result of pango-view with Serif, without wqy-zenhei-fonts.
1. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [GOOD] rendering is ok with Japanese font
2. LANG=ja_JP.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
3. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [GOOD] rendering is ok with Chinese outline font
4. LANG=zh_CN.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [BAD] outline font is still used.
5. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 100"
--> [GOOD] rendering is ok with Japanese font
6. LANG=zh_CN.UTF-8 pango-view --markup --text '<span lang="ja">日本語</span> test' --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
7. LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 100"
--> [GOOD] rendering is ok with Chinese outline font
8. (bonus)PANGO_LANGUAGE=zh LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [BAD] outline font is still used
9. (bonus)PANGO_LANGUAGE=ja LANG=en_US.UTF-8 pango-view --text "日本語 test" --font "Sans 12"
--> [GOOD] rendering is ok with Japanese font
This result would means the fallback rule by the size doesn't work which I've pointed out at comment #48.
(In reply to comment #51)
Indeed, I don't mind taking wqy-bitmap-fonts out from the default Chinese font list, and replaced by wqy-zenhei-fonts instead, since zenhei already embedded all the bitmaps and is smaller in size (disabled by default).
Then the key question is how to fix the overwritten problem between wqy-zenhei and vlgothic config files.
Again, it's a separate issue. please stop mixing up multiple bugs here. and I'm still waiting for your explanation what exactly you faced with my simpler fontconfig rule.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #53 from Jens Petersen petersen@redhat.com 2009-05-07 23:21:27 EDT --- (In reply to comment #51)
Indeed, I don't mind taking wqy-bitmap-fonts out from the default Chinese font list
Yes we really need a proper fix for this for f11, ASAP.
The serious issue in this bug is about wqy-bitmap overriding fonts for Kanji (and Hanja).
replaced by wqy-zenhei-fonts instead, since zenhei already embedded all the bitmaps and is smaller in size (disabled by default).
Too late now for f11 and a separate issue - but happy to consider that for f12 once bug 476459 is addressed.
Then the key question is how to fix the overwritten problem between wqy-zenhei and vlgothic config files.
Akira already solved it in a simple way - please check it carefully and provide some real feedback on his .conf. Otherwise we will have to make the changes or drop bitmap as a default in the chinese-support yum group.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tagoh@redhat.com)
--- Comment #54 from Qianqian Fang fangqq@gmail.com 2009-05-08 00:53:03 EDT --- (In reply to comment #52)
Again, it's a separate issue. please stop mixing up multiple bugs here. and I'm still waiting for your explanation what exactly you faced with my simpler fontconfig rule.
ok, let me first reply your above question.
Test environment: rawhide with today's update, installed Uming, wqy-bitmap-fonts, and the Japanese fonts, and NOT installed wqy-zenhei-fonts (I will discuss about this later). I used your proposed config file, referred to "NEW" and the 61-wqy-bitmapfont.conf in the current wqy-bitmap-fonts package, referred to "OLD".
* Test set 1, pango-view tests
I ran all 9 tests listed in Comment#52, for NEW, tests 1-2,4-6,8-9 got expected results. test 3: the "sans 100" was rendered by outline font UMing; test 7, the "sans 100" was rendered by bitmap song.
For OLD, same results for 1-2,4-6,8-9; both tests 3 and 7, it uses bitmap song for Chinese rendering (notice these two tests are for zh and en locales, not for ja).
Conclusion: the only difference between these two tests is test 3, which I can not say which one is better. Clearly, no Japanese fonts were overwritten by the current version of wqy-bitmap-fonts, under any test locales.
* Test set 2, browser/terminal and desktop font rendering
My standard test page is http://wenq.org/?WQYTest . I set one of the NEW and OLD file as the active setting and made screen captures under ja/zh/en desktops. The results were uploaded to this album:
http://picasaweb.google.com/fangqq/ConfigScreenshot
you can click into each screenshot and click magnify.
Basic conclusions: 1. the rendering for ja desktops are identical (ignore those simplified Chinese characters that are not defined in JIS); all Han glyphs were rendered with the preferred Japanese Gothic or Mincho fonts in both browser, desktop menu and terminal.
2. the rendering for en desktop are different. NEW config renderings is bad for 2.1 it uses a mixture of Mincho with bitmap song to render the H1/H2 titles, 2.2 it renders Han glyphs in terminals with a mixture of UKai and Gothic, 2.3 and for Sans, Hanzi at all sizes were rendered by Japanese Gothic 2.4 for serif and mono, 13pt and 14 pt still uses bitmap to render
3. for zh desktop, the rendering are identical. However, both are different from what was configured for F8~F10, which you can see in the last screenshot. in the past, all bitmaps in the web/terminal are from wqy-bitmap-fonts, but now, the web/terminal bitmaps are from Uming, which is inferior in quality. However, this is a separate issue. Perhaps some config files of Uming changed the priority.
To summarize: the two config files performs pretty much the same for zh and ja, but the OLD config file more consistent selection of fonts for en (and all non-CJK locales) desktops.
So, I don't see the benefit of switching to the new file.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Qianqian Fang fangqq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(tagoh@redhat.com) |
--- Comment #55 from Qianqian Fang fangqq@gmail.com 2009-05-08 01:10:40 EDT --- I hope the above comparison is clear.
Now let's talk about the next question, which involves ZenHei.
The comparisons we have done so far are unfair. Because Japanese fonts have both vector sans (Gothic) and serif (Mincho) installed, but for Chinese, only vector serif (UMing) were installed. As I said, ZenHei is the proper vector Chinese sans font. Without ZenHei, Chinese sans font has to fallback. Given the missing of Chinese sans vector font, Bitmap Song is indeed the most proper choice for Chinese sans (Uming will cross the lines from sans to serif). Therefore, in your tests 3 and 7, it picked Bitmap Song to render Sans, I think it is the right choice.
The only better solution is to install ZenHei by default. In that case, for larger size sans glyphs, it will use ZenHei as the first choice, and bitmap Song as the second choice.
If ZenHei needs to be installed, the config files of zenhei and VL Gothic should be "coordinated" (either you change your 66-vlgothic* or I changed my 41-wqy-zenhei.conf), in order to make both working, but we should not say which one is "correct" or "wrong". This is basically the concern of Bug#476459.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #56 from Fedora Update System updates@fedoraproject.org 2009-05-09 00:14:19 EDT --- wqy-bitmap-fonts-0.9.9-10.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Fixed In Version| |0.9.9-10.fc11 Resolution| |NEXTRELEASE
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Reopened Status|CLOSED |ASSIGNED Resolution|NEXTRELEASE |
--- Comment #57 from Jens Petersen petersen@redhat.com 2009-05-13 02:11:28 EDT --- I install rawhide (current pre-f11) with CJK support - login in to a Japanese desktop and see wqy-bitmap for Chinese glyphs in gucharmap.
I think we should not install wqy-bitmap-fonts by default for zh in F11 until this is resolved properly.
I would appreciate comments and feedback from other Fedora CJK users/testers on this.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #58 from Qianqian Fang fangqq@gmail.com 2009-05-13 10:37:05 EDT --- (In reply to comment #57)
I install rawhide (current pre-f11) with CJK support - login in to a Japanese desktop and see wqy-bitmap for Chinese glyphs in gucharmap.
screen shot please. which code points you saw bitmaps? did you install wqy-zenhei-fonts?
if your Han glyphs are before 0x4E00 (for example KangXi radicals, or CJK unicode extension A), wqy-bitmap-fonts is the only zh font that covers that range, so, showing with bitmaps is expected.
if you DID NOT install wqy-zenhei-fonts, and your fonts selected "sans", showing with bitmaps is also reasonable, because wqy-bitmap-fonts is closer to sans than Uming. If you really want to use vector fonts to display despite the sans/serif differences, open 61-wqy-bitmapsong.conf, change the last two sans-serif blocks to the following:
<match target="pattern"> <test equal="any" compare="eq" name="family"> <string>WenQuanYi Bitmap Song</string> </test> <test equal="any" compare="eq" name="family"> <string>sans-serif</string> </test> <test compare="more" name="pixelsize"> <double>16</double> </test> <edit name="family" mode="prepend" binding="same"> <string>WenQuanYi Zen Hei</string> </edit> <edit name="family" mode="prepend" binding="same"> <string>AR PL UMing CN</string> </edit> </match> <match target="pattern"> <test equal="any" compare="eq" name="family"> <string>WenQuanYi Bitmap Song</string> </test> <test equal="any" compare="eq" name="family"> <string>sans-serif</string> </test> <test compare="less" name="pixelsize"> <double>10</double> </test> <edit name="family" mode="prepend" binding="same"> <string>WenQuanYi Zen Hei</string> </edit> <edit name="family" mode="prepend" binding="same"> <string>AR PL UMing CN</string> </edit> </match>
this will match zenhei first and fallback to UMing; again, I prefer the current solution because uming is not as "sans" as bitmap song.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #59 from Akira TAGOH tagoh@redhat.com 2009-05-13 20:43:34 EDT --- That may be the expected behaviour for you as you do in your fontconfig rule though, current behaviour isn't ideal and no one is happy with it. this would be true since you asked if wqy-zenhei-fonts is installed. I'd say again, what you should take an action to fix this completely would be:
1. have a dependency in wqy-bitmap-fonts to ensure if wqy-zenhei-fonts is installed.
2. stop to depend on any other fonts in your rule and just leave it to other rules.
Your suggestion at comment #58 is just a workaround but not a solution. and you might see the same issue in the future. I'm afraid it's not a good idea.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #60 from Qianqian Fang fangqq@gmail.com 2009-05-13 21:27:57 EDT --- (In reply to comment #59)
That may be the expected behaviour for you as you do in your fontconfig rule though, current behaviour isn't ideal and no one is happy with it.
What do you mean by "no one is happy"? You don't speak for all CJK users I believe. Only a few Japanese users were bothered previously, but with my current fix, all Japanese Han glyphs were displayed properly with your preferred vector fonts. The remaining characters should be decided by their respective users.
this would be true since you asked if wqy-zenhei-fonts is installed. I'd say again, what you should take an action to fix this completely would be:
- have a dependency in wqy-bitmap-fonts to ensure if wqy-zenhei-fonts is
installed.
Please install wqy-zenhei-fonts by default then. As I said, I don't mind removing wqy-bitmap-fonts in order to install wqy-zenhei, because ZenHei is the "official" sans for Chinese, and SHOULD be installed.
- stop to depend on any other fonts in your rule and just leave it to other
rules.
I said it already, it is NOT dependency! it is fallback! if you look into all the current fontconfig files, many of the font names are not present by default. By your logic, all of these should be removed, as they are dependent to the the missing font package.
Indeed, if you want to make a synthetic font with your preferred fonts, you HAVE TO explicitly mention other font's name. That is exactly what wqy-bitmap-fonts is.
By the way, you should really blaming changing font names, rather than blaming citing font names in config files. Changing a commonly used font name should be done with extreme caution.
Your suggestion at comment #58 is just a workaround but not a solution. and you might see the same issue in the future. I'm afraid it's not a good idea.
Then, the best solution to me is my proposal in Bug#499902, but you don't like either. The only solution is to follow exactly what you suggested. I don't think we can work out this way.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #61 from Akira TAGOH tagoh@redhat.com 2009-05-14 06:00:03 EDT --- (In reply to comment #60)
What do you mean by "no one is happy"? You don't speak for all CJK users I believe. Only a few Japanese users were bothered previously, but with my current fix, all Japanese Han glyphs were displayed properly with your preferred vector fonts. The remaining characters should be decided by their respective users.
For those who wants to use different outlined font other than the above two. I don't know who exactly is.
- have a dependency in wqy-bitmap-fonts to ensure if wqy-zenhei-fonts is
installed.
Please install wqy-zenhei-fonts by default then. As I said, I don't mind removing wqy-bitmap-fonts in order to install wqy-zenhei, because ZenHei is the "official" sans for Chinese, and SHOULD be installed.
Installing by default doesn't matter and it doesn't help for upgrading. otherwise we don't need any dependencies in GNOME packages and so on in that sense. this is to ensure the sane packaging but ain't talking about something after the packages is installed here. this is the right way under the package management system to help out the insane thing. This is a suggestion to settle though.
- stop to depend on any other fonts in your rule and just leave it to other
rules.
I said it already, it is NOT dependency! it is fallback!
Again, appearing WenQuanYi Bitmap Song for outside 10~16px is the expected behaviour for current logic right. however it's not the expected behaviour for users. I'm saying that and that logic is wrong then. Even though you have taken responsibility for fallback, causing not working due to no fallback fonts available is a bug and not desirable. it's nearly equivalent to nothing. then why don't you just leave that responsibility to others or just take the above suggestion 1?
By your logic, all of these should be removed, as they are dependentto the the missing font package.
I meant to that. if something doesn't work as expected after getting rid of them then, we should have the certain thing in fontconfig or somewhere to support fallback with something rather than describing the font name not owned by the package.
Indeed, if you want to make a synthetic font with your preferred fonts, you HAVE TO explicitly mention other font's name. That is exactly what wqy-bitmap-fonts is.
I have already demonstrated to apply WenQuanYi Bitmap Song for the desired size only rather than fallback to others for outside though. you can use the preferred fonts for other sizes without modifying fontconfig rules at all.
By the way, you should really blaming changing font names, rather than blaming citing font names in config files. Changing a commonly used font name should be done with extreme caution.
For instance, would you blame someone who decided to change Chinese font to new one say because it has better quality than current font? that makes no sense. that situation is most likely to happen when we have any chance.
Your suggestion at comment #58 is just a workaround but not a solution. and you might see the same issue in the future. I'm afraid it's not a good idea.
Then, the best solution to me is my proposal in Bug#499902, but you don't like either. The only solution is to follow exactly what you suggested. I don't think we can work out this way.
Heh, I just like the sane solution for long term but not ugly hack or so.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #62 from Qianqian Fang fangqq@gmail.com 2009-05-14 10:40:33 EDT --- (In reply to comment #61)
Again, appearing WenQuanYi Bitmap Song for outside 10~16px is the expected behaviour for current logic right. however it's not the expected behaviour for users. I'm saying that and that logic is wrong then. Even though you have taken responsibility for fallback, causing not working due to no fallback fonts available is a bug and not desirable. it's nearly equivalent to nothing. then why don't you just leave that responsibility to others or just take the above suggestion 1?
If there is no other Chinese fonts cover those code points, for example, any thing between U3400~U4FD5, the best you can get is to display them with bitmaps as wqy-bitmap-fonts covers them. Even for U4E00~U9FA5, UMing have a few thousands missing, those missing ones will still be displayed by bitmaps. Without installing wqy-zenhei, what you suggested is simply not possible.
Heh, I just like the sane solution for long term but not ugly hack or so.
Seriously, I don't have time to argue with you. If you have the authority to modify cvs, go ahead, I don't care. If you believe you can convince me your "long term" solution is better, go write one that works for all the tests in Comment#54, particularly the English desktop. I will commit it without a single more word.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #63 from Qianqian Fang fangqq@gmail.com 2009-05-14 10:43:56 EDT --- (In reply to comment #62)
If you believe you can convince me your "long term" solution is better, go write one that works for all the tests in Comment#54, particularly the English desktop. I will commit it without a single more word.
and of course, if there is anything wrong in the future with this, it would have to be your responsibility to fix it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Bill Nottingham notting@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on|476459 |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Bill Nottingham notting@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |476459
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Bill Nottingham notting@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |notting@redhat.com Blocks|446452(F11Blocker) |
--- Comment #64 from Bill Nottingham notting@redhat.com 2009-05-15 15:13:14 EDT --- This font is no longer installed by default, so removing from the blocker list.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |htl10@users.sourceforge.net
--- Comment #66 from Hin-Tak Leung htl10@users.sourceforge.net 2009-07-08 03:59:52 EDT --- Is there bug # for the supposedly cairo bug for preferring the bitmap font for printing? I came to this bug report because, while screen-viewing is fine, since upgrading to F11, printing of web pages requesting fonts of 10pt to 16pt uses the bitmap font. I don't mind it using bitmap font much, except cairo seems to scale glyphs wrongly - the bitmap glyphs are rendered about 2-3 times their expected size and thus overlapping and not readable.
i.e. on a ps/pdf of a chinese typical web page, the headlines/titles are rendered with outlined fonts, body text are rendered as large overlapping bitmaps.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
J.H.M. Dassen (Ray) rdassen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |485811(GSS_4_9_proposed)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
J.H.M. Dassen (Ray) rdassen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|485811(GSS_4_9_proposed) |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #67 from Jens Petersen petersen@redhat.com 2009-12-07 02:43:46 EDT --- A fix was made to vlgothic-fonts .conf which may help with this bug.
(In reply to comment #66)
i.e. on a ps/pdf of a chinese typical web page, the headlines/titles are rendered with outlined fonts, body text are rendered as large overlapping bitmaps.
Not sure which font you are referring to? For cjkuni I am trying to get rid of the bitmap rendering. I think it has some fontconfig rules that cause it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression: |wqy-bitmap-fonts needs lang |wqy-bitmap-fonts preferred |fontconfig |font over truetype fonts |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|11 |rawhide
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Bug 492510 depends on bug 476459, which changed state.
Bug 476459 Summary: wqy-zenhei-fonts needs lang fontconfig https://bugzilla.redhat.com/show_bug.cgi?id=476459
What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |RAWHIDE
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Bug 492510 depends on bug 476459, which changed state.
Bug 476459 Summary: wqy-zenhei-fonts needs lang fontconfig https://bugzilla.redhat.com/show_bug.cgi?id=476459
What |Old Value |New Value ---------------------------------------------------------------------------- Status|CLOSED |ASSIGNED Resolution|RAWHIDE |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on|476459 |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |507684(F13Target)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #68 from Fedora Update System updates@fedoraproject.org 2010-02-25 21:55:05 EST --- wqy-bitmap-fonts-0.9.9-12.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/wqy-bitmap-fonts-0.9.9-12.fc13
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
--- Comment #69 from Fedora Update System updates@fedoraproject.org 2010-02-26 06:53:47 EST --- wqy-bitmap-fonts-0.9.9-12.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Fixed In Version|0.9.9-10.fc11 |wqy-bitmap-fonts-0.9.9-12.f | |c13 Resolution| |ERRATA
i18n-bugs@lists.fedoraproject.org
-
Red Hat Bugzilla