Broken fonts in latest iTerm2 version
jfeaver opened this issue · comments
I've tried using Inconsolata and SourceCodePro. I've also opened an issue in iTerm2 (https://code.google.com/p/iterm2/issues/detail?id=2518&thanks=2518&ts=1372092283).
What steps will reproduce the problem?
- Download iTerm2 previous stable release (early 2013 version??)
- Download and install powerline, configured for vim/tmux: https://github.com/Lokaltog/powerline
2a. Notice that powerline does not look visually pleasing (it has missing character marks all over). - Download and setup iTerm2 to use a powerline font: https://github.com/Lokaltog/powerline-fonts
3b. Notice that the new font makes the powerline in vim look visually pleasing (as in vim-powerline.png) - Upgrade iTerm2 to latest stable release 1.0.0.20130622
- Open vim or tmux in iTerm2 and notice broken font
What is the expected output? What do you see instead?
I expect that iTerm2 will use the patched font while running powerline to display a visual interface as in the attached screenshot (vim-powerline.png).
Instead, I am seeing unknown character marks as in the attached screenshot (Screen Shot ... .png)
What version of the product are you using? On what operating system?
iTerm2 1.0.0.20130622
Mac OS X 10.8.4 Build 12E55
Please provide any additional information below.
I am also seeing this behavior.
iTerm2: Build 1.0.0.20130622
Mac OS X: 10.8.4 Build 12E55
I have the same mac and iterm build as @damianball and am seeing this issue.
They updated the code points recently: powerline/powerline@53fbfe1
The fonts need to be re-patched. Who can do this?
I've repatched the fonts, only to find exactly same problem - question marks instead of symbols. Oddly enough, same font used with MacVim works fine.
I think it's a problem with iTerm2; the right character seems to be outputed, and it displays well in MacVim with same font.
57520, Hex e0b0, Octal 160260
I also found that this wasn't working, but I went to Preferences and changed Non-ASCII font to be the same as the Regular font (both patched fonts in other words) and that seemed to fix it for me.
Yeah, it works fine as long as both fonts are set and the version of iTerm2 is at least 1.0.0.20130624.
Changing the font on both ASCII and non-ASCII worked for me as well.
Thanks, it works great changing the patched font for non-ASCII.
I'm getting an o instead of the symbols (have patched fonts installed. Also have both ascii and non-ascii fonts the same"
I also get an o now.. Did you solve it?
EDIT: Ok, i solved it now. I had customized my zsh agnoster theme and didnt update it from the git repo..
Hi folks. Is this issue outstanding, or did you determine it was the code point change and the current version of the fonts fixes it?
Resolved here - although I forgot what I did to resolve it 😨
Hey all. I'm with apjanke. I am having that issue still as well. Any answers?
Actually, it's working fine for me now: we (oh-my-zsh workers) determined that it was the "agnoster" theme in oh-my-zsh which was using outdated code points, and the current version of these patched fonts is correct, with the current Powerline private code points. I got my problems fixed by getting oh-my-zsh updated to use the current Powerline code points in its theme definitions, and updating my local oh-my-zsh installations.
I think this issue can be closed.
@iWrightCode: What specific issues are you having now? If I'm correct in my understanding of this, they can probably be cleared up by a) downloading the latest version of these powerline fonts, b) making sure your theme and terminal definitions are up to date with the current code Point values, and c) setting your "non-ASCII" font in iTerm to one of the Powerline fonts.
I try this fonts and this bug become again
Version
MacOS: 10.12.4
iTerm2: 3.0.15
Sorry, but did try many resolution in this post but still not get icons correctly in prompt line.
I'm using "Meslo LG S Bold for Powerline" font on Mac Sierra
hi @bperucchi Im experiencing the same issue. Im also looking for an answer, lets share some notes. So far I already done adding powerline fonts but its still not working.
Hi @bperucchi @fusionx1
I had the same issue, with the terminal exactly the same as @bperucchi. I solved it with the following configuration:
Sorry for my English.
@fusionx1 @romandoma @kamontat
Thanks for your reply but I'm still get the same problem in the icons
@bperucchi, I know its a long shot, but have you restarted your Iterm2? If you installed everything correctly, that could be the problem. Before restarting Iterm2 just open a second tab and see if the icons are showing.
@tmikulin already did that and still got the icons problem. :/
Same story on my side. Having issue in iTerm2 alone and they are intermittent.
The broken down output:
Sometimes rebooting iTerm2 fixes the issue, sometimes rebooting my mac fixes it and sometimes both fail to do anything. I have triple checked all setting as well as the patched fonts and nothing suspicious there: everything looks as it's supposed to be.
Even when the iTerm2 fonts are not working it still works in Vim inside that same window.
EDIT:
- Reinstalled the patched font that I was using (
inconsolata-for-powerline) via brew: did not fix the issue. - Tried out another patched font (
droid-sans-mono-for-powerline): did not fix the issue either, looks the same (apart from the changed normal character's appearance).
I solved my problem! I I just open mac "Font Book" and repair the fonts.
I actually resolved this for myself after several frustrating hours of toying with Powerline and such. Essentially I had to go into Font Book and resolve "issues" with the powerline fonts I had installed (perhaps because I tried installing/reinstalling them several times? Either way - first install didn't work either). Inside Font Book I chose to allow it to repair the issue automatically for each font - the special characters now display correctly.
Thanks for that point @brenoperucchi. I'll try it out the next time my fonts break. Currently after 1 or 2 more reboots they seem to have come back to their senses automatically.
TLDR; powerline-daemon --replace fixes the problem for me
I've been having this problem intermittently for the past few months. Some observations:
- powerline works fine in vim within iTerm2, but bash still has the font problem
powerline-render shell leftwithin bash has the correct behavior (i.e. no font issues)powerline-daemon --replacefixes the font issue for some amount of time, until eventually the font issues crop up again- Tried powerline bash with several of the patched fonts; they all suffer from this problem
So I tried the "Fix fonts" proposed by @brenoperucchi but it did not work for me. I do see that I am in exactly the same case as what you describe @b-gran w.r.t vim and bash in iTerm2. And the powerline-daemon --replace does fix it! This points to something getting corrupt within the daemon but not in the OSX fonts itself.
Will need to take a closer look into Powerline's source code to see what is going wrong. Potentially a cache that gets corrupted.
@Helcaraxan The only thing which may look like a font issue with daemon is daemon launched in non-UTF-8 environment and thus assuming that Unicode is not supported. This has nothing to do with fonts actually, just it should choose ascii theme under given circumstances.
@ZyX-I but would that explain why the issue starts appearing randomly while running even if it works correctly initially? What you describe looks like something that should be binary on restart: either it always works or it never does.
NOTE: My iTerm2 is set to UTF-8 for its terminal emulation.
@Helcaraxan No idea actually. It should work just like this: always or never. It may replace powerline triangles with question marks if you force theme without fixing the encoding (there are ways to do this via environment variables), but it will not recheck locale.
@Helcaraxan But daemon does not do anything with fonts, it receives text data (current working directory, arguments to the client and the whole client environment), processes it to generate a prompt and pipes generated prompt back to the client. Your screenshot is exactly what daemon should pipe back should it be non-unicode.
About note: there is locale, I do not know what actually “iTerm settings” do, but what is needed to do is setting environment variables. On linux it is normally something like LANG=en_US.UTF-8 and it is set in /etc/profile. I saw some OS X users going with LC_ALL instead for some reason. The locale command prints what locale is.
Based on some other terminal’s settings all setting UTF-8 in their settings does is making terminal emulator interpret input to the terminal as unicode. And not setting locale. Actually do not expect any setting that is a mere “set encoding to something” to set locale: locale is encoding plus language (latter defines collation rules, decimal separator, etc). If you see a setting which is missing “language” part then know that it has nothing to do with locale.
So the only difference here is that in my case (OS X) I have the following:
-> locale
LANG="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_ALL=@Helcaraxan You need to check this at the time daemon is being run. E.g. replace powerline-daemon executable with a script which runs pstree -h (to check who runs the daemon) and locale (to actually check locale), saving theirs output to some known location and then runs actual powerline-daemon executable.
I understand yeah and will provide the output of that action when possible.
However I again do not see why this would cause the issue that this topic describes. Either the locale is set correctly on start and it works or it is not set correctly and fails immediately. I have never heard of the environment variables of a daemonized process changing while running unless the process itself does that or if you start attaching a debugger or other gnarly approaches like that.
Don't get me wrong: I am not trying to contradict you per se, just that I am really wondering what the underlying issue is as, IMHO, your suggestions would not account for the exact behaviour that is being observed by @b-gran, me and others on this topic, i.e that the prompt displays correctly initially and then gets corrupted after some (potentially long, multiple day) period.
@Helcaraxan I would also add date output there then (and both before and after calling powerline-daemon). It is actually possible that daemon was killed and restarted, though this is also strange as with all documented ways of using daemon you need to start a new application (shell or tmux server instance) to get daemon restarted while without daemon powerline will use the shell locale.
Ok. Will do. It might take a while before I will be able to post the result as I'll need to wait until the display gets corrupted again but I won't miss on following up.
In any case thank you very much for the attention that you are giving to the issue!
@ZyX-I the issue just reappeared which gave me the requested log output. Unfortunately it does not look like it gives up any extra information.
It happened after I opened up a new tab in iTerm2 (screenshot of the resulting aspect below). Running powerline-daemon --replace solved it immediately (also see screenshot).
@Helcaraxan You have
Starting powerline-daemon with args: -q
Sun Jul 30 18:44:12 BST 2017
Locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
End of log
right above “the issue appeared with the launch below”, in the same minute, and a bunch of the same runs (with C locale as well) throughtout the log. Do not forget that powerline-daemon -i will not start the daemon if it is already running.
All these runs are implicit. I have not triggered any of them apart from the last one with --replace.
The script that dumps these lines is:
#!/usr/bin/env bash
LOG_FILE="/Users/duco/.powerline-start-log.txt"
echo "Starting powerline-daemon with args: " "$@" >> "${LOG_FILE}"
pstree '$$' >> "${LOG_FILE}"
date >> "${LOG_FILE}"
echo "Locale" >> "${LOG_FILE}"
locale >> "${LOG_FILE}"
echo "End of log" >> "${LOG_FILE}"
/usr/local/bin/powerline-daemon.real "$@"@Helcaraxan I have not said you did. I just meant that “the issue appeared with the launch below” is most likely pointing to the wrong launch because it is previous one which actually started the daemon, and it did start it with the wrong locale.
By the way, your script has an error: '$$' is literal $$ and I guess you wanted a PID.
@Helcaraxan In any case, normally you must have exactly zero runs with C locale.
It appears that current discussion has absolutely nothing to do with the original post.
Since with C locale it is not a powerline issue better move to the mailing list.