@gunnarhj Everything is now DejaVu after the change you suggested!
@mhsabbagh: I see that you have the extra fonts weights. Can you please try to delete those packages temporarily to see if it makes a difference.
sudo apt purge fonts-noto-extra fonts-noto-ui-extraOh no! So we apparently need binding="strong" for sans-serif. And for some reason I donât understand that affects monospace in an undesirable way.
@gunnarhj Iâm confused aswell, I tried to mix and match strong/same but no difference!
By the way, even when DejaVu font is applied to all, it is still broken on terminal, which doesnât make sense, I wonder what @xlmnxp did for his screenshots above.
Okay, just did some test, whatâs displayed on terminal is not DejaVu font, instead Noto Mono, hence why it miss-renders. When I force the terminal to choose DejaVu, Arabic mono is rendered correctly!
The question now, why is Noto Mono chosen before DejaVu?! @gunnarhj
Done but sadly thereâs no difference.
Does that mean it does the right thing if you delete Noto Mono?
sudo apt purge fonts-noto-mono
No didnât help unfortunately 
Iâm suspecting its a gnome-terminal issue, what other apps are good candidate for testing mono fonts? Not sure if LibreOffice respects systemâs fontconfig !?!
As regards the gnome-terminal/monospace problem I compared with /etc/fonts/conf.avail/69-language-selector-zh-cn.conf for Simplified Chinese, and which I used as a model for the Arabic equivalent.
In that case fontconfig behaves similarly, i.e. the font stated for sans-serif (Noto Sans CJK SC) is given high precedence also for monospace (and for serif).
$ LC_CTYPE=zh_CN.UTF-8 fc-match -a monospace | head -6
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"
NotoSansCJK-Regular.ttc: "Noto Sans Mono CJK SC" "Regular"
NotoSansCJK-Bold.ttc: "Noto Sans Mono CJK SC" "Bold"
NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"
NotoSansCJK-Bold.ttc: "Noto Sans CJK SC" "Bold"
Iâm not aware of any complaints from Chinese users about this, though.
One thought is that DejaVu Sans Mono may not cover all the glyphs for Arabic, and that fontconfig falls back to the next font in the list for certain glyphs. The reason why that does not happen for Chinese would then be that Noto Sans Mono CJK SC is complete enough.
Does this reasoning make sense?
I made a new attempt to fix it so also monospace works as intended. This time I uploaded to this PPA:
https://launchpad.net/~gunnarhj/+archive/ubuntu/language-selector
These are the changes:
- Renamed the
.confto56-language-selector-ar.conf - Dropped
binding="strong" - Dropped the monospace section
Then I browsed ar.wikipedia.org and the inspector indicated that Noto Naskh Arabic UI was in use. But Iâm certainly not sure.
So please install language-selector-common and language-selector-gnome from the PPA on a groovy installation, and test both sans-serif and monospace.
@gunnarhj It does, also I did some interesting test yesterday, I used a default installation of Ubuntu 20.04, and fonts on the terminal were a mess!
Probably most users donât care about the terminal, or maybe if they care then theyâre competent enough to fix it (by going to settings and overriding systemâs default mono font).
Update, it is a gnome issue, here is a test with different number of terminals (kitty, xterm, konsole, terminator):
Hi @gunnarhj
Unfortunately, that made no difference to the terminal, however rendering outside it is correct:
@gunnarhj
This is my last post according to Discourse, Iâm being blocked for sending too much replies exceeding ânew accountâ limits, can you please help approve it or something?
I can only reply trough edits 
@ian-weisser: @munadi is a valuable contributor wrt our efforts to improve the fonts for Arabic scripts. Can you please raise his privileges somehow to work around that new account limit.
That may be the case. Also, some Arabic users prefer English in terminal anyway. This topic comes to mind.
That was useful input. gnome-terminal has also other issues with non-latin scripts, e.g. some Indian scripts.
Ok. Still some progress (i.e. it works without binding="strong" for sans-serif).
As a last attempt I uploaded a new variant to the PPA where I added back the monospace section including binding="strong" for monospace only. Any chance you can install that variant and see if it helps wrt gnome-terminal?
(If you havenât yet got permission to post here, please feel free to send me an email to gunnarhj@ubuntu.com.)
Trying the latest PPA version didnât change anything here.
As @mhsabbagh said, no different, gnome-terminal still broken.
Updated: No, Kitty is broken, but in a different way.
Regarding the original topic away from terminal issue⊠Any chance someone can pull a recent version from Noto fonts from GitHub and push them both to 20.04 and 20.10? So that we can see the final fonts version in their current status.
@mhsabbagh, @munadi: Thanks for your feedback on my latest attempt via the PPA. Then Iâm going to give up for now as regards the gnome-terminal behavior, and assume itâs a gnome-terminal bug.
I will upload the most sensible variant to groovy (with Noto Naskh Arabic UI for sans-serif), and later upload the same config to focal. Hopefully we are all agreed that this is at least an improvement compared to the previous DejaVu font, despite of the issues which may remain.
That would indeed be interesting to see, given the observations you reported previously, but it will need to be a project for Ubuntu 21.04. Ubuntuâs policy for updating stable releases would probably not allow us to backport new versions of the fonts-noto-* packages to 20.04 and 20.10. The first step will be to ask the Debian maintainer to update the packages in Debian, and then they will be synced to the development version for 21.04. A wishlist Debian bug might speed up the process.
For me itâs a tremendous improvement, thank for all the hard work!
It is not the end, Iâll follow up to see how Noto+Arabic will progress in the future, I didnât even know bugs in fonts exists, I always thought it was the renderrer responsible for any bug