We figured out that the default font for GNOME Terminal in Ubuntu (which is Ubuntu Mono) is causing Arabic words and letters to be broken, turned apart and sometimes overlapping each other.
Changing the terminal font to Monospace (DejaVu Sans Mono, which is already installed by default) solved the issue, and the words can be read correctly.
I would like to ask if we can change the default system mono font from Ubuntu Mono to Monospace only when Arabic language (and perhaps other Arabic script-based languages) is set as the default language?
I have added the following font config to /etc/fonts/conf.d/56-language-selector-ar.conf:
<alias>
<family>monospace</family>
<prefer>
<family>DejaVu Sans Mono</family>
</prefer>
</alias>
Which seemed to succeed in changing the Mono font to Monospace in places like Gedit, but the GNOME Terminal application was still using Ubuntu Mono for some reason. So I don’t know what is the correct configuration at the moment for font config.
provided by the ubuntu-settings package. Applications like gnome-terminal, gedit and gnome-text-editor use that setting by default rather than querying fontconfig.
Possibly we could override the override. Can you please open your ~/.profile file for editing and add this code:
if [ "${LC_CTYPE%_*}" = 'ar' -o "${LANG%_*}" = 'ar' ]; then
gsettings set org.gnome.desktop.interface monospace-font-name 'DejaVu Sans Mono 12'
else
gsettings reset org.gnome.desktop.interface monospace-font-name
fi
That ought to make a difference at next login.
I would also appreciate input from the desktop team about the idea. My thought is to let language-selector-common install /etc/profile.d/arabic-monospace.sh with that content. That’s where we have various font configuration tweaks already. One downside is that ~/.config/dconf/user would be manipulated at each login, which means that a user who wants to manually set their favorite monospace font would need to do that with e.g. a gsettings command in ~/.profile rather than just running the command once.
Thank you for the help, yes indeed it looks like fontconfig doesn’t work with Gedit or GNOME apps (perhaps I did multiple things together so I got missed up).
The solution you provided does work (before, after):
However as you said, if this method is used, it also lead to tools like GNOME Tweaks not working when setting the preferred Monospace font for the user, right? (it actually works but only until the user logs out of the session, where it will be overwritten again…)
I see there are 2 places only where we need to address this issue:
If the user chose Arabic language during installation in ubiquity.
If the user installed the system as English, and later on decided to switch to Arabic language.
As far as I know, in both situations the user will trigger the installation of the language-pack-ar package. So can’t we include a post-install script that runs the gsettings command only once?
In this way, the Monospace font will remain unchanged until the user changes it, no? If yes, then it could be possibly a better solution I hope!
Another thing that could be a possible workaround is to set the font property in GNOME Terminal’s default profile only; because Ubuntu Mono is actually a much better font than Monospace in places like Gedit and others (it suffers no issues there, and more beautiful for reading), but the only issues with Ubuntu Mono is in the terminal due to stuff related to the VTE library and how terminals work.
It is very unlikely the user would want to change the Monospace font in the terminal from DejaVu Sans Mono (which we will enforce), to another font. Because as far as I have tested, all the other fonts are suffering the same issues of Ubuntu Mono in the terminal (the spaces between letters + overlapping of some letters). So perhaps another approach could be to just edit the default font for GNOME Terminal alone.
In the light of that, changing GNOME Terminal directly is probably best. That will make it possible to determine the default font at session start without saving anything in dconf.
I have submitted a merge request which I think addresses your wish properly. Please see my comment at the bug report. I’d appreciate if you could test it on jammy.
Note that the only thing we enforce is the default. The user will keep being free to pick a custom font in the GNOME Terminal preferences. But with that said, you may well be right that they will probably not want to do so.
gnome-console seems to use the same approach as gnome-terminal in this respect. i.e. it uses Ubuntu Mono. So probably a similar change is motivated in gnome-console to improve the rendering of Arabic.
(I see no way in the gnome-console UI to set a custom font. Anything I missed?)
Console doesn’t provide a custom font option. My understanding is that it uses gsettings org.gnome.desktop.interface monospace-font-name which can be set by GNOME Tweaks > Fonts > Monospace Text
Ok. I suppose that users typically prefer the same monospace font all over the desktop, and then it’s not a big problem. For Arabic we can use the same solution as for gnome-terminal.
Was possibly Noto Sans Mono one of the fonts you tested? I’m asking because of this Debian bug. So if it wasn’t, can you please test with Noto Sans Mono too and let us know whether the issue is present also with that font.
And another question: Can you tell if it’s motivated to apply the exception also for scripts like Persian and Urdu?
The issue is also present with Noto Sans Mono (image attached).
I couldn’t find Urdu in the list of supported languages in Language Selector. I tested Persian and it suffered from the same issue as Arabic, and switching to Monospace font (DejaVu Mono) solved the problem too (2nd screenshot).
A conclusion is that we should modify the gnome-terminal patch in Ubuntu so also Persian is special cased.
My question about Noto Sans Mono was due to some considerations whether the patch is needed in Debian too. Unlike Ubuntu they use “Monospace” as the default setting for gnome-terminal, which means that they defer to fontconfig. And that in turn means that up to recently DejaVu Sans Mono has been the default font in Debian for gnome-terminal. However, fontconfig has been updated to version 2.14, and one of the changes is that Noto generally is preferred over DejaVu. So for most users of next Debian release Noto Sans Mono will be the default font for gnome-terminal.
So, what about the Arabic Debian users? It looks like fontconfig keeps preferring DejaVu Sans Mono in case of an Arabic locale (which I didn’t know when asking you to test):
$ dpkg-query -W fontconfig
fontconfig 2.14.1-3ubuntu1
$ LC_CTYPE=en_US.UTF-8 fc-match -s monospace | head -2
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
$ LC_CTYPE=ar_EG.UTF-8 fc-match -s monospace | head -2
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"
So my conclusion is that the new fontconfig version will probably not affect Debian’s Arabic users, and hence the gnome-terminal patch is not needed in Debian.
