Bug 1902881

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)

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.

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.

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.

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.

Created attachment 1735842 [details]
debug fc-match with 2.13.92-12.fc33

Created attachment 1735843 [details]
debug fc-match with 2.13.93-1.fc34

Created attachment 1735844 [details]
fc-match -v sans-serif with 2.13.92-12.fc33

Created attachment 1735845 [details]
fc-match -v sans-serif with 2.13.93-1.fc34

Created attachment 1735847 [details]
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.92-12.fc33

Created attachment 1735848 [details]
fc-query /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf on 2.13.93-1.fc34

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.

Oh, and AFAICS none of the relevant font packages changed between the affected composes. Only fontconfig itself did.

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.

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.

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.

I have built testing package at copr: https://copr.fedorainfracloud.org/coprs/tagoh/fontconfig/

Seems that would work. As for why so many packages exhibit the behaviour, that’s what generating config at scale produces.

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.

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.

Yup, looks like that worked, the affected openQA tests are back to how they behaved before the bug appeared. thanks to both of you!

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.