I would like to propose dropping adobe-source-code-pro-fonts as the default gnome-terminal Mono font for Fedora @gnome: we should just use to the Fedora default Mono font everywhere consistently.
I think it is still possible to make this change for F35, before it branches in 10 days time.
I recently made this change for RHEL here, but I made it not apply to Fedora since Source Code Pro was selected by @jimmac. Easy enough to apply to Fedora as well, though.
But our default fonts don't look very good. Even for KDE Plasma we override them because they look terrible: https://pagure.io/fedora-kde/kde-settings/c/e860b3377bbc748b12ae78435514a0fde6a3b48c
I would suggest we go the other way and use the Adobe font consistently for monospace.
What's the motivation for this change?
I recently made this change for RHEL here
Wait, what... why?
See this bug report.
I understand part of the motivation for using Source Code Pro is specifically to avoid use of DejaVu. But changing only the GTK settings is not enough to eliminate use of DejaVu. It's important to understand that we have these two different orthogonal sets of default fonts. We have the GTK defaults which are specific to GTK applications only, and only the GTK UI portions of those applications:
And we also have the Fontconfig defaults, which are generic and are used for anything that is not a GTK UI:
Applications like WebKit, Firefox, LibreOffice, etc. do not and cannot look at the GTK settings when rendering text outside of GTK UIs, because these applications require defaults for Sans/Serif/Monospace categories, but the GTK settings only provide Default/Document/Monospace categories. Now, these applications do inform Fontconfig of GTK's antialiasing and hinting settings, which may be used or ignored depending on the particular Fontconfig configuration for the particular font that is requested, but the GTK Default/Document/Monospace fonts are just always going to be ignored except by the GTK user interface portion of applications. This is pretty obviously required for Sans and Serif since GTK does not have settings for these anyway. It's only Monospace where we run into some confusion from having two different default Monospace font settings.
The GTK default document font was previously "Sans" which is an alias for Fontconfig's default sans font, and the GTK default monospace font was previously "Monospace" which is an alias for Fontconfig's default monospace font. These were changed in this commit. (I don't know what the GTK default document font is actually used for, because applications that display documents usually cannot actually use GTK's settings, as mentioned above.)
Maybe we're OK with Fontconfig and GTK using different default monospace fonts. Maybe that's a design decision that we want to make. Or maybe it's just a mistake or oversight and we want to make Fontconfig level changes too. I don't know. That's for our designers to decide, I suppose.
With KDE Plasma, our users complained about the DejaVu fonts because they don't look good and have terrible hinting. That's why we force Noto fonts everywhere.
Honestly, I don't even know why our fontconfig default isn't the Noto fonts, since they have the coverage to make that reasonable and look fairly good regardless of desktop.
The nice thing about Noto is its impressive glyph coverage. E.g. in this article if you use our default font settings, you can see in either Firefox or Epiphany that the ė in Bravė is clearly drawn with a different font than the rest of the text. I would hope that would not be the case if we were to default to Noto instead.
Lastly, since this commit we have an unresolved complaint about the GTK default monospace font size in #134.
Some testing with Firefox's font inspector, to show how our Fontconfig defaults matter in practice:
There is ui-monospace and ui-sans-serif going along with system-ui to differentiate UI fonts from document fonts. In theory org.gnome.desktop.interface.font-name and org.gnome.desktop.interface.monospace-font-name could use them and GNOME could (somehow, somewhere; might require a new project) ship a fontconfig file defining them (fontconfig already defines system-ui). This way, you could get better fallback behavior when fonts aren’t present (for example, vte needs a monospace font and instead gets a sans serif font) and handle different versions of the same font with different names (Source Code Pro, Source Code Variable). But that wouldn’t work in Flatpak because the fontconfig files wouldn’t be available there.
system-ui
org.gnome.desktop.interface.font-name
org.gnome.desktop.interface.monospace-font-name
Honestly, I don't even know why our fontconfig default isn't the Noto fonts
Apparently it requires locale support, fontconfig language coverage, and making sure the font quality isn’t worse: https://bugzilla.redhat.com/show_bug.cgi?id=1809989#c2.
I only see Noto CJK fonts in Firefox. There's a note in Noto guidelines: Put "Noto Sans" before "Noto Sans CJK". Currently, the Latin characters in the CJK fonts are from Adobe’s Source Sans Pro
From a clean install of Fedora 34 Workstation:
$ rpm -qa | grep noto google-noto-fonts-common-20181223-9.fc34.noarch google-noto-emoji-color-fonts-20200916-2.fc34.noarch google-noto-cjk-fonts-common-20201206-2.fc34.noarch google-noto-sans-cjk-ttc-fonts-20201206-2.fc34.noarch google-noto-sans-gurmukhi-fonts-20181223-9.fc34.noarch google-noto-sans-sinhala-vf-fonts-20181223-9.fc34.noarch
Thank you for interesting information. I didn't know that KDE uses Noto fonts by default. there was some discussion replacing DejaVu to Noto before, but it didn't happen because we were worried about the quality of Noto at that moment.
If that works, let me open a Change proposal for f36 then.
Thank you for interesting information. I didn't know that KDE uses Noto fonts by default. there was some discussion replacing DejaVu to Noto before, but it didn't happen because we were worried about the quality of Noto at that moment. If that works, let me open a Change proposal for f36 then.
That would be awesome. :100:
From a coverage perspective, using Noto as a fallback makes a lot of sense.
That said, one issue we currently have with Noto is the sheer number of items that appear in font selection lists:
<img alt="noto-list.png" src="/fedora-workstation/issue/raw/files/2e80709df80036780eadf8f263180d79fd0c7b236c248e27b28201450fe0dad9-noto-list.png" />
I'd need to study Noto mono in more detail before saying whether it's a good default monospace option or not.
That said, one issue we currently have with Noto is the sheer number of items that appear in font selection lists
A few more details: I count 110 entries for Noto fonts, as exposed in the GTK Font Chooser and the GTK apps that use it. LibreOffice has a similar situation. Inkscape noticeably doesn't: it manages to hide the different weights, resulting in 14 items for Noto.
From a coverage perspective, using Noto as a fallback makes a lot of sense. That said, one issue we currently have with Noto is the sheer number of items that appear in font selection lists:
That's true. I'm not sure if/how that would helps but I'm planning to unify all the Noto fonts according to the similar typefaces and make it accessible with a few names such as Noto Sans, Noto Serif, and Noto Sans Mono for all the language variants.
I understand part of the motivation for using Source Code Pro is specifically to avoid use of DejaVu.
The motivation for Source Code Pro was to have a good default monospace for the desktop, particularly the main desktop uses like the terminal and text editor. The fact that we were replacing DejaVu in that case was somewhat incidental.
But changing only the GTK settings is not enough to eliminate use of DejaVu.
I don't understand the logic of saying that, since DejaVu wasn't removed everywhere, we should extend its use, particularly in light of the fact that people are saying that DejaVu is old-fashioned and doesn't look good.
I'm not aware of a reason why we shouldn't sync up the fontconfig defaults with the GTK ones. But please, let's not revert the desktop fonts back to the current fontconfig defaults. That will look pretty terrible.
Just to repeat this point: the fact that we have one monospace font for the terminal and another on bugzilla.redhat.com is likely a bug, but it isn't one that is immediately obvious, and is far less severe than the bug of having a bad monospace font at the desktop level.
Anyway, this ticket is fairly unclear, so let's talk it over in a meeting.
Metadata Update from @aday: - Issue set to the milestone: Fedora 35 - Issue tagged with: meeting
If Source Code Pro is better monospaced font, that's fine. let's update in fontconfig level. you may need to raise a Change proposal (although it has already happened in GNOME) because we have a separate fontconfig file per packages and need to update the priority there to make it default. this will takes effect for non-GNOME desktops too. or Noto Sans Mono to make consistencies to other generic families?
I would use Noto Mono for consistency, assuming it is acceptable to our designers.
If Source Code Pro is better monospaced font, that's fine. let's update in fontconfig level. you may need to raise a Change proposal (although it has already happened in GNOME) because we have a separate fontconfig file per packages and need to update the priority there to make it default.
Makes sense, thanks @tagoh .
or Noto Sans Mono to make consistencies to other generic families?
When I try Noto Sans Mono here, it doesn't look great, to the point that makes me wonder if there's a bug somewhere. I'll try on some other platforms just to check.
Just a note that it's not just designers that need to be involved here. The monospace is important for the developer experience; when we selected Source Code Pro, we got Christian Hergert to review it from a code editing perspective.
According to this issue, Noto Mono is obsoleted by Noto Sans Mono. OK....
$ sudo dnf install google-noto-sans-mono-fonts $ gsettings set org.gnome.desktop.interface monospace-font-name "Noto Sans Mono Medium 10"
To get back to Source Code Pro:
$ gsettings reset org.gnome.desktop.interface monospace-font-name
I took some screenshots. This is all purely subjective personal preference, but honestly I'm inclined to agree. Source Code Pro is very nice. Noto feels OK, but a little cramped. DejaVu just looks tacky.
<img alt="source-code-pro.png" src="/fedora-workstation/issue/raw/files/a51dc908dc5b975233704b1edb289f98a2a5daf105877ddc17f0e43a45e4c364-source-code-pro.png" /><img alt="noto-sans-mono.png" src="/fedora-workstation/issue/raw/files/63c95ae0172f388800e554215f101c541b11490bdc1a52f8a38701fb6b3e3e08-noto-sans-mono.png" /><img alt="dejavu-sans-mono.png" src="/fedora-workstation/issue/raw/files/5d6971040a12457778374ec630217389f7a97702e29a03c3f4248b0185751c8d-dejavu-sans-mono.png" />
It would be entirely possible to change Fontconfig to use Noto even while keeping the GTK setting at Source Code Pro. It's not like we follow Fontconfig's default sans font for the rest of the desktop interface -- we use Cantarell instead -- so there's a pretty strong precedent for diverging. It is a little confusing to have two different default monospace fonts, though, which is probably why @petersen reported this issue. (@petersen, opinions?) Or we could change Fontconfig to use Noto only for Sans and Serif variants, and use Source Code Pro for the monospace font. Or maybe consistent Noto everywhere is good enough.
I'm not sure I care overly much what the end result is. My main goal here is to make sure you understand the differences between GTK and Fontconfig defaults.
Some more screenshots, to show the impact of changing defaults at the Fontconfig level. Currently we default to DejaVu. Changing to Noto is going to have a big impact on websites.
<img alt="dejavu.png" src="/fedora-workstation/issue/raw/files/b30a19ee907358a85b79e5527f6fa489892c449b840054300d7149425b21bc01-dejavu.png" /><img alt="noto.png" src="/fedora-workstation/issue/raw/files/68aa562713a2afe0d9fdf508150cb1fe06e25cfad26c8117a6b3e0ad59796588-noto.png" />
Thanks, Michael for all the comments and details. BTW your screenshots are from a default Fedora installation? I hope we can come up with more comparative screenshot mashups etc to compare more closely.
To respond to your question, yes I'd like to see an unified font approach for Fedora, so I think we should aim for using same defaults for gtk and fontconfig (and KDE etc if possible) as far as possible. So indeed that was the intent behind opening this ticket.
Our main motivation for pushing for Noto again is the broad global Unicode coverage the Noto family of fonts provides, which Western fonts like Cantarell and Adobe Code Source Pro can't really compare with. But let's see how this pans out, there are certainly complications (and advantages like variable fonts) to overcome, I am hoping we can make good progress by F36; and since it is a rather large Change I was actually hoping we could swap out dejavu for Noto sooner rather than later in Rawhide so that we can start wider testing as early as possible, since it is going to need time to stabilize and analyze.
(Also as Chris noted, we already switched CJK to Noto fonts quite a number of releases ago (and a couple more Asian languages in the meantime) and also Noto Color Emoji, but our original (#36) plans to move forward with Noto globally was stalled, so now seems a good time to continue that work.)
Here are screenshots from Fedora KDE Plasma:
<img alt="Screenshot_20210824_101429.png" src="/fedora-workstation/issue/raw/files/a8d6f97881e32f33ee69842f4a1fe693259acfcdadea667d0573586d4cbed411-Screenshot_20210824_101429.png" />
<img alt="Screenshot_20210824_101816.png" src="/fedora-workstation/issue/raw/files/4a75ab2a4f700536034cf3db0814648bc92671c5e3e1d33efc18e0e249d4a685-Screenshot_20210824_101816.png" />
Thanks, Michael for all the comments and details. BTW your screenshots are from a default Fedora installation?
Yes, the only change I made in my screenshots was the font family change. These screenshots use GNOME default settings (grayscale antialiasing, slight hinting) and no fontconfig modifications (except for the web browser screenshot, where I modified the default font families).
I think that is really necessary. The sheer number of noto fonts is a hazard (both ui-wise in the font chooser, and performance-wise, since FcFontSort works by giving you a list of all fonts, sorted.
We discussed this at yesterday's meeting, so removing the meeting tag. It would be good to return to this topic once we've done more exploration and research.
Metadata Update from @aday: - Issue untagged with: meeting
I was asked to comment on this. Not sure I got all the points here under consideration, but I personally advocate for
I think the unification of Noto is somewhere on Google Fonts to-do list. It's, uhm, a major effort that is going to take time because quite a lot of sources contain data dumps in Monotype's proprietary OpenType Layout format "MTI" instead of the much more malleable, openly specified Adobe format. Merging layout code is going to be painful. Feel free to ping them though on their issue tracker.
It may make more sense to invest time into making GUIs group fonts into two levels, as in, family → style names. Otherwise, you're back to the same usability problem when the user has a lot of fonts installed but you won't see it because the users may not complain to you directly :)
Did I forget to comment on anything?
DejaVu just looks tacky.
Try again after increasing the line height (120% or more). Fonts have default line height baked in by accident, but for best results you must always control it yourself. Sadly, fontconfig does not allow to set defaults per font here and have apps respect it...
fixable elsewhere
The scalability problems caused by installing a million noto fonts by default are fixable in two places:
Until it is addressed, installing all of noto will drastically reduce the usability of the gtk fontchooser.
Ok! Then I suggest you approach Google regarding their timetable. I don't know what can be done on fontconfig's side.
Proposal:
For KDE, make sure SCP is installed as the OTF variant so you get more consistent hinting AND Qt's linear alpha blending and gamma correction of text, i.e. correct text rendering, like for Cantarell. It will mix better. Maybe install the OTF variants for the CJK fonts as well, for better hinting? Haven't tested that.
What's going on here? Are we not already using OTF fonts?
Adopt Source Code Pro at the Fontconfig level in rawhide, as a downstream Fedora change. Change the GNOME settings from "Source Code Pro" back to "Monospace" so we go back to having a single monospace font. (It will just be Source Code Pro now, instead of DejaVu.)
Ah wait, this might not work because I think the GNOME designers want Source Code Pro upstream. Never mind. This is a little tricky because proposing Source Code Pro to upstream Fontconfig seems a lot more audacious than proposing Noto, and Akira has already expressed a preference for specific font choices to be handled downstream....
I don't know, just saying words.
I don't think what GNOME designers want for upstream GNOME affects what we can or should do in Fedora. Lets not tie our own hands needlessl
Metadata Update from @petersen: - Issue set to the milestone: Fedora 36 (was: Fedora 35)
Moving this to Fedora 36
I've submitted https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts for f36.
Seems like this has been implemented, yes? OK to close it?
f36 has been released. yes, I think we can close it.
Metadata Update from @tpopela: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Well testing in F36 on a system upgraded from older Fedora releases reveals:
$ fc-match sans NotoSans-VF.ttf: "Noto Sans" "Regular" $ fc-match serif DejaVuSerif.ttf: "DejaVu Serif" "Regular" $ fc-match monospace DejaVuSansMono.ttf: "DejaVu Sans Mono" "Regular"
That's weird. I don't think I have any special fontconfig configuration.
It does look correct if I retest on a freshly-installed system. If I remove dejavu-sans-fonts, dejavu-sans-mono-fonts, and dejavu-serif-fonts, then try again, I see:
$ fc-match mono NimbusMonoPS-Regular.otf: "Nimbus Mono PS" "Regular"
So Noto is not installed at all. We probably only handled fresh installs, and not upgrades. Reopening.
Metadata Update from @catanzaro: - Issue status updated to: Open (was: Closed)
Looking at the list of font packages from the change proposal:
$ sudo dnf install google-noto-sans-vf-fonts google-noto-serif-vf-fonts google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts google-noto-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-fonts google-noto-serif-armenian-vf-fonts google-noto-sans-canadian-aboriginal-vf-fonts google-noto-sans-georgian-vf-fonts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts google-noto-serif-sinhala-vf-fonts google-noto-sans-ethiopic-vf-fonts google-noto-serif-ethiopic-vf-fonts [sudo] password for mcatanzaro: Last metadata expiration check: 0:54:54 ago on Tue 17 May 2022 08:10:47 AM CDT. Package google-noto-sans-vf-fonts-20201206-9.fc36.noarch is already installed. Dependencies resolved. ======================================================================================================================= Package Architecture Version Repository Size ======================================================================================================================= Installing: google-noto-rashi-hebrew-vf-fonts noarch 20201206-9.fc36 fedora 25 k google-noto-sans-arabic-vf-fonts noarch 20201206-9.fc36 fedora 122 k google-noto-sans-armenian-vf-fonts noarch 20201206-9.fc36 fedora 27 k google-noto-sans-canadian-aboriginal-vf-fonts noarch 20201206-9.fc36 fedora 53 k google-noto-sans-cherokee-vf-fonts noarch 20201206-9.fc36 fedora 85 k google-noto-sans-ethiopic-vf-fonts noarch 20201206-9.fc36 fedora 164 k google-noto-sans-georgian-vf-fonts noarch 20201206-9.fc36 fedora 46 k google-noto-sans-hebrew-vf-fonts noarch 20201206-9.fc36 fedora 22 k google-noto-sans-lao-vf-fonts noarch 20201206-9.fc36 fedora 26 k google-noto-sans-math-vf-fonts noarch 20201206-9.fc36 fedora 196 k google-noto-sans-mono-vf-fonts noarch 20201206-9.fc36 fedora 241 k google-noto-sans-thaana-vf-fonts noarch 20201206-9.fc36 fedora 26 k google-noto-serif-armenian-vf-fonts noarch 20201206-9.fc36 fedora 29 k google-noto-serif-ethiopic-vf-fonts noarch 20201206-9.fc36 fedora 139 k google-noto-serif-georgian-vf-fonts noarch 20201206-9.fc36 fedora 52 k google-noto-serif-gurmukhi-vf-fonts noarch 20201206-9.fc36 fedora 39 k google-noto-serif-lao-vf-fonts noarch 20201206-9.fc36 fedora 30 k google-noto-serif-sinhala-vf-fonts noarch 20201206-9.fc36 fedora 84 k google-noto-serif-vf-fonts noarch 20201206-9.fc36 fedora 526 k Transaction Summary ======================================================================================================================= Install 19 Packages Total download size: 1.9 M Installed size: 4.2 M Is this ok [y/N]:
Shame that we didn't test this until now. Just adding packages to comps is not enough, because that doesn't affect upgraded systems. We need Recommends: from some other package as well (e.g. fedora-release-workstation).
I recently clean installed F36 Workstation replacing all of / but kept the old /home, and I have
/
/home
$ fc-match sans NotoSans-VF.ttf: "Noto Sans" "Regular" $ fc-match serif NotoSerif-VF.ttf: "Noto Serif" "Regular" $ fc-match monospace NotoSansMono-VF.ttf: "Noto Sans Mono" "Regular"
Perhaps something can be done on the langpacks metapackages side to help with this.
Do we have any way to pull in new comps group packages when upgrading?
I pushed langpacks-3.0-23.fc37 for Rawhide if you want to test langpacks-en for that.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6b143dffaf for F36
I think this happened. Can the issue be closed?
https://src.fedoraproject.org/rpms/langpacks/c/9b7d452ffec4c1e90b11cdbb268062a9a24812f8?branch=rawhide
Why not also Noto Sans? What about all the other new noto fonts that we want installed during upgrade to F36?
Hi @ngompa, can you please update us on status of dnf group/comps support for system upgrades? I thought there was some plan to ensure we don't have to remember to add Recommends every time something gets added to comps?
I'm not sure what's up with that now, @jmracek would know. Comps groups is supposed to be accounted for on system upgrades already.
Why not also Noto Sans?
Because it was already included
https://src.fedoraproject.org/rpms/langpacks/c/9b7d452ffec4c1e90b11cdbb268062a9a24812f8?branch=rawhide Why not also Noto Sans? What about all the other new noto fonts that we want installed during upgrade to F36?
Noto Sans is supposed to be pulled in by langpacks-core-font-en. no need to add it there. Also, I should've done adding non-sans fonts for other languages to langpacks in my initial work. I'm checking it to make sure, though.
I think that the system-upgrades install new items in installed groups. And I also see the code that handles it, therefore nothing to worry about.
Well we know from https://pagure.io/fedora-workstation/issue/236#comment-798203 that this didn't work in practice....
As far as I'm aware, this change mostly happened, so removing the milestone.
Metadata Update from @aday: - Issue set to the milestone: None (was: Fedora 36)
This was finished long ago, so closing.
Metadata Update from @catanzaro: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.