From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: HarfBuzz is available on MS-Windows Date: Sat, 08 Jun 2019 09:18:57 +0300 Message-ID: <83h890ppke.fsf@gnu.org> References: <83o93iwwtn.fsf@gnu.org> <83o939p3n6.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253414"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 08 08:19:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZUhc-0013qP-0n for ged-emacs-devel@m.gmane.org; Sat, 08 Jun 2019 08:19:44 +0200 Original-Received: from localhost ([::1]:55798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZUha-0004LI-HJ for ged-emacs-devel@m.gmane.org; Sat, 08 Jun 2019 02:19:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39706) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZUh1-0004LC-31 for emacs-devel@gnu.org; Sat, 08 Jun 2019 02:19:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hZUh0-0001kn-Vl; Sat, 08 Jun 2019 02:19:07 -0400 Original-Received: from [176.228.60.248] (port=1918 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hZUh0-0000Lx-Bz; Sat, 08 Jun 2019 02:19:06 -0400 In-reply-to: (message from Andy Moreton on Fri, 07 Jun 2019 22:13:36 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237322 Archived-At: > From: Andy Moreton > 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.