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

[Pip Cet]

On Sun, May 17, 2020 at 5:00 PM Eli Zaretskii <address@hidden> wrote:
> > 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.

I don't think that's true.

> 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.

HarfBuzz also tells you which codepoints are used for which glyphs. It
should also, for languages where it can do so, tell you which
codepoints are used for which subglyphs. It fails to do the latter.

(I'm aware of what the Emacs display engine does; I'm, obviously, not
accusing HarfBuzz of failing to present ligatures, because that's
easily fixable. What isn't easily fixable is going back from the
ligature glyph to its subglyphs. LibreOffice does it, and I wonder
how, because the alternative is jumping back and forth between
ligatures and individual characters depending on where PT is, and that
looks horrible.)

> 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.

I'm using a different design :-)

That one is simply unworkable for English and its limited traditional
set of ligatures.

> 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:

No, it's not. It's meaningless for some languages, but not for English
and its limited set of traditional ligatures. That a problem cannot be
solved in general is no excuse to refuse to solve it in the specific
cases where it can be.

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

LibreOffice highlights sub-glyphs of ligatures correctly. I enter
"official", and it renders <o> <ffi> <c> <i> <a> <l>. I move the
cursor right twice, and it highlights precisely what it should, the
middle "f" of the ligature glyph.

> > (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.

I don't see how that's true. Treating a ligature as a single character
for entry purposes is simply unworkable for English. It might be okay
for other languages, but for English, we really need to display "ffi"
correctly and still allow it to be edited as three characters.

> That's
> the shaper's job, and HarfBuzz does its job very well and stays on top
> of the relevant technological advances.

I don't see any evidence for that positive statement about HarfBuzz:
out of the box, Emacs fails miserably to do anything about English
ligatures. Trying to find a way to fix it, I ran into HarfBuzz
limitations that appear to make it impossible to use it to deal with
English ligatures. It might deal very well with other languages and
their ligatures, but for English text, it fails to do what TeX did
since its inception.

> > 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.

Yes, that's correct. Which means that a WebAssembly version of Emacs
would need to bundle Cairo, even though it would prefer to simply
render things in the browser using HTML 5 canvases or something
similar.