Description of problem: In /etc/fonts/conf.d/65-wqy-zenhei.conf file, it prioritized "WenQuanYi Zen Hei" fonts for Sans-Serif/Serif/Monospace linking for "zh" locale. This will force user to use "WenQuanYi Zen Hei" font for non-Chinese charactors which is not a good choice. To workaround this problem, user can create "/etc/fonts/local.conf" like below to prioritize their English fonts at 51 config priority level (51-local.conf). === <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <!-- created by WenQuanYi FcDesigner v0.5 --> <match> <test name="family"><string>sans-serif</string></test> <edit name="family" mode="prepend" binding="strong"> <string>Liberation Sans</string> </edit> </match> <match> <test name="family"><string>serif</string></test> <edit name="family" mode="prepend" binding="strong"> <string>Liberation Serif</string> </edit> </match> <match> <test name="family"><string>monospace</string></test> <edit name="family" mode="prepend" binding="strong"> <string>Liberation Sans Mono</string> </edit> </match> </fontconfig> ===== To fix this bug, we have these choices: 1. Purge "/etc/fonts/conf.d/65-wqy-zenhei.conf" and inform user to create their own /etc/fonts/local.conf 2. Keep "/etc/fonts/conf.d/65-wqy-zenhei.conf" but warn user by asking them to create /etc/fonts/local.conf with their own English fonts. 3. Update "/etc/fonts/conf.d/65-wqy-zenhei.conf" by add "Liberation" fonts before WQY font. Version-Release number of selected component (if applicable): wqy-zenhei-fonts-0.9.45-3.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Change RHEL locale to zh by adding this line to /etc/sysconfig/i18n: === LC_CTYPE="zh_CN.UTF-8" === 2. yum install -y wqy-zenhei-fonts 3. Reboot OS Actual results: Sans-Serif/Serify/Monospace are using "WenQuanYi Zen Hei" for all characters even for non-Chinese characters. Expected results: "WenQuanYi Zen Hei" should only used for Chinese characters. Additional info: Check workaround and suggest fix above. If Fedora has the same issue, please fix also. Thanks.
Liberation has some font size issue (not sure why and how). After I change to DejaVu, problem gone. FYI.
IIRC, it may cause problems if we fix it. See bug: https://bugzilla.redhat.com/show_bug.cgi?id=485566. Feel free to comment it.
That's not a "cause" but just same issue that originally reported against Japanese font for Japanese. to make my position clearer, what a font fontconfig thinks better depends on a request from application. just asking for sans-serif, serif, or monospace without the language requirement makes no sense. I think you better complaining that to application that you are facing this issue.
Maybe we could ask the wqy-zenhei-fonts to improves its English characters? If the English character's quality is improved, this problem will not affect users.
maybe but that may depends on the context of complaint. so that would be good if the reporter can explain why that is not a "good choice".
Created attachment 708676 [details] Dejavu font vs WenQuanYi font When I creating this pdf in Libreoffice, I found WenQuanYi font is larger than DejaVu even with same size number. You can check by creating a table, change left side to DejaVu font, and the other side to WenQuanYi. The row height will increase automatically when you using WenQuanYi font.
Hi Qianqian Fang, Could you improves the English characters in WenQuanYi Zen Hei Sharp, and remove the bitmap glyphs from the English characters? Thanks in advance.
hi Peng if you don't like the Latin bitmaps in Zen Hei Sharp, you can overwrite it with other Latin fonts. Actually that's exactly what I did in the upstream packages. I put bitstream/dejavu before Zen Hei Sharp in 43-wqy-zenhei-sharp.conf. have you changed it?
Hi Qianqian Fang, Please see https://bugzilla.redhat.com/show_bug.cgi?id=485566#c24. The above are some objections to land this change or a similar approach I proposed in comment #25 and #26. Yes, I changed it according to fedora font package guidelines.
I did not read the full thread in Bug#485566, but judging from the title, I do not see any conflict with the upstream settings, in fact, it does exactly so. in any case, modifying glyphs by the upstream is not the solution to this issue. you should use fontconfig to put preferred latin fonts in front of zenhei sharp. that is what fontconfig was designed for.
The Bug#485566 is the same issues and fixes as this bug. The problem is that the changes are rejected. I want to use the fontconfig to fix it by prepending the Latin fonts, too.
then I am confused. this bug is tagged for wqy-zenhei-fonts. if zenhei's setting was correct, but other packages overwrites it and prevent it from working, then you should find out which one interferes, and tag the bug with that package instead. again, I don't see anything wrong on the zenhei side (at least for the upstream package).
why changing assignee to me?
(In reply to comment #13) > why changing assignee to me? Sorry.
Continue the discussion in Fedora. Need to find a right fix first.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Some Refer URL: https://bugzilla.gnome.org/show_bug.cgi?id=481210
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.