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

[Pip Cet <pipcet@gmail.com>]

On Sat, May 23, 2020 at 9:28 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 23 May 2020 08:44:22 +0000
> > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org
> >
> > You write: "(b) is not really feasible without redesigning the entire
> > Emacs display engine". I don't see how that's true at all. All we need
> > is some limited look-ahead.
>
> We already have look-ahead: that's what the regexp part of the
> composition rules are about.  That is not the crucial problem.

But it's the only problem I see! When you see an IT_CHARACTER, you get
some context, hand it to HarfBuzz, slice up the relevant glyphs, and
display them.

This is not complicated or difficult, except for the "get some context" part.

It doesn't involve composite.c at all, and that's good, because for
those tricky special cases composite.c does a better job than standard
shaping, and we need to keep that feature. It just shouldn't be the
regular route.

> The crucial problem is that we currently perform layout decisions one
> grapheme cluster at a time, whereas what HarfBuzz people say is that
> we should basically do that one screen line at a time.

I think we're going to have to compromise: that's why my patch used a
32-character context rather than an entire line or just a single
character.

Ideally, of course, in most real cases we'd use whitespace-delimited
words as chunks. That's mere optimization, though.

> A secondary (but important) problem is that character composition
> involves calls to Lisp, which is relatively slow.  This precludes
> calling the shaper for too many characters at once, too many times for
> each redisplay cycle of a window.

I agree we shouldn't go through Lisp. My patch didn't.

Calling the shaper less often is an important optimization, too. For
whitespace-delimited words, we only need to call it once.

> > I think at the heart of it, it's about whether we treat fonts like
> > pieces of software, to be given a specific task and fixed if they fail
> > to perform it, or as bitmaps for simulating a TTY. Fonts are software:
> > they're written in a weird limited language, but essentially they're
> > programs to measure and display characters as glyphs.
>
> I don't think there's any disagreements on this high and abstract
> level.

I think there are: if we treat fonts as programs, we need to let them
do their job, which involves kerning, substitutions, ligatures, and
even crazy stuff like randomizing the glyph used for each character to
get a more hand-written appearance. We don't need to know about
ligatures, we just let the font do it. No Lisp callbacks, just a call
to harfbuzz.


> The problem is how to support that within the limits of the
> current design of the display engine.