Powerlevel9k: Confusion about integration with the Awesome Powerline fonts

[protist]

Firstly, I'm not exactly sure what you mean by "Awesome Powerline" fonts in the Readme. Is that a general style of fonts? What are some examples of this font? I took a guess and installed awesome-terminal-fonts aka FontAwesome (N.B. it doesn't have "Powerline" in its name at all). It seems to have installed fine. e.g. echo "\uf20c" now shows a glyph.

However, the Readme states that "you can add a time symbol to [a] segment" with some code. This did not work for me (see screenshot below). Also, echo "\uE868" doesn't print out a correct glyph.

In addition, it's stated here that the "Awesome Powerline" glyphs can be used to substitute for the home path. This did not happen automatically for me. Did I need to do something else?

[bhilburn]

@protist - So "Font Awesome" (http://fontawesome.io/) is one font, and "Awesome Terminal Fonts" include a powerline-patched version of it (you're right that the word powerline doesn't appear in the title).

So, just to be sure, you:
1) Installed awesome-terminal-fonts
2) Configured your terminal emulator to use one of those fonts
3) Changed your P9k config to POWERLEVEL9K_MODE='awesome-fontconfig'
4) Restarted your terminal

And you don't see the time glyph?

[dritter]

Maybe we could be more specific about the different fonts. @protist do have a suggestion?

[protist]

