contained fontconfig setting files force to make it default font

I think it's a bug in ttf-nanum, too.

Jinkyu Yi,
  Thank you for taking the time to report this bug and submit a fix.
  I've taken the liberty to report the bug to debian and attach your proposed fix at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645354 . I suggest at this point that we see if the debian maintainer is willing to fix or comment on it, and then we go from there.

  Also, for future reference, I notice that you've created a bzr branch that fixes this bug, but you neglected to "propose for merging" into lp:ubuntu/ttf-nanum . Your debdiff is sufficient, but the merge proposal is an easier work flow for many developers.

  Thanks again for your work.

Scott Moser,

Thank you for report it to upstream.
But in my opinion, this can be not bug to debian.
Ubuntu use language-selector and it link fontconfig files - not in debian - to set default font.
The problem is these settings are duplicate to fontconfig files language-selector use.
It looks like this is bug to ubntu, but just workaround at debian.
How about modify ttf-nanum for only in ubuntu and wait for upstream fontconfig settings ready in debian?
I think there's no needed to patch ttf-nanum in debian for now.

After I create a bzr branch and commit, I can't find any link for "propose for merging" at lp:ubuntu/ttf-nanum page and that's why I only attach debdiff file.
I am wondering some packages need higher permission for proposing.

Jinkyu Yi,
  Sorry for confusing things with the debian bug. You're more knowledgeable than I in this area.

  Regarding the merge proposal, you would normally see the "Propose for Merging" at *your* branch, not the Ubuntu (target) branch. The reason you don't see it at https://code.launchpad.net/~jincreator/+junk/ttf-nanum is because of the "+junk". Instead of pushing to "+junk", do:
   bzr push lp:~jincreator/ubuntu/ttf-nanum/lp835304
That way launchpad knows that this branch is related to the ubuntu ttf-nanum branch and will allow you to propose it for merging.

Scott Moser,

Thank you for your advice!
Now I proposed for merging it.

p.s lp:~jincreator/ubuntu/ttf-nanum/lp835304 is not working, so I use lp:~jincreator/ubuntu/precise/ttf-nanum/lp835304.

I'm not sure why this is necessary. "make it default Korean font by itself" sounds perfectly right, not a bug. It would be a bug if merely installing this package would make it the default font for _other_ languages, such as Latin based ones. But that doesn't seem to be the cause? It is a lot better if packages configure themselves instead of having to use the language-selector fontconfig hacks.

Martin Pitt,

I think the best way to configure CJK without language-selector fontconfig hack is ttf-nanum is apply to fontconfig itselt, not using setting file in font package.
Korean sans-serif font "UnDotum" is good example.
Package "ttf-unfonts-core" provide it without any setting files.
But it works even without language-selector's Korean fontconfig hack(69-language-selector-ko-kr.conf) because one of fontconfig's default config file(65-nonlatin.conf) specifies to use "Undotum" as sans-serif font.
Also, "ttf-nanum"'s fontconfig file name is starting with "90-~" so it can overwrite fontconfig(+language-selector)'s settings.

In debian/90-ttf-nanum.conf line 49, there is comment...
 "TODO: it will be moved to fontconfig default configs -->"
It means this is just workaround, and for now I think it is problem to Ubuntu.

I still don't understand the problem, sorry.

> I think the best way to configure CJK without language-selector fontconfig hack is ttf-nanum is apply to fontconfig itselt

Why? It doesn't make a difference, and it even sounds worse because the config can't be right or at least perfect if the ttf-nanum package is not installed.

> But it works even without language-selector's Korean fontconfig hack(69-language-selector-ko-kr.conf)

I was actually hoping that we could get rid of language-selector's fontconfig hack with the proper fontconfig snippet in the -nanum package.

Marked merge proposal as work in progress and unsubscribed sponsors for now, waiting for answer to Martin's questions.

Please re-subscribe sponsors to the bug or mark your branch as need review once the questions have been answered.

Thanks!

Martin pitt,

The difference is, fonts-nanum/fonts-nanum-coding depends on "lang" option, but language-selector/fontconfig-config does not.
And, "lang" option is not working at Ubuntu(in my test).
But fontconfig-config doesn't have information about Nanum fonts.
As a result, Un fonts become default Korean fonts because it has higher priority than Nanum fonts.

So I suggest patch fontconfig-config to have information about fonts-nanum and make it high priority in Korean fonts list.
If fonts-nanum is missing, another fonts(i.e unfonts-core) will wokr beside it.
And maybe we can remove 69-language-selector-ko-kr.conf then.

