unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "समीर सिंह Sameer Singh" <lumarzeli30@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Implementing Vertical Text support in Emacs
Date: Fri, 9 Sep 2022 00:14:45 +0530	[thread overview]
Message-ID: <CAOR1sLwNA8Fu3H595i6TR3TibfbOiapefyuJg3H3n0X4hGAryQ@mail.gmail.com> (raw)
In-Reply-To: <83mtebq0nd.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4475 bytes --]

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 <eliz@gnu.org> wrote:

> > 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.
>

[-- Attachment #2: Type: text/html, Size: 5377 bytes --]

  reply	other threads:[~2022-09-08 18:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13 15:29 Implementing Vertical Text support in Emacs समीर सिंह Sameer Singh
2022-06-13 16:16 ` [External] : " Drew Adams
2022-06-13 16:30 ` Eli Zaretskii
2022-06-15 10:08   ` Richard Stallman
2022-06-15 10:22     ` Po Lu
2022-06-15 11:09       ` समीर सिंह Sameer Singh
2022-06-16 22:48         ` Richard Stallman
2022-06-17  1:43           ` समीर सिंह Sameer Singh
2022-06-17  6:12             ` Eli Zaretskii
2022-09-08 18:44               ` समीर सिंह Sameer Singh [this message]
2022-09-08 19:05                 ` Eli Zaretskii
2022-09-10 15:53                   ` समीर सिंह Sameer Singh
2022-09-10 16:17                     ` Eli Zaretskii
2022-09-29 19:57                       ` समीर सिंह Sameer Singh
2022-09-30  6:30                         ` Eli Zaretskii
2022-11-20 11:18                           ` समीर सिंह Sameer Singh
2022-11-20 11:43                             ` Eli Zaretskii
2022-11-20 12:08                               ` समीर सिंह Sameer Singh
2022-11-24 11:39                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOR1sLwNA8Fu3H595i6TR3TibfbOiapefyuJg3H3n0X4hGAryQ@mail.gmail.com \
    --to=lumarzeli30@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).