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?

U+3164 HANGUL FILLER is already ignored by fontconfig.

(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.
http://cgit.freedesktop.org/fontconfig/log/fc-lang/ko.orth

U+3164 was set as blank in fonts.conf. can we close this perhaps?

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
:lang=bg|fj|ho|ia|ie|io|kum|nr|om|os|ru|sel|so|ss|st|sw|ts|uz|xh|zu|kj|kwm|lg|ms|ng|rn|rw|sn|za

There isn't ko language flag.

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.

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.

So, what's should I do?

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.

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.

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.

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">
    <string>Arita</string>
  </test>
  <edit name="lang" mode="assign">
    <plus>
      <name>lang</name>
      <langset>
        <string>ko</string>
      </langset>
    </plus>
  </edit>
</match>

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.

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