This bug has a much broader impact than the originally reported Arimo
hinting issue. The core problem in `56-kubuntu-noto.conf` is that **Noto
Color Emoji is listed as the FIRST preferred font for every generic font
family** (serif, sans-serif, monospace, and ui-sans):
```xml
<alias>
<family>sans-serif</family>
<prefer>
<family>Noto Color Emoji</family> <!-- FIRST, before any text font -->
<family>Arimo</family>
...
```
This config was copied from Chrome OS (per the SPDX header: `SPDX-
FileCopyrightText: 2006-2010 The Chromium OS Authors`). On Chrome OS,
this works because Chrome OS's Chromium has special emoji font handling.
On desktop Linux, it causes Chromium/Electron to use Noto Color Emoji as
a fallback for characters that exist in both the regular font and the
emoji font (numbers, punctuation, certain symbols).
**Concrete evidence from DevTools:** In Electron 39 (used by VSCode and
Kiro IDE), inspecting any text element via DevTools > Computed >
Rendered Fonts shows:
```
Ubuntu-Regular — 264 glyphs
NotoColorEmoji — 69 glyphs
```
Those 69 emoji glyphs have completely different character metrics (wider
cells, different spacing) than the Ubuntu font, causing visibly
incorrect word spacing throughout the UI. Spaces appear tab-width
instead of normal.
**Environment tested:**
- Kubuntu 24.04.4 LTS (Noble Numbat), kernel 6.17.0-14 HWE
- Intel Iris Xe GPU (Mesa), 1920x1200, NO display scaling
- Electron 39.2.3 (Kiro IDE / VSCode)
- kubuntu-settings-desktop 1:24.04.13
**This is NOT related to:** Electron 39 specifically, NVIDIA GPUs,
fractional display scaling, or GPU compositing — all of which have been
incorrectly blamed in upstream Chromium/VSCode bug reports.
**Fix:** `sudo rm /etc/fonts/conf.d/56-kubuntu-noto.conf && fc-cache -f`
**Permanent fix (survives package updates):**
```
# /etc/dpkg/dpkg.cfg.d/no-kubuntu-noto
path-exclude=/etc/fonts/conf.d/56-kubuntu-noto.conf
```
(Credit to Matteo Italia in comment #4 for this approach)
**Proper upstream fix would be** to move `Noto Color Emoji` to the END
of each prefer list instead of the beginning, so it remains available
for actual emoji rendering but doesn't interfere with regular text.
Alternatively, remove it from the prefer lists entirely — emoji will
still render correctly via Unicode emoji presentation selectors.
**Upstream bug reports that are actually caused by this issue:**
- VSCode: https://github.com/microsoft/vscode/issues/292172 (Closed as not
planned — incorrectly blamed Electron 39)
- VSCode: https://github.com/microsoft/vscode/issues/260391 (Open, milestoned
Feb 2026 — incorrectly blamed Electron 39 regression)
- Chromium: https://issues.chromium.org/issues/415453014
This has been open since April 2020. It affects every Kubuntu user
running any Chromium-based application. Please consider prioritizing a
fix.
** Bug watch added: github.com/microsoft/vscode/issues #292172
https://github.com/microsoft/vscode/issues/292172
** Bug watch added: github.com/microsoft/vscode/issues #260391
https://github.com/microsoft/vscode/issues/260391
** Bug watch added: issues.chromium.org/issues #415453014
https://issues.chromium.org/issues/415453014
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872492
Title:
Setting in /etc/fonts/conf.avail/56-kubuntu-noto.conf causes Arimo
font to be rendered weirdly in Firefox
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1872492/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
