|Summary:||Fallback font in fontconfig 2.13.93 is Montserrat, previously was DejaVu|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||fontconfig||Assignee:||Akira TAGOH <tagoh>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||ajax, caillon+fedoraproject, fonts-bugs, gnome-sig, i18n-bugs, mclasen, nicolas.mailhot, pnemade, rhughes, rstrode, sandmann, tagoh|
|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:||Story Points:||---|
|Last Closed:||2020-12-04 02:21:32 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Adam Williamson 2020-11-30 22:16:00 UTC
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.