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.devel Subject: Re: Implementing Vertical Text support in Emacs Date: Fri, 17 Jun 2022 09:12:06 +0300 Message-ID: <83mtebq0nd.fsf@gnu.org> References: <83r13sttj6.fsf@gnu.org> <87wndi6xau.fsf@yahoo.com> 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="31015"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org, rms@gnu.org To: =?utf-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuSBTYW1lZXIgU2luZ2g=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 17 08:22:59 2022 Return-path: Envelope-to: ged-emacs-devel@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 1o25Nj-0007pT-FB for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 08:22:59 +0200 Original-Received: from localhost ([::1]:37310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o25Ni-0000Li-1K for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 02:22:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o25DL-0002E6-Iq for emacs-devel@gnu.org; Fri, 17 Jun 2022 02:12:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o25DL-0005c0-9J; Fri, 17 Jun 2022 02:12:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=1O+myvLnntlJgXiAN84GdUsIFN2RG1dlU4au0t/Un84=; b=Zj1N5OvGl9OBW/4+griq inBHWoSnASlVSIRtlD/l6hYYyxSWCIoWWfh5lHSxc0874qYVypRYwc1TMh4onkJeTDecLsYAA3Zin KEk2i/1KdF7X8idTm4N1AhI4zVYYgKZRaEyei0+Z+vdccMJT7/dhZB2nvS/SGPdgW4AQNhxBr6S0j oHxyBfd5+KlkdiYmDOxj+DNVAsFVC6teyMGEX3FyIP2LCE+t3vltm0l6luSOtft0pI6kxRSyNYW/t YKENKS34KWP26gXiw10cMLGTQGRY2+nbxTvO6GW5qTdCMrGxqjoD8+aMr36ONy10YGQ05FmdW0TSz aPRizM1LnZ/0Yw==; Original-Received: from [87.69.77.57] (port=2646 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 1o25DH-0005dK-C3; Fri, 17 Jun 2022 02:12:11 -0400 In-Reply-To: (message from =?utf-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuQ==?= Sameer Singh on Fri, 17 Jun 2022 07:13:33 +0530) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291271 Archived-At: > From: समीर सिंह Sameer Singh > Date: Fri, 17 Jun 2022 07:13:33 +0530 > Cc: Po Lu , emacs-devel@gnu.org, Richard Stallman > > > AFAIU, some vertical scripts are written in rows left-to-right and > > some right-to-left, so you actually have 2 different layouts on your > > hands. > > Scripts like Mongolian are written only in one direction: ltr, but CJK > characters are bidirectional i.e. > they can either be written from ltr or from rtl .How should we support that? The low-level terminal-specific code which outputs the series of glyphs (a.k.a. "glyph strings") to the glass will have to figure it out, as part of the general support for vertical layout. This is the code you will find in the various *term.[cm] files. The current terminal-specific code which writes to the glass always outputs stuff left-to-right, one screen line after another and in generally top-to-bottom order. (The bidi display doesn't change it, it just arranges for the glyph rows to have a stretch glyph (which displays as a stretch of background-color space) of a suitably calculated width as the first glyph of the glyph row, and the rest of the glyphs are put into glyph rows in their visual order.) The code which will support vertical layout will probably need to change that, and draw "glyph columns" top to bottom. Then it could decide whether to start at the left or the right side of the window. Alternatively, there could be an intermediate step that converts column-wise series of glyphs into glyph rows (or maybe fills the glyph rows directly in the first place); then the level that writes to the glass could remain largely unchanged. This is actually preferable if we want to support vertical layout on TTY frames, because any method other than writing characters left-to-right will be much slower on text-mode terminals, due to the need of sending commands to move the output cursor. > > Do vertical-layout scripts require complex text shaping > > (a.k.a. "character composition")? If so, does HarfBuzz support such > > scripts and their corresponding fonts? I don't know. We may need a > > different shaping engine (if one exists). > > Yes they require complex text shaping and Harfbuzz supports it. Then you will need to make sure that HarfBuzz returns in that case the same information as in the horizontal case, regarding the pixel offsets of the individual parts of a grapheme cluster. For example, is the X offset still measured horizontally in that case and the Y offset still measured vertically, or did they swap the directions? It's also possible that composite.el will have to be modified, if we want the likes of compose-gstring-for-graphic to work with the vertical layout. > Also how would I test the new changes I would make in xdisp.c? There's a small test suite in test/manual/redisplay-testsuite.el, and another one in test/src/xdisp-tests.el, but by and large the only way is to just use Emacs and fix any problems that pop up. We don't currently have a good way of testing the display engine, because that requires some infrastructure to detect display effects automatically. Btw, in addition to display_line, the other places that will probably need changes are the move_it_* family of functions, starting from move_it_in_display_line_to -- those are used in code that needs to make layout decisions without displaying anything, for example when Emacs decides where to set the window-start point after scrolling the window.