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

[Pip Cet <pipcet@gmail.com>]

On Fri, May 22, 2020 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Fri, 22 May 2020 09:25:31 +0000
> > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org
> >
> > > > should work, but it has weird side effects that I'm pretty sure aren't
> > > > intended (paren highlighting is broken, for example).
> > >
> > > This is not the right way.
> >
> > What is the right way, then? I want all ligatures my font supports.
>
> You can request all the ligatures that _can_ be supported;

How do I do that? Opentype fonts can support arbitrary ligatures, such
as "Zapfino" being a seven-letter ligature.

> those which
> aren't available in the font you use will not be ligated (if you use
> font-shape-gstring in the composition-function-table slot).

> Or you can request only those ligatures that make sense for the
> particular use case.

My use case is English text, and all ligatures supported by the font
make sense for that.

> For example, when displaying program source code
> you'd probably want the various symbols, like -> etc., to produce
> ligatures, but you most probably won't want "ffi" in a variable name
> to produce a ligature.

Why not?

> Or you can provide your own function to use in the
> composition-function-table, and that function can do more complex
> stuff, like refuse to ligate under some complicated conditions.

If that kind of thing turns out to be necessary, we can find ways of
doing it, such as setting a text property with harfbuzz feature
strings to be applied when rendering.

> Therefore, I think letting Lisp programs (and thus users) control what
> gets composed into ligatures and what doesn't is an important feature
> to have.

Okay, I can accept that requirement. But it should be possible to get
"all ligatures", rather than a finite set you know about in advance.

> We should develop it more, because currently it lacks some
> features we'd need for better ligature support (see the TODO item
> about that), but I think the basic design is valid.

The TODO item is confusing and, I believe, confused.

"For the list of typographical ligatures, see

  https://en.wikipedia.org/wiki/Orthographic_ligature#Ligatures_in_Unicode_(Latin_alphabets)"

That's very wrong: typographical ligatures generally aren't assigned
Unicode codepoints; those that have them usually do so for historical
reasons. There's no finite "the" list of typographical ligatures, it's
up to each font to define glyphs covering codepoint clusters as it
sees fit.

I disagree with pretty much every statement in the rest of the TODO item.

> At least I didn't yet see any evidence that it isn't valid;

But how do I make it work? For English/Western text with ligatures
that I don't know about in advance? Please treat this as a dumb
end-user question. What lines of Lisp do I enter to get all the
ligatures my font supports, most of which do not have individual
Unicode codepoints?

> > Also, even if it is the wrong thing to do, why does it break seemingly
> > unrelated things?
>
> I don't know.  Can you show how to reproduce that in the current
> codebase on master?  Then I'll look into it.

bug#41454

> > >   (set-char-table-range
> > >    composition-function-table '(?f . ?f)
> > >    (list (vector "ffi" 0 'compose-gstring-for-graphic)))
> >
> > > This shows how to do this only for the "ffi" ligature, but I think it
> > > makes the idea clear.
> >
> > I'm afraid it doesn't, to me.
>
> Doesn't make the idea clear or doesn't produce the ligature?

It doesn't make the idea clear, because I simply see no practical way
we're going to know about the ligatures the font provides in advance.