Bug 1902881 - Fallback font in fontconfig 2.13.93 is Montserrat, previously was DejaVu
Summary: Fallback font in fontconfig 2.13.93 is Montserrat, previously was DejaVu
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: rawhide
Hardware: All
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: 2020-11-30 22:16 UTC by Adam Williamson
Modified: 2020-12-14 18:28 UTC (History)
12 users (show)

Fixed In Version: fontconfig-2.13.93-3.fc34 fontconfig-2.13.93-3.eln107 fontconfig-2.13.93-3.eln108
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-04 02:21:32 UTC
Type: Bug


Attachments (Terms of Use)
debug fc-match with 2.13.92-12.fc33 (2.80 MB, text/plain)
2020-12-03 00:41 UTC, Adam Williamson
no flags Details
debug fc-match with 2.13.93-1.fc34 (2.16 MB, text/plain)
2020-12-03 00:42 UTC, Adam Williamson
no flags Details
fc-match -v sans-serif with 2.13.92-12.fc33 (5.65 KB, text/plain)
2020-12-03 00:44 UTC, Adam Williamson
no flags Details
fc-match -v sans-serif with 2.13.93-1.fc34 (5.66 KB, text/plain)
2020-12-03 00:45 UTC, Adam Williamson
no flags Details
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.92-12.fc33 (5.40 KB, text/plain)
2020-12-03 00:48 UTC, Adam Williamson
no flags Details
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.93-1.fc34 (5.36 KB, text/plain)
2020-12-03 00:50 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2020-11-30 22:16:00 UTC
I'm still trying to figure out exactly what's going on here, but with fontconfig-2.13.92-12.fc33 , if you do "fc-match ashjopasdjhao" - just any random non-existent string - you get "DejaVuSans.ttf: "DejaVu Sans" "Regular"". If you do the same on fontconfig-2.13.93-1.fc34, you get "Montserrat-Regular.otf: "Montserrat" "Regular"".

I *think* this is why KDE window titles look different with 2.13.93 vs. 2.13.92 - this is breaking some KDE tests in openQA. KDE window titles are set to use "Noto Sans", but that font is not actually installed by default. So I think they wind up just falling back.

There's another odd discrepancy I noted: on 2.13.92, "fc-match sans-serif" gives DejaVu Sans Regular, while on 2.13.93 it gives DejaVu Sans Book. I'm not sure whether that's related or what's causing it.

Comment 1 Nicolas Mailhot 2020-12-01 10:09:54 UTC
The second one is normal and a packaging fix (Regular is the default OpenType Face, Book was a Vera Postscript leftover, if we wanted to keep Book we’d have to change DejaVu Sans Italic to DejaVu Sans Book Italic, and so on)

Comment 2 Akira TAGOH 2020-12-01 10:32:25 UTC
I can't say anything off hand so far. basically how fontconfig choose a fallback font depends on scoring fonts installed on the system. could you please run again with FC_DEBUG=2?

We can see the score for both and see what made difference between them.

Comment 3 Adam Williamson 2020-12-01 18:22:55 UTC
Nicolas: maybe I'm misunderstanding, but your comment reads to me like it'd be normal if we went from "Book" to "Regular", but that's not what happened. We went from "Regular" to "Book". 2.13.92 - the *older* version - says "Regular"; 2.13.93 - the *newer* version - says "Book".

Akira: will do.

Comment 4 Akira TAGOH 2020-12-02 02:57:50 UTC
Hmm, that sounds strange to me. there are no Regular style in DejaVu Sans. where is it coming from? can you give me a log for fc-match -v sans-serif with 2.13.92 then? and maybe good to try fc-query /path/to/font/file where 'file' property in fc-match -v points to.

Comment 5 Nicolas Mailhot 2020-12-02 13:12:23 UTC
Unless someone backed out packaging changes, the DejaVu metadata says Book and a fontconfig rule changes it to Regular as it should have been in the first place.

Comment 6 Adam Williamson 2020-12-03 00:41:55 UTC
Created attachment 1735842 [details]
debug fc-match with 2.13.92-12.fc33

Comment 7 Adam Williamson 2020-12-03 00:42:54 UTC
Created attachment 1735843 [details]
debug fc-match with 2.13.93-1.fc34

Comment 8 Adam Williamson 2020-12-03 00:44:18 UTC
Created attachment 1735844 [details]
fc-match -v sans-serif with 2.13.92-12.fc33

Comment 9 Adam Williamson 2020-12-03 00:45:17 UTC
Created attachment 1735845 [details]
fc-match -v sans-serif with 2.13.93-1.fc34

Comment 10 Adam Williamson 2020-12-03 00:48:52 UTC
Created attachment 1735847 [details]
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.92-12.fc33

Comment 11 Adam Williamson 2020-12-03 00:50:24 UTC
Created attachment 1735848 [details]
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.93-1.fc34

Comment 12 Adam Williamson 2020-12-03 00:51:19 UTC
BTW, doing this made me see that the difference affects Firefox - I'm running Firefox in the two VMs side by side, and it's definitely using different fonts in each for the non-monospace text in Bugzilla.

