Created attachment 1678854 [details] Screenshot of qt creator Since upgrading from Fedora 31 to Fedora 32, rendering of bold fonts in Qt based applications has degraded and is now showing far too heavy. E.g. in the attached screenshot Qt Creator is showing the too-bold font in the "Text Editor" heading and "Builtin color schemes..." label. Version-Release number of selected component (if applicable): How reproducible: I've seen this on two separate installations I've upgraded from Fedora 31 to 32 Steps to Reproduce: 1. Upgrade to fedora 32 2. Launch any qt application which uses a bold font in the interface (e.g qt creator)
This might be also issue in QGnomePlatform or adwaita-qt, hovewer neither of them changed in F32. I already have two bugs reported for adwaita-qt in upstream so I will try to investigate what's going on.
This has something to do with the abattis-cantarell-fonts package. Downgrading to version 0.111-3.fc31 (as opposed to 0.201-2.fc32) solves the issue.
I can confirm that the issue is limited to the Cantarell font. I don't see the same problem with other fonts.
If it's a problem in the font itself, can you file an issue upstream at https://gitlab.gnome.org/GNOME/cantarell-fonts please?
Looks like a duplicate of https://gitlab.gnome.org/GNOME/cantarell-fonts/-/issues/41
Created attachment 1679807 [details] Screenshot of Qt Creator I think this may be a Qt bug triggered by something in the font. With fonts, you can never really be sure. Anyone here familiar with Qt's text rendering facilities to help track this down? Basically, Qt synthesizes a bold face when it doesn't have to (it's all in the font). Here's the thing: I'm on F31 with only the variable font installed and I cannot reproduce the bug.
I might be wrong, but my impression is that Qt uses the "extra bold" font instead of the "bold" one, and not that it mistakenly synthesizes a bold font...
The font looks synthesized to me though, possibly an emboldened Extra Bold. Also, if it took the Extra Bold, the font should have hinting, which the font in the original screenshot doesn't.
qt is probably confused by all the broken metadata in Cantarell $ fc-scan -f "%{family};%{style};%{fullname[0]};%{width};%{weight};%{slant};%{fontversion};%{file}\n" /usr/share/fonts/cantarell | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d -k7,7dr | uniq | column --separator ';' -t Cantarell Cantarell Regular 100 [0 205] 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Thin Cantarell Regular 100 0 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Light Cantarell Regular 100 50 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Regular Cantarell Regular 100 80 0 13173 /usr/share/fonts/cantarell/Cantarell-Regular.otf Cantarell Regular Cantarell Regular 100 80 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Bold Cantarell Bold 100 200 0 13173 /usr/share/fonts/cantarell/Cantarell-Bold.otf Cantarell Bold Cantarell Regular 100 200 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Extra Bold Cantarell Regular 100 205 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell,Cantarell Extra Bold Extra Bold,Regular Cantarell Extra Bold 100 205 0 13173 /usr/share/fonts/cantarell/Cantarell-ExtraBold.otf Cantarell,Cantarell Light Light,Regular Cantarell Light 100 50 0 13173 /usr/share/fonts/cantarell/Cantarell-Light.otf Cantarell,Cantarell Thin Thin,Regular Cantarell Thin 100 0 0 13173 /usr/share/fonts/cantarell/Cantarell-Thin.otf A nice font family would have just "Cantarell" in the first column, the actual face name in the second (not a list ending with Regular) and the third column equal to first <space> second (except for the Regular face, that should just have family as first name). Regular is very dangerous to sprinkle in font metadata, it means default in OpenType, some implementations will generate bold and italic from Regular if they do not manage to locate real Bold or Italic. Though, a lot of the breakage qt-side would be avoided if it used the first entry in fontconfig lists, fallbacking to others only when there is no first-level match. That being said Cantarell is far from the first font family to use broken constructs in its metadata, to workaround bugs in some font stack implementation (triggering bugs in other font stack implementations). Things would be so nice if everyone just stuck to what the OpenType spec recommends.
I don't understand your metadata criticism. The "Cantarell Extra Bold Regular" thing is a concatenation of name id 1 and 2 and the spec recommends that you pretend to be a RIBBI font in them. It makes stuff work in old crusty applications such as modern Word. > https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids (IDs 1 and 2) > [...] > While some platforms or applications do not have this constraint, many existing applications that use this pair of names assume that a Font Family name is shared by at most four fonts that form a font style-linking group: regular, italic (or oblique), bold, and bold italic (or bold oblique). To be compatible with the broadest range of platforms and applications, it is strongly recommended that fonts limit use of Font Family name in this manner. > [...] This is established practice and what ufo2ft, the "major player" next to Adobe's makeotf, does and what the spec recommends. You start from the true family and style name and if the style is within RIBBI, you use id 1 and 2, if not, you write the true values to 16 and 17 and emulate RIBBI-ness in 1 and 2. The style names for variable font instances are taken from the fvar and/or STAT table. fontconfig seems to only use the full name from the name table without taking variation data into consideration. The correct way to determine family and style for a static font is family_name = id16 or id1 style_name = id17 or id2 In pythonesque pseudo-code and ignoring the WWS stuff that I have never seen in practice. Fontconfig seems to do the wrong thing here by including the "Regular" when id17 says something else.
The OpenType spec states, when defining fullname (Name ID 4) https://docs.microsoft.com/en-us/typography/opentype/spec/name#nid4 > name ID 4 would typically be a combination of name IDs 16 and 17 You’re not supposed to use Name ID 1/2 in Name ID 4, but Name ID 16/17 (and probably Name ID 21/22 since those override 16/17 if present) And the spec continues with > without needing any additional qualifications regarding “Regular”. So, you’re not supposed to repeat “Regular” in upper naming layers. It can only exist in Name ID 2, 17 or 21 to specify the default family face. Also, due to the RBBI limitations of Name ID 1 & 2, the default face does not have the same meaning in Name ID 1/2 & 16/17 or 21/22. A face can be default (Regular) in the RBBI sense (name ID 2), without being Regular in Name ID 17 or 21. This is all clearer in the canonical example provided with the spec: https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp (does not include Name ID 21/22, those are later creations to help font makers fix existing non conformant name ID 16/17 without breaking legacy compat)
See also https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/185 https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/208 https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/214 https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/220 It would be nice if fontconfig fixed such trivial OpentType non-conformances by default. Right now it does not so providing clean font metadata to apps helps (even if fontconfig fixed all those, the font files would still be broken on non fontconfig platforms, though I care a lot less about those). Due to its non-Linux heritage QT attempts to manage things that should be better left to fontconfig. That makes QT apps more likely to trip on problematic font metadata.
Regarding ID 4, the spec uses wording like "would generally be omitted" and "would typically be a combination of name IDs 16 and 17", so "non-conformance" sounds like hyperbole to me. I don't know if fontconfig's "fullname" is supposed to return ID 4 or if it synthesizes that field from family and style name.
The OpenType spec is quite hard to read because its authors do not use IETF-style unambiguous MUST SHOULD etc but plain human text (sometimes, repeating the same point multiple times with various levels of emphasis). It badly needs refactoring by a professional standards writer, to remove the repetitions, and make requirements more explicit and forceful. Generally speaking, you should apply everything the spec recommends no matter how polite and un-assertive the wording is. Because anything authors think is a good idea *is* a good idea, and would not have been documented if it were not a hard requirement for software somewhere. Besides, anything stated in part of the spec is likely to be repeated or built upon in more forceful terms in other parts, in later revisions, or derived standards¹. ¹ CCS4 was written by people more familiar with standards; it generally repeats OpenType, with a lot of MUSTs sprinkled everywhere, because there’s only one way to make things work reliably, and the original vocabulary is dangerously watered down
I agree that a better written specification would be highly appreciated, but I think you're fighting a losing battle here. OpenType is 40 years of accumulated cruft and vendors and applications doing whatever they want. Our font engineers spend _significant_ amounts of time testing fonts before release in major applications _every single time_. Microsoft, the owner of the specification, is no paragon when it comes to interpreting their own spec in their own applications. As it stands, font metadata is no exact science but fudged in whatever way makes the fonts work as intended for the paying client. It's the reason the spec is so weakly worded. And that's just the way it is. Anyway, this is getting increasingly off-topic. I'd wait for a Qt person to look into this. If they find that the font is doing something off-beat, I can fix it.
All theoretical and spec-related discussions aside, here is the output of Nicolas' command on my system (with Cantarell 0.111 installed): $ fc-scan -f "%{family};%{style};%{fullname[0]};%{width};%{weight};%{slant};%{fontversion};%{file}\n" /usr/share/fonts/cantarell | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d -k7,7dr | uniq | column --separator ';' -t Cantarell Regular Cantarell Regular 100 80 0 7274 /usr/share/fonts/cantarell/Cantarell-Regular.otf Cantarell Bold Cantarell Bold 100 200 0 7274 /usr/share/fonts/cantarell/Cantarell-Bold.otf Cantarell,Cantarell Extra Bold Extra Bold,Regular Cantarell Extra Bold 100 205 0 7274 /usr/share/fonts/cantarell/Cantarell-ExtraBold.otf Cantarell,Cantarell Light Light,Regular Cantarell Light 100 50 0 7274 /usr/share/fonts/cantarell/Cantarell-Light.otf Cantarell,Cantarell Thin Thin,Regular Cantarell Thin 100 0 0 7274 /usr/share/fonts/cantarell/Cantarell-Thin.otf That's pretty much the same as on Nicolas' system, except that Cantarell-VF.otf is missing. To me it seems that the metadata is quite inconsistent between Cantarell-VF.otf and the other files. Shouldn't the output for Cantarell-VF.otf be as follows, at least for the sake of internal consistency: Cantarell Cantarell Regular 100 [0 205] 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell,Cantarell Thin Thin,Regular Cantarell Thin 100 0 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell,Cantarell Light Light,Regular Cantarell Light 100 50 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Regular Cantarell Regular 100 80 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Bold Cantarell Bold 100 200 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell,Cantarell Extra Bold Extra Bold,Regular Cantarell Extra Bold 100 205 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Instead of: Cantarell Cantarell Regular 100 [0 205] 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Thin Cantarell Regular 100 0 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Light Cantarell Regular 100 50 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Regular Cantarell Regular 100 80 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Bold Cantarell Regular 100 200 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Cantarell Extra Bold Cantarell Regular 100 205 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf Maybe it's worth a shot to generate a version of Cantarell-VF.otf with this metadata? I would do it myself, but I don't know how to compile Cantarell. Would be happy to try it out on my system, though...
Cantarell VF is the variable version of Cantarell, it does not use exactly the same metadata mechanisms as the non variable files (that’s another reason it is dangerous to rely on metadata mechanisms available in static faces but not their equivalent, variable instances, because the OpenType spec clearly envisions using variable instances as direct static replacements in the future). Anyway, a lot of things were broken in fontconfig’s handling of variable instances, a lot (but not all of them) have been fixed upstream, but the result is not available in Fedora yet (even on my Fedora 33 system). If you want to test variable handling you should ask Akira for a fontconfig package containing his latest variable fixes. Right now IIRC variable instance naming should be fixed upstream, but axis values are completely broken and inconsistent between variable instances and static faces.
Alright, thank you for the update! My assumption was that the metadata should be the same for the variable and the static versions of the font. But apparently one needs a PhD in font metadata to understand all this... Anyway, given that the handling of variable fonts is broken or incomplete (?) in F32, would it be an option to remove Cantarell-VF.otf from the package for the time being?
The code is fixed upstream and F32 ships a fontconfig snapshot not a real version. Nothing stops the fontconfig maintainer for building variable fixes in F32.
FEDORA-2020-d8186e5023 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8186e5023
FEDORA-2020-d8186e5023 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d8186e5023` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8186e5023 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thank you for the update! Unfortunately, it doesn't solve the issue for me. It might improve the font rendering on Wayland slightly (not sure about that), but generally, bold fonts are still much too heavy.
FEDORA-2020-d8186e5023 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
This bug is still present -- I use an X11 session and still see the too-bold Cantarell font issue.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.