Re: Suggest installing more fonts?

[Eli Zaretskii]

> Date: Sat, 17 Oct 2020 11:21:52 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> So IMO for these users it would be much better to display characters 
> >> with a low-resolution font, together with a warning (and perhaps a 
> >> pointer to a short guide) (as a help-echo and/or in the echo area), 
> >> instead of a tofu.
> >
> > Then the problem will become "Emacs uses an ugly font where other apps 
> > don't", and we are none the wiser.
> 
> _All_ apps have that problem, it is _not_ an Emacs-specific problem.

Let's keep the discussion in context, okay?  The context was the
complaints that Emacs displays tofu where other applications display
characters from installed fonts (which aren't GNU Unifont).  It is
those use cases that I was talking about.  Where Emacs behaves no
worse than other apps is in a different category.  More about that
below.

> FWIW, here is my solution for Emojis (on Debian, after installing the 
> fonts-noto-color-emoji package):
> 
> fc-match --format='%{charset}\n' NotoColorEmoji | tr ' ' '\n' | grep 
> '^[^-][^-][^-][^-]' | grep -v '^200d$' | sed 's/^/#x/;s/-/ . 
> #x/;s/^\(#[^#]*#[^#]*\)/!(\1)/;s/^\(.*\)$/(set-fontset-font "fontset-default" 
> \1 "NotoColorEmoji")/' | tr '!' "'"
> 
> This creates 154 calls to "set-fontset-font", and as a result 
> https://unicode.org/Public/UNIDATA/emoji/emoji-data.txt is displayed 
> nicely by Emacs.  I'm sure you will tell me that you don't like that 
> solution ;-)  But I doubt it is possible to do really better, because 
> Emojis are scattered across the whole Unicode code space.

The Emoji problem was already analyzed and a solution is in the works
which will not look anywhere like the above (setting up the fontset is
not enough, btw).  Let's move on to problems for which we don't yet
have a solution, okay?

> > IOW, using Unifont is simply a kind of admission of defeat: we don't 
> > really know why Emacs doesn't find a good font, so we take the easy path 
> > of providing _some_ font that will always work, albeit show ugly glyphs. 
> > I see no need to declare defeat, as we have facilities in Emacs to solve 
> > these problems in a better way, once we understand them.  We should 
> > therefore try to understand the problems better, and once understood, 
> > solve them properly.
> 
> The meaning of my proposal was, in fact, the exact opposite of an 
> admission of defeat, it was to make Emacs better in that respect than all 
> other apps.  Displaying a tofu is an admission of defeat, and it's what 
> all other apps do.

Using Unifont is a defeat in the sense that we don't do better by
finding a good font.  The Unifont "solution" is already in Emacs, see
the setting of fontset-default.  So if you are willing to settle for
Unifont, we already do that.  IMO, we should try to find ways to do
better than that.

> Another example: I have no fonts to display tamil characters on my 
> computer.  Which means every app, including Emacs, displays tamil 
> characters as a sequence of tofus.  I attach three pictures of the same 
> short tamil text displayed by Emacs, one with its current behavior 
> (tamil-no-font.png), one if it used Unifont as a fallback 
> (tamil-unifont.png), and one if a proper tamil font (the Debian package 
> fonts-lohit-taml) is installed (tamil-good-font.png).  I do agree (of 
> course) that tamil-good-font.png is better than tamil-unifont.png, but I 
> really can't understand how tamil-no-font.png could be considered better 
> than tamil-unifont.png.

Do you read the Tamil script (I don't)?  If not, we should ask someone
who does what they think about the Unifont glyphs.  (To my un-expert
eyes, the right-most glyph looks completely unrecognizable with
Unifont, but that's me.)

In any case, it is never a bad idea to try find better ways of
handling this situation than we already have.  For starters, I'm not
sure I understand what kinds of situation is it that the user wants to
read Tamil text, but the system isn't ready for that wrt installed
fonts.  When we understand the relevant use case, we might be able to
come up with useful features for them.  For example, perhaps we should
have a command to report on fonts suitable to display a certain script
or a certain block of Unicode codepoints -- it should be easy to write
such a command, and it could be advertised as something users should
run when they are about to start using a new script or range of
characters.  We could then provide some specific advice in the text
displayed by that command if no suitable fonts were found.