https://bugzilla.redhat.com/show_bug.cgi?id=1820166
--- Comment #7 from Nicolas Mailhot nicolas.mailhot@laposte.net --- (In reply to Akira TAGOH from comment #6)
Let's say more specific thing then. as this report complains about CJK, Google Noto CJK fonts isn't even inherited from Google Droid Japanese nor Google Droid Fallback. the unification you did in Droid says "it is a part of Droid" now. but CJK support in Droid isn't worth a fallback for Noto.
Again, I disagree, for design and historical and user expectation reasons Droid as a whole is the best fallback for Noto as a whole. The problem here is not the fallback, the problem here is that fontconfig fallbacks for Noto when the CJK parts of Noto are available on system.
You’re mixing things up. This is not a "default font" family situation. The user constructed a font stack that includes Noto. When Noto coverage is insufficient, fontconfig fallbacks to the closest font, which is Droid (as it should be, for design and historical reasons). All of this is fine and normal and works as it should.
In fact your changes affected to the default font. not mixing things up.
They did not affect the default font. They affected a user-specific configuration. A user-specific configuration, BTW, that was attempting a limited Noto unification, because unification is the natural thing for users to do (as people have been reporting to fontconfig for years now).
You should be explaining to the user how to unify Noto and Noto CJK properly, since that is clearly the user wish, instead of trying to avoid the issue by breaking the configuration of other font families.
(I write "you" here because you’ve been repeatedly dismissing reports that fontconfig syntax is inadequate for use by normal users in presence of modern font families spread over multiple files. So here is the perfect opportunity to prove us all wrong. Or to change your mind and plan a fix. Either way works for me.)
What does not work as it should is that fontconfig ignores the CJK parts of Noto before fallbacking from Noto to another font. That‘s the problem root cause.
Not exactly. from the point of view how fontconfig select the best font, current situation is coming from the misconfiguation in those rules in packages. so exactly speaking the root cause is:
The problem is triggered by lack of Noto
unification in fontconfig.
That. As I said in my initial comment, we should update google-noto-fonts and google-noto-cjk-fonts for this issue. but introducing the change in google-droid-fonts without those changes as well looks agressive. particularly doing it in f32.
After 10+ years of heads-up upstream, with multiple problem reports, by multiple entities, it is not aggressive. It is way late.
no need to make changes in syntax. that is nice-to-have but not necessarily required to fix this.
Then just make use of this syntax yourself. Document and explain this syntax to users yourself. And do it for all the font families that need it (hint: that means all the wide coverage font families produced for mobile and web today, since they are *all* sub-setted and split for performance reason. Noto is no more an exception than Droid was. It’s the model font makers are following for all new font families).
Do not ask others to use a syntax that “needs no changes” if you do not want to touch it yourself.