Re: Implementing Vertical Text support in Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: समीर सिंह Sameer Singh
>  <lumarzeli30@gmail.com>
> 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.