Comment 13 Adam Williamson 2020-12-03 00:53:20 UTC
Oh, and AFAICS none of the relevant font packages changed between the affected composes. Only fontconfig itself did.

Comment 14 Akira TAGOH 2020-12-03 03:33:20 UTC
Okay, I see.  This looks like a side-effect for the change how to construct fullname property in a fontconfig cache. fullname property is being added after all scan matching patterns evaluated. this is to omit Regular in fullname and to allow changing style in config and reflect it to fullname as well.

dejavu-sans-fonts has /etc/fonts/conf.d/57-dejavu-sans-fonts.conf. this is one actually adding Regular style to DejaVu Sans Book. and replying on fullname property to do it. in 2.13.92-12, this config worked because fullname was "DejaVu Sans". but in 2.13.93-1, it doesn't because no "fullname" property available yet at this stage.

The default style is Regular and fontconfig gives higher score to it more than Book. thus, Montserrat instead of DejaVu.



Possible idea to address this:

1. Add tentative fullname property and rewrite it on-demand during evaluating scan matching patterns.
   This may be ideal behavior. but heavily affects performance. I don't want to take this.

2. Add fullname property as in the past, but if one wants to update style, they have to update fullname at your own risk.

3. Use other properties to check the target in 57-dejavu-sans-fonts.conf

4. any other ideas?

Nicolas, this was done according to your request. I need your feedback on it again.

Comment 15 Nicolas Mailhot 2020-12-03 09:10:18 UTC
Well that just shows the danger of not addressing problems in the fontconfig core, expecting users to deploy more and more elaborate fixup rules to keep things working. In the end the fixups take a life of their own.

2. is clearly not acceptable, that’s just upping on the breakage.

A clean 3. is https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/200

Let me state once again than the more verbose and low level the syntax fontconfig imposes on its users, the more likely such issues are to creep in. It’s not a matter of writing a config generator. A good syntax lets users express basic functional intent, and nothing more that can have side effects for years.

I will revisit the dejavu rules to see if fullname matching can be removed. In theory that should be possible, to many apps do not read fullname at all for it to be mandatory. However IIRC it could not be done in the past due to various bugs in the way fontconfig handled variable instance names.

Also, it will probably be stuck like the rest of the new font macros. No one wanted to be involved in their merging when I had time to work on the subject and fix bugs, and right now IRL issues mean I can’t look at it properly right now.

Comment 16 Akira TAGOH 2020-12-03 11:36:32 UTC
For the short term, postscriptname property may works as an alternative in this case. but, so many fonts packages uses fullname property.

