When and how to register various font backends

When and how to register various font backends

[Eli Zaretskii]

With HarfBuzz now available on master, we basically have 3 font
backends on almost every supported platform: the basic backend (Xfont
on Posix systems, GDI on Windows), a backend capable of shaping
complex scripts (ftfont/xftfont with FLT on X, Uniscribe on Windows),
and HarfBuzz.

Having too many active font backends is not a good idea, because when
there's no fonts on your system that can display some character, Emacs
tries to find a font with each of the active backends, so having 3
backends instead of 2 will make such failed searches significantly
longer (approximately by 50%).

Since HarfBuzz can do everything FLT can do, and more, I think it
makes sense to register HarfBuzz in preference to FLT backends when
both are available.  That is, by default each frame will only register
the basic backend and HarfBuzz; the FLT/Uniscribe backends will only
be registered if HarfBuzz is not available or if the user or the code
that creates the frame explicitly requested the other backends.

The question is how to implement this preference.  In the code that is
currently on master, you will see one way of implementing it in
w32fns.c, where the Windows code creates GUI frames (look in
x-create-frame).  Basically, after determining whether Uniscribe was
explicitly requested, this implementation registers or doesn't
register Uniscribe for each new frame.  This means the backends to be
available to a frame must be specified at frame creation time, or be
known by that time.

Yamamoto-san suggested a slightly different way of implementing the
same idea; I will let him explain his proposal in more detail.

Each implementation produces a slightly different behavior.  Since I
believe we should have the same behavior on all platforms, I would
like people to express their opinions on the two implementation, so
that we could eventually decide with which one to go, and implement it
for all platforms.

Thanks.

Re: When and how to register various font backends

[Robert Pluim]

>>>>> On Fri, 07 Jun 2019 22:40:45 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> The question is how to implement this preference.  In the code that is
    Eli> currently on master, you will see one way of implementing it in
    Eli> w32fns.c, where the Windows code creates GUI frames (look in
    Eli> x-create-frame).  Basically, after determining whether Uniscribe was
    Eli> explicitly requested, this implementation registers or doesn't
    Eli> register Uniscribe for each new frame.  This means the backends to be
    Eli> available to a frame must be specified at frame creation time, or be
    Eli> known by that time.

    Eli> Yamamoto-san suggested a slightly different way of implementing the
    Eli> same idea; I will let him explain his proposal in more detail.

    Eli> Each implementation produces a slightly different behavior.  Since I
    Eli> believe we should have the same behavior on all platforms, I would
    Eli> like people to express their opinions on the two implementation, so
    Eli> that we could eventually decide with which one to go, and implement it
    Eli> for all platforms.

I haven't seen the other proposal, but this strikes me as overly
conservative, so Iʼm going to propose the radical variant.

Currently under X11 the font backends end up as

(xft xfthb x)

Reordering that to put xfthb first is a matter of reordering the
register_font_driver calls in Fx_create_frame

Since xfthb is strictly better than xft, as far as I can tell, and we
want people to actually use it, we should just prefer it for emacs-27,
and remove the xft and x backends in emacs-28. default-frame-alist and
similar will still be available for people who absolutely want to turn
it off (and as evidenced by bug#36171, HarfBuzz should be preferred by
default).

Robert

Re: When and how to register various font backends

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

On Sat, 08 Jun 2019 04:40:45 +0900,
Eli Zaretskii wrote:
> 
> The question is how to implement this preference.  In the code that is
> currently on master, you will see one way of implementing it in
> w32fns.c, where the Windows code creates GUI frames (look in
> x-create-frame).  Basically, after determining whether Uniscribe was
> explicitly requested, this implementation registers or doesn't
> register Uniscribe for each new frame.  This means the backends to be
> available to a frame must be specified at frame creation time, or be
> known by that time.
> 
> Yamamoto-san suggested a slightly different way of implementing the
> same idea; I will let him explain his proposal in more detail.

