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: Mon, 13 Jun 2022 19:30:53 +0300 Message-ID: <83r13sttj6.fsf@gnu.org> References: 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="16026"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuSBTYW1lZXIgU2luZ2g=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 13 18:32:41 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 1o0mzY-000412-Ro for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Jun 2022 18:32:41 +0200 Original-Received: from localhost ([::1]:41392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0mzX-0005ZU-Jn for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Jun 2022 12:32:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0my3-0004kK-Rs for emacs-devel@gnu.org; Mon, 13 Jun 2022 12:31:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42108) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0my3-0000Wk-Jb; Mon, 13 Jun 2022 12:31:07 -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=qPG9r12B7LwmkjSYYK5tismiyqAU9tzOAch388gI4IM=; b=GnZxhjYaK6WfwDu2RhBy HngjnAAOc3NWDa6CD4yE+3qwt+grjRyLuwxhQczyLmxgFTvzxk75q/nSsoxAQ8fnvOppCYglgPWtu QxzPHXdVqsPGxkurRDiEbG+p48pD4P+dLF8JVXf2suJ/3M068gBZK2FMq+sP6PZeGG/sXfsmkwcxV UyKecHPndWUfcS/pl//gejabrQ6WEr8md0JT/Npl6VZf8gZ6Su6xu80Lyc6AywIUqe9zPYSARiRnX agNlfd7TBAW1k0rrBe6n8ul/ZGeVHZRHbR9u4ws8GVB+wFlIm2CZFgNVkyK+vnwzMokzI2QdPntVK XXdafBC3PewmYg==; Original-Received: from [87.69.77.57] (port=1816 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 1o0my2-0003pD-Vx; Mon, 13 Jun 2022 12:31:07 -0400 In-Reply-To: (lumarzeli30@gmail.com) 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:291150 Archived-At: > From: समीर सिंह Sameer Singh > > Date: Mon, 13 Jun 2022 20:59:45 +0530 > > Recently while implementing the Mongolian script, I thought, maybe vertical text support should be added to > Emacs too. > > Vertical text is used in scripts like the CJK characters, Mongolian, Phags Pa, Ogham etc. > Scripts like the CJK characters do not need to be rotated when written vertically and can be written either > from ltr or rtl, > while scripts like Mongolian are rotated and written from left to right. > > So my questions are: Should this be done? No one but yourself can answer that question. Obviously, scripts that are written vertically do exist, so adding such capabilities to Emacs will make Emacs more powerful, and is therefore a Good Thing, at least in principle. Whether that advantage is worth the effort and the additional complexities in the Emacs display code and the related parts (see below), is not something that can be easily answered, at least not until we understand the implications better. In general, I'd say YES, assuming there's motivation and will to see this through. > If so, where should I start. Start by reading the large commentary at the beginning of xdisp.c, which providers a general overview of the display engine and its basic structure and algorithms. After you digest that, we'd need to talk about the details, because they are non-trivial. Let me show you the tip of the iceberg (and it could be that what I say below won't make sense until you read that commentary). Emacs display is basically built around a 2D structure called "glyph matrix". The rows of each matrix correspond to screen lines of the window to which the matrix belongs. The display engine works by updating the matrix given the up-to-date buffer text, then reflecting its rows on the glass. For vertical layout, we'd need to consider each row to correspond to a screen _column_. This will require to write a vertical version of the display_line function, whose job is to produce a single row of the glyph matrix, because the layout and dimensions of the vertical text are different, and so are the various layout decisions. There will be secondary, but nevertheless important, issues, like how to wrap columns, how to indicate the wrap-around (what we currently do with fringe bitmaps for continued lines), etc. The code which converts screen coordinates to the cell in the glyph matrix and to buffer positions (it is used to process mouse clicks, for example) will also need to have its own vertical version. 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. Some redisplay optimizations will need to be rewritten for vertical text, since at least some of them are based on window-system features like moving blocks of pixels. Or maybe we will decide that some optimizations will not be used for vertical text. Then there will be issues with scrolling: do we swap horizontal and vertical scrolling for vertical-layout text, or do we keep the scroll direction (in which case we need to decide what it means to scroll up or down)? There will be more -- there's always more when Emacs display is concerned. The iceberg is very large, not unlike the one we faced when support for bidirectional display was designed and implemented. > How to correctly mix non vertical and vertical scripts in the same buffer, if it is even possible. This is an even tougher issue. Is support for such mixed scripts a necessity without which the entire feature won't make sense? If not, I'd suggest to limit yourself to either vertical or horizontal layout, leaving the mix of the two unsupported for starters. If mixing them is a must, everything I said above needs to be rethought, and it could even be that the current design of the display engine simply cannot be extended to support that. > Should this be a minor mode only? Why does it matter how we turn on or off this feature? This is the easiest decision to make, negligible when compared to the effort required to implement the stuff in the first place. > OTF Tags for vertical text: > https://docs.microsoft.com/en-us/typography/opentype/spec/features_uz#tag-vert > https://docs.microsoft.com/en-us/typography/opentype/spec/features_uz#tag-vrtr 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). > This is what the UAX#9 says about bidi text in vertical orientation: > https://unicode.org/reports/tr9/#Vertical_Text Bidirectional reordering of vertical-layout text is the least of your concerns. Either it is reordered exactly as our implementation already does, and just drawn vertiually, in which case the problem is already solved; or it isn't reordered at all, in which case the problem doesn't exist in the first place. Thanks.