Re: Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic
Thanks for your reply, Simon. It helped me realize a significant
difference between Ubuntu and Debian with respect to desktop configuration:
While Ubuntu sets a *specific* font (Ubuntu Mono) as the default
monospace font, Debian just sets "Monospace" and with that defers to
fontconfig.
To summarize: I no longer think that the issue affects Debian. It seems
to be an Ubuntu specific thing.
On 2023-01-26 15:50, Simon McVittie wrote:
Is this the patch you mean?
https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/8/diffs
Yes.
I notice that it overrules the desktop-wide user preference for the font
and font size, and sets 12pt DejaVu Sans Mono unconditionally. That
doesn't seem ideal, and in particular I could see it being an
accessibility problem for users who have difficulty reading monospaced
text at 12pt size and have configured a larger font desktop-wide.
It does so for Arabic users only. And the primary problem for those
users is not the font size, but other gnome-terminal rendering issues.
At the same time, please note that all users of gnome-terminal,
including the Arabic ones, can set a custom font in Preferences, and
there also determine a font size specific for gnome-terminal.
I don't think this patch would be upstreamable,
Neither do I.
So that we can get the requirements right, is this a fair summary of the
situation?
* gnome-terminal uses the equivalent of
`gsettings get org.gnome.desktop.interface monospace-font-name`
as its default font.
* Upstream, GNOME has "Source Code Pro 10" as the default for that
settings key.
* Downstream, neither Debian nor Ubuntu has Source Code Pro available, so
we both override it. Ubuntu uses "Ubuntu Mono" at some suitable size
(I don't know what size). Debian uses "Monospace 11".
* "Monospace" is a fontconfig alias intended to point to a generic monospace
font, which until recently was resolved to DejaVu Sans Mono by
fontconfig. Since the recent upgrade to fontconfig 2.14, "Monospace"
now prefers Noto Sans Mono instead, if available.
* Both Ubuntu Mono and Noto Sans Mono are perfectly acceptable fonts for
most uses of both Arabic and non-Arabic monospace text (e.g. in
gedit) and are generally considered preferable to DejaVu, but as
a result of some special properties of terminal emulation, vte-based
terminals specifically (like gnome-terminal and gnome-console) cannot
produce good Arabic text rendering with Ubuntu Mono or Noto Sans Mono.
Well, I no longer think that Noto Sans Mono has so much to do with it
for monospace rendering of Arabic. See more below.
* Therefore, you want to continue to use Ubuntu Mono (on Ubuntu)
or Noto Sans Mono (on Debian) as the default monospace font for ordinary
text (such as in web browsers, devhelp and gedit), but you also want to
replace those fonts with DejaVu Sans Mono for the specific use-case of
vte-based terminal emulators running in an Arabic locale.
The Ubuntu and Ubuntu Mono fonts are not used by default for web
browsing, but only for the Ubuntu desktop.
Besides those comments, your bullet points summarize my understanding of
the situation.
Looking at codesearch, I see that gedit-plugins, pluma, eog-plugins,
anjuta, gnome-console, xfce4-terminal, tilix, guake and terminator also
have approximately the same behaviour as gnome-terminal for something
that looks at a glance as though it might be a vte-based terminal
emulator. Presumably we don't want to apply non-upstreamable patches to
all of those...?
That's a good point, but probably an Ubuntu only problem. At least we
have now addressed the terminal which is currently shipped by default.
One option for avoiding this issue in Debian would be to revert the
fontconfig change that made fontconfig prefer Noto Sans Mono, which
would take it back to resolving Monospace to DejaVu Sans Mono by default,
as it did until shortly before the bookworm freeze. That wouldn't solve
anything in Ubuntu, though.
Actually I'm not sure that would be needed in Debian either. If you run:
fc-list :lang=ar | grep -i mono
you'll find that Noto fonts are absent in the resulting list. And that
is reflected in the fontconfig behavior for an Arabic user:
$ 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 the issue may not be present in Debian at all. (Any Arabic speaking
user who can confirm that?)
Or does the fontconfig configuration language allow locale-sensitive
font choices to be made, so that we could prefer DejaVu Sans Mono over
Noto Sans Mono, but only for Arabic locales?
Yes, indeed it does, but that would probably not be necessary either.
Another option would be to change the gnome-terminal patch so that if the
locale is Arabic *and* the default font is either "Monospace" or "Ubuntu
Mono", we replace it with "DejaVu Sans Mono" of the same size. That would
be a more narrowly-scoped version that at least doesn't interfere with
users' ability to set a different size, although it would still require
non-upstreamable patches in multiple packages.
That's an idea worth considering (for Ubuntu).
Maybe I made this noise in Debian unnecessarily. Sorry if I did. It has
been a learning experience for me.
--
Gunnar
Reply to: