There is currently movement towards protecting browser users from font fingerprinting. This means refusing, by default, to load user-installed fonts, which makes the set of fonts that each OS installs by default even more important than before. Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1582687 W3C CSS WG issue: https://github.com/w3c/csswg-drafts/issues/4497 Currently, Windows 10, macOS, Android, and Chrome OS provide broader installed-by-default Unicode coverage than Fedora. Examples of living scripts that have enough active users to make it to the list at https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scripts_by_adoption but are not supported by default in Fedora 31 include Javanese, Sundanese, Batak, Balinese, Mongolian, and New Tai Lue. Egyptian hieroglyphs is an example of a dead script the Fedora 31 doesn't support out of the box but Windows 10, macOS, Chrome OS, and Android do. To remedy this with minimal disk space impact, I suggest the same approach that Apple took. Apple bundles with macOS those Noto fonts that cover scripts that were not already covered by the previous installed-by-default set of fonts on macOS. In the macOS case, the on-disk footprint of the Noto fonts that were required to take macOS to Android/Chrome OS-competitive Unicode coverage was only a couple of megabytes. (The fonts are hidden in /Library/Application Support/Apple/Fonts/Language Support/.) In the case of Fedora, the set of Noto fonts required to reach the Chrome OS / Android level of script coverage is a bit larger than in the macOS case but should still be manageable. Please install, by default, those Noto fonts that provide support for scripts that are not properly supported by the fonts that Fedora already installs by default.
Thank for reporting this and the good suggestion. Unfortunately we missed it for F33 :-( but I definitely want to try to address this for F34.
We may need to make sure some steps to proceed: 1. Whether Noto fonts is really satisfied for quality. There was a case that native speaker says it is not better than blah blah blah. we need to figure out rather than trusting the acceptance in other platforms fanatically. of course we could try according to them. but as a reference. 2. We can't use a font properly without locale, except applications has own support to configure fonts per script-based like some browsers does. We need to make sure if corresponding locale is available in glibc. 3. Then also we need orthography file for that to categorize lang coverage in fontconfig
(In reply to Akira TAGOH from comment #2) > 2. We can't use a font properly without locale, except applications has own > support to configure fonts per script-based like some browsers does. > > We need to make sure if corresponding locale is available in glibc. The point here is to provide font coverage to browsers even when system locale coverage is missing. It would be sad to block on system locale availability. Comment 0 advocates imitating Apple's approach: Shipping Noto fonts for the long tail that doesn't have system locale support.
You can not avoid fixing locale declaration in wayland and apps for all the locales you want to target, because locales overlap in unicode but expect different shape rendering for the same codepoints. A mass of glyphs (even a mass as big as the one in Noto) is insufficient by itself to render text without locale info to choose which of the shapes to use in all the cases overlap happens. And, paradoxically, providing all the glyphs by default makes the situation worse, because it will definitely expose overlap situations, whereas installing just the glyph subset the user wants, hides locale support problems (because overlapping variants are not available on system)
(In reply to Akira TAGOH from comment #2) > We may need to make sure some steps to proceed: > > 1. Whether Noto fonts is really satisfied for quality. > > There was a case that native speaker says it is not better than blah blah > blah. we need to figure out rather than trusting the acceptance in other > platforms fanatically. of course we could try according to them. but as a > reference. > We had even more complaints on Fedora KDE when we *didn't* use Noto. We have been using Noto for *everything* by default since Plasma 5.21 for consistency and coverage and people generally like it. > 2. We can't use a font properly without locale, except applications has own > support to configure fonts per script-based like some browsers does. > > We need to make sure if corresponding locale is available in glibc. > > 3. Then also we need orthography file for that to categorize lang coverage > in fontconfig These seem like things we should already have regardless of backing fonts...
> A mass of glyphs (even a mass as big as the one in Noto) is insufficient by itself to render text without locale info to choose which of the shapes to use in all the cases overlap happens. This request is primarily for the benefit of browsers, and as noted in comment 2, browsers carry the required information independently of glibc.
Can we come up with a proposed list of fonts to add? I feel this makes even better sense now with our switch to Noto as the system core fonts in the soon to be released Fedora 36.
(In reply to Henri Sivonen from comment #6) > > A mass of glyphs (even a mass as big as the one in Noto) is insufficient by itself to render text without locale info to choose which of the shapes to use in all the cases overlap happens. > > This request is primarily for the benefit of browsers, and as noted in > comment 2, browsers carry the required information independently of glibc. That is true as long as the contents specifies font names in CSS properties. but what we are talking here was mainly a fallback and substitution. if one expects to see them with the generic family name like sans-serif, serif, and/or monospace for example, it won't be possible to substitute it to the best font without the locale/language information. Of course, it may be better than nothing though, maybe too much to install everything by default. To install fonts effectively and efficiently, we use langpacks to pick up against locale. In that sense, we should consider to add locale to glibc if not yet available. and then, orthography file in fontconfig if not.
We can start with missing font coverage for scripts with locales that are already defined in glibc. We don't need to get univesal coverage in one go - it can be an incremental process.