New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't set different font for the terminal #757

Closed
trainto opened this Issue Aug 4, 2016 · 72 comments

Comments

Projects
None yet
@trainto

trainto commented Aug 4, 2016

When I change font via setting menu of Bash on Ubuntu on Windows terminal, it's applied. But close the terminal and relaunch it, then it goes to default font. However in case of background colour setting, it keeps what I set before.

Is ther anyone who went through this situation?

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 4, 2016

@trainto It seems current build has this problem indeed.

However, you can use some third party tools like ConEmu. The latest version of ConEmu can use bash on Windows out-of-box. And it comes with tons of configurations as you can imagine, fonts and themes setting of course.

@onomatopellan

This comment has been minimized.

onomatopellan commented Aug 4, 2016

I changed yesterday the font of Bash on Ubuntu on Windows to DejaVuSansMono.ttf and today font is still applied.
Could it be you changed it while being in an admin bash and now the normal bash doesn't apply the change?

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 4, 2016

@onomatopellan Whether I change the font in an admin bash or a normal bash, the font falls back to default as long as I open a new bash console.

I changed fonts via: Right click on the title bar -> Properties -> Font.

@onomatopellan

This comment has been minimized.

onomatopellan commented Aug 4, 2016

Correct, I did it same way. It's a clean install too?

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 4, 2016

@onomatopellan Well, it's not. I upgraded from Windows 10 version 1511.

Maybe that is the reason?

@onomatopellan

This comment has been minimized.

onomatopellan commented Aug 4, 2016

It could. Old CMD version stored changes on registry and they could conflict with the new CMD. You can try to right click title bar -> enable Defaults and try again.

The Ubuntu guy also explained how he had to use regedit to install Ubuntu font in old CMD versions.
http://blog.dustinkirkland.com/2016/04/howto-ubuntu-on-windows.html

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 4, 2016

Well, maybe I know the reason why.

There are two ways to open bash.

  1. Press Win + R, enter "cmd.exe" then press enter, and enter "bash".
  2. Click Windows search, enter "bash" and then enter.

Method 1 launches bash within from cmd.exe, while method 2 launches bash.exe directly( Correct me if I am wrong ). You can set fonts in both methods, but method 1 keeps your setting and method 2 loses.

So it seems method 1 sets fonts for cmd.exe while method 2 sets fonts for bash.exe. I was using method 2 all the time. And the font config keeps losing. I tried method 1 just now, and the font config keeps.

@onomatopellan

This comment has been minimized.

onomatopellan commented Aug 4, 2016

I can confirm that. CMD didn't apply DejaVu font like bash did.

@russalex russalex added the console label Aug 4, 2016

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Aug 10, 2016

@clarkzjw Could I ask you to repro the following steps:

  1. Upgrade to Win10AU if you've not already
  2. Open cmd from the start menu (non-elevated). Set its font to Consolas
  3. Close cmd window
  4. Reopen the cmd window from the start menu (non-elevated). It should have the same font as selected in 2.

Note that if you run Win + R -> cmd, you're running cmd.exe, which has a different set of properties to the shortcut used by the start-menu when you find and open the console from the start menu.

And if you open cmd or Command Line (start menu tile) or PowerShell and THEN run bash from within that console, Bash's font properties aren't used - just the fonts preferred by the console you first opened.

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 10, 2016

@bitcrazed Exactly. I just followed your step. It seems the Command Prompt in Step 2 and cmd.exe via Win + R are different. I didn't noticed that before. Are they different before Win10AU?

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented Aug 24, 2016

