Fontconfig - May 2012 - any possible trouble by adding lang to the pattern by default

Hi,

I''m trying to address the case of the unexpected font selection for
non-English languages when running on English locale. particularly
likely to see with non-rich text, because the pattern doesn''t have the
appropriate lang object and what a font fontconfig will pick up really
depends on the order of the configuration files. though the order
issue can be worked around with testing the lang in the rule if the
pattern contains the proper lang object. which doesn''t help in that
case.

So I guess what we want to do here may be to set the certain language
to the pattern prior to do something in FcConfigSubstitute() if not
available or still may be good to add it as fallback though. the
candidate can be figured out from the locale and/or the environment
variables. (see the suggestion at
https://bugs.freedesktop.org/show_bug.cgi?id=32853)

Does anyone have any mind to do so? it could be added as the weak
binding to avoid putting more score on it but just to give a hint for
much better selection.

-- 
Akira TAGOH

Akira TAGOH <akira at tagoh.org> writes:
> Hi,
>
> I''m trying to address the case of the unexpected font selection
for
> non-English languages when running on English locale.
Are you trying to make fontconfig select an appropriate font without any
language hints at all, based solely on the codepoints within the text?

If so, then what I do myself is to configure a *set* of languages
instead of a single one in my fontconfig setup. This effectively creates
a multi-lingual "locale" for the purposes of font selection, guiding
fontconfig to prefer fonts for my favored languages.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120521/77c969d4/attachment.pgp>

On Tue, May 22, 2012 at 12:14 PM, Keith Packard <keithp at keithp.com>
wrote:
> Are you trying to make fontconfig select an appropriate font without any
> language hints at all, based solely on the codepoints within the text?
No, not really. that way takes too much cost to estimate. my
suggestion is simple. the complaint what I''ve ever seen about this was
it from the users who prefer to see only strings in English. i.e. set
$LANG to any English locale and $LC_CTYPE to the native one say.

So it could be used to guess from it or anything else what languages
they prefer/are expecting to use the font for when any codepoints
conflicts to other languages, and they might obtain the better font by
applying it to the pattern in fontconfig side.
> If so, then what I do myself is to configure a *set* of languages
> instead of a single one in my fontconfig setup. This effectively creates
> a multi-lingual "locale" for the purposes of font selection,
guiding
> fontconfig to prefer fonts for my favored languages.
Yes, the concept of the FC_LANG environment variable that I wrote as a
reference from bugzilla in the previous mail is the same with it. and
applying it to the pattern prior to do something with
FcConfigSubstitute() may be a bit aggressive here.

-- 
Akira TAGOH

For the reference of what I want to address:
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=add-lang-to-pattern

$ LANG=ja ./fc-match/fc-match
VL-PGothic-Regular.ttf: "VL P????" "regular"
$ LANG=zh_CN ./fc-match/fc-match
wqy-zenhei.ttc: "?????" "Regular"
$ LANG=en_US ./fc-match/fc-match
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match
...
FcConfigSubstitute Pattern has 1 elts (size 16)
        lang: "ja"(w) "zh-cn"(w)
...
VL-PGothic-Regular.ttf: "VL P????" "regular"
$ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match :lang=en
...
FcConfigSubstitute Pattern has 1 elts (size 16)
        lang: en(s) "ja"(w) "zh-cn"(w)
...
DejaVuSans.ttf: "DejaVu Sans" "Book"

On Tue, May 22, 2012 at 1:54 PM, Akira TAGOH <akira at tagoh.org>
wrote:
> On Tue, May 22, 2012 at 12:14 PM, Keith Packard <keithp at
keithp.com> wrote:
>> Are you trying to make fontconfig select an appropriate font without
any
>> language hints at all, based solely on the codepoints within the text?
>
> No, not really. that way takes too much cost to estimate. my
> suggestion is simple. the complaint what I''ve ever seen about this
was
> it from the users who prefer to see only strings in English. i.e. set
> $LANG to any English locale and $LC_CTYPE to the native one say.
>
> So it could be used to guess from it or anything else what languages
> they prefer/are expecting to use the font for when any codepoints
> conflicts to other languages, and they might obtain the better font by
> applying it to the pattern in fontconfig side.
>
>> If so, then what I do myself is to configure a *set* of languages
>> instead of a single one in my fontconfig setup. This effectively
creates
>> a multi-lingual "locale" for the purposes of font selection,
guiding
>> fontconfig to prefer fonts for my favored languages.
>
> Yes, the concept of the FC_LANG environment variable that I wrote as a
> reference from bugzilla in the previous mail is the same with it. and
> applying it to the pattern prior to do something with
> FcConfigSubstitute() may be a bit aggressive here.
>
> --
> Akira TAGOH


-- 
Akira TAGOH

Is there any more comments and concerns on this? if not, I''ll commit
the changes into master though.

On Tue, May 22, 2012 at 2:34 PM, Akira TAGOH <akira at tagoh.org>
wrote:
> For the reference of what I want to address:
> http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=add-lang-to-pattern
>
> $ LANG=ja ./fc-match/fc-match
> VL-PGothic-Regular.ttf: "VL P????" "regular"
> $ LANG=zh_CN ./fc-match/fc-match
> wqy-zenhei.ttc: "?????" "Regular"
> $ LANG=en_US ./fc-match/fc-match
> DejaVuSans.ttf: "DejaVu Sans" "Book"
> $ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match
> ...
> FcConfigSubstitute Pattern has 1 elts (size 16)
> ? ? ? ?lang: "ja"(w) "zh-cn"(w)
> ...
> VL-PGothic-Regular.ttf: "VL P????" "regular"
> $ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match :lang=en
> ...
> FcConfigSubstitute Pattern has 1 elts (size 16)
> ? ? ? ?lang: en(s) "ja"(w) "zh-cn"(w)
> ...
> DejaVuSans.ttf: "DejaVu Sans" "Book"
>
> On Tue, May 22, 2012 at 1:54 PM, Akira TAGOH <akira at tagoh.org>
wrote:
>> On Tue, May 22, 2012 at 12:14 PM, Keith Packard <keithp at
keithp.com> wrote:
>>> Are you trying to make fontconfig select an appropriate font
without any
>>> language hints at all, based solely on the codepoints within the
text?
>>
>> No, not really. that way takes too much cost to estimate. my
>> suggestion is simple. the complaint what I''ve ever seen about
this was
>> it from the users who prefer to see only strings in English. i.e. set
>> $LANG to any English locale and $LC_CTYPE to the native one say.
>>
>> So it could be used to guess from it or anything else what languages
>> they prefer/are expecting to use the font for when any codepoints
>> conflicts to other languages, and they might obtain the better font by
>> applying it to the pattern in fontconfig side.
>>
>>> If so, then what I do myself is to configure a *set* of languages
>>> instead of a single one in my fontconfig setup. This effectively
creates
>>> a multi-lingual "locale" for the purposes of font
selection, guiding
>>> fontconfig to prefer fonts for my favored languages.
>>
>> Yes, the concept of the FC_LANG environment variable that I wrote as a
>> reference from bugzilla in the previous mail is the same with it. and
>> applying it to the pattern prior to do something with
>> FcConfigSubstitute() may be a bit aggressive here.
>>
>> --
>> Akira TAGOH
>
>
>
> --
> Akira TAGOH


-- 
Akira TAGOH

Hi Akira,

On Mon, May 28, 2012 at 1:34 PM, Akira TAGOH <akira at tagoh.org>
wrote:
> Is there any more comments and concerns on this? if not, I''ll
commit
> the changes into master though.
Just want to say that something like what you have described will be
very useful to us. I will definitely give it a try once it has been
committed.

- Jiang

Akira TAGOH <akira at tagoh.org> writes:
> $ LANG=ja ./fc-match/fc-match
> VL-PGothic-Regular.ttf: "VL P????" "regular"
> $ LANG=zh_CN ./fc-match/fc-match
> wqy-zenhei.ttc: "??c?" "Regular"
> $ LANG=en_US ./fc-match/fc-match
> DejaVuSans.ttf: "DejaVu Sans" "Book"
> $ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match
> ...
> FcConfigSubstitute Pattern has 1 elts (size 16)
>         lang: "ja"(w) "zh-cn"(w)
Ah, ok. I do this in my .fonts.conf file today. Would an environment
variable really be more useful?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120529/2b8c1afc/attachment.pgp>

Hi,

On Tue, May 29, 2012 at 7:39 PM, Keith Packard <keithp at keithp.com>
wrote:
> Akira TAGOH <akira at tagoh.org> writes:
>
>> $ LANG=ja ./fc-match/fc-match
>> VL-PGothic-Regular.ttf: "VL P????" "regular"
>> $ LANG=zh_CN ./fc-match/fc-match
>> wqy-zenhei.ttc: "?? c?" "Regular"
>> $ LANG=en_US ./fc-match/fc-match
>> DejaVuSans.ttf: "DejaVu Sans" "Book"
>> $ FC_DEBUG=4 FC_LANG=ja:zh-cn LANG=en_US ./fc-match/fc-match
>> ...
>> FcConfigSubstitute Pattern has 1 elts (size 16)
>> ? ? ? ? lang: "ja"(w) "zh-cn"(w)
>
> Ah, ok. I do this in my .fonts.conf file today. Would an environment
> variable really be more useful?
How do you do that?

- Jiang

Jjgod Jiang <gzjjgod at gmail.com> writes:
> How do you do that?
Just edit the lang field in the pattern.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120529/0f83444b/attachment.pgp>

Hi,

On Tue, May 29, 2012 at 10:10 PM, Keith Packard <keithp at keithp.com>
wrote:
> Just edit the lang field in the pattern.
But how do you set lang field to be exactly the current value of your
LANG/FC_LANG variable? I think the point is to make it dynamic rather
than a static value written to a local file.

- Jiang

Jjgod Jiang wrote:
> Hi,
>
> On Tue, May 29, 2012 at 10:10 PM, Keith Packard<keithp at keithp.com>
wrote:
>> Just edit the lang field in the pattern.
>
> But how do you set lang field to be exactly the current value of your
> LANG/FC_LANG variable? I think the point is to make it dynamic rather
> than a static value written to a local file.
LANG (as opposed to FC_LANG) *is* already used to provide a default 
value dynamically, provided programs use FcDefaultSubstitute which I 
think they all do.

(BTW- Akira- is there a special reason why applying the new string set 
needed to be done in FcConfigSubstituteWithPat in addition to 
FcDefaultSubstitute?)

In case you need a different configuration for individual programs and 
cannot modify LANG for those, i. e. as would be possible through 
FC_LANG, I suspect you could create a file like:

<fontconfig>
   <include>/etc/fonts/fonts.conf</include>
   <match target="pattern">
     <test name="lang" qual="all"
compare="not_eq">
       <string>ja</string>
     </test>
     <edit name="lang" mode="prepend">
       <string>ja</string>
       <string>zh-cn</string>
     </edit>
   </match>
</fontconfig>

(i. e., assigning ''ja'',''zh-cn'' to
''lang'' in case no ''lang'' was in the
pattern (unlikely) or ''ja'' was not in it)

and use:

FONTCONFIG_FILE=your.config.file fc-match

because that will redirect fontconfig configuration for that single 
operation to your file. It would mean you need to have as many of those 
configuration files as you would have possible settings of your FC_LANG 
variable that are not matched by settings of the LANG variable (are they 
that many..??)

Raimund

On Wed, May 30, 2012 at 2:39 AM, Keith Packard <keithp at keithp.com>
wrote:
> Ah, ok. I do this in my .fonts.conf file today. Would an environment
> variable really be more useful?
Yes, particularly for the temporary solution. of course doing it in
fonts.conf would works for the permanent solution though.

Well, though I have no data to estimate how many people is running
their desktops on non-native locale, I guess it may be a few and
primarily this is to help that "few people". I also guess there may be
few people who may want to run apps on various locales without
changing the language settings on the desktop.

Having the environment variable itself for this purpose is harmless
IMHO. though adding an example how to do this in fonts.conf would be
nice too. yeah.
>
> --
> keith.packard at intel.com


-- 
Akira TAGOH

On Wed, May 30, 2012 at 7:02 AM, Raimund Steger <rs at mytum.de>
wrote:
> LANG (as opposed to FC_LANG) *is* already used to provide a default value
> dynamically, provided programs use FcDefaultSubstitute which I think they
> all do.
>
> (BTW- Akira- is there a special reason why applying the new string set
> needed to be done in FcConfigSubstituteWithPat in addition to
> FcDefaultSubstitute?)
Well, honestly I don''t still even have the reasonable answer for that
though, FcDefaultSubstitute() seems supposed to call after
FcConfigSubstitute().

https://bugs.freedesktop.org/show_bug.cgi?id=35482#c2

I guess because it may affects too many things on building the
pattern? Keith or Behdad?

Anyway, so I did it separately to avoid dirty pattern.
> In case you need a different configuration for individual programs and
> cannot modify LANG for those, i. e. as would be possible through FC_LANG, I
> suspect you could create a file like:
...
> FONTCONFIG_FILE=your.config.file fc-match
Hmm, yeah.. though if you are sure there are no config files that
checks the lang object before looking at 50-user.conf, no need to do
that nor "include" /etc/fonts/fonts.conf in your .fonts.conf.

-- 
Akira TAGOH

Hi,

On Wed, May 30, 2012 at 4:47 AM, Akira TAGOH <akira at tagoh.org>
wrote:
> On Wed, May 30, 2012 at 7:02 AM, Raimund Steger <rs at mytum.de>
wrote:
>> LANG (as opposed to FC_LANG) *is* already used to provide a default
value
>> dynamically, provided programs use FcDefaultSubstitute which I think
they
>> all do.
>>
>> (BTW- Akira- is there a special reason why applying the new string set
>> needed to be done in FcConfigSubstituteWithPat in addition to
>> FcDefaultSubstitute?)
>
> Well, honestly I don''t still even have the reasonable answer for
that
> though, FcDefaultSubstitute() seems supposed to call after
> FcConfigSubstitute().
>
> https://bugs.freedesktop.org/show_bug.cgi?id=35482#c2
>
> I guess because it may affects too many things on building the
> pattern? Keith or Behdad?
>
> Anyway, so I did it separately to avoid dirty pattern.
I''m struggling to understand how to I specify a preferred font list for
certain languages. Let''s say I want to make sure my preferred order for
"zh" font is like this:

   Hiragino Sans GB
   STHeiti
   Adobe Heiti Std
   Droid Sans Fallback
   Microsoft YaHei

But I do *not* want to specify a hardcoded lang in my FcPattern, I''d
rather have FcDefaultSubstitue() to add the default lang for me based
on current environment. If I specify the preferred zh font list like
this:

   <match target="pattern">
      <test
name="lang"><string>zh</string></test>
      <edit name="family" mode="append"
binding="same">
         <string>Hiragino Sans GB</string>?
      </edit>
   </match>

then this will happen in FcConfigSubstitute() which is (normally)
earlier than FcDefaultSubstitute(), then I don''t get the lang set
by FcDefaultSubstitute().

So what''s the preferred way to do that?

There are similar questions like
http://lists.freedesktop.org/archives/fontconfig/2004-April/000884.html

- Jiang

On Wed, May 30, 2012 at 8:26 PM, Jjgod Jiang <gzjjgod at gmail.com>
wrote:
> I''m struggling to understand how to I specify a preferred font
list for
> certain languages. Let''s say I want to make sure my preferred
order for
> "zh" font is like this:
>
> ? Hiragino Sans GB
> ? STHeiti
> ? Adobe Heiti Std
> ? Droid Sans Fallback
> ? Microsoft YaHei
>
> But I do *not* want to specify a hardcoded lang in my FcPattern,
I''d
> rather have FcDefaultSubstitue() to add the default lang for me based
> on current environment. If I specify the preferred zh font list like
> this:
>
> ? <match target="pattern">
> ? ? ?<test
name="lang"><string>zh</string></test>
> ? ? ?<edit name="family" mode="append"
binding="same">
> ? ? ? ? <string>Hiragino Sans GB</string>?
> ? ? ?</edit>
> ? </match>
>
> then this will happen in FcConfigSubstitute() which is (normally)
> earlier than FcDefaultSubstitute(), then I don''t get the lang set
> by FcDefaultSubstitute().
>
> So what''s the preferred way to do that?
Well, the rule itself roughly looks good. in theory, the lang should
be added to the pattern in applications according to their
requirements to render the text. however they don''t necessarily do
that because there are no way to figure out etc. this typically
happens when the application render non-rich text like the plain text.

The changes in the subject is to improve matching the font in even
that case. and my answer to the question in the previous mail was why
I''ve added the logic to add the lang even though the similar code was
available in FcDefaultSubstitute().

So for your question, what you need to do to get the preferred fonts
for the certain language is to set the language to FC_LANG as needed,
you should do particularly if you have complicated things on the
locale settings. otherwise it should just works. it may be easy to
understand once you try it :)

