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 - fc-match ":postscriptname=LiberationSans" returns LiberationSansNarrow
Summary: fc-match ":postscriptname=LiberationSans" returns LiberationSansNarrow
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: 35
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-07 05:30 UTC by Benjamin Herrenschmidt
Modified: 2022-03-18 19:12 UTC (History)
16 users (show)

Fixed In Version: fontconfig-2.13.94-5.fc35 fontconfig-2.13.94-5.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-05 18:30:47 UTC
Type: Bug
Embargoed:


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

Comment 3 Ben Cotton 2021-08-10 13:42:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 4 Akira TAGOH 2021-10-08 09:53:35 UTC
This has been fixed in upstream and will be included in the next release.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/2d17232a45c55cdb8d082a3bcf13d423928fcd5e

Comment 5 Benjamin Herrenschmidt 2021-10-14 05:31:28 UTC
Thanks !

Comment 6 Fedora Update System 2022-03-03 09:43:50 UTC
FEDORA-2022-b00e17ca83 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-b00e17ca83

Comment 7 Fedora Update System 2022-03-03 09:45:00 UTC
FEDORA-2022-1b9895f2c2 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b9895f2c2

Comment 8 Fedora Update System 2022-03-03 16:40:01 UTC
FEDORA-2022-b00e17ca83 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-b00e17ca83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b00e17ca83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2022-03-03 16:45:40 UTC
FEDORA-2022-1b9895f2c2 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-1b9895f2c2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b9895f2c2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2022-03-05 18:30:47 UTC
FEDORA-2022-b00e17ca83 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2022-03-18 19:12:21 UTC
FEDORA-2022-1b9895f2c2 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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