From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#41005: problem with rendering Persian text in Emacs 27 Date: Thu, 04 Jun 2020 19:52:42 +0000 Message-ID: <87pnae4nhx.fsf@gmail.com> References: <831rmwc9ke.fsf@gnu.org> <35A46479-A62C-42FF-995B-B295FE3408C0@gnu.org> <08A9D65F-0C9C-4EE2-B3B9-2AA25BFFAD54@gnu.org> <878sh35j6f.fsf@gmail.com> <83y2p3as6c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="79451"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: valizadeh.ho@gmail.com, 41005@debbugs.gnu.org, nicholasdrozd@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 04 21:54:43 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 1jgvwn-000KZa-LJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Jun 2020 21:54:41 +0200 Original-Received: from localhost ([::1]:35568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgvwm-0003EB-NK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Jun 2020 15:54:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46710) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgvvC-0000Ve-Hq for bug-gnu-emacs@gnu.org; Thu, 04 Jun 2020 15:53:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgvvC-0008Qi-7M for bug-gnu-emacs@gnu.org; Thu, 04 Jun 2020 15:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jgvvC-0000ta-5a for bug-gnu-emacs@gnu.org; Thu, 04 Jun 2020 15:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Jun 2020 19:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41005 X-GNU-PR-Package: emacs Original-Received: via spool by 41005-submit@debbugs.gnu.org id=B41005.15913003753425 (code B ref 41005); Thu, 04 Jun 2020 19:53:02 +0000 Original-Received: (at 41005) by debbugs.gnu.org; 4 Jun 2020 19:52:55 +0000 Original-Received: from localhost ([127.0.0.1]:47518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgvv5-0000tB-5R for submit@debbugs.gnu.org; Thu, 04 Jun 2020 15:52:55 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:46592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgvv3-0000sw-Iz for 41005@debbugs.gnu.org; Thu, 04 Jun 2020 15:52:53 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id x6so7374282wrm.13 for <41005@debbugs.gnu.org>; Thu, 04 Jun 2020 12:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=7LLXt/gQRPdcPgBLCRWiXy1dIoUmKsABdt3Ttt1x0O0=; b=IDyq+9yBv2P9c6b586daKRH8PqTIIt0DmoB0G7ykR8OLQW6nF1CMHpGWKw2TzrF9bL o8o4CP39baqkAsai9tW+ohkQuGWk4yfzQ+JMK9HgntR08Fp2qYGfANDw2ZVSB0g6Kfwe 2xSFQxG1iDg5kh5Gc1v2QONhLNrg5oiR0HkUhJUplHpiNUpX3o2NdApLoRt79Y8PUtC2 c7VYb+L4k0LgHqvjHNHPI7g4XldcsYpFZNm/1RGubkO24aBZF0z7vHEbrG8jzUshJaYH Kv8AWY9BdmLY8ZxH9lppcRxlwAWZm9P7vxaHZihBZFL/11ATOhNSnPBbw8w3o9LLEBoN cyXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=7LLXt/gQRPdcPgBLCRWiXy1dIoUmKsABdt3Ttt1x0O0=; b=eH9sXv3HEQQNG0nz4C5kSOQwuPqfImuH+lRsYje4HER3Laq9PZ7iGGobe1ElAW8dYn GuSKWjO13/otiqZbPq3wQdzBvYXt1fYuslaY0AJdcsZqRd7YvIr359idzFf3ZD1MPy8o ON5paP3Wid6o2sJuEo8tsOY/Weorrl0v0H0eXwRUTblTlo4OmSZj2mA5d4NJmBF8Nibl f3A3/JOMXrGMmotCZB/yAK4gpg+dQe7IXQRs65Uf6aldu1Km8d0vMyxJFu6Oc8VgA/O+ 7ijBQl0F/fSkeq7v+kLuj5C0NmmiCUjhlHGhnq71Ega/Dfm5mnSFkVVHrezEIu6Y/E69 reOQ== X-Gm-Message-State: AOAM530oob4jChskKjySVRn7lvYjYeNVg29NfXcO2WWlClY5FLLwak1c L5KxzuT9EllaETqJC8Tvpyk= X-Google-Smtp-Source: ABdhPJz4Lt0B/VuP/qGe2V9yZAr8nFrnbcaCd5uijvV1Xaql9YThi53jpOh681eHuaJ2QDUqdxp2SA== X-Received: by 2002:adf:c391:: with SMTP id p17mr5618867wrf.243.1591300367518; Thu, 04 Jun 2020 12:52:47 -0700 (PDT) Original-Received: from chametz (tor-exit-1.yui.cat. [185.107.83.71]) by smtp.gmail.com with ESMTPSA id t188sm3658105wmt.27.2020.06.04.12.52.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2020 12:52:46 -0700 (PDT) In-Reply-To: <83y2p3as6c.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Jun 2020 16:15:07 +0300") 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:181524 Archived-At: Eli Zaretskii writes: >> From: Pip Cet >> Cc: Eli Zaretskii , 41005@debbugs.gnu.org, >> nicholasdrozd@gmail.com >> Date: Thu, 04 Jun 2020 08:28:24 +0000 >> >> What happens is that font-shape-gstring is called with direction == L2R, >> mis-shapes the text, then caches that version in the composition gstring >> cache. The cache doesn't distinguish directions, and it's never cleared, >> so this "infects" other buffers, but only if they're opened afterwards, >> and only for the same words. >> >> shr appears to force bidi-display-reordering off. Removing that let >> binding from shr-insert-document avoids the problem. >> We should consider adding direction to our gstrings, on master. While >> we're there, let's also add script, language, and harfbuzz features to >> the gstrings so we know we've captured the precise harfbuzz parameters? > > On emacs-27, I can fix this by a simpler band-aid below. > On master, I think we should indeed add direction to the cached > gstrings, as there could be other much more subtle situations where > looking at bidi-display-reordering is not enough, and we could then > still cache a composition with the wrong direction. Patches welcome. Sure, such subtle situations exist. > As for script and language, for now adding them would just waste > memory, since we don't yet have any meaningful support for > buffer-local, let-alone paragraph-local, scripts and languages. When > we added HarfBuzz support, I considered adding some functionality to > determine language and/or script from the codepoints, but decided that > it made little sense, since HarfBuzz already does exactly that in > hb_buffer_guess_segment_properties. So I think we should add to the > FIXME in hbfont.c the fact that when we do support those internally in > Emacs, we should add these attributes to cached gstrings, but not yet > actually add them for now. We're going to have to change the lgstring structure, though, right? Could we maybe get away with just doing so once? My suggestion would be to add a single field to gstrings which would currently be L2R or R2L but might become an alist or something when we get around to adding those features? > Here's the patch I propose for emacs-27: Let's try that.