Le mercredi 27 octobre 2021, 18:18:21 CEST Eli Zaretskii a écrit : > > From: Alexandre Garreau > > 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?