Unable to see the correct font icons in the MobaXterm SSH terminal emulator...

[bisdavid]

I recently moved from a Mac back to Windows 10 and using the https://mobaxterm.mobatek.net/ terminal emulator. The Linux host I connect to uses Oh-My-Zsh running the PowerShell10K theme. I love it! On the Mac (using iTerm2) all of the icons showed up correctly.

After switching to Windows and MobaXterm, I installed the MesloLGS NF font, and configured MobaXterm to use it for that session. However, I don't see the Penguin icon, or any of the Git icons that I see on Windows.

What am I missing configuration-wise to make my shell prompt with those characters show up correctly in MobaXterm on Windows?

Thanks! Looking forward to this working again!!!

[romkatv]

Dunno. Please ask on a forum related to your terminal.

[romkatv]

To clarify, the question you need to ask is "how do I set my font in MobaXterm to MesloLGS NF (or any other font)". And here's the test to verify that the font is working:

zsh -fc "print '\uF17C'"

[bisdavid]

I DO have the font set in MobaXterm to MesloLGS NF. I can tell the font is changeing because of other visible changes (other than the icon characters). However, something is apparently still missing. I now have an email out to them - they don't seem to have a forum anywhere that I can find. Hopefully they'll answer. Thanks!

[romkatv]

I DO have the font set in MobaXterm to MesloLGS NF. I can tell the font is changeing because of other visible changes (other than the icon characters).

OK, that's good. So the problem is with this terminal handling this specific font. It's still something to work out with your terminal (and not powerlevel10k). Please do use the command I've posted above as a test for whether the terminal is able to use MesloLGS NF. It's much easier to use it than to use the whole of powerlevel10k.

FWIW, most windows users go with Windows Terminal and VcXsrv for X.

[bisdavid]

I agree, and hopefully they'll respond in email. I get only a vertical bar when I run that command (unlike the penguin icon when I run it on the mac). So it's definitely the Mobaxterm. Just wanted to make sure I wasn't missing something. Thanks much!

[Mithi83]

Since I'm having a similar problem with putty, I'll share my findings here. I think I remember having read somewhere that putty and MobaXterm share a common code base, but I can't find it right now. Anyway I contacted the putty developers a few days ago (and haven't heard back from them yet) about a similar problem. This bug is specific to any font that uses a certain unicode code point range for its glyphs (from the fontawesome range in nerd fonts).

I have looked at the putty source code and found an interesting special case when rendering glyphs to the screen. There is a range of unicode code points that is treated in a special way for some reason I haven't yet figured out. That range is ((value & 0xFFFFFE00) == 0xF000) and checked by the DIRECT_FONT macro. If a character is within that range, they effectively cut off the higher byte (value & 0xFF) to force it down into ASCII range.

Taking your example of \uF17C this results in 0x7C or | in ASCII. You could try to fiddle around with different values for the last byte to verify this theory. For me, the clue was the lock icon \uF023 that is used by p10k configure. It was rendered as #. Also, unicode code points outside that range from fontawesome are not messed with, e.g. the address card symbol \uF2BB.

Maybe this causes your problem as well and somehow helps the developers of MobaXterm to fix it. Either it's a problem with the terminals or fontawesome should not use this range for its icons.

[romkatv]

I can assure you that it's perfectly valid for fonts to provide a glyph for U+F17C. This is unicode private use area and it's meant for non-standard glyphs.

[bisdavid]

I can confirm that what I am seeing in in MobaXTerm when I look at \uF17C all I see is a |. And when I look at \uF023, all I see is a #. Yet when I look at \uF2BB I do actually see the address card icon. So it does appear that MobaXterm may be stripping the high byte for at least some characters.

[romkatv]

@bisdavid Your results fully confirm what @Mithi83 wrote. Those and only those glyphs are broken whose code points satisfy (value & 0xFFFFFE00) == 0xF000. That code (to break some glyphs) has been put intentionally, but we don't know for which purpose. It's not unlikely that it actually does something useful in some situations but the condition is simply too broad, which makes it trigger on glyphs on which it was not intended to trigger.

