emacs-devel
[Top][All Lists]
Advanced

[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 10:40:11 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 06 Nov 2021 06:23:27 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > 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.
> 
> Well, that doesn't follow.  Once we have a way to dump the ligature
> tables, we know what ligatures the fonts the user has loaded have (in
> total).  A typical user won't be loading more than a handful of fonts,
> so the number of ligatures at any point won't be more than a few
> hundred.
> 
> And since it's harmless (just takes a bit more time) to give a sequence
> to hb_shape for a font that doesn't have the ligature, we don't need a
> per-font thing.

I think this is a premature conclusion.  For starters, it sounds like
you are thinking only about ASCII ligatures?  Non-ASCII scripts have
ligatures as well; in fact, in some of them we already pass all the
text to the shaping engine, because that's the only way of producing
display that users of those scripts will consider valid and legible.

And why assume people will not want to disable some ligatures for some
fonts, for example if they look ugly?

More generally, we don't yet have a complete enough idea about use
patterns and wishes of users wrt ligatures in various contexts.  At
least two separate contexts should be considered: source code (where
ligatures are normally limited to operators and symbols) and
human-readable text (where people may want the typographical
ligatures).

As for "a bit more time", I think that conclusion is also premature;
I've just shown a benchmark where it is more like "a lot more time".

> The primary thing here, though, is to get at the ligature data in an
> efficient manner.

I guess nothing I can say at this point will convince you this is NOT
the most important part, so I'll just shut up ;-)



reply via email to

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