Re: Entering emojis

[Eli Zaretskii]

> Date: Thu, 28 Oct 2021 21:10:41 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: mattiase@acm.org, emacs-devel@gnu.org, schwab@linux-m68k.org, 
>     stefankangas@gmail.com, raman@google.com
> 
> > Yes, I know.  But ligatures are not the only way of handling this. When 
> > a font produces a ligature, i.e. a precomposed glyph that should be 
> > displayed instead of several characters, it produces a single font 
> > glyph.  The other way is to produce several font glyphs, each one with 
> > offsets relative to the base-line.  Emacs supports both ways. However, 
> > for any of the two to work, both the shaping engine and the font should 
> > recognize the sequence, and the font should produce one or more glyphs 
> > with the offsets for that sequence.
> 
> In this case, ISTM that the problem is not the font, but the shaping 
> engine.  If Harfbuzz does not know how handle the joiners and segment 
> delimiters, it should behave as they did not exist, and use the font 
> ligatures (if the font does have ligatures)

AFAICT, this is what happens here.

> instead of displaying the fictitious glyph at that codepoint (at the
> codepoint of the joiner or delimiter).

I don't think I understand what fictitious glyph you allude to here.
The joiners were displayed as thin spaces by the Emacs
glyphless-char-display feature, because HarfBuzz+font didn't compose
the sequence, and returned the separate font glyphs for each codepoint
in the sequence.  IOW, the composition failed, and therefore Emacs
displayed each of these characters as it's supposed to do.

> If it knows how to handle joiners and delimiters, it should ignore
> the font ligatures and create the final glyph with the individual
> glyphs in the font.

This doesn't happen in general, only in some very specific cases,
where the HarfBuzz developers decide to implement a fallback strategy
of this kind.  In the general case, HarfBuzz (and any other shaping
engine) recognizes the sequence, and looks into the font tables for
how to display that sequence; it then returns one or more font glyphs
from the font information about that sequence.  It only "ignores" the
font glyphs when some reasonable fallback is required, which is
generally avoided, because it's assumed that the font designers know
better.

> > I mean what the Unicode Standard says: it says that two hieroglyphs 
> > should be displayed "normally", i.e. as separate characters at the same 
> > vertical position, unless there's the vertical joiner between them, in 
> > which case one should be above the other.
> >
> 
> I understand.  But what the standard says doesn't make sense I think, 
> because it means that it requires one to ignore font ligatures and instead 
> requires one to use joiners and segment delimiters.

No, the joiners are supposed to tell the shaping engine and the font
that we want the ligatures and not separate font glyphs.

> > However, the composition rules I defined went with Unicode, and need to 
> > be fixed to support what the Aegyptus font does.  Does the patch below 
> > help?
> >
> 
> It does!  Thanks.
> 
> Here's a combined patch, with the comment you asked.

Thanks, installed on the release branch.