[Pkg-fonts-devel] Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

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