HTH,
-- 
Akira TAGOH

Jjgod Jiang wrote:
> Hi,
>
> On Wed, May 30, 2012 at 4:47 AM, Akira TAGOH<akira at tagoh.org> 
wrote:
>> On Wed, May 30, 2012 at 7:02 AM, Raimund Steger<rs at mytum.de> 
wrote:
>>> LANG (as opposed to FC_LANG) *is* already used to provide a default
value
>>> dynamically, provided programs use FcDefaultSubstitute which I
think they
>>> all do.
>>>
>>> (BTW- Akira- is there a special reason why applying the new string
set
>>> needed to be done in FcConfigSubstituteWithPat in addition to
>>> FcDefaultSubstitute?)
>>
>> Well, honestly I don''t still even have the reasonable answer
for that
>> though, FcDefaultSubstitute() seems supposed to call after
>> FcConfigSubstitute().
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=35482#c2
Ah OK. That makes things clearer.
>>
> [...]
> then this will happen in FcConfigSubstitute() which is (normally)
> earlier than FcDefaultSubstitute(), then I don''t get the lang set
> by FcDefaultSubstitute().
OK I think I get it now. You want the lang from the environment already 
at the time of config substitution, so that you can still react on it in 
the course of your normal ~/.fonts.conf, and preferably inferred from 
your normal locale settings without having to set any program-specific 
separate configuration files etc.?

