Fontconfig - Nov 2009 - 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

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

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

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 :)
>