From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning Date: Sun, 01 Nov 2020 18:15:04 +0200 Message-ID: <83ft5tf3zr.fsf@gnu.org> References: <83pn4zal89.fsf@gnu.org> <20201030163125.GD27593@zira.vinc17.org> <20201030203453.GF27593@zira.vinc17.org> <20201030205702.GG27593@zira.vinc17.org> <83y2jn8lqr.fsf@gnu.org> <20201030230035.GH27593@zira.vinc17.org> <20201031004617.GI27593@zira.vinc17.org> <20201031011350.GJ27593@zira.vinc17.org> <83r1pe975u.fsf@gnu.org> <20201031224324.GK27593@zira.vinc17.org> <20201101002430.GL27593@zira.vinc17.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33596"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44284@debbugs.gnu.org To: Vincent Lefevre Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 01 17:18:37 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kZG3x-0008dM-LI for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 17:18:37 +0100 Original-Received: from localhost ([::1]:36512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZG3w-0008F8-N1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 11:18:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZG1S-00063P-2h for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:16:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZG1R-0004dL-Mc for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:16:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZG1R-0000yN-IF for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:16:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Nov 2020 16:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44284 X-GNU-PR-Package: emacs Original-Received: via spool by 44284-submit@debbugs.gnu.org id=B44284.16042473343706 (code B ref 44284); Sun, 01 Nov 2020 16:16:01 +0000 Original-Received: (at 44284) by debbugs.gnu.org; 1 Nov 2020 16:15:34 +0000 Original-Received: from localhost ([127.0.0.1]:38305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZG0z-0000xi-Us for submit@debbugs.gnu.org; Sun, 01 Nov 2020 11:15:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZG0y-0000xW-N9 for 44284@debbugs.gnu.org; Sun, 01 Nov 2020 11:15:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56812) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZG0p-0004Pt-Ie; Sun, 01 Nov 2020 11:15:26 -0500 Original-Received: from [176.228.60.248] (port=2087 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZG0i-0007eQ-VA; Sun, 01 Nov 2020 11:15:21 -0500 In-Reply-To: <20201101002430.GL27593@zira.vinc17.org> (message from Vincent Lefevre on Sun, 1 Nov 2020 01:24:30 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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.io gmane.emacs.bugs:192413 Archived-At: > Date: Sun, 1 Nov 2020 01:24:30 +0100 > From: Vincent Lefevre > Cc: 44284@debbugs.gnu.org > > The issue is in xdisp.c, function compute_line_metrics. > > With size 14, one gets row->height = 14 and everything is fine. > > With size 13, one gets row->height = 13 initially, but one enters > the following condition: > > /* If first line's physical ascent is larger than its logical > ascent, use the physical ascent, and make the row taller. > This makes accented characters fully visible. */ > if (row == MATRIX_FIRST_TEXT_ROW (it->w->desired_matrix) > && row->phys_ascent > row->ascent) > { > row->height += row->phys_ascent - row->ascent; > row->ascent = row->phys_ascent; > } > > where row->height is increased to 14, hence the issue with the first > line. One successively gets > > it->current_y = 0 > it->current_y = 14 > it->current_y = 27 > > adding 13 each time for the following lines. Thanks, this makes sense. But the reason for this is still TBD. > With size 14: > row->phys_ascent = 12 > row->ascent = 12 > > With size 13: > row->phys_ascent = 12 > row->ascent = 11 > > I don't know where phys_ascent comes from, but it does not seem to be > in the font description. It does come from the font data, or at least it should. See below. > Anyway, this case is not handled correctly by Emacs. I think the jury is still out on this issue. > Note also that when building without cairo (--without-cairo), I get > with size 13: > > row->phys_ascent = 11 > row->ascent = 11 Interesting. Once you understand where did the value 12 come from, perhaps you could see how things are different in a non-Cairo build. Let me describe how row->phys_ascent is computed, so that you could take a closer look. In general, both the row->ascent and row->phys_ascent values are computed from the metrics of the character glyphs of the screen line. The difference between them is that the former is affected by various features such as the line-spacing and text properties that modify the height of the text, whereas the latter keeps the value gleaned from the character metrics. The row->ascent and row->phys_ascent are assigned by display_line, using the maximum values of ascent and phys_ascent of all the glyphs laid out on the screen line. These latter values are tracked by it->max_ascent and it->max_phys_ascent. For each character display_line examines, it calls gui_produce_glyphs (via the macro PRODUCE_GLYPHS), and there we have this fragment: if (get_char_glyph_code (it->char_to_display, font, &char2b)) { pcm = get_per_char_metric (font, &char2b); if (pcm->width == 0 && pcm->rbearing == 0 && pcm->lbearing == 0) pcm = NULL; } if (pcm) { it->phys_ascent = pcm->ascent + boff; it->phys_descent = pcm->descent - boff; it->pixel_width = pcm->width; This is where these values start: from the per-character metrics we get from the font. Near the end of gui_produce_glyphs, we have this: it->max_ascent = max (it->max_ascent, it->ascent); it->max_descent = max (it->max_descent, it->descent); it->max_phys_ascent = max (it->max_phys_ascent, it->phys_ascent); it->max_phys_descent = max (it->max_phys_descent, it->phys_descent); This accumulates the maximum values of all the glyphs. Back in display_line we have, a little ways after the call to PRODUCE_GLYPHS: row->ascent = max (row->ascent, it->max_ascent); row->height = max (row->height, it->max_ascent + it->max_descent); row->phys_ascent = max (row->phys_ascent, it->max_phys_ascent); row->phys_height = max (row->phys_height, it->max_phys_ascent + it->max_phys_descent); (This is the mainline of the algorithm; you will see that there are few special cases where we don't take the values from the font glyphs, but from other sources. Perhaps this could explain the strange situation you see with this particular font.) So now the question becomes: which of the characters on the window's first screen line, or some other condition there, causes the row->phys_ascent value become larger than row->ascent? And why does this not happen in a non-Cairo build? Thanks.