Well in that case Akira''s fix seems quite useful.

I think that changing the recommended order of the API calls otherwise 
isn''t a good idea, too, because the user should be the first instance 
that has the opportunity to specify defaults for missing properties, 
except maybe on such highly content-specific/dynamic properties as
''lang''.

Raimund

Jjgod Jiang <gzjjgod at gmail.com> writes:
> But how do you set lang field to be exactly the current value of your
> LANG/FC_LANG variable? I think the point is to make it dynamic rather
> than a static value written to a local file.
I guess I''m not sure why this needs to be per-process; I generally like
my whole environment to share the same configuration.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120530/ef0e1a42/attachment.pgp>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

it meens that localisation of help messages will be correlated to font
selection?

i wonder what side effects will be...

may be I would prefer using a dedicated environment variable.

- -- 
	Pierre

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPxlRyMQ2/jYUwmmwRAhLaAJ9N+o7Sy6k4PElgRTb8YHFUVLg/3ACghEPp
xPn3Bd6djHF+uUMUZzkKZao=Rn/Q
-----END PGP SIGNATURE-----

Pierre Hanser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> it meens that localisation of help messages will be correlated to font
> selection?
Only if you want it to (by using LANG). This is no behavior exclusive to 
fontconfig.

(Normally that would make sense too, because if you want localized help 
messages, you would need fonts with the proper character sets.)

