Coincidentally I think it does — due to the way the Noto fonts are currently packaged in Debian.
As I mentioned, the fonts-noto-core package installs a large number of both latin and non-latin font files. People have argued for splitting it into multiple packages, but that discussion seems to be stalled. The good news for us, in the light of the “excessive fonts” discussion, is that you would be able to reduce the number of installed fonts significantly by uninstalling one single package.
The Dejavu fonts should be removed completely. They have not been developed further for 7 years and do not support many current Unicode characters and often cause problems with the representation of international alphabets.
Noto Fonts should be preinstalled because they solve many problems with non-Latin alphabets (and also with Latin alphabets with some special characters).
Fedora invested much energy to improve their default font selection:
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
Well, DejaVu is in the archive and will keep being so for the foreseeable future. There are a couple of reasons why I don’t propose it to be dropped at this time from the selection of fonts installed by default:
DejaVu Sans Mono is generally decent, and has proved to be the only well working font in e.g. gnome-terminal for Arabic scripts.
Many packages depend on fonts-dejavu-core. Run the command
apt rdepends fonts-dejavu-core
to see what I mean. So even if we would stop installing it by default, it would be pulled anyway for many users.
Installing fonts-noto-core by default — in combination with an appropriate font configuration — is sufficient to make Noto be used over DejaVu.
Arabic font rendering looks currently horrible with Dejavu and Ubuntu, especially when it comes to special letters, like Quranic symbols or the letters in the Urdu language. The only solution to solve this problem is to remove Dejavu.
Yes, some packages depend on the dejavu-fonts. So as I said it before it’s a lot of work to get rid of these old fonts, but Fedora did that work and now their font rendering on non-Latin alphabets is great. And I think the work is it worth.
This is an Arabic alphabet (Urdu) sample text on my Ubuntu 22.04 LTS machine (using Dejavu Fonts)
This is how it looks in my Fedora Rawhide VM (with Noto Fonts, it looks better):
@malsabku: Please let us distinguish between sans-serif and serif fonts on one hand, and monospace on the other hand.
For sans-serif and serif I know that Arabic speaking users prefer Noto over DejaVu, and currently — as a result of this long thread — there is an arrangement in place for supporting Noto for Arabic. Unfortunately that arrangement was broken for the snaps (including the FF snap). But with the changes I have in mind now we will make Noto truly become the default also for Arabic and also for the snaps.
For monospace: When I said that DejaVu Sans Mono is better, I was specifically talking about the rendering of Arabic scripts in certain terminals, most importantly gnome-terminal at the moment. I don’t speak Arabic myself, and consequently have no own opinion on what looks better, so I defer to this bug report and this discourse thread.
Thanks for your stewardship of fonts in Ubuntu, Gunnar. It is a pleasure to know we have someone like you paying attention to such issues.
A few comments:
You say “typically”. I think it’s clear that noto would be an improvement over DejaVu overall, but we should also have a goal not to introduce regressions even for subsets of our users. What steps will be taken to validate the choice of noto as the default by communities who use particular sets of glyphs? (Latin, and CJK are already addressed; but there are many distinct language communities - as you know - in India and in central and southeast Asia who should be consulted if we’re going to move them from dejavu to noto by default.)
The ubuntu-desktop metapackage currently Depends: on fonts-dejavu-core. I’m not sure that demoting this to a Recommends: is appropriate. It actually introduces the possibility of users breaking their desktop by leaving them with NO matching fonts installed.
Some more scripts have been addressed:
Arabic (which includes Persian and Urdu) has already been discussed in considerable detail.
Sinhala users explicitly asked for Noto.
Amharic users explicitly asked for Noto.
And yes, in an ideal world we should make sure that all affected users agree before implementing the change. But there would be some difficulties with asking first:
Hard to find interested Ubuntu users everywhere.
Even harder to find such users with sufficient technical skill to be able to test without handholding.
Please remember that since the snaps no longer rely on the system host’s /etc/fonts/conf.d, providing the proposed new font configuration in e.g. a PPA wouldn’t help much. Myself plans to use use a conventionally packaged FF to do the necessary tests before committing/uploading the changes to the system. But there will be no appropriate test environment until those changes have been mirrored in the snaps.
The snaps in Ubuntu 22.04 currently use the font configuration from focal (this is about to be changed to jammy). The snaps in Ubuntu 23.04 and the development version currently use the font configuration from jammy.
So my thought is to be rather bold:
Change it in 23.10 — including the snaps used in 23.10 — without asking first.
Then, when 23.10 has been released, let’s try to reach out to the affected language communities:
Hey, the default fonts were changed to Noto fonts in Ubuntu 23.10 for most scripts. Please upgrade to that Ubuntu version and let us know what you think, so we will be able to make possible necessary adjustments before the release of Ubuntu 24.04 LTS.
(Somehing along those lines…)
The idea is to keep fonts-dejavu-core in “Depends:” for now, so it can serve as fallback, and add fonts-noto-core to “Recommends:”. Please see this comment for one reason to do it like that.
I just want to share my thoughts just because I’m less technical than almost everyone here 
I don’t think this would be a great improvement for the “too many fonts” issue for non-technical users. I never remove fonts* (or similar) packages because I’m afraid to broke the system as they are not “programs” or other packages installed by me. I’ll probably continue to remove the fonts by hand from the font manager if I won’t find a specific guide on the web.
I’m not saying this change is not useful, I’m just sharing my 2 cents.
@kenvandine: Any chance you can provide some input about the snap implication of these proposed changes? I pinged you the other day on IRC with some somewhat vague questions:
https://irclogs.ubuntu.com/2023/07/12/%23ubuntu-desktop.html#t15:25
This ties nicely into our refining the installation processes discussion, so thank you @gunnarhj your timing is excellent.
My expertise in fonts is limited, so I’m reliant on the knowledge and insights of others. In general, I’m supportive of this initiative. As you’ve suggested, one possible approach could be accepting the risk in 23.10 and proceeding with these changes. This would provide us with the best opportunity to identify and correct any regressions before 24.04. I’m inclined to lean towards being hasty now, rather than trying to implement this change post-23.10 which doesn’t leave much space to maneuver.
I believe we need a post-upgrade splash screen to highlight “What’s new” and we could use that to highlight this change to users. However, the 23.10 road map is already quite full, making it difficult to incorporate that this cycle … although definitely do-able for 24.04.
Outside of snap are there any potential side effects here?
We won’t have a new core until core24, so we won’t be able to introduce this for snaps until then. The core snaps only follow the LTS schedule. However, I think we could add the noto fonts to gnome-42-2204 as it won’t change anyone’s default but will ensure at least core22 based desktop snaps have the font available in the snap.
I see two potential side effects:
Even if I have spent some time on investigating if the Noto fonts cover at least the same ranges of Unicode characters as the packages we would stop installing, I may have missed something.
Complaints due to personal preferences. Even if Noto has a good reputaion in general, people in some language areas might prefer some other font for their particular scripts.
Both these will be easy to deal with if/when people call our attention to it.
Hmm… That would be an awfully long time with different fonts in the snaps compared to the system. I really think we should try to work around it somehow (see below).
I don’t think that would make a difference. If I put:
<fontconfig>
<alias>
<family>sans-serif</family>
<prefer>
<family>Noto Sans</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>Noto Serif</family>
</prefer>
</alias>
</fontconfig>
in ~/snap/firefox/current/.config/fontconfig/conf.d/10-prefer-noto.conf, my Firefox latest/stable/ubuntu-23.10 instantly displays latin sans-serif and serif using Noto, since the fonts-noto-core package is installed for me in mantic. The snaps honor the fonts installed in the system; it’s just the font configuration of the system host they no longer honor.
But now to my idea for a workaround. I created the directory /usr/share/fonts/snap-config-hack and moved the test file 10-prefer-noto.conf into that directory. Then I added the line:
<include ignore_missing="yes">/usr/share/fonts/snap-config-hack</include>
in ~/snap/firefox/current/.config/fontconfig/fonts.conf. That worked. 
So how about letting language-selector-common install such an extra config file in jammy-updates and refresh gnome-42-2204? (What I actually have in mind is a new proposed 56-language-selector-prefer.conf file which would also be located in /etc/fonts/conf.d in mantic, and thus not seen otherwise by the snaps.)
Question: Would it be possible to let desktop-exports write the above line conditionally, i.e. only on 23.10 and 24.04 systems, so we don’t change the behavior in stable releases?
If desktop-exports writes that snippet for fontconfig, it would just quietly be ignored on systems where that file doesn’t exist on the host. In which case we shouldn’t need to SRU that to jammy, just mantic and later releases will get the preference for noto. Right?
@kenvandine: You are right, of course. (Somehow, for a moment, I thought that the file needs to be in the snap environment, even if I just had showed that it does not need to be… Stupid me!)
So, if I understand it correctly, we can easily keep the snaps in sync with the system by simply adding a similar snippet for fontconfig as the one we are just about to drop. Nice!
I think that’s a reasonable plan; we don’t need to get their sign-off before making the change, but we should be proactive rather than making the change and then hoping that bug reports come in.
I strongly recommend that the outreach list all of the languages and scripts for which we are seeking feedback.
FWIW from a design perspective: Noto is a competent choice that’s boring in the right ways. @gunnarhj has done great analysis here and we have no reason to disagree.
@gunnarhj +1 from the desktop team for the proposal. Do you need any specific support from us to action the changes?
Also, on outreach how do you recommend we go about that?
Thanks for your confidence in me.
I have pushed these two seed commits:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=38fee601
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=447dcaf6
I also merged and uploaded this language-selector merge proposal:
And this is a pull request for snapcraft-desktop-integration:
https://github.com/snapcore/snapcraft-desktop-integration/pull/14
Somebody needs to update the ubuntu-meta package with those seed changes. Otherwise I think it’s under control. I’m currently discussing a detail with @kenvandine.
Good question. What I have in mind so far is a separate “call for testing” topic here. And a hint in the 23.10 release notes.
Aside from that, I’m open for ideas. Which channel is best to reach as many users as possible who represent a wide range of languages and scripts?