Closed YodaEmbedding closed 6 years ago
Same issue after update
That's weird, does "fp-cache -f" do any change? (run as admin)
sudo fc-cache -f
doesn't seem to have any effect.
The weird thing is I cannot reproduce this on Void Linux
(glibc).
If you specify two fonts (fallback font like "Ubuntu Mono, Source Code Pro" or alike), does the problem still appear?
Find a solution yet? I'm running i3-gaps with i3blocks on arch as well.
I saw issues like this on the font-awesome repo issues. Can you report upstream?
Found a Topic on the Archlinux Forums about this: https://bbs.archlinux.org/viewtopic.php?id=233098
Uninstalling ttf-font-awesome
and installing otf-font-awesome
worked for me.
This issue can be closed. (Though, I suppose for now that it might be better to leave open for visibility.)
Quoting @ael:
The bug is actually related to Pango. In fact i3wm use Pango to render text. The problem is that Pango does not correctly fallback to another font to render the space character U+0020 [1][2]. The new ttf Font Awesome 5 fonts do not provide anymore a space character, thus using a space after a proper Font Awesome char trigger the Pango bad behavior.
If you have ttf-fontawesome-5 installed you can reproduce the problem with: pango-view -t ' A ' --font "pango:Font Awesome 5 Free"
You will see that the space after the bike (U+F206) is not correctly rendered while the space after the A letter is properly rendered.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=775202 [2] https://bugzilla.gnome.org/show_bug.cgi?id=780068
It looks like spaces (0020) are being poorly displayed:
I'm guessing this comes with the recent update to
ttf-font-awesome
. The reason I raised this issue here is because vim and Sublime Text seem to be displaying the font correctly:i3 config:
i3blocks config:
(Notice that there is no space explicitly defined within
label=
.)