Otherwise use either LC_MESSAGES to just localize the messages, or 
LC_CTYPE to just localize font selection, this should even work with 
fontconfig-2.9.0 (and earlier) FcDefaultSubstitute-based mechanism.

Raimund

On Wed, May 30, 2012 at 10:00 PM, Raimund Steger <rs at mytum.de>
wrote:
> OK I think I get it now. You want the lang from the environment already at
> the time of config substitution, so that you can still react on it in the
> course of your normal ~/.fonts.conf, and preferably inferred from your
> normal locale settings without having to set any program-specific separate
> configuration files etc.?
Exactly.
>
> Well in that case Akira''s fix seems quite useful.
>
> I think that changing the recommended order of the API calls otherwise
isn''t
> a good idea, too, because the user should be the first instance that has
the
> opportunity to specify defaults for missing properties, except maybe on
such
> highly content-specific/dynamic properties as ''lang''.
Right.

FWIW we should get rid of the code to add the lang in
FcDefaultSubstitute() because it won''t takes any effects any more.

-- 
Akira TAGOH

On Thu, May 31, 2012 at 1:39 AM, Keith Packard <keithp at keithp.com>
wrote:
> I guess I''m not sure why this needs to be per-process; I generally
like
> my whole environment to share the same configuration.
Because the process is allowed to run on various locales. I know
running processes on various locales on the desktop is rare case. but
this fix itself is to help that rare case. otherwise no one needs to
set even FC_LANG nor .fonts.conf. it should just works.

