From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniele Nicolodi Newsgroups: gmane.emacs.devel Subject: Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Date: Thu, 6 May 2021 22:24:36 +0200 Message-ID: <239550bd-88a4-e1c8-e313-d4287458ec84@grinta.net> References: <871ramlbpy.fsf@telefonica.net> <87fsz1zmhv.fsf@gmail.com> <87sg30usa2.fsf@gmail.com> <83mtt8dvft.fsf@gnu.org> <87a6p8w0b7.fsf@gmail.com> <83h7jgdqhs.fsf@gnu.org> <531453ddd626d93fbb46@heytings.org> <83czu3evks.fsf@gnu.org> <531453ddd6aad581d339@heytings.org> <831rajesgw.fsf@gnu.org> <83sg2zda04.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19918"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 06 22:25:44 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lekZ6-00053P-Ax for ged-emacs-devel@m.gmane-mx.org; Thu, 06 May 2021 22:25:44 +0200 Original-Received: from localhost ([::1]:33714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lekZ5-0005nC-E4 for ged-emacs-devel@m.gmane-mx.org; Thu, 06 May 2021 16:25:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57550) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lekY6-00058A-Hu for emacs-devel@gnu.org; Thu, 06 May 2021 16:24:42 -0400 Original-Received: from grinta.net ([109.74.203.128]:34904) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lekY4-0003Fv-3M for emacs-devel@gnu.org; Thu, 06 May 2021 16:24:42 -0400 Original-Received: from black.local (p4fe717e2.dip0.t-ipconnect.de [79.231.23.226]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id A68E0E0F1B for ; Thu, 6 May 2021 20:24:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1620332678; bh=Hcawichv4d/u6W0A/hBoZ/jHkkbxUeR4kgu1xhvwQw0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mRFBGceogEXi2eLXIxCGQeg3F22uoGxOzOSCIFWe+w0quPvJc4qQjvN+QXtxDnh2F icglpv07NCuz5SMuuExZzKBU0F/9lJKa+e9fLBgy8FdMrkPLTXeu+YiNLAsjEUAVKt h71A8LnNYsGlpRrdFXTGc5jvJqfbGQrplibrVpKSRCofAp+sS32Ggb8gn6H9Fiekna vHADc870Q6Xfh3eC377ajwAWo4ucWDzoHbtINuxdMJwxWkYOOpgAVQH3i/hgbM5/L9 2gdy3IPGn9Cx/PRb8B4xie2dKIpWqUqw+vAdTm8jvYrkIax7x8trtz63zl3EUIorwd E6X3BOTq7Z2QA== In-Reply-To: <83sg2zda04.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268991 Archived-At: On 06/05/2021 19:53, Eli Zaretskii wrote: >> From: Daniele Nicolodi >> Date: Thu, 6 May 2021 18:57:46 +0200 >> >> I didn't look at the code, but I don't think this is true: on my Emacs, >> lines containing only "." or containing only "l" have exactly the same >> height, as I would expect. > > You assume that the metrics of these two glyphs are different in > monospaced fonts? > >> Also, lines containing only a new line character (thus no printable >> characters) still have the same height as lines with content, as >> expected. > > Newline leaves no glyphs on display, so their metrics cannot be > calculated from the font. > >> Are you sure Emacs does not consider the maximum ascent and descent of >> each _font_ contained in a line and not of each _glyph_? > > Why do you think there's a difference? Sorry for using a sloppy terminology, I don't work with these concept often. Fonts have a logical size and a ink size. See for example https://docs.gtk.org/Pango/method.GlyphString.extents.html I meant to say that Emacs may be looking at the logical size of the glyphs, which, for a monospaced font is indeed supposed to be the same for every glyph, not at the ink size. This small Python script prints the ink ang logical ascent and descent for the "Fira Code 14" font for each command line argument: import sys import gi gi.require_version('Pango', '1.0') from gi.repository import Pango gi.require_version('PangoCairo', '1.0') from gi.repository import PangoCairo map = PangoCairo.font_map_get_default() ctx = map.create_context() font = ctx.load_font(Pango.FontDescription('Fira Code 14')) def pixels(x): return (x + 512) >> 10 def ascent(rect): return pixels(-rect.y) def descent(rect): return pixels(rect.y + rect.height) def extents(text): item = Pango.itemize(ctx, text, 0, len(text), Pango.AttrList(), None) glyphs = Pango.GlyphString() Pango.shape(text, -1, item[0].analysis, glyphs) return glyphs.extents(font) for text in sys.argv[1:]: ink, logical = extents(text) print(" text:", repr(text)) print(" ink:", ascent(ink), descent(ink)) print(" logical:", ascent(logical), descent(logical)) print() Please note that this is my first time using the Pango API for something like this, thus there may be better ways to do it. Cheers, Dan