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

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Sun, 17 May 2020 16:28:30 +0000
> Cc: Julius Pfrommer <address@hidden>, address@hidden
> 
> On Sun, May 17, 2020 at 3:56 PM Eli Zaretskii <address@hidden> wrote:
> > > Date: Sun, 17 May 2020 16:59:53 +0200
> > > From: Julius Pfrommer <address@hidden>
> > > Cc: address@hidden
> > Next, please be aware that we already made the decision to use
> > HarfBuzz as our main text-shaping engine.
> 
> That's a decision that, having just played with HarfBuzz, I find
> puzzling. It appears to have no practical support for treating
> ligatures as anything but monolithic glyphs: is there a documented way
> of getting HarfBuzz to tell you which part of the "ffi" ligature is
> the middle "f"?

You are accusing HarfBuzz of crimes it didn't commit ;-)  What you see
is not produced by HarfBuzz, it's produced by Emacs.

HarfBuzz (and any other text-shaping engine we ever used) has a very
simple job: Emacs hands it a string of codepoints, and HarfBuzz
returns a series of font glyphs to be used to display that string.
That's all.  All the rest is the Emacs display engine.

And yes, the current design is that a ligature (like any other
"grapheme cluster" produced by character composition) is a single
"display element": you move across all of it with a single C-f/C-b.
The only exception to this rule is that we allow DEL (but not C-d or
Delete) to erase individual codepoints going back from the end of the
grapheme cluster -- to facilitate editing ligatures and other composed
characters.  This is the minimum "editing" capability that the user
must have, and I don't think I've heard complaints that it wasn't
enough.  But if required, we could easily add special forward and
backward movements that could "enter" the composed character, we just
need to figure out how to display the result in order to give the user
some visual feedback.  (Without visual feedback, I think you can have
it today if you customize global-disable-point-adjustment to a non-nil
value.)

In any case, the question "which part of the ligature corresponds to
some codepoint" is meaningless in the context of ligation and complex
text shaping: a sequence of N codepoints in general produces M font
glyphs, where M can be smaller, equal, or greater than N.  The
relation between the N codepoints and M glyphs is many-to-many.

> I'm not sure PangoCairo does better, but whatever Libreoffice uses
> appears to get the job done

What job is that?

> (This is assuming we want kerning, ligatures, and subpixel rendering
> for English text. "Real" text shaping, composition, reordrant glyphs,
> and bidi concerns are something that I can't really comment on, beyond
> admitting that, of course, supporting the world's major languages at
> all is more important than supporting English with the typographic
> finesse we currently lack).

The truth is that "we" the Emacs project don't want to know anything
about ligatures, we want to delegate that job to the shaper.  That's
the shaper's job, and HarfBuzz does its job very well and stays on top
of the relevant technological advances.

> Years ago, I ran a WebAssembly version of Emacs in a web browser.
> (Back then, I used a terminal emulator written in JavaScript.) I'd
> certainly like to do that again some day, and I think a hard
> dependency on Cairo and FreeType would make that even harder.

I think there's some measure of confusion here: AFAIR we don't use
Cairo for text shaping, only for its display.  IOW, we tell Cairo to
display this and that glyphs, after HarfBuzz returned them.