aside from that, as Raimund pointed out, even though it depends on
their configurations installed on the system, one may needs to include
the line to read the system''s fonts.conf and override the default
configuration, particularly one isn''t sure if they have the
language-specific rules prior to 50-user.conf, and want to expect to
work perfectly.

I don''t think relying on the environment variables is the best
solution, rather think it''s the old fashion. it may prevents to change
the configuration on the fly too. though it''s easy to try ;)

Given that we want to do it in fonts.conf, we may need a hook to apply
it as the top priority.
>
> --
> keith.packard at intel.com


-- 
Akira TAGOH

On Tue, May 22, 2012 at 11:50 AM, Akira TAGOH <akira at tagoh.org>
wrote:
> Does anyone have any mind to do so? it could be added as the weak
> binding to avoid putting more score on it but just to give a hint for
> much better selection.
just realized that there may be the side-effect after this change. if
any applications expects to see English fonts without any lang objects
in the pattern, it may possibly breaks this expectation if one runs it
on non-English locale.

-- 
Akira TAGOH

On Fri, Jun 1, 2012 at 3:14 AM, Akira TAGOH <akira at tagoh.org>
wrote:
> just realized that there may be the side-effect after this change. if
> any applications expects to see English fonts without any lang objects
> in the pattern, it may possibly breaks this expectation if one runs it
> on non-English locale.
But it won''t be too hard to fix either, right? The people who set a
list
for preferred Chinese fonts for instance can always prepend that list
with a English font.

