Bug 105756 - Can't match font family name by their localized name
Summary: Can't match font family name by their localized name
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
: 107370 (view as bug list)
Depends on:
Reported: 2018-03-27 04:33 UTC by lilydjwg
Modified: 2018-07-25 09:09 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description lilydjwg 2018-03-27 04:33:50 UTC
With 2.12.6+5+g665584a-1:

>>> fc-list | grep wqy
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: 文泉驿等宽正黑,文泉驛等寬正黑,WenQuanYi Zen Hei Mono:style=Regular
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: 文泉驿点阵正黑,文泉驛點陣正黑,WenQuanYi Zen Hei Sharp:style=Regular
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: 文泉驿正黑,文泉驛正黑,WenQuanYi Zen Hei:style=Regular

With 2.13.0+10+g58f5285-1:

>>> fc-list | grep wqy
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: WenQuanYi Zen Hei Mono:style=Regular
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: WenQuanYi Zen Hei:style=Regular
/usr/share/fonts/wenquanyi/wqy-zenhei/wqy-zenhei.ttc: WenQuanYi Zen Hei Sharp,文泉驛點陣正黑:style=Regular

You can see that the Chinese name e.g. "文泉驿正黑" is gone and unusable: I can't use that name in configuration files; fc-match can't find it. There are other Chinese, Japanese, Korean, Hebrew, Russian etc names that are gone too.

I'm on Arch Linux.
Comment 1 Akira TAGOH 2018-03-27 08:46:07 UTC
this may just unexpectedly worked on 2.12.6 for you. I can reproduce this with even 2.12.6 here and no problem on 2.12.5. apparently 161c738 makes the behavior unstable. will investigate more.
Comment 2 Akira TAGOH 2018-03-27 09:28:04 UTC
Behdad, you said on the commit log:

commit 161c7385477b9520fc4c63e3f09789d217c5cd67
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Wed Sep 27 18:36:25 2017 -0400

    Use binary-search for finding name table entries
    VotoSerifGX has over 500 named instances, which means it also has over a thousand
    name table entries.  So we were looking for names for over 500 pattern, looking for
    some thirty different name-ids, and using linear search across the 1000 entries!
    Makes scanning VotoSerifGX three times faster.  The rest is probably the lang
    matching, which can also be shared across named-instances.  Upcoming.

Is it not yet completed? apparently this change picks up one entry for giving platform_id and name_id. thus other variant names which has different language_id in SFNT is missing in the cache.
I don't know how/what GX fonts has in SFNT table though.
Comment 3 Behdad Esfahbod 2018-03-31 15:26:04 UTC
Oh I see. Let me try to fix.
Comment 4 Behdad Esfahbod 2018-03-31 17:20:46 UTC
Should be fixed in master.  Please test. Thanks.

commit a8a6efa805fc03e790214e8a0bc55843a258d774 (HEAD -> master, origin/master)
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Sat Mar 31 19:19:36 2018 +0200

    Share name-mapping across instances
    Continuation of previous commit.
    Makes scanning Voto Serif GX fast again.

commit fa13f8835c2819e693c7250e0d6729e22f0509c2
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Sat Mar 31 18:36:20 2018 +0200

    Fix name scanning
    In 161c738 I switched from linear name scanning to binary searching.
    That, however, ignored the fact that there might be more than one
    name table entry for each pair we want to query.
    To fix that and retain bsearch, I now get all name entries first,
    sort them, and use for bsearching.
    This fixes https://bugs.freedesktop.org/show_bug.cgi?id=105756
    This makes scaning Voto Serif GX twice slower though, since we are
    creating and sorting the list for each instance. In the next commit,
    I'll share this list across different instances to fix this.
Comment 5 Akira TAGOH 2018-04-02 03:09:39 UTC
that works fine. thanks Behdad.
Comment 6 lilydjwg 2018-04-02 06:35:23 UTC
It works fine, thanks!
Comment 7 Akira TAGOH 2018-07-25 09:09:13 UTC
*** Bug 107370 has been marked as a duplicate of this bug. ***

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.