Hi M.Hanny, I'm so glad that you're way more familiar with fontconfig quirks as well as Ubuntu processes than me. I wish you good luck in getting some better config accepted and made default in Ubuntu!
- Re lam-alif: As far as I remember, and https://en.wikibooks.org/wiki/Arabic/LearnRW/laam-alif tells me: The situation is: - The first (right) letter is a Lam (or Laam), U+0644, which looks similar to English J. - The second (left) letter is an Alif, U+0627, which looks similar to English I (vertical bar); or some accented variant thereof (U+0622, U+0623, U+0625, maybe more, I don't know). In the terminal, this shows up as if you'd imagine English "IJ" with the two letters connected at the bottom, i.e., similar to a U. As in the top row of your screenshot in comment 12. In gedit, browser etc. they show up in a way that either more resembles as an "y", or as a shape that reminds me of an upside-down ribbon 🎗, something like an "8" but with the upper segment cut off. As in the second row of your screenshot. I'm glad you confirm what my consultant also said, namely that it's not terribly bad to go with the not properly ligated version. At least, it's good enough for now. My BiDi work focused on way more fundamental things, namely to get the proper (non-reversed) ordering of letters done. Rendering of Lam-Alif can always be further improved in the terminal. - Re making the RTL paragraph direction (and right alignment) the default: Unfortunately the locale subsystem (according to my latest memories) does not specify whether the script is LTR or RTL. One way is to check the language part of the locale, pretty much like you did, but listing all the known RTL scripts ("he", and I guess there are some languages that are somewhat related to Arabic that have their own code, maybe Urdu and some more??). One caveat, though, is that locale-related env vars (LANG, LANGUAGE, LC_MESSAGES, LC_ALL) override each other in a certain order of priority, so probably it's wiser to invoke the `locale` utility and find the resolved value in its output. (Fun fact: some projects use gettext as a workaround for the lack of such a field in locales. Translators have to create a "translated" string containing "ltr" or "rtl", or "1" or "0", whatever choice of the programmers, to denote the default direction.) Another problem is that as the proposal says, no autodetection is the default, and if an app switches to the other mode it should revert that setting upon quitting. Which would revert what you do in the shell startup files. (I'm not aware of any app using these control codes yet, but we should think in the long term and a few steps ahead.) I'm not absolutely certain that an autodetected default direction is better in RTL locales. I'd guess there will be places where it's an improvement (like "apt" obviously) and places where it's less desired. At this moment I'm afraid we don't have enough knowledge and experience to see the pros and cons, more data should be collected first. Note that according to the BiDi proposal, there are 2x2 possible values for paragraph direction (in case the terminal is asked to perform BiDi shuffling): - LTR base dir (no autodetect) - RTL base dir (no autodetect) - Autodetect, falling back to LTR base dir - Autodetect, falling back to RTL base dir You should also test the other two possibilities, although they will probably result in more inconsistencies at e.g. shell prompts which may or may not have Arabic words (e.g. an Arabic path component) in them, or some might make it outright a pain to type typical Unix commands. I think further evaluation needs to happen on this topic, it's way too early to jump into conclusions which mode is the better one. (It should also be evaluated which apps it's more reasonable to ask to modify their behavior and switch to the other mode.) Also, if it becomes clear that it's a big overall advantage to flip the default, IMO it should happen in the spec and in existing implementations before proper BiDi in terminals gets too widespread. Glad to see someone finally actually cares about this BiDi work :) Thanks a lot for pushing it forward! -- 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