- Jiang

On Fri, Jun 1, 2012 at 6:28 PM, Jjgod Jiang <gzjjgod at gmail.com>
wrote:
> On Fri, Jun 1, 2012 at 3:14 AM, Akira TAGOH <akira at tagoh.org>
wrote:
>> just realized that there may be the side-effect after this change. if
>> any applications expects to see English fonts without any lang objects
>> in the pattern, it may possibly breaks this expectation if one runs it
>> on non-English locale.
>
> But it won''t be too hard to fix either, right? The people who set
a list
> for preferred Chinese fonts for instance can always prepend that list
> with a English font.
Sure. well, given that we go forward with it, I think there are
nothing we can do in fontconfig on this issue, because it''s the result
that the application tried to pick a font up with the unreliable way.

So if there are any rendering libraries and applications that behaves
so, I suppose we can help to fix it in apps and may be a good idea to
do it earlier. dunno how many apps behaves wrongly.

So any volunteers to test it on various apps are welcome.

Thanks,
>
> - Jiang


-- 
Akira TAGOH

On Fri, June 1, 2012 12:16, Akira TAGOH wrote:
> On Fri, Jun 1, 2012 at 6:28 PM, Jjgod Jiang <gzjjgod at gmail.com>
wrote:
>> On Fri, Jun 1, 2012 at 3:14 AM, Akira TAGOH <akira at tagoh.org>
wrote:
>>> just realized that there may be the side-effect after this change.
if
>>> any applications expects to see English fonts without any lang
objects
>>> in the pattern, it may possibly breaks this expectation if one runs
it
>>> on non-English locale.
>>
>> But it won''t be too hard to fix either, right? The people who
set a list
>> for preferred Chinese fonts for instance can always prepend that list
>> with a English font.
>
> Sure. well, given that we go forward with it, I think there are
> nothing we can do in fontconfig on this issue, because it''s the
result
> that the application tried to pick a font up with the unreliable way.
But that would only affect applications that don''t use
FcDefaultSubstitute, right? Because FcDefaultSubstitute added the lang
from the environment anyway.

Raimund




-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Fri, Jun 1, 2012 at 8:36 PM, Raimund Steger <rs at mytum.de>
wrote:
> But that would only affect applications that don''t use
> FcDefaultSubstitute, right? Because FcDefaultSubstitute added the lang
> from the environment anyway.
No. but how it affects depends on the rules you have. you might see
the different behavior when you have any language specific matching
rule on the system. because, previously such rules were not applied
due to no lang object in the pattern though, it''s applied after this
change so that it ensure the lang object is always available in the
pattern.

Though of course it may gives you different result as well
with/without FcDefaultSubstitute() but whether the pattern built by
FcConfigSubstitute() contains additional family names etc affects
scoring to find the best font out.

-- 
Akira TAGOH

> [...]
> just realized that there may be the side-effect after this change. if
> any applications expects to see English fonts without any lang objects
> in the pattern,
> [...]
> Though of course it may gives you different result as well
> with/without FcDefaultSubstitute() but whether the pattern built by
> FcConfigSubstitute() contains additional family names etc affects
> scoring to find the best font out.
Yes I understand that such applications will end up with different
patterns and different font selection after the change;
but what I meant to say was, even before they couldn''t be sure they
would
always get an English font if they leave out ''lang''.

Raimund

-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Fri, Jun 1, 2012 at 10:51 PM, Raimund Steger <rs at mytum.de>
wrote:
> Yes I understand that such applications will end up with different
> patterns and different font selection after the change;
> but what I meant to say was, even before they couldn''t be sure
they would
> always get an English font if they leave out ''lang''.
Right. that just happened to work. that would be a good idea if we can
share it and help to fix or even notice it''s not our bug ;)

-- 
Akira TAGOH

Le Ven 1 juin 2012 11:28, Jjgod Jiang a ?crit :
> The people who set a list
> [?] can always
Here be dragons

-- 
Nicolas Mailhot