https://bugzilla.redhat.com/show_bug.cgi?id=1820166
--- Comment #5 from Nicolas Mailhot <nicolas.mailhot(a)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”.
--
You are receiving this mail because:
You are on the CC list for the bug.