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: Fri, 30 Mar 2018 12:36:45 +0200 Message-ID: <87woxtq282.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> <87po3mdfl8.fsf@gmail.com> <83sh8idd3p.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 1522406112 14682 195.159.176.226 (30 Mar 2018 10:35:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 10:35:12 +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 Fri Mar 30 12:35:07 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 1f1rNC-0003jV-V4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 12:35:07 +0200 Original-Received: from localhost ([::1]:52194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1rPG-0003pc-GW for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 06:37:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1rP9-0003p9-6U for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 06:37:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1rP5-0005zs-6F for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 06:37:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51493) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1rP5-0005zm-2O for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 06:37:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1rP4-0003t2-Hs for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 06:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Mar 2018 10:37: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.152240621514928 (code B ref 30874); Fri, 30 Mar 2018 10:37:02 +0000 Original-Received: (at 30874) by debbugs.gnu.org; 30 Mar 2018 10:36:55 +0000 Original-Received: from localhost ([127.0.0.1]:59390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1rOw-0003sh-TO for submit@debbugs.gnu.org; Fri, 30 Mar 2018 06:36:55 -0400 Original-Received: from mail-wm0-f49.google.com ([74.125.82.49]:54424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1rOu-0003sU-Th for 30874@debbugs.gnu.org; Fri, 30 Mar 2018 06:36:53 -0400 Original-Received: by mail-wm0-f49.google.com with SMTP id h76so15070059wme.4 for <30874@debbugs.gnu.org>; Fri, 30 Mar 2018 03:36:52 -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:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=CIZ44aBNEZT0oCcoqWkYB3dpLLkdCfzGkdTQ5XG+P+s=; b=Hl4Io+lEI3AjtCMxqutXSKNZu7PWVbfB3RcnLCZRG6vvQ8tVUwG802qc7HEfnr/wRZ aOWNlNlkDE1ALHBYNPfPeKbuP/glhHYUlZF/19D30jKlUddRljtmwb4ssef7+B9gKKHG fzwc9QS46F4fMgWhKhQHHWeDwSi+v5k4VUOO9IibkxDkMAQt8cxx0WOfN3UPBcRd/BwJ U1vQBO8ahXwiDJmzgHkcjsCv/ZmjxFur0Q/nRM7A/Mo+xhCVAVkZZ72bI8MxLtm4Fx4U vU0xl3NXOD8lrB2n8Ukl7SmxsqR0qs9Rl0uHZ+1dsmYTU2gpcR52Xu5x2v+SnbmDISRt a0zg== 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:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=CIZ44aBNEZT0oCcoqWkYB3dpLLkdCfzGkdTQ5XG+P+s=; b=eEkliHYsQkbUv/7/yhrCe1Qmx0LCGv8uCQNordBumYjDVARDYLeauFL6W61vD6fFdy fXlOtiBo7v3NjocJunqUpbjQZ/noKFM3NT1Dmnkil87h8dBhVqcxeX2u2Lvr+CDzDhsf o1ko1YyS8AfrcLN/p7fICOZWt7EsKuy20OilRxrX4kdCQqBegERUHm2QntVFpRv2eESG dzNi8M4c232O5A2ARGJRYQ88J88xjAMdNvFy1pcpvcoYOoNrVQmV8E0PD600QZreCjMr Q9o0lZn0n1sqW8v4xPiUwdoQZ6MV1cYYJ/SuNO2serkEaiW3T1a7TCA4RrVIIeF17Rrl KlFQ== X-Gm-Message-State: AElRT7H7Gmql4HKAJgCYaWqh/6R8aPwpL4P3e1o11BL4JE5cTwepEA0X ZA51Kep05C7K5AjXOvrpLTI= X-Google-Smtp-Source: AIpwx4+kYS4c6NusVSOtzzOlE/W3WATPOl5BkskyJNpypjlxumYhg888OZjbWeLBwAfWtXdUjv3Dsg== X-Received: by 10.28.164.68 with SMTP id n65mr2014027wme.123.1522406206907; Fri, 30 Mar 2018 03:36:46 -0700 (PDT) Original-Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id k35sm8318588wre.55.2018.03.30.03.36.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 30 Mar 2018 03:36:46 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83sh8idd3p.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Mar 2018 20:07:54 +0300") 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:144730 Archived-At: Eli Zaretskii writes: >> As I understand it, we should use fontconfig for finding fonts, >> harfbuzz for doing the layout, and cairo to actually render the >> result > > Does harfbuzz require Cairo? If it does, that's unfortunate, because > the Cairo rendering option currently has a few known and annoying > redisplay bugs, which no one seems to be willing/capable of fixing. Until someone fixes , Cairo is basically unusable for me even without the redisplay issues. >> plus it=CA=BCs Emacs redisplay, which I=CA=BCm told is scary > > Don't believe the rumors too much. Besides, adding a font backend > doesn't require to mess with the display code in any way, all you need > is implement the interfaces you see documented in 'struct font_driver' > defined in font.h (reusing the methods of existing backends where > appropriate, as xftfont does with ftfont methods); all the rest is > already taken care of in the infrastructure. The only interface > between font back-end methods and the display engine is via 'struct > glyph_string', which is a relatvely simple data structure. > >> I do note we have an Xft font backend, a freetype one, and a >> freetype+cairo one already, which seems excessive. > > You forgot xfont and freetype-without-XFT. It could be that we could > remove some of them, but I don't know which ones are used and how > much. And freetype+cairo is not used much because of the Cairo > problems. I suspect Xft is the only one really used, since freetype-without-xft is disabled if I read configure.ac right. Freetype + cairo is the one we should probably target, as Xft used direct X calls which will stop working once the world moves to Wayland. >> > As a stopgap, I think we should find a way of ignoring the problematic >> > fonts. Is there some way of detecting them? >>=20 >> 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. > > AFAIK, there's no "fallback" per se. Whenever the already-loaded > fonts don't support a character, Emacs looks for the fonts that do > using the "match" method. If we always fail these fonts in that > method, they will never be used. Yes, I was confused about what was happening. This explains why I was not getting Symbola as well: that font doesn=CA=BCt have a glyph for #x274c >> > 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. >>=20 >> I=CA=BCm hoping that matching on something like !'family emoji' would wo= rk, >> although I=CA=BCve not figured out how to express that in fontconfig-spe= ak. > > I thought there could be a way of detecting those "color bitmap fonts" > by examining their attributes in ftfont_match and/or > ftfont_spec_pattern. Then we could return a failure indication for > them. So the pattern returned from fontconfig doesn=CA=BCt indicate anything specific we could use, but it=CA=BCs possible to modify the pattern we use for requesting. The following patch against emacs-26 fixes the crash for me (Emacs ends up using "Noto Emoji"). Definitely not intended to be applied to emacs-26. modified src/ftfont.c @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, = struct OpenTypeSpec **ots if (scalable >=3D 0 && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcF= alse)) goto err; + /* We really don't like color fonts, they cause Xft crashes. */ + FcPatternAddBool(pattern, FC_COLOR, FcFalse); =20 goto finish; =20