<family> tag is used for <alias> though, sometimes wants to add the family conditionally, particularly for certain language. <alias> is capable to have <test> elements but may be a good idea to have the lang attribute to <family> as another syntactic sugar: <alias> <family>serif</family> <prefer> ... <family lang="ja">MS Mincho</family> <family lang="zh-cn,zh-tw">AR PL ShanHeiSun Uni</family> ... </prefer> </alias> interpreted like: <match> <test name="family"> <string>serif</string> </test> <test name="lang"> <string>ja</string> </test> <edit name="family" mode="prepend"> <string>MS Mincho</string> </edit> </match> <match> <test name="family"> <string>serif</string> </test> <test name="lang"> <string>zh-cn</string> </test> <edit name="family" mode="prepend"> <string>AR PL ShanHeiSun Uni</string> </edit> </match> <match> <test name="family"> <string>serif</string> </test> <test name="lang"> <string>zh-tw</string> </test> <edit name="family" mode="prepend"> <string>AR PL ShanHeiSun Uni</string> </edit> </match>
Why do we need that? This way you won't get all the other aliases which are useful for font fallback. Choosing the one that matchces language is the job of the matcher, isn't it? Isn't the problem the fact that MS Mincho should just have "ja" lang but it has all the Chinese ones too, because of the Han unification? Didn't we fix that by allowing langset surgery in target="scan"?
I was thinking of improving 65-nonlatin.conf say, particularly to address selecting unexpected font against the order of the fonts. I'm expecting that applications gives the certain language in FcPattern though, it even breaks with/without the language in FcPattern if the order of the font is totally broken. As you say finding better font against langauge is matcher's job right. but this way won't affect too much IMHO because it's hard to find one out without the lang in FcPattern and it should perfectly works if one gives the certain lang in FcPattern then. what I implemented to modify the langset in target="scan" was a workaround IMHO... indeed it's capable to address this issue though, keeping "broken" default configuration isn't a good idea. this sort of issues should be fixed upstream so that most distros more or less has managed fonts in similar way. in other words they know it's broken without it.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/42.
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.