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

Gunnar Hjalmarsson gunnarhj at debian.org
Fri Feb 3 18:22:47 GMT 2023


On 2023-02-03 17:20, Simon McVittie wrote:
> On Fri, 03 Feb 2023 at 11:49:34 +0100, Gunnar Hjalmarsson wrote:
>> I chose to set "Monospace" when needed instead of specifying "DejaVu Sans
>> Mono" explicitly.
> 
> You said in the new patch that fontconfig prefers DejaVu Sans Mono as
> its implementation of Monospace in Arabic-script locales. To confirm,
> is that true upstream, or just in Debian/Ubuntu, or just in Ubuntu?

It's upstream, more specifically /etc/fonts/conf.d/60-latin.conf. And 
you get this result:

$ LC_CTYPE=ar_EG.UTF-8 fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

also with fontconfig 2.14 even if 60-latin.conf now prefers Noto for 
most other locales.

>> * Consider an Arabic Debian user who opens Tweaks and picks some beautiful
>> monospace font with e.g. the text editor in mind. With the patch applied,
>> that user would not screw up the rendering of Arabic in gnome-terminal
>> unknowingly.
> 
> Equally, if another Arabic-speaking Debian user opens Tweaks and picks
> a monospace font that *does* work OK in vte terminals, they would be
> surprised and probably consider it to be a bug for gnome-terminal not to
> respect that preference?

Fair enough. This hack to fix a known issue comes with a cost. Thanks to 
your input we no longer override the font size at least. But note that 
the Arabic speaking reporter of the Ubuntu bug sees the issue in VTE 
terminals with all other fonts he has tested.

>> * With the patch also in Debian, we avoid to add to the Ubuntu/Debian delta,
>> which is always desirable. :)
> 
> If it's good enough for Debian, is it good enough for upstream?

The approach to special case Arabic might be, but probably not that 
particular code. Doing it all in one single block of code makes sense in 
a patch since it makes maintenance easier. But I imagine that it would 
be a rather time consuming exercise to get some equivalent change into 
upstream, and am not inclined ATM to do that. Maybe better to do it for 
gnome-console later, if a decision is made to make that terminal the 
default.

> Avoiding adding to the Debian/upstream delta is at least as valuable
> as avoiding adding to the Ubuntu/Debian delta.
> 
> Or if it's not suitable for upstream, I think we should only apply it
> in Debian if the benefit *to Debian* is worth the cost of divergence
> from upstream.  The GNOME team already has too many places where someone
> applied a patch several years ago, none of us know whether it's safe
> to remove, and it's adding maintenance cost every time we update to a
> upstream release.

I'm familiar with that problem...

On the Ubuntu side the benefit of having this patch is worth the cost 
without doubt, since we have a *default* which triggers the issue for 
Arabic. I guess you will need to take the decision for Debian. ;)

> This is particularly problematic for areas like localization into a
> specific language or script, which relatively few people understand in
> detail. I spent a significant amount of time doing the research that
> led to https://gitlab.gnome.org/GNOME/gtk/-/issues/183 eventually being
> fixed upstream, 10+ years after the change was made in Debian... but I
> wouldn't have had to spend time digging up the reasoning if the change
> had been proposed upstream at the time!

So you mean that doing it only in Ubuntu and possibly Debian would be to 
do a similar mistake? Maybe. But at least the patch header is now clear 
about the background.

-- 
Rgds,
Gunnar



More information about the Pkg-fonts-devel mailing list