Bug 492510

Created attachment 336970 [details]
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.

erm, totally broken config.

Created attachment 336973 [details]
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.

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

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)
> 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)

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.

> 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>
> ???

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.

(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.png

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.

(In reply to comment #4)
> 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

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.


> 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)

same as above.

> 
> 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

because wqy-bitmap-fonts is not monospaced.

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?

> 2. 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?

(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.

(In reply to comment #8)

> > 2. 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

Setting F11blocker, fontconfig order issue is really a blocker
for CJK people.

(In reply to comment #6)
> 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.

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.

> 2. 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.

(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.

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.

Is this going to be fixable before F-11?

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.

(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.

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

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.

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?

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.

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.

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_overrides 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.

Created attachment 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.

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.

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.

(In reply to comment #24)
> Created an attachment (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-bitmapsong.conf?revision=1.5&view=markup&sortby=log

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>

Created attachment 340232 [details]
update Uming font name for F11

use Uming as serif fallback and ZenHei as sans fallback

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>

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.

(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.

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

(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.

(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?

Does this build

http://koji.fedoraproject.org/koji/buildinfo?buildID=99342

address this issue also?

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?

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.

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.

(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.

(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.

(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.

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>

(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_lists

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.

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

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.

(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?

(In reply to comment #24)
> Created an attachment (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? :)

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.

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.

(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.

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.

(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.

(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.

(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.

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.

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.

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.

(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.

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.

(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:
> 
> 1. 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.

> 
> 2. 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.

(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.

> > 1. 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.

> > 2. 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 dependent
> to 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.

(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.

(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.

This font is no longer installed by default, so removing from the blocker list.

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

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.

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.

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

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.