https://bugzilla.redhat.com/show_bug.cgi?id=1820166
--- Comment #6 from Akira TAGOH <tagoh(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #5)
It’s not "looking only at the latin glyphs". Noto and Droid
are both wide
coverage font families, and Noto started by inheriting all the coverage
already achieved in Droid. Google wide coverage efforts did not start with
Noto. The latest Droid refresh (all the painful digging in the multi-gig
Android source tree) was requested by people using Droid as a fallback font.
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.
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.
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. in fact that breaks and affects as this report. we should
release all the relevant packages together to avoid breakage, particularly for
f32. that's all what I want to say.
Alternatively, can we see a serious commitment to a more
user-friendly
syntax fontconfig-side? I’ve no problem to stage packaging changes on a
shared roadmap. But, absent this roadmap, I won’t delay fixing my stuff for
illusory “laters”.
Leaping of the logic. why such configuration was written by users is also same
root cause. introducing the unification of Noto fixes all the problem here. no
need to make changes in syntax. that is nice-to-have but not necessarily
required to fix this.
--
You are receiving this mail because:
You are on the CC list for the bug.