for i in $(for i in $(grep fullname /etc/fonts/conf.d/* | cut -d: 
-f1 | sort | uniq); do rpm -qf $i; done | sort | uniq); do rpm -qi $i; done | grep "Source RPM" | cut -d: -f 2 | sort |
 uniq
 adf-accanthis-fonts-1.8-20.fc33.src.rpm
 adf-tribun-fonts-1.17-5.fc33.src.rpm
 bitstream-vera-fonts-1.10-41.fc33.src.rpm
 catharsis-cormorant-fonts-3.602-4.20200316git83d1fa9.fc33.src.rpm
 dejavu-fonts-2.37-15.fc34.src.rpm
 ecolier-court-fonts-20070702-33.fc33.src.rpm
 gfs-ambrosia-fonts-20080624-27.fc33.src.rpm
 gfs-artemisia-fonts-20070415-33.fc33.src.rpm
 gfs-baskerville-fonts-20070327-34.fc33.src.rpm
 gfs-bodoni-classic-fonts-20070415-33.fc33.src.rpm   
 gfs-bodoni-fonts-20070415-32.fc33.src.rpm
 gfs-complutum-fonts-20070413-34.fc33.src.rpm
 gfs-decker-fonts-20090618-24.fc33.src.rpm
 gfs-didot-classic-fonts-20080702-28.fc33.src.rpm
 gfs-didot-display-fonts-20160225-4.fc33.src.rpm
 gfs-didot-fonts-20070616-33.fc33.src.rpm
 gfs-eustace-fonts-20080303-27.fc33.src.rpm
 gfs-fleischman-fonts-20080303-27.fc33.src.rpm
 gfs-galatea-fonts-20191205-4.fc33.src.rpm
 gfs-garaldus-fonts-20080707-27.fc33.src.rpm
 gfs-gazis-fonts-20091008-21.fc33.src.rpm
 gfs-goschen-fonts-20100203-21.fc33.src.rpm
 gfs-ignacio-fonts-20090923-22.fc33.src.rpm
 gfs-jackson-fonts-20080303-26.fc33.src.rpm
 gfs-neohellenic-fonts-20090918-22.fc33.src.rpm
 gfs-neohellenic-math-fonts-20180227-4.fc33.src.rpm
 gfs-nicefore-fonts-20080303-27.fc33.src.rpm
 gfs-olga-fonts-20160509-5.fc33.src.rpm
 gfs-orpheus-classic-fonts-20161102-4.fc33.src.rpm
 gfs-orpheus-fonts-20161102-4.fc33.src.rpm
 gfs-orpheus-sans-fonts-20161102-4.fc33.src.rpm
 gfs-philostratos-fonts-20090902-22.fc33.src.rpm
 gfs-porson-fonts-20060908-32.fc33.src.rpm
 gfs-pyrsos-fonts-20090618-23.fc33.src.rpm
 gfs-solomos-fonts-20071114-32.fc33.src.rpm
 gfs-theokritos-fonts-20070415-36.fc33.src.rpm
 golang-x-image-0-0.21.20200807git972c09e.fc33.src.rpm
 google-droid-fonts-20200215-8.fc34.src.rpm
 google-rubik-fonts-2.100-3.20200314git2e360a2.fc33.src.rpm
 hanamin-fonts-20170904-10.fc33.src.rpm
 ht-alegreya-fonts-2.008-6.fc33.src.rpm
 ht-alegreya-sans-fonts-2.008-7.fc33.src.rpm
 ibm-plex-fonts-4.0.2-6.fc33.src.rpm
 impallari-dancing-script-fonts-2.000-8.20200226gitf7f54bc.fc33.src.rpm
 impallari-raleway-fonts-4.025-3.20200310git98add57.fc33.src.rpm
 intel-clear-sans-fonts-1.00-6.fc33.src.rpm
 jetbrains-mono-fonts-1.0.4-5.fc33.src.rpm
 kemie-bellota-fonts-4.1-3.fc33.src.rpm
 khmer-os-fonts-5.0-31.fc34.src.rpm
 madan-fonts-2.000-29.fc33.src.rpm
 ndiscover-exo-2-fonts-1.100-3.20200316git55728cf.fc33.src.rpm
 ossobuffo-jura-fonts-5.103-4.20200314git6e2614a.fc33.src.rpm
 production-type-spectral-fonts-2.003-3.20200314git748733e.fc33.src.rpm
 pt-sans-fonts-20141121-18.fc34.src.rpm
 senamirmir-washra-fonts-4.1-29.fc34.src.rpm
 sil-alkalami-fonts-1.200-6.fc33.src.rpm
 sil-dai-banna-fonts-2.200-5.fc33.src.rpm
 sil-harmattan-fonts-1.001-4.fc33.src.rpm
 sil-mondulkiri-extra-fonts-5.300-6.fc33.src.rpm
 sil-shimenkan-fonts-1.000-5.fc33.src.rpm
 sorkintype-merriweather-fonts-2.008-3.20200314gitfad21f9.fc33.src.rpm
 sorkintype-merriweather-sans-fonts-1.008-3.20200314gitf36d6e1.fc33.src.rpm
 stix-fonts-2.0.2-8.fc34.src.rpm
 symbian-m-yuppy-gb-fonts-1.00-5.fc33.src.rpm
 typesetit-great-vibes-fonts-1.101-4.20200316gita82e16d.fc33.src.rpm
 typetogether-literata-fonts-2.200-3.fc33.src.rpm
 uswds-public-sans-fonts-1.008-5.fc33.src.rpm
 vernnobile-muli-fonts-2.001-6.20200225git580b05e.fc33.src.rpm
 vernnobile-nunito-fonts-3.504-6.20200225git6d8a4e1.fc33.src.rpm
 vernnobile-oswald-fonts-4.101-8.20200225git5a5fff2.fc33.src.rpm
 wagesreiter-patrick-hand-fonts-20200215-5.fc33.src.rpm
 weiweihuanghuang-work-sans-fonts-2.07-9.20200226gitdcd044c.fc33.src.rpm
 yanone-kaffeesatz-fonts-2.001-6.20200221git1da4935.fc33.src.rpm


Hm, I can't remember why I didn't take this way but another option:

4. Provide fullname property at scan matching phase as in the past. after all scan matching patterns evaluated, rebuild fullname from family and style in the pattern. The difference to 1 is, 4 doesn't update fullname immediately when updating family and style. 
 This woudld provide proper fullname property at the end as well as keeping the backward compatibility to the existing config.

Option 4 sounds realistic to me. if that sounds okay, I'll work on it that way.

Comment 17 Akira TAGOH 2020-12-03 12:19:40 UTC
I have built testing package at copr: https://copr.fedorainfracloud.org/coprs/tagoh/fontconfig/

Comment 18 Nicolas Mailhot 2020-12-03 17:39:26 UTC
Seems that would work. As for why so many packages exhibit the behaviour, that’s what generating config at scale produces.

Comment 19 Fedora Update System 2020-12-04 02:21:32 UTC
FEDORA-2020-7e38cc44c3 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 20 Fedora Update System 2020-12-04 02:33:34 UTC
FEDORA-2020-a07d71a53b has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

Comment 21 Adam Williamson 2020-12-04 16:39:43 UTC
Yup, looks like that worked, the affected openQA tests are back to how they behaved before the bug appeared. thanks to both of you!

Comment 22 Fedora Update System 2020-12-14 18:28:44 UTC
FEDORA-2020-873d786bd3 has been pushed to the Fedora ELN 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.