Re: Composed Sequences

[Richard Wordingham]

On Sat, 26 Feb 2022 08:33:35 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 26 Feb 2022 00:28:37 +0000
> > From: Richard Wordingham <richard.wordingham@ntlworld.com>
> > 
> > I still haven't found the code where the difference occurs, but I
> > now have a better idea of what is going on.  It seems that runs
> > with the same value of the composition property ('composed
> > sequences') are sequences of clusters for the font that match a
> > regular expression given in composition-function-table.  
> 
> (Please don't use "composition property" in this context, because it's
> confusing: the 'composition' text property does exist in Emacs (it's
> an old and now deprecated way of composing characters), but it is not
> relevant to this discussion, which instead focuses on what is known in
> Emacs as "automatic composition".)

Ah, I've misinterpreted some of the code.

> > Different renderers give different clusters, and thus, by default,
> > different cursor motion!  

> Not "different renderers", but "different fonts".

I experimented with the Tai Tham composition-function-table entry

(list (vector "[\u1a20-\u1aad]+" 0 'font-shape-gstring))

For GNU Emacs 23.4.1 (i386-mingw-nt6.2.9200) using Uniscribe, the word
ᨠᩣ᩠ᨿ <1A20 HIGH KA, 1A63 AA, 1A60 SAKOT, 1A3F LOW YA>, the glyph string
for Version 0.8 of my font Da Lekh is divided into two
clusters as identified by the 'glyph' values [0 1 6688...] [0 1
6688...] [2 3 6752...] and confirmed by ordinary cursor motion.  While
this division into <1A20, 1A63> and <1A60, 1A3F> is not the Unicode
division into grapheme clusters, it accords with what are natively
namable clusters.

For GNU Emacs 27.1 (build1 i686-w64-mingw32) of 2020-08-21, which uses
HarfBuzz, the same word is one indivisible cluster (at least with
Version 0.13 of the same font).  I think this is a change in the
behaviour of HarfBuzz.

So should also depend on the clustering by the rendering engine.

> > The reason Arabic seemed different is that when lam+hah appears to
> > ligate, what is happening (at least with Amiri) is that
> > substitutions are made which give the effect of a ligature, while
> > remaining two distinct glyphs.  

> Yes, I see that as well.  "C-u C-x =" should tell you whether ligation
> happened or not.  What you see is normal, I think: Emacs obeys the
> decisions of the font designers.

Unless they recorded the positions of the boundaries between the parts
of a ligature!  (There is such a facility in the GDEF table, but it is
very widely ignored, and so a consumer would have to check its quality.)

Richard.