> From: समीर सिंह 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 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.