From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#30874: 27.0.50; Emacs crashes Date: Thu, 29 Mar 2018 18:14:11 +0200 Message-ID: <87po3mdfl8.fsf@gmail.com> References: <837eq7lzr4.fsf@gnu.org> <831sgencgb.fsf@gnu.org> <83woy4i7rz.fsf@gnu.org> <83vadoi2ia.fsf@gnu.org> <878taf2kj5.fsf@gmail.com> <83d0zqg8p8.fsf@gnu.org> <87o9ja230e.fsf@gmail.com> <83605ig2se.fsf@gnu.org> <87fu4m1tht.fsf@gmail.com> <878tae1nzu.fsf@gmail.com> <83lgeedxv7.fsf@gnu.org> <874ll128ww.fsf@gmail.com> <83efk3dvq0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522339996 1444 195.159.176.226 (29 Mar 2018 16:13:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 16:13:16 +0000 (UTC) Cc: 30874@debbugs.gnu.org, jsynacek@redhat.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 29 18:13:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aAp-0000Fx-Hv for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 18:13:12 +0200 Original-Received: from localhost ([::1]:37267 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aCs-0007jZ-Rx for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 12:15:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aCi-0007fd-Vm for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:15:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1aCc-0003A0-Nk for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:15:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50960) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1aCc-00039M-Js for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1aCc-00069V-7L for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:15:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Mar 2018 16:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30874 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30874-submit@debbugs.gnu.org id=B30874.152234006123582 (code B ref 30874); Thu, 29 Mar 2018 16:15:02 +0000 Original-Received: (at 30874) by debbugs.gnu.org; 29 Mar 2018 16:14:21 +0000 Original-Received: from localhost ([127.0.0.1]:58856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aBx-00068H-6O for submit@debbugs.gnu.org; Thu, 29 Mar 2018 12:14:21 -0400 Original-Received: from mail-wr0-f176.google.com ([209.85.128.176]:39737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aBu-000683-VM for 30874@debbugs.gnu.org; Thu, 29 Mar 2018 12:14:19 -0400 Original-Received: by mail-wr0-f176.google.com with SMTP id c24so5910247wrc.6 for <30874@debbugs.gnu.org>; Thu, 29 Mar 2018 09:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:message-id:mime-version:content-transfer-encoding; bh=R4DxZVk9qmwf8Zk3UubpWEbVO4qxnK+ivdsuNCnRw5w=; b=Jh+0L4qY97O2tWKEGoaz7peCYSQPadzO3O6EtiJpdMwK2uAn7rJNUCsCatlxjUgUNK SK49aMcCLb7m6h4AaIBTB22GeP+zNFK62Z0g9N1RbEKnxk1K+2mj/sl1W4yVUiROjBUu eoBqI4tJUbpdiDiWlbFxcE+ke0cnj4S2AvRx6E4t1m2kISs0UYuB6YEAVJOVd+N6l2QB aRNShOGt4sD1wqL5azXH4nwRUZKjChytGA1O5N76D4hyz7jQf1miAs4zYb2MRsKy3paU U/e+YJJjg2GG8CyCTVu5hNcWIvA4Wu2Am/gaEf2dGxtyU/aLUVd3/XtL9ayD7snb/G2I xtfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:message-id:mime-version :content-transfer-encoding; bh=R4DxZVk9qmwf8Zk3UubpWEbVO4qxnK+ivdsuNCnRw5w=; b=DFp1EWm8FFWgjxJYoS9avsX4JU4N/2y5NVHzmgrlYYiOkDKjKBgXxiACU3Yi1qOl47 hH65Er1+MVbfNmVkyRgJCzU8koy5zkSCCF6ApELHbBAwXzPLGJXmFxqYye1Od9+uyPhC F8lbF29KSdq7ogk1baTYHZhC3dKxt8affJ6DrSe4eAix1mHhCXOzM9cbXBkcivQZZE3t HaIURJPpxwL8lAE/eDb/ReTwXZQhjn1ASwkiHyNniVvZNbkhBusIqPxMiVpHDyq1jXJ1 D+bn1APJdZPW2EUaXJoUXt2VeM+NAOeFqPtLURpUCU8pLPm4dIEMizHih44deOr5DnMv Q+sw== X-Gm-Message-State: AElRT7F1TG7lSBx5bgsvLEXj9tnbrJWYwi2+H97dbTjGAYMCqbicsLQC 6TyHw3owAl6tE9ug8EMrWW8= X-Google-Smtp-Source: AIpwx49NN2X4mGhSZVFx/pJVEPvLtaFLn2WWRNZgtH1pUGl6J71/yVvmcRK4WjqS9y6zsBtD6D87bA== X-Received: by 10.223.188.12 with SMTP id s12mr7016348wrg.266.1522340052810; Thu, 29 Mar 2018 09:14:12 -0700 (PDT) Original-Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id p19sm11546735wrb.75.2018.03.29.09.14.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Mar 2018 09:14:11 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144690 Archived-At: Eli Zaretskii writes: >> From: Robert Pluim >> # Inconsolata is my system default monospace font. Now I insert #x274c : >>=20 >> FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches = new >> Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 >> FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new >> Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 > > What does "matches new" mean in this log? And what does "matches > existing" (below) mean? "matches new" means "this is the first time Xft has loaded this file", similarly "matches existing" means "already loaded" (this is Xft=CA=BCs debug, not mine) >> # I think this means Inconsolata doesn=CA=BCt have a glyph for that >> # codepoint, although I thought the default fontset specified Symbola >> # for that codepoint (and Symbola is installed), so I don=CA=BCt underst= and >> # why VL-Gothic is chosen. > > Strange indeed. Does setting use-default-font-for-symbols to a nil > value change this in any way? No change. I=CA=BCm beginning to suspect that when we query for the font that Xft is doing font subsitution for us. >> # Now I change the fontset, and this time it finds the >> # emojione-android font : >>=20=20=20 >> FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new >> Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 >> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 match= es existing (2) >> FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches= new >> Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 > > Right. Does use-default-font-for-symbols change anything in this > case? No change >> > The question now becomes: how do we avoid loading such fonts, at least >> > when the xftfont back-end is in use? Is there any alternative except >> > telling users to "move such fonts out of the way"? >>=20 >> Accoding to that bug, the solution is for the application to 'move >> away from legacy Xft to fontconfig', whatever that means. I can say >> that building '--without-xft' is definitely sub-optimal (the buffer >> text isn=CA=BCt scaled, and Emacs doesn=CA=BCt find a font to display #x= 274c). > Actually, I think this is because '--without-xft' also disables Freetype, according to the configure log. > We already use fontconfig to some extent, and xftfont is AFAIK the > most advanced font backend we have. Patches for switching to using > more of fontconfig's features (assuming it can replace Xft), or for > switching to a more modern back-end (harfbuzz?) are welcome, but I > don't hold my breath, as I don't think we have expert on board who > know enough about complex script shaping to make progress in those > directions. As I understand it, we should use fontconfig for finding fonts, harfbuzz for doing the layout, and cairo to actually render the result, but this is definitely not my area (plus it=CA=BCs Emacs redisplay, which I=CA=BCm told is scary) I do note we have an Xft font backend, a freetype one, and a freetype+cairo one already, which seems excessive. > As a stopgap, I think we should find a way of ignoring the problematic > fonts. Is there some way of detecting them? You mean short of running ftfont_get_bitmap over every available codepoint in the font and skipping it if the resulting width * height is > 4096 [1]? That would probably detect a problematic font pretty quickly, but is not very elegant. Also I=CA=BCm not sure we get to intervene before Xft decides that it needs to fall back to that font. > AFAICT, we could do that > either in ftfont_match or in its subroutine ftfont_spec_pattern. We > could then pretend that these fonts don't match any font spec, perhaps > subject to some variable (which would provide a 'fire escape"), which > I think would fix the problem. I=CA=BCm hoping that matching on something like !'family emoji' would work, although I=CA=BCve not figured out how to express that in fontconfig-speak. > Failing that, we could have a non-empty list in face-ignored-fonts, > but that would be an inferior solution, and it would take us more time > to come up with the full list of the problematic fonts. That works, but it also feels hacky. Robert Footnotes: [1] If only the calculation were that simple