Unfortunately this doesn't seem to be a full fix. The ":" in the clock is now offset vertically because apparently it's coming from FontAwesome instead of Roboto. I fixed this manually in my stylesheet by adjusting #clock but that's probably not a real solution.

It's actually worse than just the : being wrong. Font Awesome apparently includes letters, numbers and a few but not all punctuation. So -: are included but %() are not. This wrecks havoc in the theme. I don't see how to fix this manually as I can't add a <span class="icon"></span> around the icons themselves as CSS class is not allowed.

The only way I found to solve this was to sprinkle the config file with things like "<span font=\"FontAwesome 5 Free Solid\"></span>. This works but then breaks the tooltip that shows the html as text.

That's not a correct fix i think, we can add a style to force font on format-icon.
I'll look into it, and push in this pr

Thanks. The workaround is working for me now because I have tooltips disabled anyway. This is definitely broken, I didn't close it in case I found a different solution to push into this branch/pr.

If you move "FontAwesome 5 Free Solid" at the end, does it still fix the issue for you?

font-family: Roboto, Helvetica, Arial, sans-serif, "FontAwesome 5 Free Solid";

I tried that as well. But then the conflicts return as the characters in Roboto are the ones that are conflicting with the ones in FontAwesome.

Which characters are you talking about? IIRC this kind of issue is often related to font fallback in freetype and setting a list of font-families in Gtk CSS never helps because Gtk doesn't do font fallback itself (or only after freetype does its own font fallback, which makes the whole thing pointless).

Here's an example from my config:

That's how gedit renders those icons. Without the span forcing the font that's how Waybar displays things as well. Setting FontAwesome as priority fixes that but then there are other characters that are used from FontAwesome instead of Roboto, like ":" in the clock which then becomes vertically offset.

Any update on this? I'm facing the issue as well.

@jtheoof Does setting a font list for sans-serif help (like in my dotfiles) as a workaround for you? (run fc-cache and restart waybar after creating or updating that file)

Yes @jplatte it works thank you.

So I ended up doing things a little differently but heavily inspired. I created a custom font replacement with a Waybar font name.

So that I can have in style.css:

* {
     border: none;
     border-radius: 0;
     font-family: Waybar;
     font-weight: 800;
     font-size: 12px;
     min-height: 0;
 }

This way I have the Font Awesome override but only for the Waybar font which is used only in this file.

Still got some missing char with your work arounds

and it is weirder if I install a new ttf package as dejavu

BTW, is someone configured his bar without any font awesome symbols and having a clean look ?

@Eluminae fc-match should be able to tell you which font is being used to render U+F796. E.g. for me it's Font Awesome:

% fc-match -s monospace:charset=f796 | head -n3
Font Awesome 5 Free-Solid-900.otf: "Font Awesome 5 Free" "Solid"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"

You can read more about how to fix issues like this in the Arch wiki page 'Font configuration'. The section Replace or set default fonts might be especially interesting in your situation, or you might want to blacklist or uninstall a font that is claiming to support character ranges it doesn't actually supply useful characters for.

Okay I got it.. In void packages we got font-awesome and font-awesome5. And guess what, font-awesome5 works very well with

font-family: "FontAwesome 5 Free Solid", Roboto, Helvetica, Arial, sans-serif;

Okay now the jtheoof's way with the Waybar font alias rocks !

@pedrocr I think this PR can now be closed since the proposed changes don't work the way they were intended to, right? I've just created an issue (see link above) about improving the documentation regarding font fallback which would probably be better for further discussion than a PR.

IMHO, there is still missing something for the font to be used out of the box. We still not have the solution.

Maybe providing another default template who do not use font-awesome could be minimalist alternative ?

Thanks for this hint. Was looking for the reason why it behaves like this when installing a Nerd Font on my system.

Here's what worked for me:
As well as adding a font-config file, I also had to change it to: font-family: Roboto, Helvetica; (dropping Arial and sans-serif). With those two removed, appending Font Awesome to the list also worked. I guess somehow they're matching characters like (0xf026) even when they shouldn't be. Given that most users have a better understanding of how to install a font than fontconfig overrides, a simple solution here might be to just drop support for the fallback fonts and use:

font-family: Roboto, Helvetica, "Font Awesome 5 Free Solid";

@rdnetto Do you actually have Roboto or Helvetica installed on your system? Does Waybar look any different if you set just font-family: "Font Awesome 5 Free Solid";? I suspect neither is the case, and my first comment still applies:

IIRC […] setting a list of font-families in Gtk CSS never helps because Gtk doesn't do font fallback itself (or only after freetype does its own font fallback, which makes the whole thing pointless)

@rdnetto Do you actually have Roboto or Helvetica installed on your system?

I can confirm I have Roboto installed. (I thought I had Helvetica installed, but I double checked and it turns out it's just "Adobe Helvetica").

Does Waybar look any different if you set just font-family: "Font Awesome 5 Free Solid";? I suspect neither is the case, and my first comment still applies:

Yes - the font changes, and th in eth0 fails to render.

For comparison, my current working config is font-family: Roboto, Helvetica; with the following font config:

    <alias>
        <family>Roboto</family>
        <prefer>
            <family>Font Awesome 5 Free</family>
        </prefer>
    </alias>

with the following font config

Right, so it's still just matching Roboto on the Gtk side and the actual per-glyph fallback happens inside fontconfig.