Noto fonts screw my system, please stop forcing fonts upon me!

[Johan Ouwerkerk]

>
> So the noto fonts are not to blame, just the noto package is.
> That does match with what i said and a couple of people said in here, i just
> didn't expect it to end up this way.
> - I've said: "just having the fonts installed cripples chrome"
> - Some in here: "The fonts are fine and the best choice there is"
>
> I'm quite happy i know that now. This means that i can fiddle with
> fontconfig settings and just blacklist those that are installed by the noto
> package, but are not the noto fonts.
> And that means i can drop my fork!
>
> KDE - plasma - should most certainly clarify what it means by noto and
> inform distribution packagers of that. You seemingly expect that noto is
> just the noto fonts, that is apparently not the case  As it currently
> stands, installing the font package breaks (read cripples it, it's still
> readable) chrome rendering on archlinux. Archlinux itself is not at fault
> here, they do exactly what one expects, the noto package from the official
> site gets installed as is. Period. The package just installs fonts that mess
> things up (Arimo, Cousine, and Timos) that need to be blacklisted and aren't
> by default.
>

>From the perspective of the upstream: KDE doesn't really care what
fonts you have installed. KDE just needs something sane to integrate
visually with their design, hence choice for Noto as default.

At that point it becomes the case that as far as KDE is concerned
there's (by default) a dependency on "something which will provide you
the Noto fonts". How exactly those are packaged up is really the
distribution's problem/business to sort out. For example on Debian the
KDE packages pull in fonts-noto-hinted by default which contains just
Noto files.

Moreover it is not KDE's responsiblity to set a packaging policy for
these fonts as they are an upstream. It would be rather like KDE
deciding how X libs ought to be packaged up. (Where in the case of
Debian there's about 3 'X' packages in total and a minimal X server
can be installed without /usr/bin/X being provided by default).

So it's really down to "how much work/effort is the distro willing to
invest towards proper packaging and integration". In the case of Arch
it's not as much as Debian because the user is expected to sort things
out/configure the system themselves, and a correspondingly greater
effort is spent in maintaining their excellent wiki instead.