Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Raphaël Halimi]

Hi Gunnar,

Le 16/08/2023 à 17:32, Gunnar Hjalmarsson a écrit :
> That's a misconception, and upstream is to blame for it. Not 
> Freedesktop, though, but Google.
> 
> Noto Sans Mono is a monospace font shipped by the fonts-noto-mono 
> package in Debian. So is Noto Mono (previously named Droid Mono). The 
> problem is that Noto Sans Mono does not declare itself as such properly. 

Yes, I already knew that. At the time that when was upgraded in Sid and 
I files the bugreport, I crawled several BTS (Gnome, Fedora, Github, 
etc) and I learned that Noto Sans Mono didn't register itself as a 
monospace font, but also (or consequently) that its spacing was not 
correct for a monospace font. The problem lies in the font itself, so 
indeed, Google is to blame. The bug was reported several times on Github 
and never fixed.

IIRC Noto Mono is a legacy, discontinued font, still distributed (albeit 
separately), and the maintainers of the Noto fonts Debian packages still 
include it (which is a good thing, since it's the only one to  work 
correctly).

On a vanilla GNOME or KDE installation (eg. on Fedora), the problem 
doesn't show for most people since Gnome Terminal and Konsole both use 
custom fonts by default (Konsole uses Hack, which I liked a lot and 
ended up using in XTerm on my machines).

On Debian, Gnome Terminal (I don't know for Konsole) uses whatever is 
defined by fontconfig as the default font for the "Monospace" alias 
(e.g. Noto Sans Mono now).

>> Using this one (which I now believe is the "real" monospace font from
>> Noto) as default for the monospace family does fix both Xterm and
>> gnome-terminal (and probably other terminals too).
> 
> So you have found that the older Noto Mono font looks better in 
> terminals than Noto Sans Mono. That's interesting.

Please see the attached screenshots.

GnomeTerminalNotoSansMono11Default.png shows the default look of Gnome 
Terminal ("Monospace" alias, e.g. Noto Sans Mono with current fontconfig 
defaults). As you can see, the horizontal spacing is somewhat right, 
making the text not-so-hard to read, but the vertical spacing is messed 
up, resulting in a square-shaped terminal, which is very different than 
what we are used to since several decades.

XTermNotoSansMono8Default.png shows XTerm also configured to use the 
"Monospace" TrueType alias as default font (e.g. Noto Sans Mono with 
current fontconfig defaults). As you can see, here both the horizontal 
and vertical spacings are ugly, resulting in very-hard-to-read text, not 
mentioning the fact that the terminal is huge, despite the default font 
size of 8.

Other screenshots show the same applications explicitly setting Noto 
Sans (e.g. not trusting the default "Monospace" alias), and DejaVu Sans 
Mono (equivalent to their default looks before upstream fontconfig 
switched the default from DejaVu to Noto).

I don't think that it's only a personal feeling, the current defaults 
are objectively ugly.

> In any case I'm pretty sure that there is no typo in 60-latin.conf, so 
> your patch is based on false premises.

Maybe the word "typo" was not appropriate. fontconfig uses by default 
Noto Sans Mono for monospace, which would seem natural since it's the 
one which is still maintained and still distributed in the default Noto 
archive upstream, unfortunately, it's currently defective and 
consequently not suitable as a default monospace font, for the reasons 
detailed above.

I maybe wrong, but I guessed upstream fontconfig developers knew that, 
hence the use of the word "typo", but it's more like an overlook (maybe 
they don't know at all that Noto Sans Mono is defective).

> But with that said, if other users are of the same opinion as you, it 
> may be motivated to consider a Debian patch as regards the default 
> monospace font for latin scripts. Personally I can think that going back 
> to DejaVu Sans Mono should should be a more natural step, in that case. 
> Noto Mono isn't even mentioned in 60-latin.conf.

IMHO, if Debian wants to follow the upstream fontconfig default to use 
the Noto fonts, the system should work without the DejaVu packages 
installed, so it would make more sense to patch fontconfig to use Noto 
Mono as a default and keep the "Noto look" across the whole system, than 
to go back to DejaVu Sans Mono. Also, like I said, maybe upstream 
fontconfig developers don't even know that Noto Sans Mono is defective, 
hence my initial suggestion to forward the fix upstream.

Of course the best would be to make Google fix Noto Sans Mono, but since 
the bug was reported several times (at least 2 IIRC when I searched back 
then) and never fixed, it seems that this is very very low in their 
to-do list.

There is still another problem though. fontconfig-config allows several 
alternatives (fonts-noto-core | fonts-dejavu-core | etc), but 
fonts-noto-mono (which ships both Noto Sans Mono and Noto Mono) is not 
pulled as a dependency, which makes fontconfig-config advertise a 
default Monospace font which the package doesn't depend on, whether it's 
Noto Sans Mono, Noto Mono or DejaVu Sans Mono.

With DejaVu there were no problem : fonts-dejavu-core used to ship 
DejaVu Sans Mono, and now that's it packaged separately, it's still 
pulled as a dependency (fonts-dejavu-core depends on fonts-dejavu-mono). 
I wonder why that's not the case with Noto. This should be fixed as well.

This dependency problem rarely shows, since a lot of packages pull both 
DejaVu and Noto fonts (libreoffice for example), but on a minimal 
system, current fonctconfig dependencies are fundamentally broken.

tl;dr

IMHO, the best choice would be to acknowledge that Noto Sans Mono is 
broken, and fix fontconfig to use Noto Mono as default Monospace font, 
either in Debian or upstream, and make noto-fonts-core depend on 
noto-fonts-mono. This would result in a consistent look (Noto) across 
the whole system, fix current broken fontconfig dependencies, and allow 
a minimal system to work without DejaVu. The divergence from upstream 
fontconfig would be minimal, or even non-existent (if they also 
acknowledge that Noto Sans Mono is broken, and agree to apply the fix).

Alternate fixes would be to completely diverge from upstream fontconfig, 
and go back to DejaVu for all variants (Monospace, Serif and Sans), and 
also go back to fonts-dejavu-core as the default alternative : 
consistent look (DejaVu), working dependencies, but a huge divergence 
from fontconfig upstream.

The worst choice (still IMHO) would be what you suggested, that is, 
partially diverge from upstream fontconfig, and go back to DejaVu for 
Monospace only, and unconditionally pull fonts-dejavu-mono (in addition 
of whatever alternative is chosen for the core fonts). This would result 
in a non-consistent look, working but heavier dependencies (suboptimal 
for a minimal system), and still a divergence from fontconfig upstream 
(albeit small), which they probably won't want to apply, since they 
agreed to use Noto as a default a long time ago.

Regards,

-- 
Raphaël Halimi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GnomeTerminalNotoSansMono11Default.png
Type: image/png
Size: 75994 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XTermNotoSansMono8Default.png
Type: image/png
Size: 33598 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GnomeTerminalNotoMono11.png
Type: image/png
Size: 73162 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XTermNotoMono8.png
Type: image/png
Size: 32685 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GnomeTerminalDejaVuSansMono11.png
Type: image/png
Size: 71733 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XTermDejaVuSansMono8.png
Type: image/png
Size: 31466 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20230817/cb4ed9ee/attachment-0011.png>