bug#39799: 28.0.50; Most emoji sequences don’t render correctly

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: rpluim@gmail.com,  39799@debbugs.gnu.org
> Date: Sat, 29 Feb 2020 08:59:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> さんはかきました:
> 
> > If Gedit selects a font by looking at more than one codepoint (and I'm
> > not sure this is how it works in Gedit), then Emacs doesn't work that
> > way.
> 
> Yes, Gedit does this somehow with pango. It tries to avoid switching
> fonts in places where it would look bad. For example, if you have a
> default font supporting only ASCII and then there is a word containing
> some non-ASCII character like “grün” it chooses a font containing the
> “ü” for the whole word to avoid the “ü” looking out of place.

Well, "somehow" is not enough to see whether we have any additional
work to do in Emacs, because Emacs also tries to achieve that same
goal.  There are many different ways to achieve it, though; for
example, Emacs will AFAIK by default not even use a font that could
support ASCII, but not Latin-1 blocks as the default face's font.

What you say about Gedit makes sense in general, but questions
immediately pop up: how does Gedit define a "word" (Emacs, as you
know, has very a flexible definition that can be controlled from
Lisp), how does it "know" that a word like "grün" belongs to the same
script (otherwise displaying a character from another script using a
different font, as in, say, "grאn" might make sense), etc.

IOW, what we need is a detailed description of what Pango does here,
and how does Gedit affect that by configuring its default fonts.  Only
then we can reason about the differences between that and what Emacs
does.

> > In any case, are these sequences displayed as composed characters?
> > Does "C-u C-x =" tell that the base character U+24C2 was composed with
> > the following variation selector?  According to the setup in
> > japanese.el, they should compose, if the font used for U+24C2 also
> > supports the variation selectors.
> 
> Yes, it does tell that it was composed with the following character:

And the resulting display is what you expect?  If not, then I think
you need to find a font which supports Emoji presentation of
characters such as Ⓜ, and make Emacs use it for those sequences.

If you think this Emacs requirement for a capable font is incorrect, I
suggest to post a question about this to the HarfBuzz mailing list,
harfbuzz@lists.freedesktop.org, maybe HarfBuzz has capabilities in
this regard that we somehow don't yet utilize.