Bug 17619 - fontconfig does not detect ko language flag for Arita korean fonts
Summary: fontconfig does not detect ko language flag for Arita korean fonts
Alias: None
Product: fontconfig
Classification: Unclassified
Component: orth (show other bugs)
Version: 2.6
Hardware: Other Linux (All)
: medium normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
Depends on:
Reported: 2008-09-16 19:22 UTC by Choe Hwanjin
Modified: 2018-08-20 21:47 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Choe Hwanjin 2008-09-16 19:22:42 UTC
I tried to use korean font  "Arita".
But fontconfig didn't detect it as korean font.
I tested it with fc-list.
I ran fc-list as below:

$ fc-list Arita lang

It didn't show ko flag.

I'm using debian unstable and fontconfig 2.6.0

You can download Arita font here:

This zip file has korean named fonts.
If you unzip this file on linux, you may not see the filename correctly.
Then try zip -F win_0131.zip first, this will fix the problem.
Comment 1 Choe Hwanjin 2008-09-29 19:26:43 UTC
I've tested them with FC_DEBUG env.
I've run fc-cache like below:

# . dir has Arita fonts
FC_DEBUG=256 fc-cache -f .

Then I got some messages and it showed such errors:

... snip ...
ko(1) { 3164 }
... snip ...

Is that mean the fonts don't have U+3164 and fontconfig doesn't consider it as korean font?

I looked up what it is, and I found that it is just a filler character and not so essential.
So how about to ignore the character and consider it as korean font?
Comment 2 Behdad Esfahbod 2008-12-28 01:18:51 UTC
U+3164 HANGUL FILLER is already ignored by fontconfig.
Comment 3 Choe Hwanjin 2008-12-28 19:33:51 UTC
(In reply to comment #2)
> U+3164 HANGUL FILLER is already ignored by fontconfig.

I didn't find a change for this issue in history.
Comment 4 Akira TAGOH 2010-12-05 22:18:48 UTC
U+3164 was set as blank in fonts.conf. can we close this perhaps?
Comment 5 Choe Hwanjin 2010-12-06 06:58:39 UTC
I've tested it again with fontconfig 2.8.0 on Debian.
But it still has this problem.

I've run these commands:
$ fc-cache -f $HOME/.fonts
$ fc-list Arita lang

There isn't ko language flag.
Comment 6 Behdad Esfahbod 2011-03-14 15:26:32 UTC
Humm.  Akira, do you agree that we should remove HANGUL FILLER from ko.orth?  That sounds right to me since the blanks element has a different purpose.
Comment 7 Akira TAGOH 2011-06-20 00:48:29 UTC
Speaking of the character sets spec thing, U+3164 (HANGUL FILTER) is required to support KS X 1001. I'm not sure how important to satisfy that for Korean people though. I don't even know how many Korean fonts that doesn't have U+3164 is available in the world though, fixing that in fonts may be right direction if they support KS X 1001.

Aside from that, not applying the blank for U+3164 looks weird if it's supposed to work regardless of the original purpose of the feature. we should have a separate bug for that perhaps.
Comment 8 Behdad Esfahbod 2011-06-20 08:11:36 UTC
So, what's should I do?
Comment 9 Akira TAGOH 2011-06-20 10:45:49 UTC
Choe, did you see anything else Korean fonts that doesn't have U+3164?
Korean fonts what I can see in Fedora (un-core and beakmuk) owns it at least so it should be fixed in the font side IMHO.

for blank feature, I'll test it again and file a bug if there are any problem.
Comment 10 Choe Hwanjin 2011-06-20 18:29:44 UTC
Of course, the font should be fixed.
Besides that, it is better to make the language detecting logic more practical.

The file 'ko.orth' already doesn't include the whole KS X 1001 characters.
Some low frequent characters are ignored, such as U+C3C0 and circled characters.

If we don't include the whole KS X 1001 set anyway, adding another rare character is not a problem.
Comment 11 Akira TAGOH 2011-09-04 19:55:23 UTC
Maybe we should check how many Korean fonts doesn't contain such characters. if correcting ko.orth would makes too much regression in Korean fonts and not a big deal to support the full KS X 1001, we could remove U+3164 from ko.orth perhaps.

That may be up to the policy in fontconfig that the orth files is supposed to be represented.
Comment 12 Akira TAGOH 2012-02-20 19:32:37 UTC
Thinking of this again. I'm starting to prepare new release, which contains a feature of modifying langset. you could try this out with fontconfig in the git repo perhaps and let me know if it works enough:

<match target="scan">
  <test name="family">
  <edit name="lang" mode="assign">

I don't want to break orth files for buggy fonts if possible unless that behavior is majority though, if you can give me some analysis if the major Korean fonts has that glyph in the fonts, that would be appreciated.
Comment 13 GitLab Migration User 2018-08-20 21:47:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/55.

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.