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

Simon McVittie smcv at debian.org
Thu Jan 26 14:50:17 GMT 2023


Control: tags -1 + moreinfo

On Thu, 26 Jan 2023 at 14:46:44 +0100, Gunnar Hjalmarsson wrote:
> Ubuntu just added a patch to set DejaVu Sans Mono as the default font in
> gnome-terminal for Arabic users.
>
> Related discussions:
> 
> https://discourse.ubuntu.com/t/33413
> 
> https://launchpad.net/bugs/2002290

Is this the patch you mean?
https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/8/diffs

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.

I don't think this patch would be upstreamable, and I also don't think
a non-upstreamable patch like this should be applied without investigating
alternatives.

(I also think that if gnome-terminal is going to hard-code a DejaVu font
name, then it needs to have its own dependency on fonts-dejavu-core,
instead of relying on some other package pulling that in.)

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.

* 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.

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...?

(mate-terminal also looks at an equivalent preference in MATE's fork of
org.gnome.desktop.interface, but that's out of scope for GNOME.)

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.

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?

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.

I'm sure there are other options, but I'm not a font expert and I can't
write or understand Arabic. Suggestions welcome!

    smcv



More information about the Pkg-fonts-devel mailing list