Hi M.Hanny,

Re bug 1 (rendering):

Thanks for attaching screenshots, I was lazy to do that. Indeed this is also how the letters look to me.

It would indeed be great if Ubuntu could change its default font choice, at least for Arabic locales. I don't know what would be the best place to bring it up with Ubuntu developers (I'm not one of them), maybe a dedicated bugreport here, filed against the relevant font or i18n projects, or perhaps an i18n mailing list (I'm afraid very little attention is being paid to bugreports here).

According to my memories from many-many years ago, I think fontconfig (or some other component in picking a font) can also behave differently depending on the locale. I definitely do remember that some piece of software, probably some terminal emulator, but I can't recall which, with the same settings except for the locale, picked different fonts depending on the locale (wider one for CJK locales). So _maybe_ one way to address the problem is to modify the configuration of fontconfig or some similar underlying font component, and still calling it "Ubuntu Mono" from the terminal. Anyway, I'm not familiar enough with the topic to propose how to solve it.

Once this is fixed, I believe there's one more prominent rendering issue, and that's the lack of the lam-alif ligature. VTE doesn't support ligatures in general, maybe this one should be handled by some one-off code as an exception, but it's still unclear how to handle some corner cases (e.g. when a color change, the cursor, or a linebreak comes in between). According to my memories, the conclusion with my consultant about the Arabic language family was that the lack of lam-alif ligature is not terribly bad on typewriter-like machines, my impression was that it's frowned upon but sort of acceptable. It can be further improved at any time.

Re bug 2 (order of words):

One more important thing that didn't occur to me yesterday was the nasty issue with the "paragraph direction". It's a generic issue with RTL handling, not related to terminals per se. The problem and its consequences (different ordering of words) is breafly explained and demonstrated with the simplest possible example in my BiDi proposal under "RTL and BiDi Introduction" -> "RTL and BiDi text handling in general".

As your gedit and browser screenshots show, they most likely auto-detect the paragraph direction, which ends up being RTL. The overall right alignment suggests that this is most likely the case. The terminal, on the other hand, assumes LTR paragraph direction until explicitly told otherwise.

Try the following command:

  printf '\e[?2501h'

to enable auto-detection of the paragraph direction in VTE, and then re-run "apt". Does this fix the order of the words for you in VTE? (Plus it should also right-align the affected lines, just as in the browser and gedit screenshots.)

You might create a wrapper script around your "apt" that sets this, and resets (letter "l" instead of "h", as in low/high) afterwards. Or enable it for your entire shell session, bearing in mind that it will affect the behavior of other RTL tools as well, some for better, some for worse.

To be honest, it was a tough choice to pick the default value whether autodetection of the paragraph direction should be enabled or disabled in terminals by default. Both possibilities have their pros and cons. I'm not entirely certain that I managed to pick the better one; given sufficiently large amount of data points (which I don't have), the decision might need to be revised in the future.

Handling the paragraph direction properly in RTL or mixed direction text (e.g. while building up a mixed language homepage) always requires plenty of manual work, and I can't imagine this being different in terminals either. Apps just need to tell the terminal which behavior they need at the given location. So again, I'd argue that "apt" (and plenty others) should instruct the terminal accordingly. (In practice I know it's pretty unlikely for many-many apps to invest this amount of work in proper BiDi support, unfortunately leaving us with a less-than-ideal final result.)