Re: When and how to register various font backends

[Robert Pluim <rpluim@gmail.com>]

>>>>> 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