Re: Verticality and future of display engine and lines (bis) [Was: Re: RTL lines]

[Alexandre Garreau]

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?

Sakhaline.png
Description: PNG image

emacs.png
Description: PNG image

qt.png
Description: PNG image