From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Greselin Newsgroups: gmane.emacs.bugs Subject: bug#39082: Inconsolata v3.000 has too wide spacing Date: Mon, 13 Jan 2020 17:56:20 +0100 Message-ID: References: <83eew47kix.fsf@gnu.org> <83d0bo7gwn.fsf@gnu.org> <83a76s7eaf.fsf@gnu.org> <838smc7bwn.fsf@gnu.org> <83zher5nyt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f815db059c085c3d" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="149068"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 39082@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 13 17:59:24 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.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 1ir32e-000SAl-5j for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jan 2020 17:58:16 +0100 Original-Received: from localhost ([::1]:52980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ir32c-0006fM-Od for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jan 2020 11:58:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59481) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ir32S-0006aN-FB for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 11:58:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ir32R-0002Lf-9M for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 11:58:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53985) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ir32R-0002Kn-6e for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 11:58:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ir32Q-0001YA-5r for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 11:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Greselin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jan 2020 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39082 X-GNU-PR-Package: emacs Original-Received: via spool by 39082-submit@debbugs.gnu.org id=B39082.15789346255886 (code B ref 39082); Mon, 13 Jan 2020 16:58:02 +0000 Original-Received: (at 39082) by debbugs.gnu.org; 13 Jan 2020 16:57:05 +0000 Original-Received: from localhost ([127.0.0.1]:59958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ir31U-0001Ws-Pb for submit@debbugs.gnu.org; Mon, 13 Jan 2020 11:57:05 -0500 Original-Received: from mail-pj1-f44.google.com ([209.85.216.44]:55748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ir31S-0001WM-Tz for 39082@debbugs.gnu.org; Mon, 13 Jan 2020 11:57:03 -0500 Original-Received: by mail-pj1-f44.google.com with SMTP id d5so4394232pjz.5 for <39082@debbugs.gnu.org>; Mon, 13 Jan 2020 08:57:02 -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=Znm6YaCFOp1vpLT3hIONFRCDM9cW1Vk9B+HEuljzaTU=; b=fX1omKkLajLsvl9o6ZyGfM/2c+n2Hs+69DEsIfIKm961Zn3kKD71z66xbxH03ylqiE JlGj0qxhU6xzfJOO7QElOHtjrhfEKPopALa4nrQWKzZ4y+asFnB7ggR+wFDWv/p3pT4h jV/eXuvpW47U5+KVdSpSKjodw3TxlfNl+eis6jO81XvYh03fCSrRwr9YIDqLY0+CPCoV DhrtKmkISXTuvbJsR+UHw/tdDy3jctnTsTRNH8Oc8g5MVnsYFuMFrebT9GHLtjOqUYz6 ROIck9079YD3M/lR4ByecOLLhnKY+dnRQUEKixQk7C/zzJQIgfO03ZKDNP/3tz6VX0e4 kl0w== 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=Znm6YaCFOp1vpLT3hIONFRCDM9cW1Vk9B+HEuljzaTU=; b=mc8OE2hVHnx0OfzLpctkzvwD6epwUdZAnFPQlq5omQAu+gLaeFQzOj8Ez3OcTfpgbI LxPMXzdHi3hBNToeoRvEqCb4uiGwQEP4CN2PtLvu1hA02Bqz1hKDSdFm9N57T/bk+LzB 3ZBcqQNu+jA3CY7IS2Jh0vq5Vb9Q4mUQ2zBiga+NgoiOLWZ6KpWiiU9eTwbeBdLk9Z2t eQ/gfQZBVvCZ/epnC4YSh2n6J5nZvK8YnRPll66XEbpdA7H21sMshfv0eJsO9P3OYib/ hz9vTBcT+Hpk3/ENo2TX79f8cCLWPMPtEMoqGSNcCWd8EhALd1KC2Bd9TyJ5FONHYtC6 JbNQ== X-Gm-Message-State: APjAAAUxl/Cn4djOed9GGN9CONUU62V0at6MMRYCQKbMqGcoReXvusfl xfLsv/jeNvFh0WBAsvSg/lNEPMozF2ytvXhD5Is= X-Google-Smtp-Source: APXvYqzxC1v5JNsE8BYk83PXoVKWeCOHmwzIaQ3R1wlkfc55gCoe7mIZrYWPWz1jW6tyyDMx3DL1ppJQtPUYMC0y9MI= X-Received: by 2002:a17:902:b40b:: with SMTP id x11mr3581729plr.268.1578934616985; Mon, 13 Jan 2020 08:56:56 -0800 (PST) In-Reply-To: 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174538 Archived-At: --000000000000f815db059c085c3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've never built Emacs before (nor any other non-trivial program for that matter). If you can instruct me on doing that I will try, otherwise I don't have time to learn by myself now, I'm sorry. Andrea On Mon, 13 Jan 2020 at 17:43, Robert Pluim wrote: > >>>>> On Mon, 13 Jan 2020 18:18:50 +0200, Eli Zaretskii > said: > > >> From: Robert Pluim > >> Cc: Andrea Greselin , > 39082@debbugs.gnu.org > >> Date: Mon, 13 Jan 2020 10:27:32 +0100 > >> > Eli> So the question now becomes how come we get such a large value. > Looks > Eli> like we somehow use the space-width value instead of the charact= er > Eli> glyph's width, not sure why. I guess stepping through the code > I've > Eli> shown from xdisp.c is still necessary to understand this. > >> > >> I can reproduce this, but I don=CA=BCt know how much effort we sho= uld > spend > >> getting to the bottom of it: a Cairo-enabled build (ie !XFT) does > not > >> have this problem. > > Eli> So I guess this is some kind of Xft bug? In that case, I think = it > Eli> would be enough to describe the Cairo workaround in etc/PROBLEMS= , > and > Eli> close the bug with that. > > It=CA=BCs either a bug or a limitation in the Xft interface. I see the > width of characters coming back from XftGlyphExtents as 26, with all > the other metrics as 0, so I don=CA=BCt think there=CA=BCs much we can do= . > > Andrea, does building emacs-27 configure '--with-cairo' fix this for > you? > > Robert > --000000000000f815db059c085c3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've never built Emacs before (nor any other non-trivi= al program for that matter). If you can instruct me on doing that I will tr= y, otherwise I don't have time to learn by myself now, I'm sorry.

