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 ?