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

[Julius Pfrommer]

> First, we need to establish that this is a solution, and for what
> problem(s).  It is important to realize that the GUI backends we use
> handle much more than just drawing text, they need to be able to
> display GUI widgets, frame and window decorations (menu bar, tool bar,
> scroll bars, the frame title, etc.), and much more.

I am quite supportive of the native GUI toolkits.

Cairo is a vector-drawing library and only responsible for the "glass"
of each frame (called the "canvas" in other communities). All the
event-handling logic, menu-drawing, etc. is untouched by it.

> Next, please be aware that we already made the decision to use
> HarfBuzz as our main text-shaping engine.  X and w32 already use it;

Very good to see Emacs settle on HarfBuzz! Text-shaping touches into the
very core, as the glyph rendering impacts line-breaking, redisplay, and
so on.

> I don't think the answer will be full and definitive until "Someone"
> walks through all the APIs we implement in x/w32/ns/fns.c and
> x/w32/ns/term.c, and makes sure they all can be covered.

Looking at xterm.c, it is littered with #ifdef USE_CAIRO.

A first step could be to assume Cairo on X-based platforms and remove
duplicate code. The second step could be to decouple the "glass" from
the tookit "chrome" more thoroughly in xterm.c. That is easier to do
when a Cairo-canvas can be assumed for drawing.

Then, that entire "glass" could be reused by other platforms once they
have a Cairo-canvas for drawing as well. (Modulo the XWidget support
that depends on GTK.)

Once a switchover is in reach, it can live separately to the existing
platform-specific "glass" until all the kinks are worked out.

Regards, Julius

Am Sun, 17 May 2020 18:55:23 +0300
schrieb Eli Zaretskii <address@hidden>:

> > Date: Sun, 17 May 2020 16:59:53 +0200
> > From: Julius Pfrommer <address@hidden>
> > Cc: address@hidden
> >
> > Let me phrase the question differently: Would it be okay to have a
> > hard dependency on the Cairo+FreeType+Harfbuzz (CFH) libraries, as
> > they are available everywhere?
>
> First, we need to establish that this is a solution, and for what
> problem(s).  It is important to realize that the GUI backends we use
> handle much more than just drawing text, they need to be able to
> display GUI widgets, frame and window decorations (menu bar, tool bar,
> scroll bars, the frame title, etc.), and much more.  Is the
> configuration you propose capable of doing all that?  I don't think
> the answer will be full and definitive until "Someone" walks through
> all the APIs we implement in x/w32/ns/fns.c and x/w32/ns/term.c, and
> makes sure they all can be covered.
>
> Next, please be aware that we already made the decision to use
> HarfBuzz as our main text-shaping engine.  X and w32 already use it;
> for NS someone has to write the code (and they are not very likely to
> do so because macOS users consider the native text shaping more
> feature-rich).  Dropping the other font backends is a matter of time,
> but it could take a long time.
>
> In any case, the font backend is not the main issue here; in
> particular, the likes of FreeType are hardly even seen except on very
> low level of the code.  It's the other aspects of GUI code that
> bothers me much more.
>
> > Even on Linux, this would unlock quite a few simplifications. I
> > count at least three font handling "backends" here.
>
> Down to 2 and one deprecated one on master.  Bu again, font backends
> is a relatively easy problem, and it is being dealt with.