A look at terminal emulators, part 1: more on bidi and such

Posted Apr 2, 2018 4:08 UTC (Mon) by tzafrir (subscriber, #11501)
In reply to: A look at terminal emulators, part 1 by gutschke
Parent article: A look at terminal emulators, part 1

Joining of Arabic (and similar: also Farsi and some others) was indeed not supported here. Though I'm not sure it's that much of a complication with fixed-width fonts: in the Arabic script the shape of the letter may (and usually does) change depending on its place in the word. But it would still be a single character and a single character's space in a terminal. It does mean that shapes of letters around may change when you change the shape of a single letter. How does that work with the various terminal emulators in this review?

Though some south-east Asian scripts are indeed more complex and break that assumption of one character per space.

I think this was not mentioned in the review, but Konsole's bidi support is optional (It's an option you have to tick somewhere deep in the menus). Indeed there's one common use case where bidi is annoying: if you use an Israeli locale, the day of the week and the month name are Hebrew, and thus the output of ls has some Hebrew in it. Some terminals would make a mess of it aligning some file names to the right and some file names to the left.

Generally in my experience mlterm works relatively well for editing Hebrew. Konsole: less so.

A look at terminal emulators, part 1: more on bidi and such

Posted Apr 10, 2018 13:24 UTC (Tue) by pjm (guest, #2080) [Link]

I actually object to the article's "they should be rendered right to left when displayed" and "handle this correctly [i.e. rendering right to left]": terminal input doesn't really have a good concept of where paragraphs start or end, what the base directionality of the paragraph is, and so on, so it's hard to say that any attempted bidi rendering really is "correct". Picking arbitrary answers such as "each line is considered a new paragraph" makes text really hard to follow due to the incorrect reordering for text that doesn't match that arbitrary answer.

While rendering rtl text left to right does make that text very slow to read, it does at least have the advantage that it's clear what the logical order is (avoiding the ls problem referred to above), so I would often prefer the ltr approach when using a terminal. However, I'll grant that this is only viable because I don't use an rtl locale for LC_MESSAGES.

(I wonder, is there any value in the Mongolian solution, i.e. rotating the text so that everything is written top-to-bottom instead of either ltr or rtl ? 90°-rotated text is still a bit slower to read than unrotated text, but much quicker than reading ltr isolated-form letters for arabic script.)