Bug 23419 - "contains" expression seems not working on the fontconfig rule
Summary: "contains" expression seems not working on the fontconfig rule
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.7
Hardware: Other All
: medium normal
Assignee: Keith Packard
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 23359
  Show dependency treegraph
 
Reported: 2009-08-19 18:55 UTC by Akira TAGOH
Modified: 2009-09-02 01:39 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
sample fontconfig rule for Lohit Marathi (1.17 KB, text/plain)
2009-08-19 18:55 UTC, Akira TAGOH
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Akira TAGOH 2009-08-19 18:55:42 UTC
Created attachment 28804 [details]
sample fontconfig rule for Lohit Marathi

I see this issue on fontconfig-2.7.1 on Fedora with Lohit Indic fonts at least. Even if the pattern contains strings that the rule specifies with "contains" expression, it doesn't match. this behaviour affects all of applications that uses FcDefaultSubstitute() and no explicit language pattern is given because language pattern will be set like mr-in from current locale mr_IN.UTF-8 say.

Steps to reproduce:
1. Download Lohit fonts from https://fedorahosted.org/lohit/ and install lohit_hi.ttf and lohit_mr.ttf particularly.
2. put the attached rule into /etc/fonts/conf.d
3. run fc-match "sans-serif:lang=mr"
4. run fc-match "sans-serif:lang=mr-in"

Actual results:
3 will be: lohit_mr.ttf: "Lohit Marathi" "Regular"
4 will be: lohit_hi.ttf: "Lohit Hindi" "Regular"

Expected results:
both results of 3 and 4 should be: lohit_mr.ttf: "Lohit Marathi" "Regular"

Additional info:
From a full debugging log with FC_DEBUG:
FcConfigSubstitute test pattern any lang Contains "mr"
FcLangSet mr-in contains mr
        Missing bitmap ku-am
No match

I'm not quite sure why fontconfig refers ku-am map here but apparently it looks like fontconfig doesn't know what mr-in is.
Comment 1 Behdad Esfahbod 2009-08-19 20:08:52 UTC
Indeed fontconfig doesn't know about a separate mr-in.  Should it?
It just has a orth file for mr.
Comment 2 Akira TAGOH 2009-08-19 23:27:02 UTC
IMHO it should or implement a fallback pattern if the guessed language pattern from locale is unknown. the real problem here may be FcDefaultSubstitute() - correctly FcGetDefaultLang() sets it from current locale without any validation.
Comment 3 Behdad Esfahbod 2009-08-20 08:34:46 UTC
I have absolutely no clue what the bug being discussed is.  Can someone summarize it in two lines?  No speculation please.
Comment 4 Akira TAGOH 2009-08-20 19:15:37 UTC
I'm not talking about the unrelated things at all though.

Sure. fontconfig doesn't know mr-in. cool. but given that's correct, the behaviour of FcGetDefaultLang() makes no sense then. is there are any way of specifying "mr" to the language pattern from applications but not from the code?

FWIW What's the case where "contains" expression is useful?
Comment 5 Akira TAGOH 2009-08-20 22:16:53 UTC
I may be misunderstanding the behaviour of the expressions here since someone suggested it's better using ja-jp instead of ja say. but I think fontconfig doesn't know ja-jp too.

If the expressions affects to the glyph coverage in the language but not whether the language name _contains_ the given value, that doesn't still makes sense to me that FcGetDefaultLang() returns the unknown language name in fontconfig and set it to the pattern, doesn't it?

Does it make clearer to explain the issue?
Comment 6 Behdad Esfahbod 2009-08-21 07:10:20 UTC
Can someone summarize the issue in two lines?
Comment 7 Jens Petersen 2009-08-23 23:43:09 UTC
Perhaps the summary can be updated to:
"FcGetDefaultLang() returns unknown language name"?
Comment 8 Behdad Esfahbod 2009-08-24 08:31:25 UTC
This is becoming ridiculous.  Can someone explain what's wrong?

