* When and how to register various font backends @ 2019-06-07 19:40 Eli Zaretskii 2019-06-14 9:14 ` Robert Pluim 2019-06-14 10:52 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-06-07 19:40 UTC (permalink / raw) To: emacs-devel; +Cc: YAMAMOTO Mitsuharu 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-07 19:40 When and how to register various font backends Eli Zaretskii @ 2019-06-14 9:14 ` Robert Pluim 2019-06-14 12:19 ` Eli Zaretskii 2019-06-14 10:52 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 18+ messages in thread From: Robert Pluim @ 2019-06-14 9:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: YAMAMOTO Mitsuharu, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 9:14 ` Robert Pluim @ 2019-06-14 12:19 ` Eli Zaretskii 2019-06-14 13:16 ` Robert Pluim 2019-06-14 16:54 ` Andy Moreton 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-06-14 12:19 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 12:19 ` Eli Zaretskii @ 2019-06-14 13:16 ` Robert Pluim 2019-06-14 14:47 ` Eli Zaretskii 2019-06-14 16:54 ` Andy Moreton 1 sibling, 1 reply; 18+ messages in thread From: Robert Pluim @ 2019-06-14 13:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 13:16 ` Robert Pluim @ 2019-06-14 14:47 ` Eli Zaretskii 2019-06-15 9:50 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-06-14 14:47 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 14:47 ` Eli Zaretskii @ 2019-06-15 9:50 ` Eli Zaretskii 2019-06-17 3:03 ` Michael Welsh Duggan 2019-06-17 9:41 ` Robert Pluim 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-06-15 9:50 UTC (permalink / raw) To: rpluim; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-15 9:50 ` Eli Zaretskii @ 2019-06-17 3:03 ` Michael Welsh Duggan 2019-06-17 9:41 ` Robert Pluim 1 sibling, 0 replies; 18+ messages in thread From: Michael Welsh Duggan @ 2019-06-17 3:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, emacs-devel 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-15 9:50 ` Eli Zaretskii 2019-06-17 3:03 ` Michael Welsh Duggan @ 2019-06-17 9:41 ` Robert Pluim 2019-06-17 16:01 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Robert Pluim @ 2019-06-17 9:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-17 9:41 ` Robert Pluim @ 2019-06-17 16:01 ` Eli Zaretskii 2019-06-18 1:29 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-06-17 16:01 UTC (permalink / raw) To: Robert Pluim, YAMAMOTO Mitsuharu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-17 16:01 ` Eli Zaretskii @ 2019-06-18 1:29 ` YAMAMOTO Mitsuharu 2019-06-18 17:26 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: YAMAMOTO Mitsuharu @ 2019-06-18 1:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Robert Pluim, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-18 1:29 ` YAMAMOTO Mitsuharu @ 2019-06-18 17:26 ` Eli Zaretskii 2019-06-18 23:21 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-06-18 17:26 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: rpluim, emacs-devel > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-18 17:26 ` Eli Zaretskii @ 2019-06-18 23:21 ` YAMAMOTO Mitsuharu 2019-06-19 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: YAMAMOTO Mitsuharu @ 2019-06-18 23:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-18 23:21 ` YAMAMOTO Mitsuharu @ 2019-06-19 16:42 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-06-19 16:42 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: rpluim, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 12:19 ` Eli Zaretskii 2019-06-14 13:16 ` Robert Pluim @ 2019-06-14 16:54 ` Andy Moreton 1 sibling, 0 replies; 18+ messages in thread From: Andy Moreton @ 2019-06-14 16:54 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-07 19:40 When and how to register various font backends Eli Zaretskii 2019-06-14 9:14 ` Robert Pluim @ 2019-06-14 10:52 ` YAMAMOTO Mitsuharu 2019-06-14 11:52 ` Robert Pluim 1 sibling, 1 reply; 18+ messages in thread From: YAMAMOTO Mitsuharu @ 2019-06-14 10:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- 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", ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 10:52 ` YAMAMOTO Mitsuharu @ 2019-06-14 11:52 ` Robert Pluim 2019-06-14 12:26 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2019-06-14 11:52 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Eli Zaretskii, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 11:52 ` Robert Pluim @ 2019-06-14 12:26 ` Eli Zaretskii 2019-06-14 13:24 ` Robert Pluim 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-06-14 12:26 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: When and how to register various font backends 2019-06-14 12:26 ` Eli Zaretskii @ 2019-06-14 13:24 ` Robert Pluim 0 siblings, 0 replies; 18+ messages in thread From: Robert Pluim @ 2019-06-14 13:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-06-19 16:42 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-06-07 19:40 When and how to register various font backends Eli Zaretskii 2019-06-14 9:14 ` Robert Pluim 2019-06-14 12:19 ` Eli Zaretskii 2019-06-14 13:16 ` Robert Pluim 2019-06-14 14:47 ` Eli Zaretskii 2019-06-15 9:50 ` Eli Zaretskii 2019-06-17 3:03 ` Michael Welsh Duggan 2019-06-17 9:41 ` Robert Pluim 2019-06-17 16:01 ` Eli Zaretskii 2019-06-18 1:29 ` YAMAMOTO Mitsuharu 2019-06-18 17:26 ` Eli Zaretskii 2019-06-18 23:21 ` YAMAMOTO Mitsuharu 2019-06-19 16:42 ` Eli Zaretskii 2019-06-14 16:54 ` Andy Moreton 2019-06-14 10:52 ` YAMAMOTO Mitsuharu 2019-06-14 11:52 ` Robert Pluim 2019-06-14 12:26 ` Eli Zaretskii 2019-06-14 13:24 ` Robert Pluim
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.