Re: Supporting stylistic sets

[Eli Zaretskii]

> From: Nicolas Ouellet-payeur <nicolaso@google.com>
> Date: Mon, 26 Sep 2022 12:35:34 -0400
> Cc: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>, 
>       emacs-devel@gnu.org
> 
> > To measure the slowdown, run the benchmark of scrolling through a
> > large file, like xdisp.c, one line at a time, and compare with the
> > current code.
> 
> It's not as bad as I feared, but it's still pretty bad. Scrolling 2000
> lines through xdisp.c is ~2.3x slower in the patched version. The jank
> is noticeable though, especially because scrolling *should* be limited
> by the keyboard repeat rate.

I think you tried a relatively benign situation.  To see how this
could _really_ be slow, make a composition rule that will catch any
sequence of any non-whitespace characters.

This slowness is the main disadvantage of our current method of
handling character compositions.  (It also has numerous advantages.)
If we want to progressively increase the use of text-shaping engines
when rendering text, we will need to redesign this part, because the
way we do this now cannot be extended in those directions without
causing significant slowdown.

> > But what do you do if the user wants to disable ligation, or control
> > which ligatures should and shouldn't happen?
> 
> To disable ligation, one can turn off font features selectively. For
> instance disabling 'rlig' in Fira Code disables the code ligatures. We
> could disable it by default on the mode-line, for instance. Or just a
> section of the default mode-line.

That would disable ligation in complex script shaping, where it is a
must.  For example, displaying the Arabic script requires ligatures.
So I think disabling ligation this way is unworkable; we must find
some other ways of doing that.

> - Ignore the shaping engine. Read the GSUB table from the font file
>   ourselves, and populate `composition-function-table' with that.
>   Supporting *everything* is really hard, but basic use-cases might work
>   fine out-of-the-box.

That's a non-starter, IMO.  We don't want to develop our own
font-related and text-shaping-related capabilities, as it's not our
expertise and we will never be able to have enough knowledge and
development resources to do it.  We must rely on external shaping
engines such as HarfBuzz.

> - Give up on OOTB ligature support (status quo).

The status quo is NOT that we don't support ligatures.  The support is
available; you can have it at the price of a few minutes' work by
installing the composition rules in composition-function-table.  What
is missing is a convenient interface and UI for users to control where
and which ligatures will be available.  See the related TODO item.