(In reply to comment #7)
> Perhaps the summary can be updated to:
> "FcGetDefaultLang() returns unknown language name"?

FcGetDefaultLang() returns whatever you set in LANG.  Whether fontconfig has an orth file for that language or not is irrelevant.
Comment 9 Akira TAGOH 2009-08-24 19:36:22 UTC
(In reply to comment #8)
> FcGetDefaultLang() returns whatever you set in LANG.  Whether fontconfig has an
> orth file for that language or not is irrelevant.

Are you saying "mr-in" that FcGetDefaultLang() returns whatever I set in LANG is relevant to ku-am and it's the expected behaviour?

fontconfig doesn't know "mr-in" right. but it's the default behaviour of fontconfig against FcGetDefaultLang() with LANG=mr_IN.UTF-8 though.

Please correct me if I'm wrong or missing something.

Thanks,
Comment 10 Behdad Esfahbod 2009-08-25 11:16:58 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > FcGetDefaultLang() returns whatever you set in LANG.  Whether fontconfig has an
> > orth file for that language or not is irrelevant.
> 
> Are you saying "mr-in" that FcGetDefaultLang() returns whatever I set in LANG
> is relevant to ku-am and it's the expected behaviour?
> 
> fontconfig doesn't know "mr-in" right. but it's the default behaviour of
> fontconfig against FcGetDefaultLang() with LANG=mr_IN.UTF-8 though.
> 
> Please correct me if I'm wrong or missing something.

See, that's why I'm asking someone to explain the bug in simple terms to me.  You keep saying FcGetDefaultLang() is doing wrong.  Ok, let me spend 20 minutes deciphering the comments to see what the bug is....


> Thanks,
> 

Comment 11 Behdad Esfahbod 2009-08-25 11:24:55 UTC
Ok, I read all the comments again.  Makes no sense.

(In reply to comment #9)
> (In reply to comment #8)
> > FcGetDefaultLang() returns whatever you set in LANG.  Whether fontconfig has an
> > orth file for that language or not is irrelevant.
> 
> Are you saying "mr-in" that FcGetDefaultLang() returns whatever I set in LANG
> is relevant to ku-am and it's the expected behaviour?

Where does ku-am come from?  What is it you are seeing that you think is wrong?
Comment 12 Jens Petersen 2009-08-25 17:11:12 UTC
> Where does ku-am come from?

We dunno: it appears in fc's debug output.  See the original report:

"""
FcConfigSubstitute test pattern any lang Contains "mr"
FcLangSet mr-in contains mr
        Missing bitmap ku-am
No match
"""

> What is it you are seeing that you think is wrong?

$ fc-match "sans-serif:lang=mr-in"
lohit_hi.ttf: "Lohit Hindi" "Regular"

It should be Marathi.
Comment 13 Behdad Esfahbod 2009-08-25 17:18:17 UTC
Ok, I think I now understand.   And in fact I think I know the fix too.
Lemme code.
Comment 14 Behdad Esfahbod 2009-08-25 17:44:45 UTC
Should be fixed in fontconfig master.  Please test.  If you can verify the fix, I'll make a release.  Thanks.
Comment 15 Parag 2009-08-26 03:41:53 UTC
(In reply to comment #14)
> Should be fixed in fontconfig master.  Please test.  If you can verify the fix,
> I'll make a release.  Thanks.
> 

I tested master code and here i got 2 line question
1) While using desktop in locale mr_IN, "fc-match" command output is not same to "fc-match :lang=mr" command output.
2) Is above behavior correct?

fc-match
=> lohit_hi.ttf: "Lohit Hindi" "Regular"

fc-match :lang=mr
=>lohit_mr.ttf: "Lohit Marathi" "Regular"
Comment 16 Behdad Esfahbod 2009-08-26 09:52:22 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Should be fixed in fontconfig master.  Please test.  If you can verify the fix,
> > I'll make a release.  Thanks.
> > 
> 
> I tested master code and here i got 2 line question
> 1) While using desktop in locale mr_IN, "fc-match" command output is not same
> to "fc-match :lang=mr" command output.
> 2) Is above behavior correct?

Donno.  I fixed the bug.  No idea what your config file is doing.

> fc-match
> => lohit_hi.ttf: "Lohit Hindi" "Regular"
> 
> fc-match :lang=mr
> =>lohit_mr.ttf: "Lohit Marathi" "Regular"
> 

Comment 17 Parag 2009-08-26 10:03:50 UTC
Ok then here is 2 line reply
1) Thanks for the fix that does something.
2) can you make a release?
Comment 18 Behdad Esfahbod 2009-08-26 10:47:42 UTC
I'll make a release soon, but helps if someone verifies that the bug is indeed fixed.  But then again, maybe I just verify myself that the fix is correct and make the release...


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.