Bug 1809989

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.