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.)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/2002290

Title:
  Poor Arabic rendering in VTE

Status in gnome-terminal package in Ubuntu:
  New
Status in vte package in Ubuntu:
  New

Bug description:
  VTE has a number of issues when it comes to rendering Arabic letters
  in the terminal, which could affect a number of languages (Arabic,
  Urdu, Persian... etc).

  Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed
  with spaces between its letters, making readability hard and sometimes
  not possible. Sometimes the letters are crushed together very closely
  making reading impossible too.

  Bug 2: If a non-Arabic text and an Arabic text are displayed together
  in the same line, then the entire line will be missed up and you won't
  be able to understand what is being said.

  Both of these bugs can be seen from the image I attached.

  I reported both of these bugs together because it's unlikely they can
  be fixed separately, probably they are related to each other.

  Problem can be seen in any VTE-based terminal. Here I am using GNOME
  Terminal 3.44.0 on Ubuntu 22.04, but it can be seen in any Ubuntu
  version and in any terminal version as well (it has been there since
  forever).

  I reported the bug here instead of upstream because that's what they
  said at the page: https://wiki.gnome.org/Apps/Terminal/ReportingBugs,
  but this bug is not related to Ubuntu only; it happens on all Linux
  distributions.

  Happy to provide any information you need, or any do tests or
  experiments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2002290/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to