Akira TAGOH
2009-Nov-20 08:52 UTC
[Fontconfig] Proposal to always add FC_LANG_OBJECT to the pattern
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
Behdad Esfahbod
2009-Nov-23 00:33 UTC
[Fontconfig] Proposal to always add FC_LANG_OBJECT to the pattern
On 11/20/2009 03:52 AM, Akira TAGOH wrote:> 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.Hi Akira, You''re correct that this problem exists. I first found out about it in 2006 Text Layout Summit. However, it does not affect GTK+ applications since Pango always sets FC_LANG. But I want to fix this.> Why not adding FC_LANG_OBJECT anyway to the pattern for FcMatchPattern > as well and ensure it in fontconfig to make all happy?That doesn''t fit in how fontconfig works. Where would that happen? In FcConfigSubstituter()? That doesn''t sound like a good idea to me. Here''s one way I can think of fixing this: - Expand env vars in the configuration (so you can use $LANG in your configuration file), - In the default configuration, very early, add $LANG to "lang" if there is no "lang" set. The problem with this is that $LANG needs a slight conversion (replacing _ with -) before it can be used for FC_LANG. Not sure how to fix that. While fixing this I also want to fix this bug: Add a FC_LOCALE_LANG element https://bugs.freedesktop.org/show_bug.cgi?id=17311 """ This would be quite similar to FC_LANG, except that it holds the default language of the locale, not the language we are looking for fonts for. The idea is that an application (Pango) looking for a font to render English always passes en as lang. However, in CJK locales, it may be desirable to select the same font for Latin as well as CJK. With the proposed element, a conf file can check whether FC_LOCALE_LANG is CJK and in that case, add the CJK font as the single preferred font. All this without affecting the case of not running under a CJK locale. """ That also can be fixed similarly. behdad
Akira TAGOH
2009-Nov-25 07:00 UTC
[Fontconfig] Proposal to always add FC_LANG_OBJECT to the pattern
On Mon, Nov 23, 2009 at 9:33 AM, Behdad Esfahbod <behdad at behdad.org> wrote:> That doesn''t fit in how fontconfig works. ?Where would that happen? ?In > FcConfigSubstituter()? ?That doesn''t sound like a good idea to me.I see.> Here''s one way I can think of fixing this: > > ?- Expand env vars in the configuration (so you can use $LANG in your > configuration file), > > ?- In the default configuration, very early, add $LANG to "lang" if there is > no "lang" set.That sounds promising.> The problem with this is that $LANG needs a slight conversion (replacing _ > with -) before it can be used for FC_LANG. ?Not sure how to fix that.Can''t it deal with _ and - similarly in fontconfig, but not replacing it? is it too much cost than the outcome? Otherwise I guess you could replace _ with - when it''s set something to the "lang" regardless of the source of the env vars?> While fixing this I also want to fix this bug: > > Add a FC_LOCALE_LANG element > https://bugs.freedesktop.org/show_bug.cgi?id=17311 > > """ > This would be quite similar to FC_LANG, except that it holds the default > language of the locale, not the language we are looking for fonts for. > > The idea is that an application (Pango) looking for a font to render English > always passes en as lang. ?However, in CJK locales, it may be desirable to > select the same font for Latin as well as CJK. ?With the proposed element, a > conf file can check whether FC_LOCALE_LANG is CJK and in that case, add the > CJK font as the single preferred font. ?All this without affecting the case > of not running under a CJK locale. > """ > > That also can be fixed similarly.Fantastic. I''d love to see that :) -- Akira TAGOH
Behdad Esfahbod
2009-Nov-25 23:30 UTC
[Fontconfig] Proposal to always add FC_LANG_OBJECT to the pattern
On 11/25/2009 02:00 AM, Akira TAGOH wrote:> >> The problem with this is that $LANG needs a slight conversion (replacing _ >> with -) before it can be used for FC_LANG. Not sure how to fix that. > > Can''t it deal with _ and - similarly in fontconfig, but not replacing > it? is it too much cost than the outcome? > Otherwise I guess you could replace _ with - when it''s set something > to the "lang" regardless of the source of the env vars?The problem is the XML parser stuff and much of the rest of fontconfig doesn''t case which element it is you are dealing with. They work with types: string, integer, double, .... I''ll think about it more. behdad>> While fixing this I also want to fix this bug: >> >> Add a FC_LOCALE_LANG element >> https://bugs.freedesktop.org/show_bug.cgi?id=17311 >> >> """ >> This would be quite similar to FC_LANG, except that it holds the default >> language of the locale, not the language we are looking for fonts for. >> >> The idea is that an application (Pango) looking for a font to render English >> always passes en as lang. However, in CJK locales, it may be desirable to >> select the same font for Latin as well as CJK. With the proposed element, a >> conf file can check whether FC_LOCALE_LANG is CJK and in that case, add the >> CJK font as the single preferred font. All this without affecting the case >> of not running under a CJK locale. >> """ >> >> That also can be fixed similarly. > > Fantastic. I''d love to see that :) >