Hi,
I'd like to propose to ensure FC_LANG_OBJECT is available in the
pattern at fontconfig, for FcMatchPattern too.
this would somewhat helps if applications is rendering the text
without the certain language information, such as the plain text.
Details:
The behaviour really depends on how applications implements it. it may
works as expected if they raise FcDefaultSubstitute() prior to
FcConfigSubstitute(pat, FcMatchPattern), because FcDefaultSubstitute()
adds FC_LANG_OBJECT and others too.
I'm not talking about that case, but the case is
FcConfigSubstitute(pat, FcMatchPattern) and FcDefaultSubstitute() then
as fc-* tools and Pango do.
In this case, fontconfig evaluates all of the matching rules that is
targetting "pattern" without FC_LANG_OBJECT pattern, and applies.
evaluating all of the matching rules that is targetting "font" with
FC_LANG_OBJECT and applies then. this means all of the rules that
contains like:
<match>
<test name="lang">
<string>lang</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend" binding="same">
<string>fontname</string>
</edit>
</match>
is just skipped because no matches in the lang. this issue explains
why LANG=mr_IN.UTF-8 fc-match and fc-match :lang=mr at
http://bugs.freedesktop.org/show_bug.cgi?id=23419#c15 say made the
different result.
Why not adding FC_LANG_OBJECT anyway to the pattern for FcMatchPattern
as well and ensure it in fontconfig to make all happy?
Regards,
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
