From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#41645: 27.0.91; Combining Grapheme Joiner (#x34f) gui artifacts Date: Tue, 2 Jun 2020 15:39:15 +0100 Message-ID: References: <83zh9merd4.fsf@gnu.org> <83wo4qepab.fsf@gnu.org> <83lfl6eiod.fsf@gnu.org> <87367dzgbm.fsf@gmail.com> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="29078"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 41645@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 02 16:43:14 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 1jg88I-0007TF-KM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Jun 2020 16:43:14 +0200 Original-Received: from localhost ([::1]:44660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jg88H-0007lw-Ns for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Jun 2020 10:43:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jg886-0007ln-DF for bug-gnu-emacs@gnu.org; Tue, 02 Jun 2020 10:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jg886-0006PG-2G for bug-gnu-emacs@gnu.org; Tue, 02 Jun 2020 10:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jg885-0007Bx-VQ for bug-gnu-emacs@gnu.org; Tue, 02 Jun 2020 10:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jun 2020 14:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41645 X-GNU-PR-Package: emacs Original-Received: via spool by 41645-submit@debbugs.gnu.org id=B41645.159110893227588 (code B ref 41645); Tue, 02 Jun 2020 14:43:01 +0000 Original-Received: (at 41645) by debbugs.gnu.org; 2 Jun 2020 14:42:12 +0000 Original-Received: from localhost ([127.0.0.1]:40541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg87I-0007As-88 for submit@debbugs.gnu.org; Tue, 02 Jun 2020 10:42:12 -0400 Original-Received: from mail-qt1-f169.google.com ([209.85.160.169]:40793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg87G-0007Ad-JV for 41645@debbugs.gnu.org; Tue, 02 Jun 2020 10:42:10 -0400 Original-Received: by mail-qt1-f169.google.com with SMTP id i16so4145528qtr.7 for <41645@debbugs.gnu.org>; Tue, 02 Jun 2020 07:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dw2NYg86k3CAxzjfRf4xIgkaUkgOD1cCinJo3712r9A=; b=K3NuJ7LRvo2Z9yTjQbcgtgs7MXimiD5FSna9+2VSI5+0MSsZ9XPt151ZdyNiHRMEv3 +7Xp2K0EXLfkACysTbgljQwtGNjkD8LSuNQhcyOZXWny0eOd9jVD2oQgyAx3NnRlPQCB kod96pBqffWn1qSH7V64SihboslfxVq8AanCl0MY34nMvoDEdfMX5hy8bIeX6VW2YCST vIEo1ofpMQBw9wJuk1xLgsikdJTj90tYIlVsntxfIGXfn63fStzZw7piwiOI/UJZftwu Wl4yHRgTU0JTxjg+nh1fXlM8zMm+Ig+RRHByofHb9hDI92Yam5M77E8vuWEt/tYObpgK CMhQ== 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=Dw2NYg86k3CAxzjfRf4xIgkaUkgOD1cCinJo3712r9A=; b=c49QGfeQkB5PUB2AgFOQJszZCtrWQCK8XTyJTPgmT7Zam/egnMpJ0xI6jHErIyBjG9 +B8zNYtdEaQrV5vOuC7IUvZ4l/xKjOkIgYcbHaUGh4ape8WRNP8n/x5x5QwB7bCtuhDc tdwRmtGB5J1ocnNmH6ZNcEmEx3mjyVwaHYD4WoOzVlNiz4qe3HC5i4s4g/ubNVKJafdD 3AJyI5mugywpmKbX1nhh6WekKKwfI/oge4Yws/QyM35v7Ui+Gxw4+KroXkV6122q4hKw PMoH655kN3mKr92/tmi7vsR/cKsPs67DUqCCORv9685BAIY+bTVGQc1we9OiH3r5WjF5 hLBw== X-Gm-Message-State: AOAM533I8mLaqN1Bb9BNoIJQplO6Eu8FfIZwhip0y4Lz+n1fPv3+rgLd WSYe/E2i1tMAVUWZ5twEuR/dcLhKTpta43UZVds= X-Google-Smtp-Source: ABdhPJzazvXWcGLrXdByerQeyZXPkZjHGVZGKwZOL0IK++piNH7q3VvV90zJofvWXaTw2ZIHVy3iVroruJnXhzHN9Gw= X-Received: by 2002:ac8:5494:: with SMTP id h20mr28053057qtq.247.1591108925006; Tue, 02 Jun 2020 07:42:05 -0700 (PDT) In-Reply-To: <87367dzgbm.fsf@gmail.com> 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:181399 Archived-At: On Tue, 2 Jun 2020 at 15:35, Pip Cet wrote: > > David Fussner writes: > > A couple of data points, in case they're helpful: > > Thanks again for testing. > > > On 27.0.91 _unpatched_, I see the artifact whenever the font of the > > CGJ is different from that of the glyph before it, no matter which > > script I'm using. When the font of the CGJ and the previous glyph are > > the same, I don't see the artifact, except in Hebrew, where it's still > > present. > > Which font are you using for Hebrew text? DejaVu Sans, in this instance, which at least has its own CGJ. > > > C-u C-x = displays the CGJ on its own, as a separate glyph, > > whenever it's used in Hebrew and also whenever its font doesn't match > > that of the glyph before it. When the font does match, in Latin or > > Greek script, the cursor doesn't stop on the CGJ, and C-u C-x = shows > > it as composed with the previous character. > > > That sounds as it should be. I'm not sure I understand what you're > seeing in Hebrew text, though: you said you saw the artifact there, but > also that the CGJ is displayed as a separate glyph. Is that corrcet? Yes, C-u C-x = doesn't present the CGJ as having been composed with anything else in Hebrew text. > > > With Pip Cet's second patch, 27.0.91 shows exactly the same behavior > > with C-u C-x =, but the visual artifact never appears, at least in my > > testing, neither in Hebrew nor in the LTR scripts. > > So that sounds like an improvement. > > While I think we definitely want the patch I sent , it doesn't solve the > real issue: zero-width glyph strings. If we want to allow those, a lot > of the display code has to be changed (we're going to have to figure out > how to show the cursor, for starters); if we don't, that's a change to > the composition-function interface, albeit a minor one. > > > Hope this helps. > > > > On Mon, 1 Jun 2020 at 23:37, Pip Cet wrote: > >> > >> On Mon, Jun 1, 2020 at 7:48 PM Pip Cet wrote: > >> > > > Indeed, the composition gstring is a single zero-width glyph. > >> > > See the composition information above: my interpretation of it is that > >> > > the composed glyph is not zero-width. > >> > > >> > ... something is odd here, I agree. > >> > >> I think it's a very odd combination of things: > >> 1. a font which defines an isolated CGJ to have zero width > >> 2. an isolated CGJ appearing in the first place (in this case, because > >> another font does not support CGJ) > >> 3. the fall-back [nil 0 compose-gstring-for-graphic] rule defined for > >> codepoint #x34f > >> 4. compose-gstring-for-graphic attempting to salvage non-spacing > >> characters not following base characters, and producing zero-width > >> lgstrings from zero-width lglyphs > >> > >> Avoiding any of the four will avoid the problem. (1) is something we > >> cannot fix directly. (2) is also something that a user may want. (3) > >> could be dropped, and (4) could be expanded to take care of the > >> zero-width case. > >> > >> However, as long as zero-width gstrings can somehow slip through, I > >> suggest we also apply the patch I sent, assuming it fixes the problem. > >> > >> We might consider simply prohibiting zero-width zero-lbearing > >> zero-rbearing gstrings, the way we prohibit zero-width zero-lbearing > >> zero-rbearing characters in the code I posted.