Bug 35482

Summary: fc-match cannot handle $LANG
Product: fontconfig Reporter: Mitsuya Shibata <mty.shibata>
Component: fc-matchAssignee: Akira TAGOH <akira>
Status: RESOLVED FIXED QA Contact: Behdad Esfahbod <freedesktop>
Severity: normal    
Priority: medium CC: akira, fontconfig-bugs, freedesktop
Version: 2.8   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: change order API

Description Mitsuya Shibata 2011-03-21 00:01:45 UTC
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.
Comment 1 Mitsuya Shibata 2011-03-21 00:09:05 UTC
Created attachment 44647 [details] [review]
change order API

My suggestion is that FcDefaultSubstitute() should call before FcConfigSubstitute().
Comment 2 Behdad Esfahbod 2011-06-22 10:12:38 UTC
(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.
Comment 3 Akira TAGOH 2011-07-15 04:47:25 UTC
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.
Comment 4 Behdad Esfahbod 2011-07-15 05:49:59 UTC
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.
Comment 6 Akira TAGOH 2012-06-08 00:08:16 UTC
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.