[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ligature support

From: Eli Zaretskii
Subject: Re: Ligature support
Date: Sat, 06 Nov 2021 09:12:59 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 05 Nov 2021 23:38:12 +0100
> Heh; there's some glitches here -- the leftmost swoosh is so extensive
> that it doesn't paint it correctly, and:
> Entering some spaces at the start doesn't clear up all the artefacts.

Probably some display glitches because we don't expect characters to
reach so far to the left.

Note, however, that displaying this correctly will slow down
redisplay, because any change in the "swish" area will need to redraw
all the characters of that word.  This will be in particular painful
when the only change is that cursor moved in the same screen line:
we'd probably need to disable one of the more powerful redisplay
optimizations we have.

> > I think we rather need to have a (minor) mode which uses those, and
> > under that mode we do want to pass these strings to HarfBuzz.  If the
> > default font doesn't support the corresponding ligatures, we display
> > the literal strings.  It is then up to the user to install the right
> > font and tell Emacs to use it (via some face, I guess).
> Yes and no.  There's no limit to the number of these strings that fonts
> support, so if this hypothetical minor mode were to "list them all",
> it'd basically be the same as running all text through harfbuzz.  Which
> we don't want to do in general.  Ergo the need to have a per-font
> ligature table.

I don't necessarily agree with the conclusion.  The list of ligatures
will have to be customizable, that's a given.  Thus, the user will
always be able to add/remove ligatures.  Whether we should have a
built-in tool to show all the ligatures supported by a font is an
orthogonal question, because there are (external) tools out there to
do that, and we don't have to duplicate their functionality.  (I also
think that the list of ligatures depends on the script and the
language, so the response to such a query is not necessarily a single

This is not, and should not be, the area of our expertise.  We
delegate that to a shaping engine for a good reason.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]