Indeed fontconfig doesn't know about a separate mr-in.  Should it?
It just has a orth file for mr.

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.

I have absolutely no clue what the bug being discussed is.  Can someone summarize it in two lines?  No speculation please.

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?

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?

Can someone summarize the issue in two lines?

Perhaps the summary can be updated to:
"FcGetDefaultLang() returns unknown language name"?

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.

(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,

(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,
> 

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?

> 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.

Ok, I think I now understand.   And in fact I think I know the fix too.
Lemme code.

Should be fixed in fontconfig master.  Please test.  If you can verify the fix, I'll make a release.  Thanks.

(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"

(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"
> 

Ok then here is 2 line reply
1) Thanks for the fix that does something.
2) can you make a release?

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...