So "Font Awesome" (http://fontawesome.io/) is one font, and "Awesome Terminal Fonts" include a powerline-patched version of it (you're right that the word powerline doesn't appear in the title).

Thanks @bhilburn. Ah ok. I installed awesome-terminal-fonts in Arch, which installed a font with family "FontAwesome". Which was slightly confusing to me.

Maybe we could be more specific about the different fonts. @protist do have a suggestion?

Yes, I agree @dritter. I admit I'm still a bit confused, too. So for the fonts that you refer to, I presume that there are just glyphs for specific unicode code points that are required? I'm still not sure if vanilla "Font Awesome" has them or users need the powerline-patched version. I guess for the readme, you could list a few fonts that possess the characters that you need? Presumably there are only a couple of them at this point?

So, just to be sure, you…

I did almost all of those…

Changed your P9k config to POWERLEVEL9K_MODE='awesome-fontconfig'

Except this step. I had another look at the readme, and I couldn't see any reference to this in the dir section. I did find a reference in the vcs symbols section, but there's then a dead link to "the Installation section above". Either way, I couldn't find any substantial information on this setting in the readme. Once I set this, the home icon, etc. work, but not the \uE868 glyph.

And you don't see the time glyph?

No… Is that what echo "\uE868" should be? I had a look through awesome-terminal-font, and \uf017 looked like a clock to me (is that "the time glyph"?) . I also noticed some other differences. The custom command section suggests that \uf230 is an antenna symbol, but it's a Facebook icon for me. Finally, my git symbol looks different to the readme, although it could be that you are just using a different font.

[dritter]

The changed time format example in the readme requires a prepatched "Awesome Terminal Font". And several other examples too..

[protist]

The changed time format example in the readme requires a prepatched "Awesome Terminal Font". And several other examples too..

Sorry, I'm still a little confused. I'm using "awesome-terminal-fonts", and I get the error glyph as the screenshot above.

[protist]

Also, after setting POWERLEVEL9K_MODE='awesome-fontconfig', the dir_writable lock glyph changes into the error glyph for E138, which is also missing from awesome-terminal-fonts. I had a skim of the characters in awesome-terminal-fonts, and I could only find a lock-like glyph at F23E.

[dritter]

The only way (for now) to print fancy icons in a Terminal Emulator is by using an icon font (there is a progress in displaying images in the terminal, but that is specific to single Terminal Emulator Projects).
So to use such an icon font you need to install it, and set it as font in your Terminal Emulator. Powerlevel9k now outputs unicode code points that the terminal emulator picks up and renders the according glyph from the font with the help of the operating system / external programs. So far so good. What makes it difficult is that these pretty icons are not described in the unicode standard (they are in the "private" space). The definition of the code points is up to the font creator.
To make things worse, it may be that these code points collide if you want to merge two different icon fonts together.

To be more concrete: There are two general strategies to use icon fonts.

• You could use a "pre-patched" variant, which is basically a new font created by merging several other fonts together.
• You could use "fontconfig" method, which means an external program that looks for the first (or last, not sure) configured font that supplies a glyph for a code point. You could think of it as a program that creates a font on the fly.

Powerlevel9k needs to know which kind of font the user wants to use, so that it can output the according code points. This is the famous POWERLEVEL9K_MODE, which is basically just a shortcut to define a list of code points for a specific font configuration. Internally the print_icon function is used, that outputs the code point of the current POWERLEVEL9K_MODE. As said this is limited to a known set of icons. You can bypass this by outputting your own code point in the content of a segment (like in the time segment example), or by overwriting the icon variable (try out the get_icon_names function in your terminal).

Powerlevel9k supports currently about five different modes:

1. default, which assumes that you use a recent powerline font
2. compatible, which is a workaround if you use an old version of powerline icon font
3. awesome-fontconfig, which assumes that you use an awesome-terminal-font in the fontconfig setup
4. awesome-patched, which assumes that you use an awesome-terminal-font as a pre-patched variant
5. nerdfont-fontconfig, which assumes that you use nerdfont in a fontconfig setup

I hope that clears it up and I didn't miss a thing. ;)

[protist]

Thank you, that's great information! Thanks for the clarification.

Having said that, the only part that confuses me now is that I do have awesome-terminal-font installed, with POWERLEVEL9K_MODE='awesome-fontconfig' set. However, it seems like the glyphs are still often wrong. That's fine, because as you say, I could just configure my own code points. However, I would have expected the default for that setting and font to be correct?

[dritter]

Yes, overwriting every single icon is one way to deal with that.

Another way is to change your fontconfig configuration. There is a list of fonts to define which takes precedence (the one in awesome-terminal-fonts is here). And it depends which fonts (and sometimes which version) you have configured (e.g. if you use a different icon font than expected, you will get "wrong" icons).
Here is a little example: Lets pretend you have two fonts, A and B. They both have a glyph for the code point XYZ. And powerlevel9k outputs that code point, expecting to result in the glyph of font A, but you have setup fontconfig to use font B first. So you get the wrong glyph.
As you can see this is nothing we could avoid from the P9K perspective..

That being said, it sounds like you should double check your fontconfig configuration..

[protist]

Yes, I installed awesome-terminal-fonts from Arch's AUR repository, so that fontconfig was automatically installed.

Sorry, I probably should have been explicit before. I actually previously checked the code points from awesome-terminal-fonts using gucharmap "Gnome Unicode Charmap", with "Show only glyphs from this font". My understanding is that this would ignore fontconfig, anyway. The displayed glyphs and code points in the character map are consistent with the terminal. It's just that both look different to the readme.

Perhaps we can double-check an example glyph? What does \uE868 look like for you in awesome-terminal-fonts? As per my earlier comment, that one doesn't exist for me, but it's in the readme. (Also, I'm not sure if this is a complete list, but that code point appears to be missing from awesome-terminal-fonts too.)

[dritter]

Well I use a pre patched font. So we can't compare our code points. And codepoints being in one variant, but not in the other is one part of the topics complexity..

So, awesome terminal fonts in the pre patched variant yields

With pre patched fonts I can have a look on all glyphs in my icon font, because font book (app on OSX) shows me them all in a table (and because it is a single font). fontconfig configured fonts are more complicated, because the code points can collide, and you have to figure out which one wins. I don't know if there is a program that does such a thing for you. A quick search revealed this StackOverflow post.

@bhilburn We should make a wiki page out of this issue ;)

[protist]

I probably misunderstood, but I expected a pre-patched font to add the glyphs to the same code points that they would have been in anyway. I guess not. My calender glyph is F073, consistent with the file in awesome-terminal-fonts. Oddly enough, it looks different to yours though.

If I use the gucharmap application, I can just select "Show only glyphs from this font", so it's easy enough to tell which glyphs come from each font, without having to consider collisions.

[dritter]

Okay. I'll try to explain it differently.
A font is a collection of vectors so that the OS knows how to draw them. One for each character (and icon). To address these characters a code is used. That is our code point. The problem is now, to get a font working on every OS and every machine, they all must know the same code points. Of course there are way to many code points to keep them in sync all the time. So there is a standardization group - the Unicode Consortium - that creates the standard. Our icons are not in the standard, they are in the "private space" a reserved address space not occupied by standard code points. A lot of people create icon fonts (like fontawsome, devicons, github, etc), and use addresses from the private space. If you want to merge some of these fonts, collisions would appear very quickly.
So there are different strategies to cope with collisions:

1. When patching a new font together and you detected a collision, you could move all following glyphs one address behind. Or move the colliding glyph at the end. It's totally up to you.
2. You could use fontconfig that "overlays" or "shadows" the glyphs. So if two glyphs share the same code point, the first one configured wins. That way the code points are quite equal to the ones in the original fonts.

And that is our difference. We both use awesome-terminal-fonts, you with fontconfig, me as pre patched. Your calendar icon is from FontAwesome, mine is from somewhere else (don't know). That is why you use the original code point F073, and I use E184 for the same* glyph.

• Here is yours:
  

** same, because E868 is not from FontAwesome, but I have the same icon as you (but as said, under another code point):

[protist]

Ah, okay, I think I get it now. So your original (different to mine) calendar glyph was presumably provided by your vanilla font, without it being patched. In addition, when your vanilla font was patched with awesome-terminal-fonts, some private code points were already used, so the new awesome-terminal-fonts glyphs were moved to alternative code points.

If that is correct, then every pre-patched font might potentially have different private code point glpyh types from each other. If so, wouldn't it make sense for POWERLEVEL9K_MODE='awesome-fontconfig' to default to the fontconfig code points, since it's the only one that is guaranteed of being consistent? Also, if your E868 was not provided by awesome-terminal-fonts, it doesn't make sense to have that as a suggestion in the readme section that states that it's a symbol from the "Awesome Powerline Font" set?

[dritter]

Also, if your E868 was not provided by awesome-terminal-fonts, it doesn't make sense to have that as a suggestion in the readme section that states that it's a symbol from the "Awesome Powerline Font" set?

Yep. That is what I suggested we need to be more specific about ;)

If so, wouldn't it make sense for POWERLEVEL9K_MODE='awesome-fontconfig' to default to the fontconfig code points, since it's the only one that is guaranteed of being consistent?

Did you spot a wrong code point in the awesome-fontconfig mode?

If that is correct, then every pre-patched font might potentially have different private code point glpyh types from each other.

Right. That is one difference between awesome-terminal-fonts (patched) and nerd-fonts. And even the nerd-font variants have different code points. See my issue there about that.

In addition, when your vanilla font was patched with awesome-terminal-fonts, some private code points were already used, so the new awesome-terminal-fonts glyphs were moved to alternative code points.

Almost right. Only thing is that awesome-terminal-fonts is a mixture out of a normal font (like "SourceCodePro"), FontAwesome, Octoicons and Pomodoro Icons. So not "my font was patched with it", all these fonts were patched together (well one-by-one).

[protist]

Yep. That is what I suggested we need to be more specific about ;)

