emacs-devel
[Top][All Lists]
Advanced

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

Re: Ligatures


From: Pip Cet
Subject: Re: Ligatures
Date: Mon, 18 May 2020 19:19:19 +0000

On Mon, May 18, 2020 at 5:18 PM Eli Zaretskii <address@hidden> wrote:
> > So, maybe we don't need very much info: all we need is a boolean which
> > tells us whether the glyph should be treated atomically or not.
> > When not treating it atomically, we would (somewhat arbitrarily) divide
> > the glyph horizontally into N equal sized "subglyphs" and draw the
> > cursor on the corresponding subglyph.
>
> That strikes me as not a very user-friendly UX.  Especially if you
> keep in mind that glyphs can be composed into a grapheme cluster using
> 2D offsets, not just left-right one-dimensional offsets.

So such clusters would be marked as atomic? I like Stefan's proposal,
and maybe it's what LibreOffice actually does: at large font sizes,
the horizontal division of "subglyphs" seems off.

> An alternative which might be nicer is to "split" the composition:
> display it as if a ZWNJ character was inserted at point.  Thus, moving
> forward one buffer position into the ffi would show f followed by a thin bar
> cursor followed by the fi; moving forward one more buffer position
> would show ff followed by a thin bar cursor followed by i.  Etc.

I tried something like that (with a variable-pitch font), and the
effect is nauseating because the rest of the line shifts as the width
of the word at point changes. What I tried was to use Harfbuzz to
shape entire words when PT is not in them, then split them up into
individual characters (the way it's done now) when PT enters them.

Of course, people might still like it.

> > If Harfbuzz could tell us more precisely how to divide the glyph into
> > subglyphs, we could do a better job, of course.
>
> I don't think it's possible because AFAIK fonts don't store this
> information.

Well, they should!

> It should be possible, of course, to have a private
> database of such offsets, but I don't really see how it could work in
> general.

And this is where it gets back to "let's not hardcode the dependency
on Harfbuzz and FreeType, because other backends might actually give
us the information we need".



reply via email to

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