Attached is my proposal.  The idea is to register all the drivers in
x-create-frame as before, but tweak the function font_update_drivers
(in font.c) so it only chooses "unsuperseded" drivers if the user did
not explicitly specify font backends (i.e., if NEW_DRIVERS is t).
Unlike Eli's current code in w32fns.c, this leaves the room to change
the font backend from uniscribe to harfbuzz (and vice versa) for the
same frame.  (You can't change xft/frcr to xfthb/ftcrhb on X
regardless of this patch because Bug#23386).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: font-driver-supersede.diff --]
[-- Type: application/octet-stream, Size: 8005 bytes --]

diff --git a/src/font.c b/src/font.c
index 5705758b99f..b786d623a77 100644
--- a/src/font.c
+++ b/src/font.c
@@ -3518,7 +3518,8 @@ free_font_driver_list (struct frame *f)
 
 /* Make the frame F use font backends listed in NEW_DRIVERS (list of
    symbols, e.g. xft, x).  If NEW_DRIVERS is t, make F use all
-   available font drivers.  If NEW_DRIVERS is nil, finalize all drivers.
+   available font drivers that are not superseded by another driver.
+   If NEW_DRIVERS is nil, finalize all drivers.
 
    A caller must free all realized faces if any in advance.  The
    return value is a list of font backends actually made used on
@@ -3527,16 +3528,32 @@ free_font_driver_list (struct frame *f)
 Lisp_Object
 font_update_drivers (struct frame *f, Lisp_Object new_drivers)
 {
-  Lisp_Object active_drivers = Qnil;
+  Lisp_Object active_drivers = Qnil, default_drivers = Qnil;
   struct font_driver_list *list;
 
+  /* Collect all unsuperseded driver symbols into
+     `default_drivers'.  */
+  Lisp_Object all_drivers = Qnil;
+  for (list = f->font_driver_list; list; list = list->next)
+    all_drivers = Fcons (list->driver->type, all_drivers);
+  for (Lisp_Object rest = all_drivers; CONSP (rest); rest = XCDR (rest))
+    {
+      Lisp_Object superseded_by = Fget (XCAR (rest), Qfont_driver_superseded_by);
+
+      if (NILP (superseded_by)
+	  || NILP (Fmemq (superseded_by, all_drivers)))
+	default_drivers = Fcons (XCAR (rest), default_drivers);
+    }
+
+  if (EQ (new_drivers, Qt))
+    new_drivers = default_drivers;
+
   /* At first, turn off non-requested drivers, and turn on requested
      drivers.  */
   for (list = f->font_driver_list; list; list = list->next)
     {
       struct font_driver const *driver = list->driver;
-      if ((EQ (new_drivers, Qt) || ! NILP (Fmemq (driver->type, new_drivers)))
-	  != list->on)
+      if ((! NILP (Fmemq (driver->type, new_drivers))) != list->on)
 	{
 	  if (list->on)
 	    {
@@ -3559,8 +3576,7 @@ font_update_drivers (struct frame *f, Lisp_Object new_drivers)
 
   if (NILP (new_drivers))
     return Qnil;
-
-  if (! EQ (new_drivers, Qt))
+  else
     {
       /* Re-order the driver list according to new_drivers.  */
       struct font_driver_list **list_table, **next;
@@ -3599,6 +3615,8 @@ font_update_drivers (struct frame *f, Lisp_Object new_drivers)
 	    {
 	      struct font_driver const *driver = list->driver;
 	      eassert (! list->on);
+	      if (NILP (Fmemq (driver->type, default_drivers)))
+		continue;
 	      if (! driver->start_for_frame
 		  || driver->start_for_frame (f) == 0)
 		{
@@ -5359,6 +5377,8 @@ syms_of_font (void)
   DEFSYM (QL2R, "L2R");
   DEFSYM (QR2L, "R2L");
 
+  DEFSYM (Qfont_driver_superseded_by, "font-driver-superseded-by");
+
   scratch_font_spec = Ffont_spec (0, NULL);
   staticpro (&scratch_font_spec);
   scratch_font_prefer = Ffont_spec (0, NULL);
diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index 1c28a7ceb67..a019fe8294a 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -599,6 +599,7 @@ syms_of_ftcrfont (void)
   DEFSYM (Qftcr, "ftcr");
 #ifdef HAVE_HARFBUZZ
   DEFSYM (Qftcrhb, "ftcrhb");
+  Fput (Qftcr, Qfont_driver_superseded_by, Qftcrhb);
 #endif	/* HAVE_HARFBUZZ */
   pdumper_do_now_and_after_load (syms_of_ftcrfont_for_pdumper);
 }
diff --git a/src/ftfont.c b/src/ftfont.c
index efd0fcbd8c0..4380a48d8dc 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -2970,6 +2970,7 @@ syms_of_ftfont (void)
   DEFSYM (Qfreetype, "freetype");
 #ifdef HAVE_HARFBUZZ
   DEFSYM (Qfreetypehb, "freetypehb");
+  Fput (Qfreetype, Qfont_driver_superseded_by, Qfreetypehb);
 #endif	/* HAVE_HARFBUZZ */
 
   /* Fontconfig's generic families and their aliases.  */
diff --git a/src/w32fns.c b/src/w32fns.c
index 8ebfc119521..83830c616e5 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -5844,46 +5844,10 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
       specbind (Qx_resource_name, name);
     }
 
-  bool register_uniscribe = uniscribe_available;
 #ifdef HAVE_HARFBUZZ
-  /* Register Uniscribe only if HarfBuzz is not available or if
-     explicitly requested.  If Uniscribe is registered, register
-     HarfBuzz only if explicitly requested.  */
-  bool register_harfbuzz = harfbuzz_available;
-  if (register_harfbuzz)
-    register_uniscribe = false;
-  Lisp_Object dflt_backends
-    = gui_display_get_arg (dpyinfo, parameters, Qfont_backend,
-			   "fontBackend", "FontBackend", RES_TYPE_STRING);
-  if (!EQ (dflt_backends, Qunbound))
-    {
-      bool harfbuzz_requested = false, uniscribe_requested = false;
-      if (CONSP (dflt_backends))
-	{
-	  if (!NILP (Fmemq (Quniscribe, dflt_backends)))
-	    uniscribe_requested = true;
-	  if (!NILP (Fmemq (Qharfbuzz, dflt_backends)))
-	    harfbuzz_requested = true;
-	}
-      else if (STRINGP (dflt_backends))
-	{
-	  if (strcmp (SSDATA (dflt_backends), "uniscribe") == 0)
-	    uniscribe_requested = true;
-	  else if (strcmp (SSDATA (dflt_backends), "harfbuzz") == 0)
-	    harfbuzz_requested = true;
-	}
-      if (uniscribe_requested)
-	{
-	  register_uniscribe = uniscribe_available;
-	  if (!harfbuzz_requested)
-	    register_harfbuzz = false;
-	}
-    }
-  if (register_harfbuzz)
-    register_font_driver (&harfbuzz_font_driver, f);
+  register_font_driver (&harfbuzz_font_driver, f);
 #endif
-  if (register_uniscribe)
-    register_font_driver (&uniscribe_font_driver, f);
+  register_font_driver (&uniscribe_font_driver, f);
   register_font_driver (&w32font_driver, f);
 
   gui_default_parameter (f, parameters, Qfont_backend, Qnil,
@@ -6935,46 +6899,10 @@ w32_create_tip_frame (struct w32_display_info *dpyinfo, Lisp_Object parms)
       specbind (Qx_resource_name, name);
     }
 
-  bool register_uniscribe = uniscribe_available;
 #ifdef HAVE_HARFBUZZ
-  /* Register Uniscribe only if HarfBuzz is not available or if
-     explicitly requested.  If Uniscribe is registered, register
-     HarfBuzz only if explicitly requested.  */
-  bool register_harfbuzz = harfbuzz_available;
-  if (register_harfbuzz)
-    register_uniscribe = false;
-  Lisp_Object dflt_backends
-    = gui_display_get_arg (dpyinfo, parms, Qfont_backend,
-			   "fontBackend", "FontBackend", RES_TYPE_STRING);
-  if (!EQ (dflt_backends, Qunbound))
-    {
-      bool harfbuzz_requested = false, uniscribe_requested = false;
-      if (CONSP (dflt_backends))
-	{
-	  if (!NILP (Fmemq (Quniscribe, dflt_backends)))
-	    uniscribe_requested = true;
-	  if (!NILP (Fmemq (Qharfbuzz, dflt_backends)))
-	    harfbuzz_requested = true;
-	}
-      else if (STRINGP (dflt_backends))
-	{
-	  if (strcmp (SSDATA (dflt_backends), "uniscribe") == 0)
-	    uniscribe_requested = true;
-	  else if (strcmp (SSDATA (dflt_backends), "harfbuzz") == 0)
-	    harfbuzz_requested = true;
-	}
-      if (uniscribe_requested)
-	{
-	  register_uniscribe = uniscribe_available;
-	  if (!harfbuzz_requested)
-	    register_harfbuzz = false;
-	}
-    }
-  if (register_harfbuzz)
-    register_font_driver (&harfbuzz_font_driver, f);
+  register_font_driver (&harfbuzz_font_driver, f);
 #endif
-  if (register_uniscribe)
-    register_font_driver (&uniscribe_font_driver, f);
+  register_font_driver (&uniscribe_font_driver, f);
   register_font_driver (&w32font_driver, f);
 
   gui_default_parameter (f, parms, Qfont_backend, Qnil,
diff --git a/src/w32font.c b/src/w32font.c
index 14d49b24d9b..5d54f048fb5 100644
--- a/src/w32font.c
+++ b/src/w32font.c
@@ -2821,6 +2821,8 @@ versions of Windows) characters.  */);
 
   defsubr (&Sx_select_font);
 
+  Fput (Quniscribe, Qfont_driver_superseded_by, Qharfbuzz);
+
   pdumper_do_now_and_after_load (syms_of_w32font_for_pdumper);
 }
 
diff --git a/src/xftfont.c b/src/xftfont.c
index 04cda12fb52..4d2a5f520e0 100644
--- a/src/xftfont.c
+++ b/src/xftfont.c
@@ -679,6 +679,7 @@ syms_of_xftfont (void)
   DEFSYM (Qxft, "xft");
 #ifdef HAVE_HARFBUZZ
   DEFSYM (Qxfthb, "xfthb");
+  Fput (Qxft, Qfont_driver_superseded_by, Qxfthb);
 #endif	/* HAVE_HARFBUZZ */
 
   DEFVAR_BOOL ("xft-font-ascent-descent-override",

Re: When and how to register various font backends

[Robert Pluim]

>>>>> On Fri, 14 Jun 2019 19:52:07 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

    YAMAMOTO> On Sat, 08 Jun 2019 04:40:45 +0900,
    YAMAMOTO> Eli Zaretskii wrote:
    >> 
    >> The question is how to implement this preference.  In the code that is
    >> currently on master, you will see one way of implementing it in
    >> w32fns.c, where the Windows code creates GUI frames (look in
    >> x-create-frame).  Basically, after determining whether Uniscribe was
    >> explicitly requested, this implementation registers or doesn't
    >> register Uniscribe for each new frame.  This means the backends to be
    >> available to a frame must be specified at frame creation time, or be
    >> known by that time.
    >> 
    >> Yamamoto-san suggested a slightly different way of implementing the
    >> same idea; I will let him explain his proposal in more detail.

    YAMAMOTO> Attached is my proposal.  The idea is to register all the drivers in
    YAMAMOTO> x-create-frame as before, but tweak the function font_update_drivers
    YAMAMOTO> (in font.c) so it only chooses "unsuperseded" drivers if the user did
    YAMAMOTO> not explicitly specify font backends (i.e., if NEW_DRIVERS is t).
    YAMAMOTO> Unlike Eli's current code in w32fns.c, this leaves the room to change
    YAMAMOTO> the font backend from uniscribe to harfbuzz (and vice versa) for the
    YAMAMOTO> same frame.  (You can't change xft/frcr to xfthb/ftcrhb on X
    YAMAMOTO> regardless of this patch because Bug#23386).

Whilst such an ability to change font backends is cool, I really donʼt
see it being very much used: as I said in my other message, in the
long term only the HarfBuzz backend will be supported, so I donʼt see
any need to add such infrastructure.

Robert

Re: When and how to register various font backends

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org,  YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Date: Fri, 14 Jun 2019 11:14:17 +0200
> 
> Currently under X11 the font backends end up as
> 
> (xft xfthb x)
> 
> Reordering that to put xfthb first is a matter of reordering the
> register_font_driver calls in Fx_create_frame

That's true, but we don't want to have 3 font backends in the list,
because then looking for a font that isn't available on the system
will take much longer (Emacs tries to find the font with each backend
in turn).  We want to have only 2 backends by default.

> Since xfthb is strictly better than xft, as far as I can tell, and we
> want people to actually use it, we should just prefer it for emacs-27,
> and remove the xft and x backends in emacs-28.

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

> default-frame-alist and similar will still be available for people
> who absolutely want to turn it off

The main issue at hand is how to allow users to specify the
non-preferred backends when they want that.  See Yamamoto-san's
message about that.

Re: When and how to register various font backends

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 14 Jun 2019 13:52:28 +0200
> 
> Whilst such an ability to change font backends is cool, I really donʼt
> see it being very much used: as I said in my other message, in the
> long term only the HarfBuzz backend will be supported, so I donʼt see
> any need to add such infrastructure.

In addition to what I already wrote on this matter, there's one more
consideration we should keep in mind: Emacs should never put all of
its eggs into a single basket.  As active as HarfBuzz development is
today, that could change in the future for reasons beyond our
control.  So we should keep the mechanism of using more than a single
font backend, in case we will need to make another change such as the
one we did now with HarfBuzz.

Re: When and how to register various font backends

[Robert Pluim]

>>>>> On Fri, 14 Jun 2019 15:19:14 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org,  YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
    >> Date: Fri, 14 Jun 2019 11:14:17 +0200
    >> 
    >> Currently under X11 the font backends end up as
    >> 
    >> (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.

    >> Since xfthb is strictly better than xft, as far as I can tell, and we
    >> want people to actually use it, we should just prefer it for emacs-27,
    >> and remove the xft and x backends in emacs-28.

    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.

    >> default-frame-alist and similar will still be available for people
    >> who absolutely want to turn it off

    Eli> The main issue at hand is how to allow users to specify the
    Eli> non-preferred backends when they want that.  See Yamamoto-san's
    Eli> message about that.

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

Robert

Re: When and how to register various font backends

[Robert Pluim]

>>>>> On Fri, 14 Jun 2019 15:26:18 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
    >> Date: Fri, 14 Jun 2019 13:52:28 +0200
    >> 
    >> Whilst such an ability to change font backends is cool, I really donʼt
    >> see it being very much used: as I said in my other message, in the
    >> long term only the HarfBuzz backend will be supported, so I donʼt see
    >> any need to add such infrastructure.

    Eli> In addition to what I already wrote on this matter, there's one more
    Eli> consideration we should keep in mind: Emacs should never put all of
    Eli> its eggs into a single basket.  As active as HarfBuzz development is
    Eli> today, that could change in the future for reasons beyond our
    Eli> control.  So we should keep the mechanism of using more than a single
    Eli> font backend, in case we will need to make another change such as the
    Eli> one we did now with HarfBuzz.

I was not proposing that we remove the ability to change font
backends, just that we not implement the font backend superseding
stuff.

Robert

Re: When and how to register various font backends

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 Jun 2019 15:16:51 +0200
> 
> >>>>> On Fri, 14 Jun 2019 15:19:14 +0300, Eli Zaretskii <eliz@gnu.org> 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.

Re: When and how to register various font backends

[Andy Moreton]

On Fri 14 Jun 2019, Eli Zaretskii wrote:

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

A quick test using the "System" font on Windows confirms that:
gdi:-raster-System-bold-normal-normal-sans-16-*-*-*-p-*-iso8859-1

    AndyM

Re: When and how to register various font backends

[Eli Zaretskii]

> Date: Fri, 14 Jun 2019 17:47:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > (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.

Maybe we should approach this from the requirements aspect.  Namely,
what do we want to be possible regarding control of font backends of a
frame, and in what situations.

I assume that we want to be able to set the font backend(s) from the X
resources and via the -xrm command-line option.  AFAIU, both proposed
methods allow that.

I assume we also want to be able to specify the backend(s) at frame
creation time, via the frame parameters passed to make-frame.  Again,
both methods allow that.

But what about being able to specify the backend(s) via
default-frame-alist in the init file, and expecting that to affect all
the frames including the initial one?  Mitsuharu's proposal allows
that, whereas mine doesn't.  That's because in my implementation the
font backend is registered at frame creation time, and only the
backends known to be requested at that time are registered.  So when
we call modify-frame-parameters later, after processing the init file,
to make default-frame-alist parameters take effect, you cannot request
a backend that wasn't registered.

By contrast, Mitsuharu's method registers all the backends, but only
activates some of them.  So modify-frame-parameters can work, because
it just needs to activate an already registered backend.

I hope the difference is clearer now, and people can voice their
opinions.

Re: When and how to register various font backends

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

> But what about being able to specify the backend(s) via
> default-frame-alist in the init file, and expecting that to affect all
> the frames including the initial one?  Mitsuharu's proposal allows
> that, whereas mine doesn't.  That's because in my implementation the
> font backend is registered at frame creation time, and only the
> backends known to be requested at that time are registered.  So when
> we call modify-frame-parameters later, after processing the init file,
> to make default-frame-alist parameters take effect, you cannot request
> a backend that wasn't registered.
>
> By contrast, Mitsuharu's method registers all the backends, but only
> activates some of them.  So modify-frame-parameters can work, because
> it just needs to activate an already registered backend.
>
> I hope the difference is clearer now, and people can voice their
> opinions.

I find that I, at some point, specified a font-backend ordering by
modifying the default-frame-alist in my init file.  So, although my
reasons for doing that are by now obscure and possibly defunct, I did,
at least, assume that this would work at some time in the past.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: When and how to register various font backends

[Robert Pluim]

>>>>> On Sat, 15 Jun 2019 12:50:23 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Fri, 14 Jun 2019 17:47:07 +0300
    >> From: Eli Zaretskii <eliz@gnu.org>
    >> Cc: emacs-devel@gnu.org
    >> 
    >> > (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.

    Eli> But what about being able to specify the backend(s) via
    Eli> default-frame-alist in the init file, and expecting that to affect all
    Eli> the frames including the initial one?  Mitsuharu's proposal allows
    Eli> that, whereas mine doesn't.  That's because in my implementation the
    Eli> font backend is registered at frame creation time, and only the
    Eli> backends known to be requested at that time are registered.  So when
    Eli> we call modify-frame-parameters later, after processing the init file,
    Eli> to make default-frame-alist parameters take effect, you cannot request
    Eli> a backend that wasn't registered.

    Eli> By contrast, Mitsuharu's method registers all the backends, but only
    Eli> activates some of them.  So modify-frame-parameters can work, because
    Eli> it just needs to activate an already registered backend.

I see. I guess one potential fix would be to change the default value
of default-frame-alist, but that wouldnʼt help people who have already
customised it.

So it seems that Mitsuharu's proposal is the only one that fulfills
all your requirements.

Robert

Re: When and how to register various font backends

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 17 Jun 2019 11:41:00 +0200
> 
> I see. I guess one potential fix would be to change the default value
> of default-frame-alist, but that wouldnʼt help people who have already
> customised it.
> 
> So it seems that Mitsuharu's proposal is the only one that fulfills
> all your requirements.

Thanks.  So I will ask Mitsuharu to please commit his changes, and the
Windows rework will follow.

Re: When and how to register various font backends

[YAMAMOTO Mitsuharu]

On Tue, 18 Jun 2019 01:01:55 +0900,
Eli Zaretskii wrote:
> 
> > I see. I guess one potential fix would be to change the default value
> > of default-frame-alist, but that wouldnʼt help people who have already
> > customised it.
> > 
> > So it seems that Mitsuharu's proposal is the only one that fulfills
> > all your requirements.
> 
> Thanks.  So I will ask Mitsuharu to please commit his changes, and the
> Windows rework will follow.

Pushed to master.  It includes some changes for Windows, so please
check if it works.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: When and how to register various font backends

[Eli Zaretskii]

> Date: Tue, 18 Jun 2019 10:29:11 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Robert Pluim <rpluim@gmail.com>,
> 	emacs-devel@gnu.org
> 
> > Thanks.  So I will ask Mitsuharu to please commit his changes, and the
> > Windows rework will follow.
> 
> Pushed to master.  It includes some changes for Windows, so please
> check if it works.

Thanks.  I needed to tweak that a bit, because on Windows we cannot
determine whether HarfBuzz supersedes Uniscribe at dump time, we can
only determine that at Emacs startup time.

Do we need to fix something in the manuals or NEWS following this
changeset?

Re: When and how to register various font backends

[YAMAMOTO Mitsuharu]

On Wed, 19 Jun 2019 02:26:02 +0900,
Eli Zaretskii wrote:
> 
> > > Thanks.  So I will ask Mitsuharu to please commit his changes, and the
> > > Windows rework will follow.
> > 
> > Pushed to master.  It includes some changes for Windows, so please
> > check if it works.
> 
> Thanks.  I needed to tweak that a bit, because on Windows we cannot
> determine whether HarfBuzz supersedes Uniscribe at dump time, we can
> only determine that at Emacs startup time.

Thanks.

> Do we need to fix something in the manuals or NEWS following this
> changeset?

I don't think so.  The curent NEWS entry works as it is, and the
property 'font-backend-superseded-by is a bit internal and wouldn't
need documentations for users.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: When and how to register various font backends

[Eli Zaretskii]

> Date: Wed, 19 Jun 2019 08:21:49 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: rpluim@gmail.com,
> 	emacs-devel@gnu.org
> 
> > Do we need to fix something in the manuals or NEWS following this
> > changeset?
> 
> I don't think so.  The curent NEWS entry works as it is, and the
> property 'font-backend-superseded-by is a bit internal and wouldn't
> need documentations for users.

OK, thanks.  I guess this job is done, then.