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

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Tue, 19 May 2020 21:43:49 +0000
> Cc: Eli Zaretskii <address@hidden>, Alan Third <address@hidden>, 
> address@hidden
> 
> And I'm afraid the difference is much more obvious with box cursors
> than it is with carets. I'm attaching a screenshot of a patched Emacs
> displaying "ffi", with point on the second f, in the "Linux Libertine
> Display O" font (using approximately equal slices).
> 
> I think this is a bit of a worst-case scenario, a three-letter
> ligature in a font using ligatures and overhangs very
> enthusiastically. It might be okay for other fonts.

I'm not sure this is the worst case.  It might be the worst case if we
are talking about ligatures that involve only ASCII characters, and
don't involve symbols like ==> that gets converted to ⇒.  But in
general, there are worse cases, like á (two codepoints).  And for
kicks see the Khmer hello in etc/HELLO, where you can find 4
codepoints that produce a grapheme cluster made of 3 glyphs.

If we only want this feature for ASCII ligatures, then it sounds like
a limitation to me (and frankly, somewhat unclean as features go), but
if we really want this only for these limited cases, we will need to
somehow indicate to the display engine which ligatures are to be
handled like this and which aren't.

> My remaining idea is to stretch characters so we can break up a
> ligature without changing its total width. I'm not sure how to do
> that, though.

I don't think I understand what you'd like to do.  Can you elaborate?

> (I'm also attaching the patch, for the morbidly curious; it isn't
> clean, readable, or finished in any way, and contains at least one
> obvious bug. It's just good enough to produce the screenshot, and
> maybe it can serve as a hint as to which files need changing for
> ligatures to work; but such changes would have to be done very
> differently from the patch.).

Right, the actual implementation will have to be different.  In
particular, I think that if ligatures will use automatic compositions,
the information you need is already stored in the composition table
and reachable from the glyph string, so you don't need to invoke the
shaper again.

I see you implemented this for static compositions, which are
semi-obsolete.  Also, I don't see the code which moves point inside
the ligature; Emacs will not allow doing that by default.  In
particular, how did you tell the display code to show the cursor on
the middle 'f', not on the first one?  Did I miss something?

And finally, you said you intended to do this via row->clip, but this
patch does something very different.  What changed your mind?

Thanks.