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?

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:

• GTK default font: Cantarell
• GTK default document font: Cantarell
• GTK default monospace font: Source Code Pro (except in RHEL)

And we also have the Fontconfig defaults, which are generic and are used for anything that is not a GTK UI:

• Fontconfig default sans font: DejaVu Sans
• Fontconfig default serif font: DejaVu Serif
• Fontconfig default monospace font: DejaVu Sans Mono

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.

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:

• On this Pagure issue, the font used for comments is Open Sans. That's just a web font, unrelated to our defaults, so let's ignore it.
• On bugzilla.redhat.com, the font used for comments is DejaVu Sans Mono, because Bugzilla requests "monospace" and Fontconfig says monospace means DejaVu Sans Mono.
• On lwn.net, the primary font is DejaVu Serif, because the LWN requests "serif" and Fontconfig says serif means DejaVu Serif.
• On example.com the default font is, somewhat impressively, Cantarell, because example.com requests "system-ui" and Firefox implements that using the GTK default setting. We actually have this hooked up in WebKitGTK too. (Sadly it seems broken under flatpak, because I only see Cantarell here when using Fedora's system Epiphany, not GNOME's Epiphany Tech Preview.)

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.

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:

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.

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.

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.

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.

I would use Noto Mono for consistency, assuming it is acceptable to our designers.

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....

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.

$ 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

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.

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.

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.

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.

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:

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).

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 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.

I was asked to comment on this. Not sure I got all the points here under consideration, but I personally advocate for

1. Use Noto (Sans, Serif, Mono) Whatever as the base font setting for everything, fontconfig and GTK, regardless of any "locale" information (fixable elsewhere) or whether the natives like it better than another font (have them complain to Google so Noto has a chance to get fixed for everyone!)
2. Use Source Code Pro as the Fedora fontconfig overlay so that it's the default Mono font in Fedora
3. Make GTK use the default mono so either Noto Sans Mono or SCP on Fedora is picked up by default
4. 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.
5. Maybe install the OTF variants for the CJK fonts as well, for better hinting? Haven't tested that.

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:

1. Noto unification
2. fontconfig

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:

• Wait for Akira or Google to report progress on Noto unification before attempting to replace DejaVu with Noto. i.e. this change is rejected for now, but would be welcome again in the future after unification has happened.
• 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.)

1. 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.
2. 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....

What's going on here? Are we not already using OTF fonts?

I don't know, just saying words.

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 think what GNOME designers want for upstream GNOME affects what we can or should do in Fedora. Lets not tie our own hands needlessl

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.

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.

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

$ 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"

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).

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'm not sure what's up with that now, @jmracek would know. Comps groups is supposed to be accounted for on system upgrades already.

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.

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.

This was finished long ago, so closing.