BiDirectional text support

[XVilka]

In the modern world, the support for some languages that are right-to-left and mixing them with left-to-write words and numbers is crucial for a different software. At some point, this should be supported everywhere, including the console.

I started to gather the information about BiDi support in various console terminals (and programs) in analogy with true color crusade at https://gist.github.com/XVilka/a0e49e1c65370ba11c17

New console BiDi specification was recently implemented in libvte by @egmontkob: https://terminal-wg.pages.freedesktop.org/bidi/implementations.html#vte

Note, that with the release of GNOME 3.34 the support of BiDi is available in Gnome Terminal out of the box, which makes testing/implementing it in the other programs, such as kitty way easier.

[ctrlcctrlv]

Why not use fribidi

[ctrlcctrlv]

In master you can now use Fribidi if you enable force_ltr. See #2293

[ctrlcctrlv]

@egmontkob Sorry to bother you. We've corresponded briefly. Would you have an answer to why Fribidi isn't sufficient? Is the main problem that it impedes text selection (text is reversed)? I can probably fix that.

[egmontkob]

@ctrlcctrlv What do you exactly mean "fribidi isn't sufficient"? In what sense?

For example, in VTE I implemented BiDi by using FriBidi plus tons of custom wiring code, but no other 3rd party library. In that sense, FriBidi was sufficient as the only new dependency to pull in. I assume this is not what you meant.

Or fribidi as the command-line tool used by the user? Or the FriBidi library "simply" used by the terminal? If the latter then it raises many questions: When would you run it? On what data exactly would you run it? With what parameters would you run it? How would you use its output exactly?

With a background of many years of experience with terminals, combined with a notable experience with BiDi, I was thinking for years how to fundamentally address the problem. Once it was clear, it took months of heavy work to study and evaluate prior work, figure out tons of details, and write them down. Its result is my BiDi proposal, which does not only state as a raw specification what a terminal needs to do, but gives lots of context, reasoning, builds up step by step why it has to be done along these lines, and argues why all terminals so far got it fundamentally wrong.

Please get familiar with my work, read it thoroughly multiple times (feel free to skip the future and dropped ideas). You'll understand what problems needed to be solved, and why creating a proper BiDi-aware platform for others to build upon is way more complex than just a "let's use fribidi".

Feel free to ask if you still have questions after studying my work. For broad questions like "why Fribidi isn't sufficient" all I can do is point you to that spec, especially the chapter "RTL and BiDi Introduction".

[ctrlcctrlv]

@egmontkob Thank you, you answered my question. Your implementation, (which I consider to be the reference implementation,) uses FriBidi. @XVilka ignored my question which made me think that the answer was complicated, even too complicated for someone starting a "BIDI crusade", but actually it's simple—I'm just wrong, FriBidi is sufficient, and @XVilka just didn't have time to say so.

I'm very sorry if you feel I'm not familiar with your written work. To an extent that is true, however, I have read it. I will not trouble you again unless I have a specific actionable question. Thank you for your prompt reply even when the question seemed to you n00bish.

I meant the library, not the command line program. I understand that the plumbing necessary to get that working without changing Kitty's source is not at all desirable.

[XVilka]

I am sorry if I missed your question. I have significant email/GitHub traffic so some messages went unread.

…

On Wed, Feb 5, 2020, 22:19 Fredrick Brennan ***@***.***> wrote: @egmontkob <https://github.com/egmontkob> Thank you, you answered my question. Your implementation, (which I consider to be the reference implementation,) uses FriBidi. @XVilka <https://github.com/XVilka> ignored my question which made me think that the answer was complicated, even too complicated for someone starting a "BIDI crusade", but actually it's simple—I'm just wrong, FriBidi is sufficient, and @XVilka <https://github.com/XVilka> just didn't have time to say so. I'm very sorry if you feel I'm not familiar with your written work. To an extent that is true, however, I have read it. I will not trouble you again unless I have a specific actionable question. Thank you for your prompt reply even when the question seemed to you n00bish. I meant the library, not the command line program. I understand that the plumbing necessary to get that working without changing Kitty's source is not at all desirable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2109?email_source=notifications&email_token=AABRT7JBDVCRFZOJWDE7EQ3RBLDFRA5CNFSM4JHXA4C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK3SS4I#issuecomment-582429041>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRT7PRTFJMV73V63PVOYDRBLDFRANCNFSM4JHXA4CQ> .

[egmontkob]

@ctrlcctrlv Sorry if I falsely assumed from your question that you hadn't read the doc.

If you're familiar with that, you should know that you'll need to keep track of paragraph boundaries, carry for each paragraph the BiDi properties (including cases when two paragraphs merge into one, or one is split in two), run the BiDi algorithm on the entire paragraph (even its offscreen parts) with the given properties, and lay out the result accordingly. Although not part of the spec, keeping track of which character goes to which position, taking double wide ones, combining accents etc. in account is quite a hairy coding task.

I indeed didn't (and probably still don't) understand your previous question; sure let me know if you have more concrete questions.

Your implementation, (which I consider to be the reference implementation,)

The code itself is probably hard to figure out and adopt to Kitty, as I assume the internals of the two terminals are quite different. It might give you some ideas though.

You're probably more interested in the test file at https://gitlab.gnome.org/GNOME/vte/blob/0.58.3/perf/bidi-demo.txt .

By the way, the BiDi spec is by no means complete or final. The most obvious missing bit is to figure out how to handle BiDi control characters at the beginning of a paragraph. This requires re-working the current cell model of "base character + combining accents and maybe BiDi controls too" to "opening BiDi controls + base character + combining accents + closing BiDi controls", answering all the questions that this raises, plus actually implementing it. I would have loved to do it for vte-0.60, but it's postponed indefinitely since I have other things to work on.

The doc should also be updated to reflect the current status (e.g. VTE has implemented it, it's no longer work-in-progress; also mention Mintty that implements it too), and point to (or rather: grab ownership of) the test file.

Hope this helps!

[kovidgoyal]

@ctrlcctrlv if you are thinking of implementing this, please keep in mind that I wont accept changes that have significant negative performance impact on normal (i.e. no bidi) usage. Given the current kitty design you will at the very least have to add some kind of extra data structure to track paragraph properties. Currently kitty tracks only lines and cells.

[ctrlcctrlv]

@kovidgoyal I would aim to make BIDI an "enabled-by-default" feature, disabled via "force_ltr". But the current behavior, where single words are reversed by the shaper, would no longer be selectable.

[kovidgoyal]

I dont care about enabled by default or not, I care about it not
impacting performance in the absence of bidi control sequences/text.

[ctrlcctrlv]

Gotcha, understood. Note fontforge/fontforge#703 (comment), but once that's done I'll take a serious crack at this. Not promising to succeed, but I'll definitely try.

[sharpenedblade]

BiDirectional text is partially a shell thing, partially a font thing, not very much a terminal thing in a prefect world, but if ti must be done in a terminal, it should be done in a simple way, so you dont need to understand complex algorithims to understand how its implemented. I would say, two escape sequences that change text direction, and inside those escape sequences all charecters are drawn normally, then inverted, would be a basic aproach

[ShadiZade]

Concurring on this. It's a big hurdle for me towards using kitty efficiently, since most of my files have Arabic names. Would love to see this get focused attention!