Fonts registered by fontconfig fail to load resulting in panick

[bound-variable]

In yofi.config

font = "Inter"

Running yofi produces

2022-09-30][16:20:28][yofi][WARN] cannot read blacklist file "/home/alan/.config/yofi/blacklist": No such file or directory (os error 2)
[2022-09-30][16:20:28][yofi::font::fdue][INFO] The font Inter could not be found.
[2022-09-30][16:20:28][yofi::font::fdue][INFO] Best matches:
	D050000L
	C059-Bold
	P052-Bold
	C059-Italic
	P052-Italic

thread 'main' panicked at 'Format: was already formatted once', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/itertools-0.8.2/src/format.rs:81:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

None of my fonts are working except a few that are installed under root directory.

Querying fontconfig (with formatting) produces:

Alegreya		Nimbus Mono PS		Noto Serif CJK HK
Archivo Narrow		Nimbus Roman		Noto Serif CJK JP
C059			Nimbus Sans		Noto Serif CJK KR
Cantarell		Nimbus Sans Narrow	Noto Serif CJK SC
Cinzel			Noto Color Emoji	Noto Serif CJK TC
Cinzel Decorative	Noto Sans CJK HK	Open Sans
D050000L		Noto Sans CJK JP	P052
DejaVu Math TeX Gyre	Noto Sans CJK KR	Roboto Mono
DejaVu Sans		Noto Sans CJK SC	Source Code Pro
DejaVu Sans Mono	Noto Sans CJK TC	Source Code Variable
DejaVu Serif		Noto Sans Mono CJK HK	Standard Symbols PS
Inter			Noto Sans Mono CJK JP	URW Bookman
Liberation Mono		Noto Sans Mono CJK KR	URW Gothic
Liberation Sans		Noto Sans Mono CJK SC	Z003
Liberation Serif	Noto Sans Mono CJK TC

[l4l]

Ugh, why font handling is such a mess. As a quick workaround: you may specify an absolute path (e.g /usr/share/fonts/inter/Inter-Regular.ttf).

I couldn't reproduce your case yet, for me output is the following:

[2022-10-01][10:11:38][yofi::font::fdue][INFO] The font Inter could not be found.
[2022-10-01][10:11:38][yofi::font::fdue][INFO] Best matches:
	Inter Bold
	Inter Thin
	Arial
	Inter Black
	Inter Light

Do you have some no-default path for this font? It seems rust-fontconfig that searches fc-cache doesn't handle xdg dirs properly, is it your case?

[bound-variable]

Okay, the absolute path works. (I thought I tried that before)

The fonts I want are located in $HOME/.local/share/fonts/

I leave /usr/share/fonts/ just for system fonts from my distro (Arch)

My other apps load the fonts fine.

It seems rust-fontconfig that searches fc-cache doesn't handle xdg dirs properly, is it your case?

Sorry, I don't know what you mean. I don't know rust. But fontconfig registers all my fonts fine. I can print all their information (For example, with fc-list --verbose)

[l4l]

Sorry, I don't know what you mean. I don't know rust. But fontconfig registers all my fonts fine. I can print all their information (For example, with fc-list --verbose)

Yeah, sure. The link is for the library I'm using for finding fonts, it's not a system fontconfig thus a different behavior. It doesn't handle XDG standard directories, in particular yours $HOME/.local/share/fonts/. You may find searched dirs with grep '<dir>' /etc/fonts/fonts.conf, for me it produces the following output:

	<dir>/usr/share/fonts</dir>
	<dir>/usr/local/share/fonts</dir>
	<dir>~/.fonts</dir>

So basically these 3 dirs are searched. There are also entries <dir prefix=..>..</dir> in that file but these are handled poorly (prefix=xdg in particular implies searching in $HOME/.local/share). Includes are not supported as well so anything in /etc/fonts/conf.d is not considered.

Unfortunately I didn't find any other libraries for that job and I don't really want to be bound to fontconfig system libs. Hopefully I make my own implementation soon.

[bound-variable]

I get the same output when grepping /etc/fonts/fonts.conf

I'm a novice coder, but to me it seems strange that the tilde (~) would be referenced here. I thought it was considered poor form to use the tilde anywhere outside of the command line, and that instead we should use $HOME.

Additionally, by only looking at the base of the home directory, we're inviting our home to be cluttered with dot files. Again, strange policy.

In any case, I'll go with the absolute path for now.

Thanks again