https://bugzilla.redhat.com/show_bug.cgi?id=1820166
--- Comment #5 from Nicolas Mailhot nicolas.mailhot@laposte.net --- (In reply to Akira TAGOH from comment #4)
Why? Noto is effectively Droid v2. It is the same design, produced by the same people, for the same use cases. There are some metric differences, but mostly, it is an evolution of the same family. The only reason it is not called Droid still is that Google realized the Droid naming was a mistake (for trademark reasons, and due to how they contracted out Droid to Ascender in the first place).
If looking at Latin glyphs only, that may be true.
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.
that's not what I'm talking about. my concern is about Droid blahblahblah unified as *Droid*. those had never been considered to be worth changing default fonts for certain languages despite that other Noto families did for some.
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.
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.
if you
don't want to drop those lines, those poor quality fonts should be dropped from unified Droid. those aren't worth a fallback font as *unified Noto*.
Again, Droid is not configured as a generic fallback font here.
Is there an ETA for this? Droid has been unified in Fedora for a decade+. Noto upstream formally requested Noto unification. I don’t see how you can argue in this issue tracker, that unification is a challenge, while arguing in the fontconfig issue tracker, that the existing fontconfig syntax needs no changes and serves font deployment needs well.
On your efforts, new fonts packaging guidelines has taken effect. thank you for that. all the fonts packagers are encouraged to follow on it in f33 IMHO. probably good to have Change proposal for that? dunno.
Forgive me but this has been going on for 10+ years. The “at least until it is done” card expired long ago. Do you have a more definite forward plan than that?
It's for you right. but not for most of people, because there were no strong reasons to do so and is really new in guidelines.
But that’s not what I wrote about. The problem is triggered by lack of Noto unification in fontconfig.
*I* did not make Google request unification. *I* did not make Adobe unify font in its products. *I* did not go to the ISO standardise unifications syntaxes. That‘s a huge amount of work by lots of people and companies. That’s not my own private project. That should be enough by itself to show “strong reasons” exist (and BTW, Adobe unification efforts were driven by the needs of CJK, not Latin users).
There are multiple, years old requests to make unification easier in fontconfig. Your answer so far has been that no syntax changes are needed, and font deployers can use the existing syntax just fine.
Well, here unification is needed to fix a user problem. Just do it then. That will solve the requester problem.
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”.