[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Order of fonts returned by list-fonts
From: |
Kévin Le Gouguec |
Subject: |
Order of fonts returned by list-fonts |
Date: |
Sat, 08 Jan 2022 23:59:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Hello Emacs,
My distro ships with Noto Color Emoji 13.1. I have installed version 14
under ~/.local/share/fonts. fc-match seems to prioritize the latter:
$ fc-match -f '%{fullname} %{file}\n' "Noto Color Emoji"
> Noto Color Emoji /home/peniblec/.local/share/fonts/NotoColorEmoji.ttf
Emacs, however, seems to favour the former:
(find-font (font-spec :family "Noto Color Emoji"))
> #<font-entity ftcrhb GOOG Noto\ Color\ Emoji nil iso10646-1 regular
> normal normal 0 nil 100 0 ((:font-entity
> "/usr/share/fonts/truetype/NotoColorEmoji.ttf" . 0))>
(list-fonts (font-spec :family "Noto Color Emoji"))
> (#<font-entity ftcrhb GOOG Noto\ Color\ Emoji nil iso10646-1 regular
> normal normal 0 nil 100 0 ((:font-entity
> "/usr/share/fonts/truetype/NotoColorEmoji.ttf" . 0))>
> #<font-entity ftcrhb GOOG Noto\ Color\ Emoji nil iso10646-1 regular
> normal normal 0 nil 100 0 ((:font-entity
> "/home/peniblec/.local/share/fonts/NotoColorEmoji.ttf" . 0))>)
Could this be considered a bug? I didn't dig into the code yet, beside
looking at font_list_entities (which led me to restart with
EMACS_FONT_LOG set; unfortunately font-show-log doesn't have much to say
about how font files are searched).
I don't know if my expectation (that Emacs and fc-match should agree on
how files are prioritized) is warranted; I know that Emacs relies on
Fontconfig APIs to some degree, but I'm sure there is more complexity
lurking under the hood.
I figured I'd ask around if the above makes sense to someone before
putting my spelunking hat on :)
FWIW: I originally "solved" the problem by uninstalling the version
shipped by my distro; unfortunately, today's upgrade seems to have
brought it back, presumably because another package has started
depending on it.
FWIW²: the bigger-picture fix would probably be to send a patch to the
distro to migrate to Noto Color Emoji 14; I might get to that at some
point, but I still would like to understand what's going on with Emacs.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo
version 1.16.0)
of 2022-01-01 built on amdahl30
Repository revision: 1d3020908b4e4ff398c3faed9321aa4932fbaad1
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: openSUSE Tumbleweed
Configured using:
'configure --with-cairo --with-gconf --with-xinput2'
Configured features:
ACL CAIRO DBUS FREETYPE GCONF GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
- Order of fonts returned by list-fonts,
Kévin Le Gouguec <=