Re: Entering emojis

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 28 Oct 2021 17:06:56 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: mattiase@acm.org, raman@google.com, schwab@linux-m68k.org, 
>     stefankangas@gmail.com, emacs-devel@gnu.org
> 
> >> Given the limited available manpower in that narrow subfield, I'm not 
> >> quite sure it was the best thing to do.  Using a font with predefined 
> >> ligatures is much easier to enter text.
> >
> > I think the issue is not whether the font delivers ligatures or not, the 
> > issue is whether the font recognizes the sequences which should produce 
> > either ligatures or series of glyphs with offsets, when the formatting 
> > controls are in the sequence.  It sounds like the existing fonts don't 
> > recognize such sequences for what they are supposed to produce.
> 
> This is not how ligatures work.  Ligatures automatically translate a 
> sequence of characters into an appropriate glyph, which may or may not be 
> a combination of other glyphs.  For example, the Computer Modern font 
> translates the two-character sequence "fi" into a character which looks 
> better than "f" followed by "i".  If for some reason you don't want that 
> ligature to take place, you write "f{}i" (in TeX), and you get "f" 
> followed by "i".

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.

> >> But it's not a joiner, it's a non-joiner.  The logic is the opposite of 
> >> what Unicode decided to do: known quadrats are automatically recognized 
> >> and combined appropriately when their individual characters appear one 
> >> after the other in a string.  It's only when you want to avoid this 
> >> that you have to add a non-joiner.
> >
> > That's not what the Unicode Standard says.
> 
> I don't know what you mean by this.

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.

> With the ligature logic, to enter "em-hotep", which is composed of four 
> characters, you just enter these four characters: G17, R4, X1, Q3.

Which then means that you cannot write anything where these 4
characters are displayed in an arrangement different from that
particular one that's encoded in the font, unless you use non-joiners.

> I don't know.  The problem is that the sequence of egyptian characters in 
> etc/HELLO that are displayed correctly by hb-view and LibreOffice (and 
> that are included in my patch) is for some reason not displayed correctly 
> by Emacs, even with the recent Aegyptus font installed.  Are ligatures 
> disabled for some reason in Emacs?

No, they aren't.  In Emacs, ligatures are just part of character
composition, they aren't a separate feature.

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?

diff --git a/lisp/language/misc-lang.el b/lisp/language/misc-lang.el
index a2ca678..141349a 100644
--- a/lisp/language/misc-lang.el
+++ b/lisp/language/misc-lang.el
@@ -192,7 +192,12 @@ egyptian-shape-grouping
    composition-function-table
    #x13437
    (list (vector "\U00013437[\U00013000-\U0001343F]+"
-                 0 #'egyptian-shape-grouping))))
+                 0 #'egyptian-shape-grouping)))
+  (set-char-table-range
+   composition-function-table
+   '(#x13000 . #x1342E)
+   (list (vector "[\U00013000-\U0001342E]+"
+                 0 #'font-shape-gstring))))
 
 (provide 'misc-lang)