Sorry, I misunderstood. 😬

Did you spot a wrong code point in the awesome-fontconfig mode?

Well, I guess it's hard to say without knowing what they should be, but get_icon_names shows some oddities. See the screenshot below, but the following look broken or odd to me:

• POWERLEVEL9K_LOCK_ICON
• POWERLEVEL9K_VCS_COMMIT_ICON
• POWERLEVEL9K_VCS_BOOKMARK_ICON
• POWERLEVEL9K_VCS_HG_ICON (I expected ☿, but that one made sense too)

Thanks for that other information.

[dritter]

Yep. That is what I suggested we need to be more specific about ;)

Sorry, I misunderstood. 😬

No need to apologize. I should apologize. I was quite unspecific, because all code examples should be double checked.

POWERLEVEL9K_LOCK_ICON

Yep. that one is broken for sure. functions/icons.zsh state it's $'\UE138' for awesome-fontconfig and awesome-patched mode. It should be look like this:

POWERLEVEL9K_VCS_COMMIT_ICON

Looks suspicious. I got the github commit icon:

POWERLEVEL9K_VCS_BOOKMARK_ICON

Mine:

POWERLEVEL9K_VCS_HG_ICON (I expected ☿, but that one made sense too)

That's one I selected. I knew there was the chemical mercurial sign, but that was too narrow for me besides the quite bold icons. That is why I decided to use the other icon..

