# Omarchy issue: the last-resort Noto Naskh Arabic rule captures Latin digits in GTK apps, rendering them in a serif/caligraphic style

## Where this file lives

- `default/fontconfig/conf.avail/50-omarchy.conf` (installed as `/etc/fonts/conf.d/50-omarchy.conf`)
- Omarchy `4.0.1-1`, fontconfig `2.18.3`, Arch/Hyprland
- Branch: `quattro`

## Summarize the problem

On a stock install, digits in GTK4/libadwaita apps (e.g. Nautilus/GNOME Files) are rendered in **Noto Naskh Arabic**, a caligraphic/serif-looking face, instead of the system sans-serif font. Letters look correct; only numerals (sizes, dates, counts, file-permission numbers) fall to Naskh.

## The innocent-appearing cause

The final (unconditional) rule is an intentional "last resort" that appends Noto Naskh Arabic to every pattern:

```xml
<!-- Chromium and Electron resolve missing glyphs one character at a time
     without lang on the pattern ... Naming Naskh as a last-resort family
     covers that path. Appending keeps it behind every family the app
     actually asked for, and charset matching outranks family matching, so a
     font that does not cover the codepoint can never be pulled in: Latin,
     monospace, emoji, Nerd Font glyphs and CJK all resolve exactly as
     before. -->
<match target="pattern">
  <edit name="family" mode="append" binding="strong">
    <string>Noto Naskh Arabic</string>
  </edit>
</match>
```

The design intent — charset matching should outrank family matching so Naskh can never be *pulled in* for a codepoint it does not cover — holds for the standalone `fc-match` charset cases the comment describes. **It does not hold for GTK/Pango digit rendering**, where the digit does fall through to Naskh in practice.

## Steps to reproduce

1. Render a digit with the system sans-serif font and ask Pango which font actually draws the glyph (this reproduces the real fallback path and works on any stock install with GTK/Pango):

   ```python
   import gi
   gi.require_version('Pango','1.0'); gi.require_version('PangoCairo','1.0')
   from gi.repository import Pango, PangoCairo
   import cairo
   s = cairo.ImageSurface(cairo.FORMAT_ARGB32, 200, 80)
   c = cairo.Context(s); pcx = PangoCairo.create_context(c)
   l = Pango.Layout(pcx); l.set_text("0", -1)               # Latin digit
   l.set_font_description(Pango.FontDescription.from_string("sans-serif 11"))
   PangoCairo.update_layout(c, l)
   it = l.get_iter()
   while True:
       r = it.get_run()
       if r is not None:
           print(r.item.analysis.font.describe().get_family()); break
       if not it.next_run(): break
   ```
   Expected on a stock install: `Noto Naskh Arabic` (the bug) instead of `Liberation Sans`.
2. In Nautilus, a monospaced numeric column, the file size/count text, and the file-mover progress all show digits in Naskh's serif/caligraphic form while surrounding text is Liberation Sans. GTK4 inspector confirms the computed `font-family` is `Adwaita Sans` but the glyphs come from the fontconfig fallback chain.

## Expected behavior

Digits with the system sans-serif font render in the system font, not in a serif/caligraphic Arabic face.

## System

- **OS / Omarchy version:** Omarchy `4.0.1-1` (package `omarchy 4.0.1-1`; release branch quattro)
- **Kernel:** `7.1.9-arch1-2`
- **CPU:** AMD Ryzen 7 250 w/ Radeon 780M Graphics (16 threads, x86_64)
- **GPU:** AMD Ryzen 780M iGPU — reported as `AMD/ATI HawkPoint1` (integrated, Radeon 780M)
- **RAM:** 13935072 kB (~13.9 GiB)
- **Display / scale:** eDP-1 `1920x1200 @ 60.01 Hz`, scale `1.5`, format `XRGB8888`
- **Window manager:** Hyprland (Omarchy)
- **Locale:** `es_AR.UTF-8`
- **fontconfig:** `2:2.18.3-2`
- **Nautilus (GNOME Files):** `50.2.2`; **GTK4 / libadwaita:** `4.22.4`
- **System font (GTK font-name):** "Adwaita Sans"; aliases `sans-serif`→`Liberation Sans`

## Root-cause hypothesis

The "last-resort" appending of Noto Naskh Arabic, combined with how Pango falls back for digits, lets Naskh win the digit race on sans fonts (Liberation Sans, Adwaita Sans, Noto Sans). This is the same category of side effect already reported for unrelated rules in #8404 (global omarchy fontconfig rules that capture patterns they were not meant to).

## Suggested direction (for maintainers to weigh in)

Because the Naskh rule is intentional and documented, the fix is not a blind removal. Options worth discussing:

- Scope the last-resort append so it cannot win for Latin digits: e.g. bind it only when charset requires Arabic script, or only when `lang` is absent **and** the pattern covers Arabic — matching the Chromium path it was written for.
- The GTK path (fonts with latin+digits) should never reach Naskh; Naskh should remain reachable *only* as an actual Arabic-script fallback.
- Consider alias/`prefer` idioms to let user overrides compose, as suggested in #8404.

## Workaround (user config, for now)

A user-level override in `~/.config/fontconfig/conf.d/99-maskh-numeros-sans.conf` that removes Naskh only when it is the effective fallback for a pattern, preserving the generic aliases:

```xml
<fontconfig>
  <match target="pattern">
    <test name="family" compare="eq"><string>Noto Naskh Arabic</string></test>
    <edit name="family" mode="prepend" binding="strong"><string>sans-serif</string></edit>
    <edit name="family" mode="delete"><string>Noto Naskh Arabic</string></edit>
  </match>
</fontconfig>
```

Verified: digit "0" with the system font → Liberation Sans; `fc-match sans-serif` → Liberation Sans, `monospace` → JetBrainsMono Nerd Font, `serif` → Liberation Serif, and the Arabic-aware rules in `50-omarchy.conf` are left intact. (Arabic-specific rendering under this workaround is exactly what needs maintainer guidance and is part of why the upstream fix should be scoped, not removed.)

<img width="931" height="555" alt="Image" src="https://github.com/user-attachments/assets/7c0282f9-db58-4b2e-a77f-ef9807cdf43d" />