From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vincent Lefevre 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, 1 Nov 2020 19:34:58 +0100 Message-ID: <20201101183458.GP27593@zira.vinc17.org> References: <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> <83ft5tf3zr.fsf@gnu.org> <20201101173240.GO27593@zira.vinc17.org> <83a6w1ezwv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27053"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.14.5+76 (bb407ec3) vl-127292 (2020-06-24) Cc: 44284@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 01 19:36:12 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 1kZID6-0006wa-3d for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 19:36:12 +0100 Original-Received: from localhost ([::1]:38296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZID5-0004Ep-6r for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 13:36:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZICw-0004E0-8M for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 13:36:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55151) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZICv-0003wy-VY for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 13:36:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZICv-0000Fg-Sd for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 13:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Nov 2020 18:36: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.1604255702888 (code B ref 44284); Sun, 01 Nov 2020 18:36:01 +0000 Original-Received: (at 44284) by debbugs.gnu.org; 1 Nov 2020 18:35:02 +0000 Original-Received: from localhost ([127.0.0.1]:38464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZIBy-0000EF-Bn for submit@debbugs.gnu.org; Sun, 01 Nov 2020 13:35:02 -0500 Original-Received: from joooj.vinc17.net ([155.133.131.76]:57556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZIBw-0000Dn-Fo for 44284@debbugs.gnu.org; Sun, 01 Nov 2020 13:35:01 -0500 Original-Received: from smtp-zira.vinc17.net (128.119.75.86.rev.sfr.net [86.75.119.128]) by joooj.vinc17.net (Postfix) with ESMTPSA id 19BD73A4; Sun, 1 Nov 2020 19:34:59 +0100 (CET) Original-Received: by zira.vinc17.org (Postfix, from userid 1000) id C1FBBC23E7A; Sun, 1 Nov 2020 19:34:58 +0100 (CET) Content-Disposition: inline In-Reply-To: <83a6w1ezwv.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ 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:192426 Archived-At: On 2020-11-01 19:43:12 +0200, Eli Zaretskii wrote: > > When the cache is filled with > > > > cache->ascent = ceil (- extents.y_bearing); > > > > extents.y_bearing (whose type is double) is equal to: > > > > Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002 > > Font size 14: -0x1.8p+3 = -12 > > > > With ceil(), 11.000000000000002 rounds to 12, while the expected value > > is 11. A rounding issue, as I guessed at > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#29 > > Thanks. Do you have a suggestion for a fix? Well, I think that there are 3 potential issues. 1. That fact that here, extents.y_bearing is slightly incorrect, which appears to be a bug in Cairo. If I understand correctly, Cairo can handle any font size (not just integer ones), e.g. with scalable fonts. Thus rounding cannot be avoided. Ideally one should have correct rounding on each visible result, but I suppose that this can be very complex and slow down applications, so that in general, an indeterminate rounding error may be acceptable, and applications / rendering algorithms should cope with that (when discontinuous functions are involved, such as rounding to an integer): if continuity is preserved in some way, the user will never see an error of, say, 2^(-45) pixel. Now, there's the particular case of integer font sizes, in particular with X fonts, and one may want to preserve integers exactly on the Cairo side. I don't know whether this can be done or there are tricky issues. 2. The fact that the cache->ascent integer gets incorrect in Emacs. This could be fixed either on the Cairo side (see above) or on the application (Emacs) side. In the latter case: First, if Emacs knows that under some condition, extents.y_bearing should be an integer, it could round to nearest. For instance, if this is an X font like here, is this necessarily the case? Alternatively, Emacs could use some heuristic: if extents.y_bearing is very close to an integer, assume that it should be this integer. This is rather ugly as this might yield unexpected results in some applications, but would this be OK in Emacs? 3. The fact that row->phys_ascent > row->ascent in compute_line_metrics yields an incorrect behavior. This is about the following comment: /* 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. */ Or is the bug I've reported about that is specific to the incorrect cache->ascent issue (item 2), in which case fixing (2) would be sufficient for everyone? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)