From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#38442: 27.0.50; segmentation fault switching to cairo Date: Mon, 2 Dec 2019 18:28:32 +0100 Message-ID: References: <83tv6kn2ap.fsf@gnu.org> <83sgm4lzup.fsf@gnu.org> <22778C0D-D396-45A2-8D53-2D24795A59D3@gnu.org> <83r21mlnen.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b5ee6d0598bbeaae" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="30560"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rpluim@gmail.com, ola.nilsson@gmail.com, 38442@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 02 18:30:23 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ibpWh-0007jF-9t for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 18:30:23 +0100 Original-Received: from localhost ([::1]:41862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibpWa-0004Mk-3K for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 12:30:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50711) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibpWQ-0004KT-LK for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 12:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibpWP-000398-Ez for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 12:30:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32897) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibpWP-000394-CM for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 12:30:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ibpWP-0002tO-84 for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 12:30:05 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Dec 2019 17:30:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38442 X-GNU-PR-Package: emacs Original-Received: via spool by 38442-submit@debbugs.gnu.org id=B38442.157530775510997 (code B ref 38442); Mon, 02 Dec 2019 17:30:05 +0000 Original-Received: (at 38442) by debbugs.gnu.org; 2 Dec 2019 17:29:15 +0000 Original-Received: from localhost ([127.0.0.1]:38870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibpVa-0002rH-AW for submit@debbugs.gnu.org; Mon, 02 Dec 2019 12:29:15 -0500 Original-Received: from mail-qt1-f194.google.com ([209.85.160.194]:37598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibpVZ-0002r6-84 for 38442@debbugs.gnu.org; Mon, 02 Dec 2019 12:29:13 -0500 Original-Received: by mail-qt1-f194.google.com with SMTP id w47so529457qtk.4 for <38442@debbugs.gnu.org>; Mon, 02 Dec 2019 09:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l4TE6jCuZMQo6sknzOuSgN9V//9+CoPgtqSu6nV0c5o=; b=qgXJSg5CAeDLNZUG/STg8yPD5LPSt4aL5a+N6iSS0nQjsjula9EqqM8QW2m8ePIVI8 u+IZv7OOEMFanO1kB9nzFB2SfhiclkT4OBsYisRxvu1cV1hNiubTQ5UVzCqGfAMZzVGn zIcCx7k2lE5VEAYfvnnDWyYu1NOjsv1dtxIwd7B/FeF5x3II/Rj/88WCylVa+EPQlsmH ixZNo5sYu8jBQ/y+uUJxq2o7/6nQA/jO3WiUeeoNMG5p6hAzo9nM2PgytXUD5LgFdyxf 1prN1GyLYsK/ySYoAMK459e76KSMe6tlGqliqdFCU7Msv0Dimg4pmbTwwCTjFg4lG9jt IAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l4TE6jCuZMQo6sknzOuSgN9V//9+CoPgtqSu6nV0c5o=; b=J/1HI7qLgUT/v7qyXwKNBH/fUqUFbtL7Jp0cLIGs916iu3IxiKs4A/Vb2k0doGhER0 qllKMtxo+F4b1BDeTt3x2VYlym+7wndiQgNyRAPo9uUnoG1fiaRQFQYVVDJGYNH3J2Wv vsA7LHV/3vUs7NZQgJLbsa2rlJT3hJxtW4JwajREOQiuJfITXefn11tngpG0/Bjpjyjb QogspVU+R4A5VvSc8VIXFwcALLUQkrdFC8JGBZPhC6w1GErwn7IfuCWIvg63g1++sqmH Itkj3yYjjeWzW+mISkM1kHPHoYu7SIgKYDTWMWjBd6zZlOMASa49nkUEyMX/OQtyZZxh IItA== X-Gm-Message-State: APjAAAUwKQSwyzDQj7TRw2+8CPqSKcWmiA7yJnRQCSSxM7038P0qDElv N4JkceaxEfuWgQ6BWpF+vSKqQBJ0Bwf+TPRb8KhuNA== X-Google-Smtp-Source: APXvYqyRhBthSLWzgxlahGIw/PuvEhq1RbvrNpo+DqZf8ovAGemcrU2h3zXfv0VP3QaMv70GOr3A9lWfSyDS7yc/8xg= X-Received: by 2002:aed:3c5b:: with SMTP id u27mr411163qte.287.1575307747650; Mon, 02 Dec 2019 09:29:07 -0800 (PST) In-Reply-To: <83r21mlnen.fsf@gnu.org> 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: 209.51.188.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:172777 Archived-At: --000000000000b5ee6d0598bbeaae Content-Type: text/plain; charset="UTF-8" On Mon, Dec 2, 2019 at 5:09 PM Eli Zaretskii wrote: > We may be mis-communicating. Entirely my fault. > In most cases, the first (default) backend in the list finds a > suitable font, but some fonts can only be used with specific backends, > so they force Emacs to choose that backend. An example is a the *.fon > bitmapped fonts on MS-Windows, which will force the GDI backend. But the font-backend's list on Windows defaults to (harfbuzz gdi), so that's not surprising. Could Emacs automatically choose uniscribe, too, for some font, with the current default configuration, or would the user be forced to add uniscribe to the frame's font-backend list? I mean, if the answer is "yes, Emacs would use uniscribe"; then I agree with you and just not saving/restoring font-backend is the best fix. If the user has a font that needs uniscribe, and they *have* to add uniscribe to font-backend in default-frame-alist or via set-frame-parameter or whatever, then there's a (likely uncommon) use case and I think it makes at least a bit of sense to save font-backend with the frame and restore it afterwards. I hope now my misunderstanding is a bit clearer. Thanks, Juanma --000000000000b5ee6d0598bbeaae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Dec 2, 2019 at 5:09 P= M Eli Zaretskii <eliz@= gnu.org> wrote:

> We = may be mis-communicating.

Entirely my fault.

> In most cases, the first (default) b= ackend in the list finds a
> suitable font, but some fonts can only b= e used with specific backends,
> so they force Emacs to choose that b= ackend.=C2=A0 An example is a the *.fon
> bitmapped fonts on MS-Windo= ws, which will force the GDI backend.

But the font-backen= d's list on Windows defaults to (harfbuzz gdi), so that's
not surprising. Could Emacs automatically = choose uniscribe, too, for some font,
with the current default configuration, or would the user be forced to= add
uniscribe to the frame's= font-backend list?

I mean, if the answer is "yes, Emacs= would use uniscribe"; then I agree with
you and just not saving/restoring font-backend is the best f= ix.

If the user has a font that needs uniscribe, and they *ha= ve* to add uniscribe
to font-back= end in default-frame-alist or via set-frame-parameter or whatever,
then there's a (likely uncommon) use = case and I think it makes at least a bit
of sense to save font-backend with the frame and restore it afterwa= rds.

I hope now my misunderstanding is a bit clearer.

Thanks,

=C2=A0 =C2=A0 Juanma

=
--000000000000b5ee6d0598bbeaae--