Note to self: I should fix that order of get_icon_names...

[protist]

From awesome-terminal-fonts, this is the lock icon

CODEPOINT_OF_AWESOME_LOCK='f023'

I can't find a commit icon at all, either in that file or by skimming the glyphs visually.

There are two bookmark glyphs

CODEPOINT_OF_AWESOME_BOOKMARK='f02e'
CODEPOINT_OF_AWESOME_BOOKMARK_O='f097'

But they look slightly fatter than yours. Here are the three glyphs I've mentioned.

Oh, and test icon (second from top) is odd too, yeah? There may be more that I missed.

[dritter]

Your link refers to the FontAwesome part of awesome-terminal-fonts, but there is also other fonts, like octoicons. You can see the code here.

My bookmark-icon is also from octoicons.

[protist]

Oh yes, I missed those files. Yep, I can confirm the code points for commit and bookmark, and that they look the same as your screenshot.

CODEPOINT_OF_OCTICONS_GIT_COMMIT='f321'
CODEPOINT_OF_OCTICONS_BOOKMARK='f37b'

[dritter]

Great! I don't know why these icons were not there in the first place, but it would be awesome, if you could change the icons in functions/icons.zsh (in the awesome-fontconfig array) and open a PR for that :)

[shibumi]

Hello,
I am the maintainer of awesome-fonts in the AUR btw and indeed the icon mappings are wrong. I reported this already months ago but no reaction from the developer. That's the reason why I still use an old awesome-fonts commit from February 2016..

https://github.com/gabrielelana/awesome-terminal-fonts/issues/31

[dritter]

Hi @shibumi !

@gabrielelana is the author of awesome-terminal-fonts, so he can do whatever he wants with it. So, if the decides to relocate the code points of a certain font it is totally up to him. Well, it is bad for us, because we have to redo our code points. I think this BC break is because we have a different understanding what the public "API" of awesome-terminal-fonts is. For us it is the raw code points. For him it is exporting an env variable for each code point. That is, btw., something that @V1rgul addresses in #385

IMHO the describe scenario is exactly what happened. If you look at https://github.com/gabrielelana/awesome-terminal-fonts/commit/e7c89834fa58a593c7a4db8fda7f61cf82a84fa1 you'll see that with the update of FontAwesome the code points are now relocated to a different space (0xf300 instead of 0xf200), so all glyphs from FontAwesome now have other code points.

Thinking more about it, I come to the conclusion that the right thing to do is to rely on the "public API", a.k.a. the variables that get exported by awesome-terminal-fonts. The problem is that this project is not a dependency, and we do not use a dependency manager. So we cannot say "if version X is used, use our configuration from Y".

@protist As an addition to my earlier explanations, I find it interesting that awesome-terminal-fonts relocates all code points from the fonts even if fontconfig is used. They try to avoid collisions so that all glyphs are reachable for somebody who knows the right code points.

[protist]

Ah… @dritter I just had a draft that I was about to submit, which came to a very similar conclusion.

Thanks for that information @shibumi. Hmm… yes, until we get a reply from the dev, it's hard to know if these new code points are permanent or not. If the developer is MIA, then I guess we should probably just assume they are. This recent commit comment says "Build of latest fonts without overlapping", so presumably this re-coding of points was necessary.

