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 bugzilla.redhat.com.

Bug 1946871

Summary: fc-match ":postscriptname=LiberationSans" returns LiberationSansNarrow
Product: [Fedora] Fedora Reporter: Benjamin Herrenschmidt <benh>
Component: fontconfigAssignee: Akira TAGOH <tagoh>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: ajax, caillon+fedoraproject, cfergeau, fonts-bugs, gnome-sig, i18n-bugs, mark, mclasen, petersen, pnemade, psatpute, rhughes, rstrode, sandmann, tagoh, vishalvijayraghavan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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/psfonts.ph.

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 (findfont.ph) 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:

/usr/share/fonts/liberation-narrow/LiberationSansNarrow.ttf
LiberationSansNarrow

Instead of the expected:

/usr/share/fonts/liberation-sans/LiberationSans-Regular.ttf
LiberationSans

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.