Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY))

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Thu, 21 May 2020 16:26:13 +0000
> Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org
> 
> On Thu, May 21, 2020 at 2:11 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Pip Cet <pipcet@gmail.com>
> > > Date: Thu, 21 May 2020 10:01:03 +0000
> > > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org
> > > > but
> > > > if we really want this only for these limited cases, we will need to
> > > > somehow indicate to the display engine which ligatures are to be
> > > > handled like this and which aren't.
> > >
> > > Well, we now know that fonts can provide information about how a
> > > ligature is to be split into one-dimensional slices;
> >
> > The question is: do we want to show those carets for all the character
> > compositions, even if the information is provided?  If not, we will
> > have to indicate somehow whether they should or shouldn't be shown for
> > each particular grapheme cluster.
> 
> Oh. I hadn't thought about fonts providing such caret information in
> cases where they shouldn't, but of course that's a valid concern.
> 
> > > Of course that means that Emacs behavior would depend on the font
> > > tables in ways it currently doesn't. That's a problem.
> >
> > It isn't a problem to depend on that if most fonts provide this
> > information.
> 
> > Then we could simply say this is not supported when the
> > information is not in the font.
> 
> I'm not sure how simple that would be: we could treat ligatures
> without carets as atomic, or we could tell harfbuzz not to apply
> ligatures without carets, or maybe make that decision depend on
> whether the ligature is required or discretionary...
> 
> > But if many fonts that support
> > ligatures don't provide this information, we will need to have some
> > fallback, like assume that every codepoint has the same share of the
> > ligature's width.  the fact that other applications use a simplistic
> > heuristic and not the information in the fonts suggests that either
> > the information is not readily available or there are some other
> > problems with using it.
> 
> Correct, it does. I'm not sure which one is the case.
> 
> > > > Right, the actual implementation will have to be different.  In
> > > > particular, I think that if ligatures will use automatic compositions,
> > > > the information you need is already stored in the composition table
> > > > and reachable from the glyph string, so you don't need to invoke the
> > > > shaper again.
> > >
> > > Well, I'm sorry to bring up a different (though somewhat related
> > > issue), but kerning is also an issue: we need a shaper to get that
> > > right, not just a composition table, right?
> >
> > Automatic compositions already use the shaper, see autocmp_chars.
> 
> I'm not sure I understand how kerning would work using automatic compositions.
> 
> > > > I see you implemented this for static compositions, which are
> > > > semi-obsolete.
> > >
> > > I'm sorry, I'm afraid I don't understand. This should handle any
> > > composition the shaper does, and only those, but slices up everything
> > > horizontally by default.
> >
> > I'm talking about the changes in gui_produce_glyphs.  Its high-level
> > structure is basically
> >
> >   if (it->what == IT_CHARACTER)
> >     {
> >     ... /* handles character glyphs */
> >     }
> >   else if (it->what == IT_COMPOSITION && it->cmp_it.ch < 0)
> >     {
> >     ... /* A static compositions. */
> >     }
> >   else if (it->what == IT_COMPOSITION)
> >     {
> >       /* A dynamic (automatic) composition.  */
> >     }
> >   [...]
> >
> > You made changes only in the "static compositions" part.
> 
> No. I didn't touch the "static compositions" part at all, except for
> passing an extra NULL pointer to an API I'd extended. (At least,
> that's what I intended, for all the changes to be in the IT_CHARACTER
> part).

I mean this part:

  @@ -30433,8 +30483,9 @@ gui_produce_glyphs (struct it *it)
		else
		  {
		    get_char_face_and_encoding (it->f, ch, face_id,
  -					      &char2b, false);
  -		  pcm = get_per_char_metric (font, &char2b);
  +					      &char2b, false,
  +					      make_context (it));
  +		  pcm = get_per_char_metric (font, &char2b, make_context (it));
		  }

This calls make_context and passes it to these functions.  This code
handles static compositions only.

> > The "modern" way of composing text in Emacs uses automatic
> > compositions, which are controlled by data in
> > composition-function-table.  This is where we call the shaping
> > engine to produce the glyphs according to rules stored in the
> > font.  I don't see in your patch any changes that affect ligatures
> > created by automatic compositions; did I miss something?
> 
> I don't think so; I went for a third route, that of leaving all
> compositions handling to the shaper and doing none of it in Emacs
> itself.

But automatic compositions do work by calling the shaper.

> Perhaps I can digress a little and describe what I think the
> interaction with the shaper should be like:
> 
> Emacs: I'd like to display codepoint 'f'
> Harfbuzz: you'll have to tell me the codepoint before that
> Emacs: 'f'
> Harfbuzz: and the one after those two
> Emacs: 'i'
> Harfbuzz: and the one before all of those
> Emacs: That's too expensive for me to compute / it's the beginning of
> paragraph / a bidi boundary / an object without an assigned codepoint
> / ...
> Harfbuzz: okay, display it as the middle slice of the "ffi" glyph
> 
> I.e., I'd like Harfbuzz to be asynchronous, and request more
> information, parsimoniously, about the context of the codepoint we're
> describing, rather than working in one go from "complete" information
> to an indefinitely-long line of glyphs. And deal well with us deciding
> it's too expensive to perform that much look-back/look-ahead. (Because
> in real life, ligatures depend on knowing some amount of the context,
> but not all of it, or people could never start writing.)

That would prevent Emacs from controlling what is and what isn't
composed, leaving the shaper in charge.  We currently allow Lisp to
control that via composition-function-table, which provides a regexp
that text around a character must match in order for the matching
substring to be passed to the shaper.  We never call the shaper unless
composition-function-table tells us to do so.

I'm not sure I understand what problems do you see with this design.