[Top][All Lists]

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

Re: When and how to register various font backends

From: Eli Zaretskii
Subject: Re: When and how to register various font backends
Date: Fri, 14 Jun 2019 17:47:07 +0300

> From: Robert Pluim <address@hidden>
> Cc: address@hidden
> Date: Fri, 14 Jun 2019 15:16:51 +0200
> >>>>> On Fri, 14 Jun 2019 15:19:14 +0300, Eli Zaretskii <address@hidden> said:
>     >> (xft xfthb x)
>     >> 
>     >> Reordering that to put xfthb first is a matter of reordering the
>     >> register_font_driver calls in Fx_create_frame
>     Eli> That's true, but we don't want to have 3 font backends in the list,
>     Eli> because then looking for a font that isn't available on the system
>     Eli> will take much longer (Emacs tries to find the font with each backend
>     Eli> in turn).  We want to have only 2 backends by default.
> That I think pleads for your solution, where xfthb is preferred to xft
> unless xft is specifically requested.

Both solutions provide this, the difference is in how you request
specific backend, and at which point in frame's life cycle you
can/should request that.

>     Eli> I'm not sure removing x (and gdi on Windows) is a good idea, even in
>     Eli> Emacs 28.  I understand (more accurately, was told very recently) 
> that
>     Eli> HarfBuzz was designed to be able to work with any font, not just OTF,
>     Eli> but I'm not sure our integration of HarfBuzz allows that.  We should
>     Eli> actively test that with old fonts, like bitmapped fonts and BDF,
>     Eli> before we make the decision.  For example, I suspect the methods we
>     Eli> currently use for finding fonts suitable for HarfBuzz filter out
>     Eli> non-OTF fonts (at least on Windows, this is definitely so).
> OK. So itʼs just xft (and uniscribe) weʼd be removing, eventually.

We can only remove those if we require HarfBuzz and don't support
builds without HarfBuzz.

> (add-to-list 'default-frame-alist '(font-backend xft x)) works already, no? 
> And
> presumably continues to work with your solution.

No, it doesn't work with my solution, at least not reliably, because I
didn't intend it to work.

reply via email to

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