Re: HarfBuzz is available on MS-Windows

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Fri, 07 Jun 2019 22:13:36 +0100
> 
> >> It appears to work ok, but is noticeably slower compared to the
> >> master branch.
> >
> > I didn't see any tangible slowdown with HarfBuzz on my system.  Can
> > you post some benchmarks with timings?  (I assume both branches were
> > built using the same optimization switches.)
> 
> My feeling was only subjective based on running from "emacs -Q", but
> that may be problems with font lookup making everything slow.

If it's font lookup, then it has nothing to do with HarfBuzz.  The
font lookup is entirely our own code, and for HarfBuzz we actually
use the same code as for Uniscribe.  IOW, the speed of finding a
suitable font should be unaltered in the current master.

> I've now bootstrapped the master branch after you merged the harfbuzz
> support, and everything appears to be working fine so far.

Good to know, thanks.

> > In any case, the font backend has nothing whatsoever to do with how
> > Emacs searches for a suitable font, at least on Windows.  What the
> > above means is that Leelawadee somehow doesn't fit the criteria for
> > the Lao script and/or the features bits these fonts exhibit don't
> > announce that they cover the respective codepoint ranges.  The way to
> > improve the font search is to customize the fontsets.
> 
> Agreed, but it would be nicer for the average Windows user if the
> built-in fonts were used by default, and that configuring the fontset
> would only be needed to override the default selection.

That's the situation, AFAIK.  With the qualification that "the default
selection" depends also on the order in which the installed fonts are
enumerated by the system APIs -- we have no control on this order.
Emacs chooses the first matching font produced by the enumeration, so
if a font comes later in the enumeration order that is better in some
sense, Emacs might not select it without fontset customizations.

> >> Perhaps the built in fonts should be added to the default mappings for
> >> Windows 10.
> >
> > I think the policy is not to mention non-free fonts in our fontsets.
> 
> That's reasonable when recommending additional fonts to install, but it
> is unhelpful to avoid using fonts that are installed by default.

There are 2 issues here: one is about the speed of finding fonts for
certain characters, the other is about finding a suitable font at
all.  I was under the impression that your fontset customizations were
meant to solve the speed issue, in which case I don't think it's an
issue with the defaults, and in any case we shouldn't assume anything
about the users' installation: they could have other fonts installed
that they prefer, so it would be improper for Emacs to force them to
use the built-in fonts.  In addition, quality of built-in fonts
changes with time, so a font that comes with the system today might be
less desirable to use tomorrow.  Thus, including those fonts in our
sources would mean we need to track the development of system fonts,
update the fonts in our default fontsets, and perhaps make the fontset
dependent on the OS version.  This would be a maintenance burden.

However, above you seem now to be talking about failure to find a font
although some fonts do support the character.  That is a separate
issue.  The question in this case is why doesn't Emacs find and select
these fonts by itself, without any hints in the fontset in addition to
what we already have there.  To answer this question, one needs to
step through the code which enumerates the fonts on your system and
determines whether a given font matches the criteria we require for
supporting that particular character.  For example, we treat Emoji
like we treat symbols; maybe that is incorrect?  For Lao, we require
that the font supports certain OTF features; perhaps there's a mistake
there, or the criteria need some adjustments?  If you'd like to try
debugging this, I can help by pointing to the code where this
happens.  In general, start with the fontset as defined in fontset.el,
and then look in w32font.c:w32font_list_internal and its subroutines.