Jinkyu Yi (jincreator) wrote on 2011-11-30:
> The difference is, fonts-nanum/fonts-nanum-coding depends on "lang"
> option, but language-selector/fontconfig-config does not.
> And, "lang" option is not working at Ubuntu(in my test).

What is the "lang" option in fontconfig? Is it possibly something that makes the LANG env. variable control the fontconfig settings, and can this have something to do with the fact that language-selector's fontconfig hack basically has been controlled by the LANGUAGE env. variable (i.e. not LANG)?

Gunnar,

> What is the "lang" option in fontconfig?

I mean, something like this...

    <test qual="any" name="lang" compare="contains">
      <string>ko</string>
    </test>

This code make NanumGothic, NanumMyeongjo, NanumGothicCoding is default font for Sans, Serif, Monospace only at Korean locale.
But it's not working at latest Ubuntu, in my test.
And according to LP: #884645, I think it is not working for Japanese locale, too.

> Is it possibly something that makes the LANG env. variable control the fontconfig settings, and can this have something to do with the fact that language-selector's fontconfig hack basically has been controlled by the LANGUAGE env. variable (i.e. not LANG)?

When use "lang", locale can affect to fontconfig settings.
But I'm not sure which env. variable affect to fontconfig exactly.
I'm testing with LANG(ex: export LANG=ko_KR.UTF-8 && fc-match sans).
But language-selector's fontconfig hack(file name starting with '69~lang...') doesn't need it because language-selector automatically link file to matching locale environment.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/04/2011 08:54 PM, Jinkyu Yi wrote:
> Gunnar,
>
>> What is the "lang" option in fontconfig?
>
> I mean, something like this...
>
> <test qual="any" name="lang" compare="contains">
> <string>ko</string>
> </test>
>
> This code make NanumGothic, NanumMyeongjo, NanumGothicCoding is default font for Sans, Serif, Monospace only at Korean locale.
> But it's not working at latest Ubuntu, in my test.
> And according to LP: #884645, I think it is not working for Japanese locale, too.

I remember it works on my Ubuntu 10.10, but I haven't tried on newer
Ubuntu releases.
However, the 'lang' tester is useful for other scenarios, namely when
you use a non-Korean locale and want to browse Korean websites, or text
snippets which have been tagged with lang=ko in their XML/HTML markup.
In that case firefox at least will choose the correct font automatically
if it hasn't been specified in the XML/HTML markup itself.
Also, at least on Ubuntu 10.10 that works.
Not sure if other applications also support that functionality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJO3DQWAAoJENiwmJtstTzslz0QALXwCD7thb168kTjLxNsbR6X
T/i/uBdU3UrYuU70zHvS/je6SrQnqwH7X5IgohccLPKEl5Q5TzneIVj6QX96+6rb
1Gnolie6YaO30QMxLymcjk+1VJwQTtAcE4brDFQ6WlC27cuaeAgeV3ukM9G6tBKB
3avp23qoU99VKh2nOCLaFO7Bz94N1irgZn630mSqAg4Uyj25ubEIbgZkm005xV6w
FOLWN54mUOD5RASTwpWAsqf5hc7xgRIXM12l9n/ijPmu0/LM0WEZaZMSQCTEp4pS
Vc1G6LsyUeHoGd773L1UV6cPmuCew+yDPNU8QtMMePzXNUlw8//M7jmLL87RFdsk
0qx9xod7RM8YqdFwKfbE9aWfZ7aFnuQwre6H81lDuwazJjaJgze5fcQf6E5ChYaE
ewB4a/bAAmHLjuO3oiZvp/LnQLN/aiy23iPys+KlwpDxO/w8/+n+dsVchlX20Mzt
DezXJwAoERqLVRe18bJcemK0hX4lOcZIbt5JCzO+RczG9gmPxW+5oLlllLBnXnJQ
Zl5OyZKd2znAk3oAlVHJ+3i0E/rBMsQaZ6v0LkUQUaBA2qUkvFYg8qaxgolXcXjF
tMBCecWw8DQMrqnwJ20gGdBEeT8Uc1+kU3XdIVuGU6SLd9QjIVfWsTYOi42xrqJx
N82xF0zCjqWEIR8A6Cak
=r0SI
-----END PGP SIGNATURE-----

I retest it with command "fc-match sans:lang=ko" and can't find any problem with "lang" tag.
It's all my big mistake, so please forget about it.
I really apologize for it.

For now, 69-language-selector-ko-kr.conf is dropped and fonts-nanum* doesn't have any problem.
So, I suggest to close this bug.

Thanks Jinkyu for testing again!