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#20140: 24.4; M17n shaper output rejected Date: Mon, 14 Feb 2022 15:26:07 +0200 Message-ID: <83leydpok0.fsf@gnu.org> References: <20150318222040.4066e6e9@JRWUBU2> <87r18jk5nr.fsf@gnus.org> <83v8xv2icg.fsf@gnu.org> <20220205225251.08a0faab@JRWUBU2> <83sfsmpmxb.fsf@gnu.org> <20220213211152.03e2990a@JRWUBU2> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10062"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 20140@debbugs.gnu.org, larsi@gnus.org To: Richard Wordingham Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 14 15:17:04 2022 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 1nJcA3-0002Nk-Uy for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Feb 2022 15:17:04 +0100 Original-Received: from localhost ([::1]:57040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nJcA2-0006S8-G1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Feb 2022 09:17:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJbNe-0006Bd-5e for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 08:27:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46334) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJbNd-0004SR-SZ for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 08:27:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nJbNd-0007WX-Pc for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 08:27: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: Mon, 14 Feb 2022 13:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 20140-submit@debbugs.gnu.org id=B20140.164484517728862 (code B ref 20140); Mon, 14 Feb 2022 13:27:01 +0000 Original-Received: (at 20140) by debbugs.gnu.org; 14 Feb 2022 13:26:17 +0000 Original-Received: from localhost ([127.0.0.1]:40231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJbMv-0007VR-Ev for submit@debbugs.gnu.org; Mon, 14 Feb 2022 08:26:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJbMt-0007VC-7t for 20140@debbugs.gnu.org; Mon, 14 Feb 2022 08:26:15 -0500 Original-Received: from [2001:470:142:3::e] (port=58410 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJbMn-0004QF-H1; Mon, 14 Feb 2022 08:26:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZHMuJVrd8b57PWwT5hmCzBBzyMKttXYAaJn0WQjzdrk=; b=kaRRvCwr47MR pjtkzFEnhL93uTjuBZ2NLO+VcbLhNO2WogK2u94WOXX/yQNwBYxxut5kuS6Qq9yKY7owKilgY9fWI nu50iFR+uzXNCUjNMH/I3hM5E3TJl9uOvniockJ65nnQEe63CutxG4+mZBhm+xTVJVNldw85g1XQ8 Mvb79XOIZCCLUGWFE5+D6G9Bg4GyJNZDrShaTxdUJaAydNxaI6/6pB0CmxrbIvkzE6octNSFwb/1e xEvwl55wa0rxA2zb9TqPkLoYl9XqM3Ei9m5mh1qljIo8wW09ztRugzzSsHZX21xsuhs6+zmXALcqf HWFy+mVyk7qyofcTZM41Mg==; Original-Received: from [87.69.77.57] (port=1135 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJbMn-0007q4-11; Mon, 14 Feb 2022 08:26:09 -0500 In-Reply-To: <20220213211152.03e2990a@JRWUBU2> (message from Richard Wordingham on Sun, 13 Feb 2022 21:11:52 +0000) 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:226883 Archived-At: > Date: Sun, 13 Feb 2022 21:11:52 +0000 > From: Richard Wordingham > Cc: larsi@gnus.org, 20140@debbugs.gnu.org > > > Btw, the _only_ reason Handa-san and now myself were able to implement > > something like the forward/backward-char-intrusive commands is that we > > DO control which parts of text are composed and which aren't. If we > > were to follow HarfBuzz developers' advice, and were to hand all the > > text to HarfBuzz for shaping, we would need the HarfBuzz cooperation > > to implement such features in the editor. > > You mean the more sophisticated mechanisms which position the cursor > intelligently. Those two commands you named work by completely > ignoring the composition mechanism. Yes. And the reason we can ignore compositions in certain portions of the text is that we have control on what is passed to HarfBuzz. > Correct me if I am wrong, but for Arabic, is not Emacs restricted to > typewriter-like fonts? No, that's not true. I'm not aware of any such limitation; AFAIK Arabic shaping works correctly in Emacs, certainly with HarfBuzz and Emacs 27 or later. Or maybe I misunderstand what you mean by "typewriter-like" fonts? Can you give an example of a non-typewriter-like font for Arabic that I can find on MS-Windows and try? > There would be a similar problem with the use of Tai Khuen or other > tunnelling fonts for Northern Thai if you used the current mechanism > for advancing character by character. Tunnelling fonts write parts of > one cluster under the next. The Tai Khuen fonts I've seen do this by > relying on characteristics of Tai Khuen spelling. The rules don't hold > for Northern Thai, and consequently the subscript portions of > successive orthographic syllables can overwrite one another. A > sophisticated font could check for clashes, but that needs the > orthographic syllables to be passed to the shaper together. I'm not sure I understand. Does HarfBuzz know about these advancement features? We rely on HarfBuzz to give us back as many grapheme clusters as it sees fit for a given chunk of text, and we expect each grapheme cluster to include glyphs with relative offsets as needed by the script and the font. IOW, this job is delegated to the shaping engine, such as HarfBuzz; Emacs just takes the glyphs and offsets HarfBuzz gives us and blindly obeys them.