From: Marc Espie <marc.espie.openbsd@gmail.com>
Subject: noto hack
To: tech@openbsd.org
Date: Tue, 18 Jun 2024 16:26:27 +0200

Like many people, I want to have the noto fonts around for web content,
because I often browse wikipedia and unicode pages, but it is a definitive
impediment for the font requester in creation programs.

The fontconfig format is somewhat poorly documented, it's decently hard to
put together something that works from the documentation, yes, even with
examples.

Anyhow, I cobbled together something like this, as /etc/fonts/local.conf

<fontconfig>
    <match target="pattern">
	<test qual="all" name="prgname" target="pattern" compare="eq">
	    <or>
		<string>gimp</string>
		<string>libreoffice</string>
	    </or>
	</test>
	<rejectfont>
		<glob>/usr/local/share/fonts/noto/*</glob>
	</rejectfont>
    </match>
</fontconfig>

which does make sure both libreoffice and gimp do NOT see the 50+ fonts
that are useless for them.

IMO, it would be way more useful if we could actually organize the Noto stuff
as a proper family. Namely: reject most Noto fonts as "independent" fonts
but propose them as decent codepoints for glyphs that are not in the basic
font (which is, after all, the whole purpose of splitting up the noto
unicode coverage into separate fonts) but I have zero idea how to do that
(not sure it's even possible to both neuter some fonts as a primary selection
mechanism but propose them as alternates)

Alternately, one may choose to shutter noto fonts EXCEPT for specific programs.

<fontconfig>
    <match target="pattern">
	<test qual="all" name="prgname" target="pattern" compare="not_eq">
	    <and>
		<string>chromium</string>
		<string>firefox</string>
	    </or>
	</test>
	<rejectfont>
		<glob>/usr/local/share/fonts/noto/*</glob>
	</rejectfont>
    </match>
</fontconfig>

but I have zero idea if more programs should actually benefit.

Ideally, being able to have a match that would only trigger in the actual
UI font selection mechanisms, BUT not in the rendering proper would be ideal,
but I fear fontconfig, for all its sophistication, lacks the semantics to do
that.

IMO, there is definitely a problem with how fonts are currently handled.

It seems crazy to me that we have regressed compared to the ancient 
time when we had PostScript 1 composite fonts, some 20+ years ago,
that would precisely do the right thing in such situations.