[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 ;-)
- Re: Ligature support, (continued)
- Re: Ligature support, Eli Zaretskii, 2021/11/05
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/05
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/05
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/05
- Re: Ligature support, Eli Zaretskii, 2021/11/06
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/06
- Re: Ligature support, Eli Zaretskii, 2021/11/06
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/06
- Re: Ligature support,
Eli Zaretskii <=
- Re: Ligature support, chad, 2021/11/12
- Re: Ligature support, Richard Stallman, 2021/11/14
- Re: Ligature support, Stefan Kangas, 2021/11/15
- Re: Ligature support, Richard Stallman, 2021/11/17
- Re: Ligature support, Eli Zaretskii, 2021/11/15
- Re: Ligature support, Eli Zaretskii, 2021/11/06
- Re: Ligature support, Lars Ingebrigtsen, 2021/11/06
- Re: Ligature support, Eli Zaretskii, 2021/11/06
- Re: Ligature support, Benjamin Riefenstahl, 2021/11/06
- Re: Ligature support, Eli Zaretskii, 2021/11/06