terminal
terminal copied to clipboard
microsoft
Add emoji support to Windows Console
Please support emoji within Windows Console.
Very useful when you code in vim newsletters for startups or when you categorize stuff by emoji.
Sweet! Another use case: I have a command line app that outputs warnings using ⚠.
@zadjii-msft will this include support for non-latin unicode characters? i.e. can Arabic or Japanese characters not found in the currently deployed console font be displayed with a different font face?
Hypothetically, yes.
Arabic is kinda it's own problem though - there's pretty much no chance we'll be implementing left to right language support any time soon, bt the characters might be able to render correctly.
@adiviness can speak more on the topic if there's more to share.
Arabic is a difficult one because of the additional support required for bidirectional text and ligatures. As far as I’m aware not many terminal emulators currently support it.
There is also a difference between the console being able to render emoji and supporting font fallback in the case of the current font not having a glyph. They are both items on our backlog.
+1 Our build and CI scripts have emojis for success ✔️, warning ⚠ and errors ❌ for quick, productive eyeballing of logs.
Can we please not +1 issues? Please use reactions or subscribe to notifications.
@miniksa , I wouldn’t get too distracted by the +1. You could entirely ignore it. The main purpose of typing it out was to articulate the use case. Presumably platform/product owners ought to be very interested in customer use cases ... thought granted in this case it’s not too extravagant.
@SidShetye - appreciate your comment - your use-case is not unusual, but is useful to hear about.
In general, we ask people not to +1 because we'd like to avoid people +1-ing (esp. with no further comment), which just ends up as noise, and makes threads more difficult to parse and manage.
Sharing additional comments, context, observations, issues, etc. is FAR more valuable than a +1 ;)
Weird that nobody mentioned it, but the Yarn package manager uses Emoji's and it's a bit annoying that they are only displayed as squares :/
Thanks @destructive-dragon - there are many tools that contain/emit emoji, but the Console is not yet able to render them.
@bitcrazed You mentioned in this twitter thread on the conpty release that we still need to wait for a new buffer and a new renderer (DirectWrite). Are those the only two major blockers left?
@kavdev Essentially, yes. To display emoji glyphs, we first have to be able to store (potentially compound) Unicode code-points for each glyph (E.g. Ninjacats), but we also have to be able to render them, which requires font-fallback, which GDI doesn't support.
We'll be working on improvements to both the Console's text buffer implementation, and also the Renderer in future releases.
@bitcrazed Many Emoji are composites, i.e., having multiple code points joined together (using ZWJ or VS, or whatever), and in most cases they do not fit in one Console cell. So your problem is not "1 cell to n characters" but "m cells to n characters"...
FWIW, my terminal emulator and iTerm2 both render emoji by basically treating them as "full width" (2 cell) CJK style characters. I don't know about iTerm2 but I don't make any attempt to support unicode "modifiers" on emoji or any other characters. Each character has to be one unicode code point although it may be normal width or full width.
@sedwards2009 The ultimate solution should be a Unicode or whatever specification that tell us how to handle complex script on a character grid.
The closest idea may be applying some concepts from justification (like inserting spaces between East Asian characters, and inserting Kashida when fitting Arabic characters into the grid), but justification implementation is a total mess. AFAIK DWRITE does the best job so far, but some implementations (like Kashida) is still very hacky.
Just one comment which might be useful - certain emoji and unicode symbols used to work, I'd display some on my WSL login banner, e.g. 🍰 (U+1F370), since 1809 update they no longer display in any terminal (WSL bash, Hyper, VS Code)
Some symbols do work in 1809 however, such as ☕ (U+2615) but I think they are in a different parts of the Unicode spectrum i.e. much lower codepoints
October update seems to bring a regression in this regard rather than progress. I was previously able to use all unicode symbols I have tested in VS Code integrated terminal (Which uses powershell), however after the October update all emoji and certain foreign language characters do not render correctly.
This actually seems to be a semi-system-wide font issue as even console emulators like ConEmu now fail to render emoji correctly.
@Ben-Hope @noxabellus same here.
I updated Windows 10 to 1809 and emojis are gone (PowerShell and Visual Studio Code; integrated terminal).
See command vue ui of vue-cli as an example:
🚀 Starting GUI...
@bitcrazed @zadjii-msft is there an issue tracking the regression found in 1809? I'm not talking about full-on emoji support, just getting back the basic foreign language/unicode glyphs that were supported under previous releases. Do you know if the issue persists in later beta releases?
Same here. I updated my Win10 from 1803 to 1809 several days ago, and now all characters >= U+10000 (UTF-8 with 4 bytes or more) no longer display. I have also tried the newest insider version(Windows 10 Insider Preview 18358.1 (19h1_release)), unfortunately, this bug still exists.
Since 19H1 will be released soon, could you please fix it, or report it because it could be a bug in other project?
Emoji rendering seems to have improved.
I tried a recent build of CascadiaPackage (Windows; x64) and get this (see image):
Running Windows 10, Build 1903.
Is there any merit to having an option to disable colour font emoji?
So any emoji used will be single colour using the font colour settings?
@mdtuak yep, in fact thats a setting @miniksa and I have previously discussed adding. I just filed #956 to track that work :)
@MartinMa that's an entirely different thing than the existing conhost.exe, if you tried to run OpenConsolePackage (which is the OSS conhost) you should still have the issue.
@MartinMa that's an entirely different thing than the existing conhost.exe, if you tried to run OpenConsolePackage (which is the OSS conhost) you should still have the issue.
Don't be so sure! The DirectWrite renderer that's used in Windows Terminal is also part of OpenConsole! You just need to set a registry key (HKCU\Console\UseDx = DWORD(1)) before it'll use it.
