Re: Suggest installing more fonts?

[Eli Zaretskii]

> Date: Sat, 17 Oct 2020 19:18:25 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 
> > But the "bitmap" in this case is a font glyph.  So to get at that glyph, 
> > we would need to have the code that is already in the library we use for 
> > accessing fonts, is that what you have in mind?  So we'd need to have 
> > the code which understands how font files are structured, and how to 
> > find in them the glyph(s) for a certain character given that character's 
> > codepoint, and how to know whether the font has a glyph for that 
> > character to begin with?
> >
> > For example, look at xftfont_open, which is one implementation of how to 
> > open a font.  Count the number of functions and variables whose names 
> > begin with "Fc" -- those are references to the Fontconfig library. 
> > Under your proposal, we'd need to implement all that in our own code, is 
> > that right?
> 
> I don't understand why you think we would need something complex.  We 
> don't need it.  Unifont has the simplest format you can imagine: a 
> sequence of bitmaps.

Even for such a simple file, and even if we believe the file will not
change, there's a lot of code to write, maintain and test, code that
already exists in the libraries we use.  For example, how do you know
which characters are in Unifont and which aren't? this is a very basic
capability that any font backend used by Emacs is required to have.
Even if we want to write code to access Unifont "by hand", we still
need to do that within the framework of how Emacs deals with fonts.

> > So we will code a special font "backend" that is tailored to what 
> > Unifont has in its files now, and on top of that support this only for a 
> > single size of the default font, i.e. no support for "C-x +", no support 
> > for specifying a different size in default-frame-alist, etc.? And then 
> > we will have to maintain this code when Unifont changes something in its 
> > files?  I'm sorry, but this makes very little sense to me, especially 
> > with an ugly font such as Unifont.
> 
> The format of Unifont hasn't changed since it was created, about 25 years 
> ago, and it will not change in the future (because this format is part of 
> its design principles).

What about the contents -- do they also not change?  If they do, we
will need to know how to read the data and how to adapt to changes in
the contents (e.g., when glyphs are added/removed from the font).

> But you are so reluctant to this idea that I don't think it is useful to 
> continue this discussion.

I'm reluctant to reinvent the wheel that others already invented, and
to maintain code that is already maintained by experts in this area,
yes.  It is not an efficient use of our scarce resources.

> I only tried to propose something to improve Emacs, so that it would
> behave in a more user-friendly way when it is asked to display a
> character for which it has no fonts.

I appreciate the motivation, but the way to improve Emacs in this area
is not by using Unifont, let alone "manually" handling it.  Much
better solutions exist, we just need to understand the problems well
enough, find their solutions, and improve/extend Emacs to incorporate
those solutions.  Computer typography is a fast-advancing field of
technology, we just need to take advantage of those advances in a
timely manner.  One reason for migrating our main font backends to
HarfBuzz was that it allows us to follow those advances much more
easily.