https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Bug ID: 1809989 Summary: By default install Noto fonts for Unicode scripts not already covered by default Product: Fedora Version: 31 Status: NEW Component: google-noto-fonts Assignee: petersen@redhat.com Reporter: hsivonen@hsivonen.fi QA Contact: extras-qa@fedoraproject.org CC: fonts-bugs@lists.fedoraproject.org, i18n-bugs@lists.fedoraproject.org, petersen@redhat.com, psatpute@redhat.com, pwu@redhat.com, tagoh@redhat.com Target Milestone: --- Classification: Fedora
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_script... 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |FutureFeature, i18n Priority|unspecified |medium Version|31 |rawhide Doc Type|--- |If docs needed, set a value Severity|unspecified |medium
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #1 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|google-noto-fonts |Fonts Assignee|petersen@redhat.com |i18n-bugs@lists.fedoraproje | |ct.org QA Contact|extras-qa@fedoraproject.org |fonts-bugs@lists.fedoraproj | |ect.org
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #2 from Akira TAGOH tagoh@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #3 from Henri Sivonen hsivonen@hsivonen.fi --- (In reply to Akira TAGOH from comment #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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #4 from Nicolas Mailhot nicolas.mailhot@laposte.net --- 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Neal Gompa ngompa13@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jgrulich@redhat.com, | |ngompa13@gmail.com, | |rdieter@gmail.com
--- Comment #5 from Neal Gompa ngompa13@gmail.com --- (In reply to Akira TAGOH from comment #2)
We may need to make sure some steps to proceed:
- 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.
- 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.
- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Red Hat One Jira (issues.redhat.com) redhat-one-jira@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Link ID| |Red Hat Issue Tracker | |FC-412
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #6 from Henri Sivonen hsivonen@hsivonen.fi ---
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Fonts |google-noto-fonts Assignee|i18n-bugs@lists.fedoraproje |tagoh@redhat.com |ct.org | QA Contact|fonts-bugs@lists.fedoraproj |extras-qa@fedoraproject.org |ect.org |
--- Comment #7 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #8 from Akira TAGOH tagoh@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
--- Comment #9 from Jens Petersen petersen@redhat.com --- 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.
i18n-bugs@lists.fedoraproject.org