fc-match calling API order is following: - FcConfigSubstitute (0, pat, FcMatchPattern); => substitute family(with lang tag is NULL) - FcDefaultSubstitute (pat); => set default lang tag from $LANG This order causes ignoring $LANG when substitute family in FcPattern. Therefore there is incosisency between "fc-match serif" and "fc-match serif:lang=ja" when $LANG is "ja". How to reproduce. 1. check LANG $ echo $LANG ja_JP.UTF-8 2. check default pattern $ FC_DEBUG=4 LD_LIBRARY_PATH=./src/.libs/ ./fc-match/.libs/fc-match serif | grep -A2 donePattern 3. add font which there is not in abobe pattern, for my LANG(ja) ex.) add TakaoPGothic (/usr/share/fonts/truetype/takao/ttf-takao-pgothic.ttf) $ vi ~/.fonts.conf <match target="pattern"> <test name="lang" compare="contains"> <string>ja</string> </test> <test qual="any" name="family"> <string>serif</string> </test> <edit name="family" mode="prepend" binding="strong"> <string>TakaoPMincho</string> </edit> </match> </fontconfig> 4. retry fc-match $ FC_DEBUG=4 LD_LIBRARY_PATH=./src/.libs/ ./fc-match/.libs/fc-match serif | grep -A2 donePattern but TakaoPMincho doesn't appear in pattern, and not selected TakaoPMincho 5. if specify lang tag, then TakaoPMincho appears in pattern in head and is selected. $ FC_DEBUG=4 LD_LIBRARY_PATH=./src/.libs/ ./fc-match/.libs/fc-match serif:lang=ja | grep -A2 donePattern 5. or if commented out lang tag in ~/.fonts.conf, then TakaoPMincho appears in pattern in head and is selected.
Created attachment 44647 [details] [review] change order API My suggestion is that FcDefaultSubstitute() should call before FcConfigSubstitute().
(In reply to comment #1) > Created an attachment (id=44647) [details] > change order API > > My suggestion is that FcDefaultSubstitute() should call before > FcConfigSubstitute(). No. That's wrong. I'm not sure how to fix this correctly. Will think about it.
I'd like to encourage to fix the broken apps/tools to add the certain lang what they want. this just reminds me I've seen the same issue two or three years ago and was asking why not adding the default lang in the default pattern. Behdad suggested some and fixing Bug#17311 was one of them. again, thinking about it, I don't think that would really helps because what we are expecting on the result of fontconfig is to get the certain fonts for characters and that's less relevant to the locale today since we are moving to Unicode. one can see non-native languages on applications regardless of their current locale. adding the sort of FC_LOCALE_LANG would make it complicated and would speeds up to be scary on the lang selection in the config files. Back to the way to fix this, in this case, there are no strict requirements on what lang is supposed to be used for, because there no real characters to be queried on fc-match. so if there are no lang object in the pattern, we could simply use FcGetDefaultLang() to add the lang pattern in fc-match prior to invoke FcConfigSubstitute(). we may need to fix Bug#32853 first though.
Well, while this bug is about fc-match, the problem is broader. But I can see the logic in your reasoning. Maybe that's what we want afterall. I'll consider that.
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz32853 http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=add-lang-to-pattern Those changes would helps this issue.
merged into git master. and the behavior should be better now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.