Description of problem: In my en_US.UTF-8 locale, I use default Chinese font which is "Adobe Source Han Sans CN", and I set the language ordering in fonts-tweak tools as the first language(actually,it's the only language i added). when I type Chinese character, e.g. 今, or 骨, the shape of it is obviously not Simplified Chinese. I doubt these characters are from Japanese or Traditional Chinese. Version-Release number of selected component (if applicable): Fedora 23 fonts-tweak-tool.x86_64 0.3.2-8.fc23 How reproducible: everytime Steps to Reproduce: 1. set locale as en_US 2. set Chinese (P.R. of China) - 中文（简体） as the first language in "Language Ordering" tab of fonts-tweak-tools 3. type Chinese character like 骨 or 今 Actual results: the character is from Japanese or Traditional Chinese Expected results: the character should be from Simplified Chinese Additional info: I understand this is hard to say where the character is from from its looking， but one can compare 骨 in http://blog.typekit.com/alternate/source-han-sans-chs/
the link is the first post in English http://blog.typekit.com/2014/07/15/introducing-source-han-sans/
More reference http://googlechinablog.blogspot.com/2014/07/googlenoto-sans-cjk.html
Have you restarted your desktop after that change? and see if your $HOME/.i18n has FC_LANG=zh-CN and it is loaded on your shell say.
Yes, I have restarted my laptop a few times. And there is no $HOME/.i18n file in my home directory, needless to say FC_LANG=zh-CN is in there or not.
Does fonts-tweek-tool say something if you run it from the terminal?
Hey Akira This is what I got when I launch fonts-tweak-tool These are warnings, any problem? [raywang@laptop ~]$ fonts-tweak-tool /usr/lib64/python2.7/site-packages/fontstweak/util.py:30: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded. from gi.repository import Gtk /usr/lib64/python2.7/site-packages/fontstweak/aliasui.py:36: PyGIWarning: Easyfc was imported without specifying a version first. Use gi.require_version('Easyfc', '0.12') before import to ensure that the right version gets loaded. from gi.repository import Easyfc /usr/bin/fonts-tweak-tool:34: PyGIWarning: FontsTweak was imported without specifying a version first. Use gi.require_version('FontsTweak', '0') before import to ensure that the right version gets loaded. from gi.repository import FontsTweak Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
and no output after adding a language then?
Created attachment 1127885 [details] fonts-tweak-tool start from console Yes, when I do remove/add the new language, there is just no output
and no .i18n file created? that is quite strange. can you create .i18n file manually on your homedir? and if you add FC_LANG-zh-CN there and run fonts-tweek-tool, can you see Simplified Chinese in the language ordering tab?
Hey, I'm sorry, there is ~/.i18n in my home directory, and FC_LANG-zh-CN is in the file. However the font for Chinese characters is still matching Traditional Chinese (zh-TW) rather than zh-CN (I add P.R.China as my first language in "language order", and I didn't add Chinese (Taiwan) in the language order)
How about the result of: FC_LANG=zh-CN LANG=en_US.UTF-8 fc-match?
Hello Akira, I got this [raywang@laptop ~]$ FC_LANG=zh-CN LANG=en_US.UTF-8 fc-match SourceHanSansCN-Regular.otf: "思源黑体 CN" "Regular" But the looking of Chinese characters still match Traditional Chinese in my Simplified Chinese environment. Thanks
What applications are you seeing that unexpected behavior? the basic behavior on fontconfig looks good though.
Well, as long as I need Chinese characters, the characters are not from correct character set. typing Chinese in text-editor or terminal, or in Webbrowser or libreoffice etc etc...., it's everywhere For more difference between different Chinese character set of the character, please refer to the link. http://blog.typekit.com/2014/07/15/introducing-source-han-sans/ You can take 骨 as the example, from what I can tell based on this character in the above link, it seems 骨 is from Japanese character set, rather than Simplified Chinese
which text editor, terminal, web browser? Tried on libreoffice 5, it sets Source Han Sans CN automatically here when pasting 骨 on writer though. what font is chosen on your libreoffice? Is that font installed from the Fedora package right?
Hey Akiro Every text editor, for example, gedit. Every web browser, for example, chrome or firefox. I have to correct myself, and you're right. In libreoffice, you use "Source Han Sans CN" as the font, it shows the character correctly. However, if you paste 骨 in the terminal or gedit, observe the shape of the character is slightly different, especially on the top part of it. (in Simplified Chinese, the direction of the top part is to the left, in Japanese or Traditional Chinese, the direction of top part of it is to the right, which is just mirror to the Simplified Chinese one)
You can try in libreoffice to see the different too. paste 骨 in libreoffice three times. The first 骨 as in "Source Hans San CN" font The second 骨 as in "Source Hans San TW" font The third 骨 as in "Source Hans San JP" font or some other Japanese font if available You can tell the difference from there.
I know those difference and works fine here. since the result of fc-match looks good, I don't think it is a problem in fontconfig. those applications basically has own preferences about fonts. please check. at least gedit looks good here.
Hey Akira, Well, the application like libreoffice, you can set different fonts for characters, but the applications like gedit or gnome-terminal, they all use system default fonts, IMHO, changing the default font for all the applications is not a proper way to do that, especially they changes are only for displaying characters, since English letters will be also from the new font. If I apply the "P.R.China" as my system default language(zh_CN.UTF-8), and reboot the laptop, the Chinese font are looking good and correct. However, if use English(US) as my default language(en_US.UTF-8), and set "P.R.China" as the first language in "Language Order", the Chinese character is not correct, and they may be from Japanese or Traditional Chinese character set. Hope that helps to understand my problem, and thank you so much for the help.
Created attachment 1129116 [details] screenshot of gedit with LANG=en_US.UTF-8 and FC_LANG=zh-CN This is the screenshot of gedit being invoked with LANG=en_US.UTF-8 and FC_LANG=zh-CN here and changed the font size to improve the visibility but still same for the family to the default "Monospace". I think it works as expected. if it is not same for you, maybe good to sort out what fonts you installed on your box. there might be any problematic fontconfig configuration installing by any packages or in your HOME.
Hey Akira Thanks for your reply. I've verified your test, and yes does look good. However,if you test it on the application use system font or don't have configuration for fonts, it looks bad. Please see my following comments [raywang@laptop ~]$ LANG=en_US.UTF-8 FC_LANG=zh-CN fc-match SourceHanSansCN-Regular.otf: "思源黑体 CN" "Regular" It's a new and fresh install Fedora 23, I didn't do any configuration or install a font Installed Packages aajohan-comfortaa-fonts.noarch 2.004-5.fc23 @koji-override-0 abattis-cantarell-fonts.noarch 0.0.17.2-1.fc23 @koji-override-0 adobe-source-han-sans-cn-fonts.noarch 1.004-1.fc23 @koji-override-0 adobe-source-han-sans-tw-fonts.noarch 1.004-2.fc23 @updates dejavu-fonts-common.noarch 2.35-2.fc23 @koji-override-0 dejavu-sans-fonts.noarch 2.35-2.fc23 @koji-override-0 dejavu-sans-mono-fonts.noarch 2.35-2.fc23 @koji-override-0 dejavu-serif-fonts.noarch 2.35-2.fc23 @koji-override-0 fontconfig.x86_64 2.11.94-4.fc23 @koji-override-0 fontpackages-filesystem.noarch 1.44-14.fc23 @koji-override-0 fonts-tweak-tool.x86_64 0.3.2-8.fc23 @fedora ghostscript-fonts.noarch 5.50-34.fc23 @koji-override-0 gnome-font-viewer.x86_64 3.16.2-3.fc23 @koji-override-0 gnu-free-fonts-common.noarch 20120503-11.fc23 @koji-override-0 gnu-free-mono-fonts.noarch 20120503-11.fc23 @koji-override-0 gnu-free-sans-fonts.noarch 20120503-11.fc23 @koji-override-0 gnu-free-serif-fonts.noarch 20120503-11.fc23 @koji-override-0 google-android-emoji-fonts.noarch 1.01-0.4.20120228git.fc23 @koji-override-0 google-crosextra-caladea-fonts.noarch 1.002-0.6.20130214.fc23 @koji-override-0 google-crosextra-carlito-fonts.noarch 1.103-0.4.20130920.fc23 @koji-override-0 google-noto-fonts-common.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-lisu-fonts.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-mandaic-fonts.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-meetei-mayek-fonts.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-tagalog-fonts.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-tai-tham-fonts.noarch 20150417-2.fc23 @koji-override-0 google-noto-sans-tai-viet-fonts.noarch 20150417-2.fc23 @koji-override-0 jomolhari-fonts.noarch 0.003-20.fc23 @koji-override-0 khmeros-base-fonts.noarch 5.0-20.fc23 @koji-override-0 khmeros-fonts-common.noarch 5.0-20.fc23 @koji-override-0 libXfont.x86_64 1.5.1-3.fc23 @koji-override-0 liberation-fonts-common.noarch 1:1.07.4-6.fc23 @koji-override-0 liberation-mono-fonts.noarch 1:1.07.4-6.fc23 @koji-override-0 liberation-sans-fonts.noarch 1:1.07.4-6.fc23 @koji-override-0 liberation-serif-fonts.noarch 1:1.07.4-6.fc23 @koji-override-0 libfontenc.x86_64 1.1.3-2.fc23 @koji-override-0 libreoffice-opensymbol-fonts.noarch 1:5.0.4.2-3.fc23 @updates lklug-fonts.noarch 0.6-13.20090803cvs.fc23 @koji-override-0 lohit-assamese-fonts.noarch 2.91.3-1.fc23 @koji-override-0 lohit-bengali-fonts.noarch 2.91.3-1.fc23 @koji-override-0 lohit-devanagari-fonts.noarch 2.95.2-1.fc23 @koji-override-0 lohit-gujarati-fonts.noarch 2.92.2-4.fc23 @koji-override-0 lohit-gurmukhi-fonts.noarch 2.91.0-6.fc23 @koji-override-0 lohit-kannada-fonts.noarch 2.5.3-7.fc23 @koji-override-0 lohit-odia-fonts.noarch 2.91.0-2.fc23 @koji-override-0 lohit-tamil-fonts.noarch 2.91.1-2.fc23 @koji-override-0 lohit-telugu-fonts.noarch 2.5.4-1.fc23 @koji-override-0 naver-nanum-fonts-common.noarch 3.020-15.20140930.fc23 @koji-override-0 naver-nanum-gothic-fonts.noarch 3.020-15.20140930.fc23 @koji-override-0 paktype-naskh-basic-fonts.noarch 4.1-5.fc23 @koji-override-0 paratype-pt-sans-fonts.noarch 20141121-2.fc23 @koji-override-0 sil-abyssinica-fonts.noarch 1.200-9.fc23 @koji-override-0 sil-mingzat-fonts.noarch 0.100-4.fc23 @koji-override-0 sil-nuosu-fonts.noarch 2.1.1-10.fc23 @koji-override-0 sil-padauk-fonts.noarch 2.8-9.fc23 @koji-override-0 smc-fonts-common.noarch 6.1-5.fc23 @koji-override-0 smc-meera-fonts.noarch 6.1-5.fc23 @koji-override-0 stix-fonts.noarch 1.1.0-8.fc23 @koji-override-0 tabish-eeyek-fonts.noarch 1.0-8.fc23 @koji-override-0 thai-scalable-fonts-common.noarch 0.5.0-10.fc23 @koji-override-0 thai-scalable-waree-fonts.noarch 0.5.0-10.fc23 @koji-override-0 urw-fonts.noarch 3:2.4-21.fc23 @koji-override-0 vlgothic-fonts.noarch 20141206-2.fc23 @koji-override-0 xorg-x11-font-utils.x86_64 1:7.5-29.fc23 @koji-override-0
Created attachment 1129140 [details] font in gnome-terminal is not correct font on terminal, neither on gnome-terminal, nor on input method (fcitx)
Created attachment 1129141 [details] font on gedit and input method font on gedit is correct, on input method is not.
Created attachment 1129142 [details] font in browser address bar and in the webpage font on browser's address bar is not correct. font on input method is not correct font on webpage is correct (didn't take the screenshot, but it's correct in the page, It might because I set the font in the page to use Adobe Source Sans Han CN)
(In reply to Ray Wang from comment #21) > Hey Akira > > Thanks for your reply. I've verified your test, and yes does look good. > However,if you test it on the application use system font or don't have > configuration for fonts, it looks bad. Please see my following comments What does the system font mean here? for example, gnome-terminal and gedit uses "Monospace" as default font. if both applications has different behavior, I think there are a bug in that application. please file a separate bug for them. As long as there are applications working correctly, I don't think there are anything else I can do in fontconfig.
Hey Akira In my case,(I guess it's also common for others), gnome-terminal uses "Monospace" as the default font. When typing Chinese characters, those characters are obviously not from "Adobe Source Han Sans CN" (maybe from Adobe Source Han Sans TW" or other Japanese font). If I explicitly set the custom font of gnome-terminal to "Adobe Source Han Sans CN", and type Chinese characters, the font is correct. That JUST means fontconfig does not match the characters correctly, or use wrong language order to render the characters. I think that also applies the font in browsers' address bar. I don't know why gedit can display correct font though. Thank you so much
(In reply to Ray Wang from comment #26) > Hey Akira > > In my case,(I guess it's also common for others), gnome-terminal uses > "Monospace" as the default font. When typing Chinese characters, those > characters are obviously not from "Adobe Source Han Sans CN" (maybe from > Adobe Source Han Sans TW" or other Japanese font). Again, it is an application bug. > That JUST means fontconfig does not match the characters correctly, or use > wrong language order to render the characters. I think that also applies the > font in browsers' address bar. fontconfig just returns the best font *for* the requested font from applications. if it is wrong or they wrongly use the result, it won't looks good. as we confirmed if the request is sane, it works. that is good enough to explain this isn't a bug in fontconfig.
Hello Akira Thank you for your explanation. I really appreciate it. > fontconfig just returns the best font *for* the requested font from > applications. if it is wrong or they wrongly use the result, it won't looks > good. as we confirmed if the request is sane, it works. that is good enough > to explain this isn't a bug in fontconfig. Actually, I set two languages in "Language Ordering" tab in fonts-tweak-tool, Chinese (P.R.China) Chinese (Taiwan) What's the expected behavior? From my guess 1. Set FC_LANG to zh-CN and then zh-TW, and other LC_* 2. Application which use system default font. For English letters, it will search and match first available fonts to render the letters. For example "Liberation" or "Deja Vu"(I don't know where to check the font matching orders); For Chinese or other languages which the default system font don't have that character set, it will search and match the first available font which has those characters. 3. In my case, when I type a Chinese character, it will find it if default font has it, otherwise, it will continue to find it from "Adobe Source Han Sans CN" and then "Adobe Source Han Sans TW", since I set the "Chinese (P.R.China)" as the first language, I'm expecting the character will be pick up from "Adobe Source Han Sans CN" rather than other font. I'm assuming fontconfig or fonts-tweak-tool will change or set the correct environment variable for me, so that application could use these variable to display letters/characters correctly. Having said that it's an application bug. IMHO, I'm afraid I'm not with it. Because if I set system language to "Chinese (China)" in "Region & Language", everything is working fine, the only difference is that I'm using English locale (en_US.UTF-8) Again thank you so much for your patience
fonts-tweek-tool is just an GUI to help users to configure fontconfig configration. FC_LANG is an environment variable to give a priority to the given language but the highest priority is still the language in the query. let's see: $ LANG=en_US.UTF-8 FC_LANG-zh-CN:zh-TW FC_DEBUG=4 fc-match ... FcConfigSubstitute Pattern has 2 elts (size 16) lang: "zh-cn"(w) "zh-tw"(w) prgname: "fc-match"(s) You can see FC_LANG can affects the query with the weak binding. and: $ LANG=en_US.UTF-8 FC_LANG-zh-CN:zh-TW FC_DEBUG=4 fc-match ... cConfigSubstitute Pattern has 2 elts (size 16) lang: ja(s) "zh-cn"(w) "zh-tw"(w) prgname: "fc-match"(s) the languages in the FC_LANG is added after the original query. (In reply to Ray Wang from comment #28) > For Chinese or other languages which the default system font don't have that > character set, it will search and match the first available font which has > those characters. Not exactly. it actually depends on the query. fontconfig computes the score to select the best font. > 3. In my case, when I type a Chinese character, it will find it if default > font has it, otherwise, it will continue to find it from "Adobe Source Han > Sans CN" and then "Adobe Source Han Sans TW", since I set the "Chinese > (P.R.China)" as the first language, I'm expecting the character will be pick > up from "Adobe Source Han Sans CN" rather than other font. That is correct in Pango. but not necessarily correct for everything. determining the fallback font is up to the library because the best font might not be picked up by the first query. that's why setting LANG=zh_CN works but not necessarily on LANG=en_US. and saying that it is an application bug. Apparently there are some applications you want to see the correct behavior and there are nothing to do in fonts-tweak-tool nor fontconfig. I'll close this so far. Please file another bug for the certain applications and back to (maybe) fontconfig as needed.
the second example meant: $ LANG=en_US.UTF-8 FC_LANG=zh-CN:zh-TW FC_DEBUG=4 fc-match :lang=ja but anyway.
Hey Akira Really appreciate your reply, I'll see what I can do to improve this in the future. For right now, I will bear with my current desktop looking :) Thanks again
Hi Ray Wang, Maybe try to remove the adobe-source-han-sans-tw-fonts package to work around it for your use case.
Hey Wu Peng, Thanks for you advise, but removing adobe-source-han-sans-tw-fonts may cause other problems. For example, Traditional Chinese characters may not be displayed correctly. IMHO, it's better to have a way to modify the characters matching order manually as long as one can.
Hi Ray Wang, For Traditional Chinese characters, maybe install the google-noto-cjk-fonts package.
Hey Wu Peng Thanks for the tip. However, it doesn't work. I've tried to install fonts-tweak-tools, and put P.R.C Simplified Chinese as the first one language in "Language Ordering", and I can see FC_LANG is set in ~/.i18n, but it seems it doesn't show up in environment variable ($ env). I have tried to launch gedit by $ FC_LANG=zh_CN gedit It works btw. So I assume there is a better way to put FC_LANG variable into the env vars?
Hi Ray Wang, Maybe this is related to the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1317385
Hi Wu Peng bug 1317385 does fix the problem if I run gedit from the gnome-terminal, the Chinese characters are looking good. However, if I launch gedit from GUI (press super key, and type 'gedit'), the characters in gedit are still not looking correct. Additionally, the characters in the input method dropdown menu are not look good too. I guess we need to set and export FC_LANG not only for shell, but also for desktop environment?
Hi Ray Wang, Maybe you could try to add export to ~/.i18n file.
'export' shouldn't be added into .i18n file. that has the portability issue among shells and fonts-tweak-tool may not work correctly after that.
Thanks Akira So what do you recommend to have FC_LANG variable set correctly in gnome-shell environment? It seems if I launch gedit from gnome-terminal, then the characters are correct, but if i launch gedit from gnome GUI, then the characters are not correctly displayed.
(In reply to Ray Wang from comment #40) > Thanks Akira > > So what do you recommend to have FC_LANG variable set correctly in > gnome-shell environment? > > It seems if I launch gedit from gnome-terminal, then the characters are > correct, but if i launch gedit from gnome GUI, then the characters are not > correctly displayed. See the proposed patch in the url at comment#36.
Hey Akira Thanks for your input. I'm sorry to say that I have tried and tested the patch in the bug 1317385, but unfortunately, the patch seems not fix the problem
Did you log out from our desktop once?
s/our/your/ but anyway.
Oh yes, I have rebooted my laptop, and it's still not working
hmm, does `sh -c ". /etc/profile.d/lang.sh && sh -c printenv|grep FC_LANG"` work?
Hello Akira Yes, that one works
Hm, that may be because gnome-session didn't be brought up with /etc/profile.d/lang.sh. dunno what to fix it there. anyway, adding the keyword of "export" into .i18n causes an error on csh-like environment. so apparently need further fix to get this working for desktops (or simply GNOME dunno)
Hi, I have opened a bug 1326547 to track on this.