However, this comment from the dev suggests that the code points are liable to move around in the future. That's why these *.sh file are provided; it's recommended to source this file, then refer to glyphs by name (e.g. echo -e "\u$CODEPOINT_OF_AWESOME_CHECK)

So, @dritter I agree that this is probably the best way to do it. Since we don't know what version of awesome-terminal-fonts people are using, I think that using code points is an even worse option. Using the variables is agnostic to that… assuming that the variables are from the same version as the font. So, I wonder if powerlevel9k can source these mappings from the users' installation of awesome-terminal-fonts. For example, the AUR's awesome-terminal-fonts installs these shell scripts to /usr/share/fonts/awesome-terminal-fonts/. However, I'm not sure if every distro will package the scripts as well. Perhaps if POWERLEVEL9K_MODE='awesome-fontconfig' is set, then powerlevel9k can check for the presence of these shell scripts in "normal" places, then fallback to the code points if necessary? It's a bit of a pain to have to maintain the code points regularly though.

[V1rgul]

@protist I updated the PR #385 to be able to specify the awesome install location, defaulting to the recommended install path :)

[protist]

@V1rgul Nice one! Thanks for that! I was originilly wondering why you didn't include devicons-regular.sh and pomicons-regular.sh. I read your comment about devicons-regular.sh, i.e. no named codepoints, and that makes sense. However, do you think you should include pomicons-regular.sh? I doubt I'd ever use those few icons, but just for the sake of completeness? Cheers.

@dritter If you are happy with this solution, then I'm happy to submit a pull request to change all of the hard-coded code points to these ones. However, I'm still not 100% sure what the icons are meant to look like in all cases, so perhaps you could submit a screenshot of what you see with get_icon_names (presuming your configuration shows the canonical mapping)?

[gabrielelana]

Hi, author of awesome-terminal-fonts here

You guys already said it all so no need to argument further. I will only say that yes, using the font maps is the way to go

As @dritter already wrote, when you want to merge multiple fonts that evolve independently either you accept to lose some glyphs (when more than one font use the same codepoint for different glyphs) or you need to move the glyphs to different codepoints, I chose the second

To avoid the unstable mapping between codepoints and glyphs when I move the glyphs I also create the font map files so that if you refer to a glyph by its name in the map (ex. $CODEPOINT_OF_AWESOME_LOCK refers to the LOCK icon of the http://fontawesome.io and $CODEPOINT_OF_OCTICONS_TAG refers to the TAG icon of the octicons font from https://github.com) you should be resilient to future relocation (unless a glyphs disappears from a font)

Anyway, I'm here for any further question and open to suggestion on how to improve awesome-terminal-fonts

[gabrielelana]

@shibumi sorry for the late reply, I've completely missed your issue, I'll reply to you right now

[dritter]

@gabrielelana Thanks for your insights!

@protist I think the PR to solve this is #385 , no? Or do you have something else in mind?

[gabrielelana]

@dritter #385 is perfect 😉 👍

[protist]

Oh sorry @dritter (and @V1rgul), I only looked at the last commit. Yes, that looks great!

Ah… so my issue here was actually previously submitted as issue #382, and already partially addressed! Okay, makes sense now!

[V1rgul]

@protist I didn't add pomicons-regular.sh because we don't use any of them

[bhilburn]

This has been a really great discussion! A huge 👏 to @dritter for providing so much insight, and a special thanks to @gabrielelana for weighing-in! Moving forward, I would like to do a few things:

1)

Fonts are terribly confusing, especially if you aren't familiar with how they work. @protist's question is common, and I want to be sure we provide enough information to explain things to new users. @dritter has provided a lot of really excellent information here, and I don't want to 'lose' it in this thread.

I recently created the new About Fonts wiki page using content that @dritter had actually written in a different bug! @protist, would you mind giving it a read and letting us know where you think it's lacking? I think some of @dritter's comments in this thread could be added to that wiki page.

2)

Per @gabrielelana, @V1rgul's PR #385 is the right answer to this problem. I am working on integrating it in a way that is backwards-compatible for users who are using that config but not that specific installation method. This is at the very top of my priority list :)

[protist]

Thanks @bhilburn, that new wiki page looks great! I had a few minor comments though.

On my system (Arch Linux), the second fontconfig option wasn't "more complicated" than the first option would have been. In both cases, I just installed the new font using the package manager, and it just… worked. In fact, the first "patched" option would have been slightly more complicated, because I would have had to change my terminal emulator's font. In the second case, no configuration was required by me.

Also, is the installation of (pre-patched) fonts an OSX thing? In Linux, I just download/install via the package manager… I'm not even sure if I can double-click fonts. (And a minor point, should this section refer to both pre-patched and additional fonts, not just the former?)

Apart from that, it's perfect. TBH my confusion wasn't precisely about what is covered in this page, but more because the examples in the main readme were broken, due to the changed code points. However, presumably once the pull request is merged that will all make sense. And presumably you plan to add information about that side of the config after the pull request.

Cheers!