Skip to content
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

Unicode characters not rendering properly via WSL #306

Closed
wkbrd opened this issue Nov 10, 2018 · 4 comments
Closed

Unicode characters not rendering properly via WSL #306

wkbrd opened this issue Nov 10, 2018 · 4 comments
Assignees
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Product-Conhost For issues in the Console codebase Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@wkbrd
Copy link

wkbrd commented Nov 10, 2018

  • Your Windows build number: 10.0.18277.1000

  • What you're doing and what's happening:
    Attempting to view the contents of a UTF-8 file via WSL does not show the contents of the file.

  1. Create a new file on Linux with UTF-8 characters, such as: 国際
  2. Within WSL, attempt view file using vi. Question mark characters will be shown instead.
  • What's wrong / what should be happening instead:

When using vi, expecting to see 国際. Note this problem reproduces with a local file to WSL as well as over an ssh connection. Characters show properly when using PuTTy.

@zadjii-msft
Copy link
Member

Is this unique to WSL, or does this issue also repro in a normal cmd/powershell window?

@zadjii-msft zadjii-msft added the Issue-Question For questions or discussion label Nov 12, 2018
@bitcrazed bitcrazed added the Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues label Nov 12, 2018
@bitcrazed
Copy link
Contributor

Same behavior in WSL and PowerShell.

image

This is most likely caused by a combination of the following:

  1. The glyph for the characters in question likely not available in the currently selected font (Consolas)
  2. Because Console uses GDI to render text, and since GDI does not support font-fallback (a mechanism for dynamically finding and loading a font that does contain the required glyph), Console is unable to render the requested glyph.

We are very aware of this limitation (e.g. see #190) and are working on a set of changes to remedy this issue in a future OS release.

@zadjii-msft zadjii-msft added backlog Product-Conhost For issues in the Console codebase and removed Issue-Question For questions or discussion labels Nov 12, 2018
@zadjii-msft zadjii-msft added this to the Backlog milestone Nov 12, 2018
@zadjii-msft zadjii-msft added the Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. label Nov 12, 2018
@zadjii-msft
Copy link
Member

I'm going to close this as a dupe of #190 then.

ellemenno added a commit to ellemenno/programming-pages that referenced this issue Jan 27, 2019
vanilla windows terminal (cmd.exe) does not have robust unicode support
beyond the old ibm codepage 437.

the console team is aware and working on it..

- microsoft/WSL#75
- microsoft/terminal#104
- microsoft/terminal#190
- microsoft/terminal#226
- microsoft/terminal#306
@WSLUser WSLUser mentioned this issue Jun 2, 2020
2 tasks
@willi84
Copy link

willi84 commented Jul 4, 2021

as a workaround try this:
https://stackoverflow.com/a/68236169
install all the fonts and set up "Dejavu sans mono for powerline"

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Product-Conhost For issues in the Console codebase Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

5 participants