@clarkzjw cmd.exe and Command Prompt are the same thing, but they are loaded slightly differently, so they each have separately stored properties (it's confusing, but legacy, behavior).

Changing the properties on a bash window launched from the start menu (Win Key -> "bash") should persist the properties, but again, separately from the properties of Win Key + R -> "bash".

Perhaps you're setting the "Defaults" and not the "Properties"? These are again, different (and complicated for legacy reasons), and in my experience, changing the "Properties" is the option you always want.

@clarkzjw

This comment has been minimized.

clarkzjw commented Aug 25, 2016

@zadjii-msft Well, things become more interesting after some additional tests.

First, I am pretty sure I am editing Properties, not Defaults. If I use Win Key -> "bash" to launch a bash window, and change the fonts in Properties. and type exit to close and reopen in the same way. I tried some different fonts, it seems some fonts can persist while some cannot.

But if I use Win Key + R -> bash to launch a bash window, and change font settings, in my tests, all fonts can persist, including the fonts failed in (Win Key -> "bash") case.

It's quite interesting. I am not sure if this is what you mean they are loaded slightly differently.

@lnyng

This comment has been minimized.

lnyng commented Sep 9, 2016

I think the difference is due to using shortcut or not, but not depends on using cmd or not.
You can go to system32 and double click the bash.exe instance, and it behaviors exactly the same as opening it through cmd. But when you use shortcut, it's different. (at least for me)

By different I mean both the font as and a coloring issue. This is the PS1 I am using:

\n${debian_chroot:+($debian_chroot)}\[\033[38;5;226m\]\u\[$(tput sgr0)\]\[\033[38;5;39m\]@\[$(tput sgr0)\]\[\033[38;5;46m\]\h\[$(tput sgr0)\]\[\033[38;5;15m\]:\[$(tput sgr0)\]\[\033[38;5;87m\]\w\[$(tput sgr0)\]\[\033[38;5;28m\]\\$

It seems that only the bash launched through shortcut could display the color of the PS1 correctly. That's why I want to fix the font problem when using the Win Key + bash (shortcut) way to launch bash.

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented Sep 12, 2016

@clarkzjw That's strange to me. I'm gonna ping @bitcrazed and @paulcam206 (who has a bit more experience with the properties loading) to see if we can't triage this

@LeonYang5114 Are the colors on the "Colors" properties tab the same for both your bash.exe shortcut and launching it from Win+R the same? This is a bit of what I meant by they are loaded slightly differently - Launching from the shortcut stores the properties in the shortcut itself which the shortcut reads on future relaunches, while launching from Win+R launches the exe directly, reading&writing the properties from the registry.

Because the console doesn't support 256-color in the AU, \033[38;5;226m will get translated into the nearest color in the color table to color 266, so if you have different color tables, it will get translated differently depending on what's available. You can see #76 for more on this.

@gurnec

This comment has been minimized.

gurnec commented Sep 13, 2016

FWIW I just ran into what I believe is a general Windows console bug which I at first thought was WSL related, but no longer do. I'm just pointing it out on the off chance it's being encountered by anyone watching this issue.

To reproduce (on Win10AU):

  1. Open the font properties (via any method), change the font size to something that's not in the font size list (e.g. 15) by typing it into the provided edit box, OK out. (The size will change as expected.)
  2. Open the font properties again. You'll see that 15 has been added to the font size list and it's pre-selected. Leave it alone, choose a different font, and OK out. The font should change as requested, however it doesn't (and the new setting isn't persisted).

For whatever reason, if that 15 temporarily added to the list box remains selected, font changes are ignored.

The workaround is to ensure the 15 in the list box isn't selected before OKing out, either by selecting a different size or by entering 15 in the edit box.

My apologies for the noise it this is unrelated...

@spivoler

This comment has been minimized.

spivoler commented Sep 18, 2016

Hi Guys,

I am having exactly the same problem. The only thing I wanted to do is to use font consolas and save it as default. That used to work until after I install language package (Simplified Chinese). After that, the default font is always a Chinese font. I can manually change the font of current bash, while the setting cannot be saved for future usage...

It would be good to have the bug fixed asap. Appreciate it.

@mchenzero

This comment has been minimized.

mchenzero commented Oct 7, 2016

I have this same issue too. I figured that this may only happen to Asian installations.

Asian installations have different fonts available for use in a console session window than non Asian installations. (See the explanation here.)

While, for example, Consolas is available for use in console for non Asian installations (yes?), it is not shown in the font list of Command Prompt's properties setting window for Asian installations. However, it is shown and usable in Bash on Ubuntu on Windows.

I found that for any fonts shown in Command Prompt's font list, for example MS Gothic, the setting on Bash on Ubuntu on Windows could persist. (A shortcut is needed as pointed out by @LeonYang5114.) But for any fonts not shown in Command Prompt's font list, the font setting on Bash on Ubuntu on Windows only works for the current session. However, if we right click and see properties of the shortcut, we can see that font setting has actually been saved.

@bitcrazed bitcrazed added the bydesign label Oct 10, 2016

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Oct 10, 2016

@ALL: There are several nuances to how and where console apps get their settings from when launched directly, via start-menu tiles, and via shortcuts / pinned apps. We'll be writing-up a blog post on this v. soon.

For now, remember:

  1. If you run a console app directly (e.g. via [Win] + [R] -> console app), its settings are pulled from the registry. If there are no pre-existing settings configured for a console app, its settings are initialized from the console defaults.
  2. If you launch a console app from a shortcut or tile, the settings for that app are pulled from the shortcut/tile. If you create your own pinned links to apps, each pinned link can have it's own font, colors, etc.
  3. If you make changes to the settings of a system-managed .lnk / shortcut / start menu tile / [Win] + [X] menu item, your settings will be restored to defaults each time you upgrade to a new OS build.

In the screenshot below, you'll notice that the two bash consoles, started via different means, have different fonts:
image

Same app. Same ConHost terminal, different settings due to different start-mechanisms. This can be a very useful feature if you want to create terminals with different settings for different tasks.

@ryanerwin

This comment has been minimized.

ryanerwin commented Oct 29, 2016

@bitcrazed,

It's been 19 days since you posted, and I hope your blog post is coming soon.

Still don't understand HOW to change the font when launching it via a Live Tile or Pinned app? Strange that it would be different from launching via a shortcut...

At least ConEmu supports Bash for Windows quite well so that's probably the best workaround until we've got clarification.

@andrewfinnell

This comment has been minimized.

andrewfinnell commented Oct 29, 2016

@ryanerwin Personally I recommend ALWAYS launching it via a Shortcut. The best way I've found is to Right click on the Start Menu shortcut, Pin to Taskbar, then change those properties. Bash for Windows for Ubuntu (i.e. bash.exe.) needs to Run As Administrator anyways, which can only be done via a shortcut. If it isn't Run As Administrator so many things do not work.

@willise

This comment has been minimized.

willise commented Oct 29, 2016

@bitcrazed Very looking forward to your post.

@ryanerwin

This comment has been minimized.

ryanerwin commented Oct 30, 2016

@afinnell

Besides ping (which I replace with httping) what else doesn't work without bash.exe being run as administrator? I can't stand that full screen warning each time I launch an app confirming it requires admin access, and I don't want to disable UAC (doesn't sound like a good idea)...

Must admit that it's very strange basic things like mklink can fail in cmd.exe when you're not running with administrator access...

@Po-wei

This comment has been minimized.

Po-wei commented Oct 11, 2017

Does it support codepad 950(traditional Chinese)?

@Po-wei

This comment has been minimized.

Po-wei commented Oct 11, 2017

Unfortunatelly, it seems that this font does not persist in CP950.

@licett

This comment has been minimized.

licett commented Nov 11, 2017

@SwimmingTiger You are so wonderful guy!
I'm almost killed by this problem, and your advice really come to my rescue.

@liuluheng

This comment has been minimized.

liuluheng commented Nov 12, 2017

use cmder and type wsl and Enter. The font problem solves perfectly

@ac-m

This comment has been minimized.

ac-m commented Nov 17, 2017

Bug reproduce :

  1. Install Win10 1709 Simplified Chinese Version and WSL
  2. Install ubuntu font :
    Download
    http://font.ubuntu.com/download/ubuntu-font-family-0.83.zip
    Unzip ubuntu-font-family-0.83.zip
    Install font UbuntuMono-R.ttf
  3. Open shortcuts / pinned "Bash on Ubuntu on Windows", change font to "Ubuntu Mono"
  4. Close and reopen "Bash on Ubuntu on Windows", the font isn't "Ubuntu Mono", the font is default font "新宋体".
  5. Right click the pinned "Bash on Ubuntu on Windows" icon, continue right click "Bash on Ubuntu on Windows", select "property", goto font tab, you can see the font is "Ubuntu Mono".

So,the change of font do persist to "Ubuntu Mono".
Maybe problem is, it can not init from font "Ubuntu Mono".

@winteryoung

This comment has been minimized.

winteryoung commented Dec 1, 2017

Can anyone reopen this issue?

@miniksa miniksa self-assigned this Dec 1, 2017

@miniksa miniksa removed the fixed label Dec 1, 2017

@miniksa miniksa reopened this Dec 1, 2017

@miniksa

This comment has been minimized.

Member

miniksa commented Dec 1, 2017

MSFT: 14907854 filed for additional investigation.

@winteryoung

This comment has been minimized.

winteryoung commented Dec 2, 2017

The best way to do this is adding a fallback font. Windows has already used the system default font (in the case of East Asia) for non-ascii characters. You just need to make this setting available for users.

@miniksa

This comment has been minimized.

Member

miniksa commented Dec 4, 2017

Our current rendering system in the console doesn't support font fallback.

I can work on resolving the persistence of any given font if it is not sticking, but font fallback would require a near complete overhaul of the renderer (which is on the long-term plan, but isn't a bug-size fix.)

@NyaMisty

This comment has been minimized.

NyaMisty commented Dec 7, 2017

@ac-m running from Win+R will solve that issue

@ac-m

This comment has been minimized.

ac-m commented Dec 8, 2017

@NyaMisty

Thx.

I just tried it from Win+R, the UbuntuMono font is OK, the SourceCodePro font is still not good.

I'm using a customized font, YaHei mixed with SourceCodePro.
It's OK.

@miniksa

This comment has been minimized.

Member

miniksa commented Dec 8, 2017

I've submitted an additional fix today to this issue. It should go out to Insiders sometime in the next few weeks (probably in January since we're about to hit the holiday season in the United States).

@NyaMisty had the best explanation above of why this is happening with the console.

As an example on a Traditional Chinese system, the non-Unicode Codepage will be 950. On any console host start, it will retrieve this value from the system and then load up all your settings and preferences. It will convert the codepage to a charset (https://msdn.microsoft.com/en-us/library/cc194829.aspx) getting the CHINESEBIG5_CHARSET and submit that along with the font name preference to GDI. At that point, GDI will realize that your preferred font might not have CHINESEBIG5_CHARSET as an option and instead fallback to another font that does have CHINESEBIG5_CHARSET as an option. Then the console host startup sequence is complete and we will accept a connection from an application.

The WSL subsystem attaches to the console and immediately changes the codepage through SetConsoleCP (https://docs.microsoft.com/en-us/windows/console/setconsolecp) to 65001 (UTF-8). 65001 doesn't have a particular charset associated with it, but the console host doesn't retry your preferred font face name with GDI at the later time.

What I've done in the fix I just submitted is that we will retry setting your preferred font face name with GDI each time your codepage changes. This should mean that while when the console immediately loads, it may not choose Ubuntu Mono for the few moments when the window displays and is waiting for WSL to attach, that it will retry Ubuntu Mono when it receives the SetConsoleCP(65001) command from the subsystem and it will switch to your preferred font by the time the shell prompt comes up.

@miniksa miniksa added the fixinbound label Dec 8, 2017

@liyuan-rey

This comment has been minimized.

liyuan-rey commented Dec 15, 2017

I'm using Chinese-Simplified Win10 version 1709, I have same font issue when run cmd.exe/wsl.exe/bash.exe/ubuntu.exe from Start -> Run...
After specified the codepage to 65001(0xfde9) with regedit like below, the font of terminal can be chosen and persistent.

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe]
"CodePage"=dword:fde9

But if run cmd.exe/wsl.exe/bash.exe/ubuntu.exe or any other console application by a shortcut(*.lnk), the font of terminal fallback to Chinese font SimSun.

I found these information, https://msdn.microsoft.com/en-us/library/dd891330.aspx , does that mean .lnk file have its own codepage information, and if we run a console application through .lnk, system will use codepage in .lnk rather than registry - HKEY_CURRENT_USER\Console\*? Is there any way to change codepage in .lnk file?

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Dec 15, 2017

@liyuan-rey Yes, shortcuts may contain codepage info.

@Brainor

This comment has been minimized.

Brainor commented Jan 19, 2018

Here's how I solve the problem, inspired by @liyuan-rey .
My situation: using Chinese-Simplified Win10 version 1709, using Run->Bash to invoke bash interface. The font can't be changed to Consolas permanently.
Solution: Run->regedit, in the path HKEY_CURRENT_USER\Console\%SystemRoot%_system32_bash.exe, add/modify item CodePage->(DWORD)FDE9(65001)

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Jan 19, 2018

@ALL: As discussed above, we posted two relevant blogs on this subject:

  1. How Console and command-line app settings work
  2. The default Console colors have been updated (in current Insider builds)
  3. Announcing the Console ColorTool to help you apply color themes to Console instances

The first of these blogs is likely of most interest, and we encourage you to read it through several times to make sure you grok the nuances of how Console finds and loads settings for command-line apps from the registry or from shortcuts (inc. shortcuts on the start menu, or pinned to your taskbar/desktop).

Note that the discussion about settings is orthogonal to the Console's current inability to display a broad range of international characters, symbols, and glyphs: That's an entirely different issue that we are keen to address. Please bear with us for now.

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Jan 19, 2018

@liyuan-rey - If you modify the default codepage of cmd.exe in the registry, it'll likely be ignored when you start Cmd from a start menu or pinned shortcut because Console is reading the codepage set in the shortcut itself, and not bothering to look at the registry because shortcut settings override registry settings.

@liyuan-rey

This comment has been minimized.

liyuan-rey commented Jan 22, 2018

@bitcrazed
Yes. And I failed to find tools to adjust codepage settings of the shortcut, I only use [Win+R] to start the console now. 😞

@xqdoo00o

This comment has been minimized.

xqdoo00o commented Jan 23, 2018

@Brainor @liyuan-rey
in the path HKEY_CURRENT_USER\Console\C:_Program Files_WindowsApps_CanonicalGroupLimited.UbuntuonWindows_xxxx.ubuntu.exe,
add CodePage->(DWORD)FDE9(65001)
then I start Ubuntu directly from start menu, It's Consolas !
PS: I use the new Ubuntu distribution from windows appstore, not the old one from Windows Subsystem for Linux

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented Jan 23, 2018

@xqdoo00o This should be unnecessary - when you launch a Linux/WSL Console, the codepage is automatically set to UTF-8 anyhow.

Execute the following from within your Linux instance's Console:

$ cmd.exe /C chcp
Active code page: 65001
@PaaandaChen

This comment has been minimized.

PaaandaChen commented Feb 1, 2018

I use the ubuntu app from windows store now, my code page is 65001 after running cmd.exe /C chcp command.

In default settings I can set font to consolas, but everytime I run ubuntu from windows start the font is still Chinese font SimSun

@xqdoo00o

This comment has been minimized.

xqdoo00o commented Feb 1, 2018

@PaaandaChen you could follow the setup that I published 9 days ago。

@PaaandaChen

This comment has been minimized.

PaaandaChen commented Feb 1, 2018

@xqdoo00o
that works, many thanks to you XDDD
didn't watch this issue for a long time.

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented May 22, 2018

Thanks for the discussion regarding this issue. Closing for now since there are several solutions to the posted issues.

Please open an issue on the Console Issues repo if you have continued/related issues.

@bitcrazed bitcrazed closed this May 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment