Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1946871 - fc-match ":postscriptname=LiberationSans" returns LiberationSansNarrow
Summary: fc-match ":postscriptname=LiberationSans" returns LiberationSansNarrow
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-04-07 05:30 UTC by Benjamin Herrenschmidt
Modified: 2021-06-28 06:10 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Benjamin Herrenschmidt 2021-04-07 05:30:46 UTC
Description of problem:

So this started when I tried to fix the build of nasm-doc for nasm 2.15 :-)

(Which once fixed I was going to contribute back to Fedora of course).

This was disabled in Fedora due an alleged dependency on Adobe fonts. However, its supposed to be able to fallback to Liberation fonts using substitutions in doc/

This doesn't work for a couple of reasons. One is that it was missing the "Liberation" entries in a couple of places, which is easily fixed. The other issue is the cause of this bug report: It won't find LiberationSans (Regular).

IE. Entry @BText in there will fail to match "LiberationSans".

Now, digging through perl scripts, this boils down to the fact that when it tries ( to find the font using its postscript name, fc-match returns a different font postscript name, which the script explicitly checks against.

The exact command used is:

fc-match -f "%{file}\n%{postscriptname}\n" " : postscriptname=LiberationSans"

Which on Fedora 33 returns:


Instead of the expected:


Note: this works on Ubuntu 20.04

I've dug a little bit, and blew up my brain a few times trying to follow fontconfig matching logic, but it appears that using fc-match -s, the "Narrow" variant simply comes up first (and the expected one second).

It's easily "Fixed" by removing /etc/fonts/conf.d/59-liberation-narrow.conf

So it *seems* that marking the narrow variant as the "Preferred" variant for sans-serif causes it to get a better score than the exact match. Ubuntu seems to avoid this issue by not having that file (nor any liberation font related .conf files).

It could be possible to instead patch nasm to use a different font like DejaVu which doesn't have that problem, but that would possibly deviate too much from the original intended Arial. I've tried just making nasm use LiberationSansNarrow, but the resulting PDF is rather ... ugly and hard to read.

This feels like something not right with fontconfig matching. I wouldn't expect a match on postscriptname to find anything other than an exact match or at least it should prefer an exact match, shouldn't it ?

Comment 1 Benjamin Herrenschmidt 2021-04-30 03:41:52 UTC
Note: This bug is still present in f34

Comment 2 Akira TAGOH 2021-06-28 06:10:08 UTC
The matcher function for postscriptname needs to be fixed.

Note You need to log in before you can comment on or make changes to this bug.