Andrea

On Mon, 13 Jan 2020 at 17:= 43, Robert Pluim <rpluim@gmail.com> wrote:
&g= t;>>>> On Mon, 13 Jan 2020 18:18:50 +0200, Eli Zaretskii <eliz@gnu.org> said:<= br>
=C2=A0 =C2=A0 >> From: Robert Pluim <rpluim@gmail.com>
=C2=A0 =C2=A0 >> Cc: Andrea Greselin <greselin.andrea@gmail.com>,=C2=A0= 39082@debbugs.g= nu.org
=C2=A0 =C2=A0 >> Date: Mon, 13 Jan 2020 10:27:32 +0100
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 Eli> So the question now becomes how come we get such a la= rge value.=C2=A0 Looks
=C2=A0 =C2=A0 Eli> like we somehow use the space-width value instead of = the character
=C2=A0 =C2=A0 Eli> glyph's width, not sure why.=C2=A0 I guess steppi= ng through the code I've
=C2=A0 =C2=A0 Eli> shown from xdisp.c is still necessary to understand t= his.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I can reproduce this, but I don=CA=BCt know how much= effort we should spend
=C2=A0 =C2=A0 >> getting to the bottom of it: a Cairo-enabled build (= ie !XFT) does not
=C2=A0 =C2=A0 >> have this problem.

=C2=A0 =C2=A0 Eli> So I guess this is some kind of Xft bug?=C2=A0 In tha= t case, I think it
=C2=A0 =C2=A0 Eli> would be enough to describe the Cairo workaround in e= tc/PROBLEMS, and
=C2=A0 =C2=A0 Eli> close the bug with that.

It=CA=BCs either a bug or a limitation in the Xft interface. I see the
width of characters coming back from XftGlyphExtents as 26, with all
the other metrics as 0, so I don=CA=BCt think there=CA=BCs much we can do.<= br>
Andrea, does building emacs-27 configure '--with-cairo' fix this fo= r
you?

Robert
--000000000000f815db059c085c3d--