From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuSBTYW1lZXIgU2luZ2g=?= Newsgroups: gmane.emacs.devel Subject: Re: Implementing Vertical Text support in Emacs Date: Fri, 9 Sep 2022 00:14:45 +0530 Message-ID: References: <83r13sttj6.fsf@gnu.org> <87wndi6xau.fsf@yahoo.com> <83mtebq0nd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000068a6bf05e82ed340" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24719"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 08 20:46:56 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 1oWMYB-0006KV-Ob for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Sep 2022 20:46:55 +0200 Original-Received: from localhost ([::1]:50592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWMYA-0001zH-Qf for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Sep 2022 14:46:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33040) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWMWN-0000cN-Cz for emacs-devel@gnu.org; Thu, 08 Sep 2022 14:45:04 -0400 Original-Received: from mail-oa1-x2d.google.com ([2001:4860:4864:20::2d]:36677) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWMWJ-0005yx-Al; Thu, 08 Sep 2022 14:45:01 -0400 Original-Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-127ba06d03fso23219530fac.3; Thu, 08 Sep 2022 11:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=1pO0inCmYGxX8UwdTxvL91Ih0nV4n2CDD9n6MgyEhCw=; b=VbEpXGTZew8/nyYPHsQhaWgmeBQQVhWeZoKwxT3NLD9P73AkwWIHiTX/E35QCplsGl QA/GAxHn0O2Qi5N0KNe+XNarHYqdrkEKiwL5XN+iE5KLmNvo2zqlDtGBdsITGgEUCAQk 7v/545KBVUiZN1SdbKqfk0bTU7M8xp9l7qZX7zgVHI/6Ulxb6DSI35EKjtGLwd+vHmDM mMdAxyCwtxWOORHkKdNrknEUmpxIHj4h68rm3EQiqjl580Tt9tkYaWlabbwC0d6QdSxB jgZhWclUPt7pHOOTnRgHhez5JD7rfzboLAVID1NszraYDC71BQMiO+u/f85ahE1SgRsz /zDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=1pO0inCmYGxX8UwdTxvL91Ih0nV4n2CDD9n6MgyEhCw=; b=01sFFuaOXAshUJMSIPfgMO49Y33pQ3VS34FYd6GSGQh1wEdr/UudERgjzTNibkX7Be GtFb5BVgCVbzO2J9iVaGuAQawaxt8KrFy0WWUShrQ4pN5JWyTIouyPbNod50LHFIXQtP UEry5p238cFHMDkx+BomwSXhcCrJIK/p7/GLv4pTu04x4XOXs8GRdQGheE/pzvTFEnYo DumQylK/sQ4ItNE098s91a4DOp1UO0p6MAgJWlXuu17qPBSfAeg2zaGz7VXFvLzkcP1n 6szpz8f2ltcPlfTEM4b6pmWJWtGk4QGMmdaYEpd8slw0wGF9WrJMDYn46lvbSBMkWQ2o Gj6w== X-Gm-Message-State: ACgBeo0Nh/popvtMw1Q7zWstgd5MtNL9g9nuB10Y8Nq+9u8f1s07JS3U G2x5QKXQU31fR6h67W5Zhn+7gY3bXJ3NnlTZoRbA5nuSAgg= X-Google-Smtp-Source: AA6agR5n8UBAJwqOQtGpzrYbVBp8P5JmUZp2Tz4l3eXdOoXxGpiqgLWHxnKOnXAK5Zj/DvJZnRWr1TfCQeD+ZdkIsF4= X-Received: by 2002:a05:6870:d1d4:b0:12a:f8b5:6bd0 with SMTP id b20-20020a056870d1d400b0012af8b56bd0mr919000oac.42.1662662696542; Thu, 08 Sep 2022 11:44:56 -0700 (PDT) In-Reply-To: <83mtebq0nd.fsf@gnu.org> Received-SPF: pass client-ip=2001:4860:4864:20::2d; envelope-from=lumarzeli30@gmail.com; helo=mail-oa1-x2d.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:295001 Archived-At: --00000000000068a6bf05e82ed340 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well after getting some free time I started to work on this for a week or so and I have to say I am quite a bit lost :( Right now I don't care about harfbuzz or correct character composition, I only want to display rows vertically, but I don't know where to start, does modifying only display_line and move_it_in_display_line_to work? Even if this is the case, I don't know how to parse the huge display_line function and find the area of interest among the lines of wrap and hscroll code? where is the code where the matrix is filled? Regrettably my inexperience is causing hurdles therefore any guidance would be a huge help. Thank you. On Fri, Jun 17, 2022 at 11:42 AM Eli Zaretskii wrote: > > From: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 =E0=A4=B8=E0=A4=BF=E0=A4=82= =E0=A4=B9 Sameer Singh > > Date: Fri, 17 Jun 2022 07:13:33 +0530 > > Cc: Po Lu , emacs-devel@gnu.org, Richard Stallman < > rms@gnu.org> > > > > > 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. > --00000000000068a6bf05e82ed340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well after getting some free time I started to work o= n this for a week or so and I have to say I am quite a bit lost :(

Right now I don't care about harfbuzz or correct = character composition, I only want to display rows vertically, but
I don't know where to start, does modifying only display_line and mov= e_it_in_display_line_to work?
Even if this is the case, I don'= ;t know how to parse the huge display_line function and find the area of in= terest
among the lines of wrap and hscroll code? where is the cod= e where the matrix is filled?

Regrettably my inexp= erience=C2=A0 is causing hurdles therefore any guidance would be a huge hel= p.

Thank you.

On Fri, Jun 17, 2022 at 11:= 42 AM Eli Zaretskii <eliz@gnu.org>= ; wrote:
> Fr= om: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 =E0=A4=B8=E0=A4=BF=E0=A4=82=E0=A4= =B9 Sameer Singh <lumarzeli30@gmail.com>
> Date: Fri, 17 Jun 2022 07:13:33 +0530
> Cc: Po Lu <= luangruo@yahoo.com>, emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>
>
> > AFAIU, some vertical scripts are written in rows left-to-right an= d
> > some right-to-left, so you actually have 2 different layouts on y= our
> > 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.=C2=A0 This is the<= br> 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.=C2=A0 (The bidi display doesn't change i= t,
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.=C2=A0 Then i= t 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.=C2=A0 This is actually preferable if<= br> 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")?=C2=A0 If so, does Har= fBuzz support such
> > scripts and their corresponding fonts?=C2=A0 I don't know.=C2= =A0 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.=C2=A0 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.=C2=A0 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.
--00000000000068a6bf05e82ed340--