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

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Sat, 23 May 2020 15:13:38 +0000
> Cc: address@hidden, address@hidden, address@hidden
> 
> > > Calling the shaper less often is an important optimization, too. For
> > > whitespace-delimited words, we only need to call it once.
> >
> > This doesn't work when the produced sequence of glyphs doesn't fit on
> > the screen line.
> 
> > What the current layout code does in this case won't
> > work well when you need to break a long sequence of glyphs in the
> > middle and then continue on the next line from where you left off on
> > this one.
> 
> You mean in visual-mode?

Not just in visual-line-mode, but also for the default line
continuation.

> Because what the current layout code does by default is to break
> along any glyph boundary, and I don't see how that's broken in any
> way.

The code assumes that breaking on some glyph leaves the buffer
iterator ('struct it') in a state that we can simply continue to the
next buffer position.  But if you already picked up several characters
via look-ahead, that is not true, and you will have to return back
several character positions, in order to continue on the next screen
line.  The whole convoluted logic of display_line (and a similar one
in move_it_in_display_line_to) is based on the assumption that this
line-wrap decisions are made as soon as a single glyph is produced;
that code will need to be rewritten if this assumption breaks.  And
since the code is already hairy, to say the least, I cannot even
imagine what it will look like after such rewriting.

This is just a small example of how deep are the current design
assumptions entrenched in the code.  I don't see how this can be
resolved to yield code that is readable and maintainable without
changing the design.  Again, maybe I'm missing something.

> > In short, I really don't see how this could ever work, except in a
> > very limited set of simple use cases.  E.g., what do you do with
> > bidirectional text? ignore it?
> 
> A bidi boundary is a hard boundary for HarfBuzz, and no shaping
> happens across it. Is that what you mean by "ignore it"?

I don't mean the boundary, I meant the fact that clusters need to be
reordered.

> > I don't see how it could work in production while supporting all the
> > use cases we already do.
> 
> It only comes in for use cases not handled otherwise, i.e. those where
> the iterator is at an IT_CHARACTER. All other use cases are
> unaffected, because they mean we're overriding the font decision
> anyway.

I see no reason to add such patches just to handle some simple enough
use cases.  If we want the shaper to handle all the text we display,
we should go all the way and do it for any text, ASCII, non-ASCII,
symbols, emoji, everything.  The current codebase is already very
difficult to understand and modify; you seem to suggest to make it
even more so, and on top of that solve only a small part of the
underlying problem.  That makes very little sense to me.