From: Alexandre Garreau <galex-713@galex-713.eu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Verticality and future of display engine and lines (bis) [Was: Re: RTL lines]
Date: Wed, 27 Oct 2021 20:46:45 +0200 [thread overview]
Message-ID: <3414507.SNmyYOu4Ja@galex-713.eu> (raw)
In-Reply-To: <83wnlyv3ua.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 6486 bytes --]
Le mercredi 27 octobre 2021, 18:18:21 CEST Eli Zaretskii a écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Date: Wed, 27 Oct 2021 16:50:17 +0200
> >
> > I just coincidentally ended on a webpage with a vertical script (which
> > surprisingly to me displayed correctly under firefox):
> >
> > https://fr.wikipedia.org/wiki/Sakhaline
> >
> > However copypasting that into emacs, or viewing the page with Eww
> > makes
> > that text incorrectly LTR. Hence I suppose emacs doesn’t yet support
> > viewing and editing TTB/BBT text as such…
> >
> > Have there been an attempt at that?
>
> No.
I feel like although RTL support is considered as a minority concern in
IT, TTB/BBT is something several orders of magnitude more esoteric…
There have been literally only *once* I saw it mentioned anywhere, and it
was in the spec of XML-FO (yet not a lot of technical details were given
about the precise implementation, especially about mixing).
> > Anyway, what would a such change require and how much would it
> > overturn the current display engine?
>
> The low level of the display engine will need to acquire a set of
> routines that work very differently from what we have there now.
>
> And I don't even understand what is being expected from this. E.g.,
> what happens when the user scrolls the window up or down? Do all the
> columns change like a snake?
I expect a full TTB buffer to behave exactly as a LTR one but turned 90°
and portrait-like instead of landscape-like (like a screen usually is)
Hence to see the rest of buffer, instead of scrolling up/down, the user
would scroll left/right.
Scrolling up/down would not be needed (and the up/down scrollbar shouldn’t
be displayed) unless the (vertical) lines are too long to fit on the screen
(which shouldn’t happen because by default they get wrapped): then you
would just scroll as little as the length of lines requires. That’s just
like when in LTR/RTL lines are too long and not wrapped and then you get a
right/left scrollbar. This is the current behavior. It just happens to
support only one direction: left/right.
The most complex scenario is when you mix LTR/RTL and TTB/BTT: then you
will get very high spacing between lines of the containing text, to leave
space for the contained text. The wikipedia page I linked initially in
the OP, under firefox ESR 78, displays a such example, here attached so you
can see it’s not an image and even supports hybrid LTR/TTB text selection.
Interestingly, this is an already existing behavior within emacs, and that
question arises under any powerful-enough unicode-supporting display: if
you add a lot of dı̇̇̇̇̇̇̇̇̇̇̇̇̇̇̇̇acritics (like here) on a character, the line becomes
taller to contain it (most of other software than emacs actually either
fails (most often) to display more than one diacritic (erroneously, since
this is a necessary display feature for some writing systems (such as
vietnamese, afair)), or (rarely, or only with Qt in textareas)
overdisplays the diacritics over the above lines, screenshot (Qt/KMail,
GTK/Emacs) attached). Interestingly, other GTK software than emacs just
fails to display several diacritic one on top of each other, and just
surimpress them all at the same place (so it’s unreadable), so emacs
performs just better than bare gtk alone.
Overdisplaying is not necessarily a bad thing (although this is not
current emacs behavior), because it keeps the typographical gray
consistent. However, it makes both sets of glyphs unreadable, so it’s
unpractical: what would be interesting is not to display totally the
contained text most of the time (maybe by making it progressively clear
from the baseline up to the top of the next line, so the user still
understands the text normally continues down), and when you move to TTB
text or the char/word/line with diacritics, to put an (partially) opaque
background under the TTB text or the char with diacritics, so at least one
of the portions of text is readable at every time, without perturbing the
beautiful typographical grey of the typesetting.
Another useful thing would be to wrap the TTB text very heavily, like
after some chars, or to display it very small (at least most of the time,
as for the last suggestion)
The final useful thing is the current behavior: simply not to display it
TTB, but LTR. I think that’s the most practical, although the less
faithful. We could however generalize into “always use the direction of
containing text for the contained text”, or rather, in our simple case
with our simple buffers: “select only one text direction for one buffer”.
That’s akin to the preferred solution of some friend of mine who simply
did set up his XeTeX config so that when he includes latin text into arabic
text, it’s written RTL, and when he includes arabic text into latin text,
it’s written LTR. Although that’s counter-intuitive and a little
confusing to native reader of both languages for the included text, he
deems that more practical as anyway such included portions of text are
usually very small (usually one word (for linguistic reference), sometimes
small sentences (typically quotes)), and “having to find the other part of
the included text portion to begin reading it and then going back to it
after being over” is considered as tiring by him (but well, he’s also a
adept of boustrophedon, although he still didn’t manage to set up any
software to support such directionality).
Btw it would be nice if emacs supported such tweaking of directionality
(although my friend wouldn’t benefit from it since he’s a user of vim, but
I’m pretty sure that would be a point in advertising emacs to him).
> > would a solution to that problem possibly cover up with the problem
> > I raised in the other almost-homonym thread?
>
> Which is what?
“Future of display engines and lines”, where I started talking about
multicolumn and that continued about sub-buffers, evolving the display
engine, how web engines wouldn’t last long enough, etc.
If we found a solution to that problem (inserting multiple columns or
subbuffers inside a window, having something more like a DOM/tree like
within TeX, etc.), would support of TTB/BTT become easier, or naturally
come along?
[-- Attachment #2: Sakhaline.png --]
[-- Type: image/png, Size: 123705 bytes --]
[-- Attachment #3: emacs.png --]
[-- Type: image/png, Size: 14556 bytes --]
[-- Attachment #4: qt.png --]
[-- Type: image/png, Size: 21207 bytes --]
next prev parent reply other threads:[~2021-10-27 18:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 12:40 RTL lines Alexandre Garreau
2021-10-18 13:18 ` Eli Zaretskii
2021-10-27 19:26 ` Alexandre Garreau
2021-10-28 6:04 ` Eli Zaretskii
2021-10-28 6:08 ` Alexandre Garreau
2021-10-28 7:03 ` tomas
2021-10-28 8:59 ` Eli Zaretskii
2021-10-27 14:50 ` Verticality and future of display engine and lines (bis) [Was: Re: RTL lines] Alexandre Garreau
2021-10-27 16:18 ` Eli Zaretskii
2021-10-27 18:46 ` Alexandre Garreau [this message]
2021-10-27 18:58 ` Eli Zaretskii
2021-10-27 19:54 ` Alexandre Garreau
2021-10-28 6:53 ` Eli Zaretskii
2021-10-28 7:12 ` Alexandre Garreau
2021-10-28 9:23 ` Eli Zaretskii
2021-10-28 14:40 ` Alexandre Garreau
2021-10-28 16:11 ` Eli Zaretskii
2021-10-28 7:18 ` Alexandre Garreau
2021-10-28 9:28 ` Eli Zaretskii
2021-10-28 14:28 ` Alexandre Garreau
2021-10-28 16:07 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3414507.SNmyYOu4Ja@galex-713.eu \
--to=galex-713@galex-713.eu \
--cc=eliz@gnu.org \
--cc=help-gnu-emacs@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.