[bisdavid]

Thank you! I passed the link to this discussion on to the MobaXTerm developers to whom I sent my complaint. Thanks to both of you for helping to narrow this down!

[Mithi83]

@bisdavid: Have you get received any feedback from those developers? My email to the Putty developers has not yet been answered. If you get some feedback please keep me in the loop: Email me at mithi@mithi.net

I investigated the putty source code more deeply and have a theory what the intention of this problematic code is. The terminal emulation layer has several modes that can be used to draw lines or other special characters. To provide a translation between a certain character within such a mode and the font there are several arrays to map a character to a specific glyph (see windows/winucs.c, struct unicodedata *ucsdata, they are called `unitab*`). However these arrays are sparse and the unmapped entries contain values that match (0xF100 + ASCII). This 0xF100 is stripped off again by the code I already pointed out in my earlier post. It seems that putty does not take into account that other ways to generate 0xF100 to 0xF1FF (such as the shell printing it on purpose) might occur.

I managed to compile a patched version of putty that does not run into this problem anymore but I can't say for sure what the side effects of my patch will be. Maybe it will break something else more badly than what it attempts to fix. Instead of converting it from the 0xF100-0xF1FF area (and back again later), I try to immediately store the ASCII value in the array and skip the back-conversion entirely. putty-fontawesome.patch.txt

[romkatv]

For my education, why do you use putty? When I have to ssh from widows, I use openssh. It seems superior compared to putty (it doesn't come with use own terminal but any terminal seems at least as good and most are better). Is there a reason to choose otherwise?

[Mithi83]

When I started using SSH on Windows (maybe Window 7 or maybe even Windows XP) many years ago, this was the variant I deemed universally applicable. Suppose you use a Windows system (that is not your own) and you don't want to install new software. You could just download the putty binary (no installer necessary) and start working on your Linux server right away. Back in the days, the alternative was cygwin and that involved a lot of installation etc.

Windows is my secondary OS anyway so I haven't put too much effort into optimization of workflows there. Once I found a solution that worked reasonably well I stopped looking further and just stuck with putty.

[bisdavid]

Yes - it's definitely an issue with MobaXterm (and any other program that uses the shared underlying libraries like Putty). They seemed interested in looking into the problem. Hopefully their next release will address this.

[hostmit]

Did you get any feedback from MobaXterm? @bisdavid

[bisdavid]

Only that they’re aware of the issue. ☹

I’ve now switched to the new Microsoft Terminal app, and it’s running great with PowerLevel10K. 😊

From: Konstantin Odnoralov notifications@github.com Sent: Thursday, August 20, 2020 11:57 AM To: romkatv/powerlevel10k powerlevel10k@noreply.github.com Cc: Bishop, Dave bisdavid@amazon.com; Mention mention@noreply.github.com Subject: Re: [romkatv/powerlevel10k] Unable to see the correct font icons in the MobaXterm SSH terminal emulator... (#674)

Did you get any feedback from MobaXterm? @bisdavidhttps://github.com/bisdavid

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/romkatv/powerlevel10k/issues/674#issuecomment-677840311, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACI5ZQ5WZRNNJFX3ROHSNH3SBVWZTANCNFSM4MUAWS2A.

[romkatv]

I’ve now switched to the new Microsoft Terminal app, and it’s running great with PowerLevel10K.

This seems like the obviously good solution both for the short and the long term. As I mentioned above, I'm not aware of any reason to use Putty or the like. It was useful for a long time but now we have real terminals on Windows (and even real Linux with WSL2).

[ahnberg]

puTTY 0.75 finally fixed the unicode issues now!

"Bug fixes in this release include:

• The terminal was unable to display Unicode characters in the range U+F000 to U+F1FF (part of the private-use area)."

[bisdavid]

Yay! Glad to hear it, though I've long since moved on to the new MS Terminal. Works great in the same situations for me. :-) Thanks for the update though!

[romkatv]

I've long since moved on to the new MS Terminal.

Good choice. They've recently implemented bracketed paste, so it's a decent terminal now.