Make wqy-zenhei-fonts default in the chinese-support group. Make sure it does not take over as default desktop font (unless desired).
Qianqian, any idea how to do this: I think currently installing zenhei makes it take over the Chinese desktop overriding cjkuni-fonts?
Can we soften the font config so that wqy-zenhei-fonts can be installed by default by Chinese without taking over the whole desktop? :)
hi Jens I am not entirely sure if I understood "setting as default" and "not overriding", maybe you can explain it a little bit more? As you know, Uming is a Song/Mincho style font, therefore, it is close to "serif" alias, and wqy-zenhei is a Hei/Gothic font with sans-serif styled glyphs for both proportional and monospaced faces (in a single ttc). On Ubuntu, uming is used as the default serif and wqy-zenhei as the default sans-serif for zh locales. is this what you intend to achieve?
(In reply to comment #3) > I am not entirely sure if I understood "setting as default" and "not > overriding", maybe you can explain it a little bit more? I wrote "install as default", ie meaning install the package by default. Overriding means that installation should not override other default desktop fonts, like dejavu-fonts and cjkuni-fonts > As you know, Uming is a Song/Mincho style font, therefore, it is close to > "serif" alias, and wqy-zenhei is a Hei/Gothic font with sans-serif styled > glyphs for both proportional and monospaced faces (in a single ttc). On Ubuntu, > uming is used as the default serif and wqy-zenhei as the default sans-serif for > zh locales. is this what you intend to achieve? Eventually maybe. :) What about Ukai? Last I tested wqy-zenhei was still too aggressive in priority to coexist with cjkuni-fonts. Thanks for the information about ubuntu's defaults.
(In reply to comment #4) > > I wrote "install as default", ie meaning install the package by default. > > Overriding means that installation should not override other default desktop > fonts, like dejavu-fonts and cjkuni-fonts ok, that's fine (zenhei had never overrode dejavu), I will change the settings when I update the fontconfig file to follow the new guideline (I am still not able to compile due to %{_fontdir} definition #478891). However, I would like to remind that this basically means Uming will "override" sans-serif and monospace and all Chinese will be displayed as bitmaps. Also there is no way to use Dejavu and zenhei together anymore. > > Eventually maybe. :) What about Ukai? > this is up to you and the Chinese i18n. I rarely see people use Ukai as desktop fonts despite that fontconfig default settings giving it high priority, as it is designed mostly for printing, and it look very blurry on screen.
Okay I think if you restrict wqy-zenhei-fonts to just zh, which has similarly been done to fedora cjkuni-fonts and baekmuk-ttf-fonts recently with font conf directives to restrict to one language (to avoid unihan issues, etc) then we can start to think about this seriously.
Though better in the long term would be to get the font included in fontconfig's /etc/fonts/conf.d/65-nonlatin.conf file like dejavu, cjkuni, etc.
(In reply to comment #7) > Though better in the long term would be to get the font included in > fontconfig's /etc/fonts/conf.d/65-nonlatin.conf file like dejavu, cjkuni, etc. Certainly. I heard the fontconfig developers were re-working on the default font priorities last year, but then, nothing has happened.
here I have a problem: in 44-wqy-zenhei.conf, I used alias sections to set the preferences, I remember this is the recommended way of setting the priorities, however, if I want to use lang tags, I may have to write this whole section using match and prepend, or kill the whole section. Jens, is this what you want to do? ---------------------------------------------------- <alias> <family>serif</family> <prefer> <family>Bitstream Vera Serif</family> <family>DejaVu Serif</family> <family>WenQuanYi Zen Hei</family> </prefer> </alias> <alias> <family>sans-serif</family> <prefer> <family>Bitstream Vera Sans</family> <family>DejaVu Sans</family> <family>WenQuanYi Zen Hei</family> </prefer> </alias> <alias> <family>monospace</family> <prefer> <family>Bitstream Vera Sans Mono</family> <family>DejaVu Sans Mono</family> <family>WenQuanYi Zen Hei Mono</family> </prefer> </alias>
ok, I just killed the alias sections in 44-wqy-zenhei.conf. Basically, this means users have to manually select this font to use in their desktop or browsers; if they want to use dejavu and zenhei together, they have to code up their conf file, or wish one day the ancient font orders in 65-nonlatin get updated. Jens, let me know if this is good, thanks
new package was built in rawhide.
(In reply to comment #10) > ok, I just killed the alias sections in 44-wqy-zenhei.conf. Basically, this > means users have to manually select this font to use in their desktop or > browsers; if they want to use dejavu and zenhei together, they have to code up > their conf file, or wish one day the ancient font orders in 65-nonlatin get > updated. You could still include the old config file in avail.d/. > Jens, let me know if this is good, thanks I tried wqy-zenhei-fonts-0.8.34-2.20081027cvs.fc11 and it still behaves the same way for me on a Japanese desktop, overriding the default Japanese font.
Was your desktop font set as "sans"? and your lang=ja? Can you attach the 44-wqy-zenhei.conf file and the debug output: FC_DEBUG=4 fc-match -s "sans:lang=ja"
Will all the font changes in rawhide it would probably not be total waste if people with CJK knowledge did install all the rawhide font packages and check we do the right thing for sans/serif/monospace for CJK languages.
(In reply to comment #13) > Was your desktop font set as "sans"? and your lang=ja? Yes it is a default Japanese rawhide install. > Can you attach the 44-wqy-zenhei.conf file You mean it works for you in a japanese desktop session? ;-) 35f7bdfcc512ac6cb03a520e702a0c45 /etc/fonts/conf.d/44-wqy-zenhei.conf (I am not excluding a fontconfig bug: at least the behaviour seems have changed...)
Created attachment 331999 [details] fc-match-4.output.bz2 output for > FC_DEBUG=4 fc-match -s "sans:lang=ja"
hi Jens are you sure you are using the rawhide version of wqy-zenhei-fonts (0.8.38-2.f11)? in Feb. I already removed all the font preference from 44-wqy-zenhei.conf (see my reply earlier), so if the font order are not right, I don't think it has to do with the configuration files of for wqy-zenhei-fonts. Let me know what you find out.
I am using the latest package in rawhide (devel). Then perhaps it is 65-nonlatin.conf? :-/
if 65-nonlatin has not been changed from F10 to F11, then I don't think it caused this problem either (while, it did cause difficulties for CJK font selections as I described in the upstream bug, but that was already taken care of by the past revisions of all the 3rd party font config hacks, such as those for wqy-zenhei and wqy-bitmap-song, the only thing we can do better is to incorporate these hacks into fontconfig upstream, but, this is a different problem). I still give my biggest suspicion to cairo.
(In reply to comment #19) > I still give my biggest suspicion to cairo. sorry, this comment was actually talking about Bug#492510. > FC_DEBUG=4 fc-match -s "sans:lang=ja" Which Japanese font did you expect to be selected as the first? From your fc-match output, I can't find any specific settings that gives higher priority for a Japanese font. Does a japanese-specific fontconfig setting exist? (by the way, I really think fedora should have a language-selector-%locale% type of configurations for each cjk language, like in Ubuntu, that can save a lot of troubles).
(In reply to comment #20) > > FC_DEBUG=4 fc-match -s "sans:lang=ja" > > Which Japanese font did you expect to be selected as the first? VL Gothic > Does a japanese-specific fontconfig setting exist? Yes, vlgothic-fonts should have font .conf. > (by the way, I really think fedora should have a language-selector-%locale% > type of configurations for each cjk language, like in Ubuntu, that can save a > lot of troubles). Do you have a URL? I would like to look at it.
(In reply to comment #18) > I am using the latest package in rawhide (devel). > > Then perhaps it is 65-nonlatin.conf? :-/ Probably it is. I don't see any fault in the config for wqy-zenhei-fonts except the numeral prefix maybe? Anyway it should be a separate issue.
just for the record, I posted my diagnosis to this problem as the comment to Bug#492510.
Let's separate the discussion on bitmap-song and zenhei properly. from bug 492510: > 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! Right, 66-vlgothic-fonts.conf comes after.. > 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. I tested language-selector - it actually has a problem currently: eg its settings will override CJK fonts even when other CJK locale for app is specified. > 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 That doesn't sound like the right fix IMHO but perhaps I am missing something.
(In reply to comment #24) > > 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 > > That doesn't sound like the right fix IMHO but perhaps I am missing something. I agree with this. why don't we just restrict to apply ZenHei for only Chinese? adding something not-owned by the package looks ugly and isn't the right thing to do.
From Bug #492510: (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. As the suspicious was pointed out the above, I've confirmed getting rid of WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue.
(In reply to comment #26) > As the suspicious was pointed out the above, I've confirmed getting rid of > WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue. This id definitely not a right fix. Rename your 66-vlgothic config files to 44 or other numbers will also fix it. But as I said, the only solution is to coordinate between our config files, not to eliminate the other.
(In reply to comment #27) > (In reply to comment #26) > > As the suspicious was pointed out the above, I've confirmed getting rid of > > WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue. > > This id definitely not a right fix. Rename your 66-vlgothic config files to 44 > or other numbers will also fix it. But as I said, the only solution is to > coordinate between our config files, not to eliminate the other. No. remember that vlgothic fonts' fontconfig rule is only applied when lang == ja now. if I get rid of it, this numeral prefix race will breaks Chinese rendering. it doesn't solve ANYTHING. furthermore as you suggested the above, the language-selector idea also applies the rules at the same priority for CJK. I thought we have agreed that the difference is it's done by inside fontconfig or outside. if you're right, that would also means that idea won't solve anything then. I don't think so. and actually it works properly if it's gone from 65-nonlatin.conf. What's the issue you mind when it's gone from 65-nonlatin.conf?
(In reply to comment #28) > What's the issue you mind when it's gone from 65-nonlatin.conf? Because it is going completely to the other direction as what I was proposing: I hope to centralize all CJK font order settings into 1) 65-nonlatin and 2) a set of language-specific files. Removing font settings from theses centralized places and scatter these settings into multiple font packages will only increase the chance of conflict. Indeed, I tested my proposal and things are working perfectly. You can find my latest proposal at https://bugzilla.redhat.com/show_bug.cgi?id=499902 and I love to know what you think.
that idea is hard to maintain the rule. as you are aware, even current rule is outdated. maintaining it in the font packages with the accurate policy would rather be better than centralized management. aside from that, it just reflects your favorite someone may not likes. one could do modify it any time, but it may breaks after updating or causes the unwanted file creation on the packaging management system. applying the necessary rules with installing the package would be easier and intuitive.
(In reply to comment #30) > that idea is hard to maintain the rule. as you are aware, even current rule is > outdated. maintaining it in the font packages with the accurate policy would > rather be better than centralized management. I don't think so. I am not saying this must be included in fontconfig upstream (which get updated slowly), we can certainly create a new package which only include these CJK specific config files. Even fontconfig have similar files, we can still ship something to override if it gets updated. But the key idea is not to let individual font to do this. Functional-wise, they are completely equivalent. > aside from that, it just reflects > your favorite someone may not likes. one could do modify it any time, but it > may breaks after updating or causes the unwanted file creation on the packaging > management system. applying the necessary rules with installing the package > would be easier and intuitive. Either way does not prevent people from customizing their own list. As I said, they are simply equivalent.
(In reply to comment #31) > I don't think so. I am not saying this must be included in fontconfig upstream > (which get updated slowly), we can certainly create a new package which only > include these CJK specific config files. Even fontconfig have similar files, we > can still ship something to override if it gets updated. But the key idea is > not to let individual font to do this. Functional-wise, they are completely > equivalent. I have never been saying about fontconfig upstream but the centralized management is painful to maintain. > Either way does not prevent people from customizing their own list. As I said, > they are simply equivalent. Sure. so how is it better than applying it with the package installation then?
(In reply to comment #32) > Sure. so how is it better than applying it with the package installation then? To activate rules when installing font package is still possible with centralized approach. Just check out how WenQuanYi Bitmap Song is configured in Bug#499902.
(In reply to comment #33) > (In reply to comment #32) > > Sure. so how is it better than applying it with the package installation then? > > To activate rules when installing font package is still possible with > centralized approach. Just check out how WenQuanYi Bitmap Song is configured in > Bug#499902. It just works for your desired packages. but not for someone's. that's not a neutral solution. we can suggest the default font in comps. but someone may not likes that. the centralized management for the rule would prevents to use the preferred font packages for users. I'm afraid you can't maintain/update it without painful for you and everyone nor without any notice from the font package maintainers. The point I'm saying is: * Do not make any changes that affects to the other font packages. -> this can be solved to apply the rule for the specific language. * Do not make any changes that depends on the other font packages. otherwise it must has certain dependencies in the package. * Maintaining all of the font packages available on Fedora at the centralized fontconfig rule isn't realistic. as fontconfig is capable to read the rule from each fonts, maintaining it in each font packages with the certain policy would works enough. Right now some font packages doesn't follow even current policy. we have to mass-file a bug for them in F-12.
(In reply to comment #34) > It just works for your desired packages. but not for someone's. that's not a > neutral solution. But you do realize, in the end, there only exists one font order, no matter which way you set it. It is impossible for two fonts to be both preferred if they are both installed. If you want to control the orders by the presence of fonts, you can do exactly the same thing with a centralized conf file. The only difference is that a single config file gives you a master fallback list, and what you suggested determines this list ad-hoc, which is more difficult to predict and debug. > we can suggest the default font in comps. but someone may not > likes that. the centralized management for the rule would prevents to use the > preferred font packages for users. I'm afraid you can't maintain/update it > without painful for you and everyone nor without any notice from the font > package maintainers. > > > The point I'm saying is: > > * Do not make any changes that affects to the other font packages. > -> this can be solved to apply the rule for the specific language. IMHO, this is impossible. If you set <prefer> or use prepend/prepend_first, you ARE affecting other font packages. Indeed, that's how fontconfig works. Again, for a given system state, there is only one priority list for each language, no matter you set it from a single file, or by a bunch of font-specific files. > > * Do not make any changes that depends on the other font packages. otherwise it > must has certain dependencies in the package. It's not dependency, it is fallback relationship. If you set priority as A>B>C and some of them do not present, fontconfig will pick up the next one with the highest priority. I think that's how fontconfig was designed. > > * Maintaining all of the font packages available on Fedora at the centralized > fontconfig rule isn't realistic. as fontconfig is capable to read the rule from > each fonts, maintaining it in each font packages with the certain policy would > works enough. If you check my old posts, I used to be a supporter to font-specific config files, because I know the fonts I maintained are good, but other high priority fonts prevent the use of these good one but I have no control (for exp. 65-nonlatin). I endured a lot of troubles in order to set my own list. Now I am suggesting to get things right from the very beginning, and save time of the font maintainers. In you really want to insist, you can still do what you have been doing, but having a up-to-date default language-specific font list will greatly reduce the amount of work you need to do. > > Right now some font packages doesn't follow even current policy. we have to > mass-file a bug for them in F-12.
(In reply to comment #35) > But you do realize, in the end, there only exists one font order, no matter > which way you set it. It is impossible for two fonts to be both preferred if > they are both installed. If you want to control the orders by the presence of > fonts, you can do exactly the same thing with a centralized conf file. The only > difference is that a single config file gives you a master fallback list, and > what you suggested determines this list ad-hoc, which is more difficult to > predict and debug. That's the policy to not mess up. > IMHO, this is impossible. If you set <prefer> or use prepend/prepend_first, you > ARE affecting other font packages. Indeed, that's how fontconfig works. Again, > for a given system state, there is only one priority list for each language, no > matter you set it from a single file, or by a bunch of font-specific files. Right. I meant language, but not font packages. sorry. > It's not dependency, it is fallback relationship. If you set priority as A>B>C > and some of them do not present, fontconfig will pick up the next one with the > highest priority. I think that's how fontconfig was designed. At least you should do as long as you expect them to get it working. otherwise you just leave it to outside your rule. If you have a dependency in the package, the referred font package owner or that package owner can realizes any attentions is needed when something is changed. you can prevent the font naming issue you've faced in wqy-bitmap-fonts say. > If you check my old posts, I used to be a supporter to font-specific config > files, because I know the fonts I maintained are good, but other high priority > fonts prevent the use of these good one but I have no control (for exp. > 65-nonlatin). I endured a lot of troubles in order to set my own list. Now I am > suggesting to get things right from the very beginning, and save time of the > font maintainers. In you really want to insist, you can still do what you have > been doing, but having a up-to-date default language-specific font list will > greatly reduce the amount of work you need to do. Yes, but what you are suggesting is actually the same thing what fontconfig does because both are centralized management. why you feel it's comfortable is, you're about to get an control of it. it's not necessarily a happy solution for everyone.
This font is no longer installed by default, so removing from the blocker list.
Whoops, wrong bug.
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
We need a .conf file in fedora to make this only apply for zh like we do for other CJK fonts.
Created attachment 376560 [details] add fedora fontconfig for zh This adds the following .conf file to the package and works well for me. Any objections to commiting this to package cvs?
Created attachment 376561 [details] fedora .conf file for zh Based on the vlgothic .conf files and /usr/share/fontconfig/templates/l10n-font-template.conf.
I am changing comps-f13 to make wqy-zenhei-fonts the default Chinese default font.
Not sure how TC users feel about zenhei so it may make sense to have zenhei as default SC font and uming (though serif) as TC font still perhaps, but let's test a little in rawhide first.
F13 rawhide is now using comps-f13 and zenhei is not overriding ja so going ahead with the above change.
Actually I think we should do this for f12 and f11 too.
However the 65-wqy-zenhei.conf is not enough. :-( I think we need to get rid of 65-nonlatin.conf! or at least prune it (of fedora fonts).
How about using prepend_first instead of prepend ? In my test, prepend_first could fix this problem. If you like wqy-zenhei for zh, you also may need to change 64-ttf-arphic-uming.conf . BTW, I recommend to use compare="contains" attribute in lang tag. Currently :lang=ja-jp works fine but :lang=ja doesn't work while Red Hat doesn't provide the short locale names. <test name="lang" compare="contains"> <string>ja</string> </test>
Maybe binding="strong" for vlgothic is a better workaround?
Replacing the "65" priority with "65-0", etc in Fedora fonts packages with lang tags should help according to Behdad. Need to test to verify this, but it sounds a reasonable solution.
Moving this to vlgothic since we can fix it there easily. Other fonts packages should also follow: so maybe we should have a tracking bug?
(Similarly 65-vlgothic-pgothic.conf should move to 65-0-vlgothic-pgothic.conf of course.)
fixed in vlgothic-fonts-20100126-1.fc14.
vlgothic-fonts-20100126-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc13
vlgothic-fonts-20100126-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc12
vlgothic-fonts-20100126-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc11
vlgothic-fonts-20100126-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
vlgothic-fonts-20100126-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
vlgothic-fonts-20100126-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.