Enable Bold Text in Windows Terminal

[bitcrazed]

From @agocke on April 27, 2017 22:5

Repro: echo -e "text \033[1mbold\033[0m text"

This prints the following for me:

bold should actually be bold, not just another color in the color palette. It also shouldn't change the foreground color.

Microsoft Windows [Version 10.0.15063]

Copied from original issue: microsoft/WSL#2027

[bitcrazed]

From @sunjoong on April 27, 2017 23:17

@agocke - lt looks not bold but bright. Effect of code 1 is "Bold or increased intensity -- ANSI escape code".

[bitcrazed]

From @zadjii-msft on April 27, 2017 23:24

@agocke that's exactly right. We don't support proper bold at the moment, but the intensity works just fine for now. Like with all feature requests, it's already on the backlog :)

[bitcrazed]

From @agocke on April 27, 2017 23:29

@zadjii-msft How do you decide what "intensity" means in this context? It seems to pick a different color from the palette, i.e. I can actually change the color that is printed by bold and it can be completely different from the normal color.

This is important because if I change the color scheme for my 8 foreground colors, what happens to my bold colors? It seems like sometimes nothing may happen, which means the bold colors show up as unreadable in my new color scheme.

[bitcrazed]

From @fpqc on April 28, 2017 3:6

@agocke This is pretty standard for terminal emulators. The 'bright' colors are the second row of 8 colors in programs that have a sane color picking interface =p.

[bitcrazed]

From @agocke on April 28, 2017 3:26

Yeah, I think I screwed up the transcription from my .Xresources. Still, bold would be useful.

[bitcrazed]

From @dgilmour77 on November 14, 2017 15:45

This creates a bit of a trap for unwary users. I like black text on dark grey background, and when I set it, it looked great. Until I brought up a man page and it looked garbled and broken because I was unlucky that the bold color automatically chosen was the same as my background color - dark grey. At a minimum, the logic for choosing a bold color should be based not just on the foreground color but the foreground/background combination. Yeah, good luck with that ;-)

[j4james]

If you do decide to implement this, is there any chance it could be made an option? Using the SGR bold (increased intensity) parameter to generate 16 colors has been a de facto standard (at least in the DOS world) for what must be decades now. And I think the default Linux console might work that way too actually. It would be sad to lose that functionality if you change it to bold instead.

I realise there are there are now other ways of getting bright colors, but that's obviously going to be a breaking change for old code, not to mention all that glorious ANSI artwork from the BBS era.

[bitcrazed]

@agocke: "Still, bold would be useful"

Bold is a little tricky because it actually changes the physical size & shape of letters and, depending on what fonts you use, sometimes ends up looking pretty awful.

Alas, the Console's current text renderer uses GDI which is > 30 years old and lacks much of the sophistication of modern text rendering technologies like DirectWrite.

Console's GDI renderer can't currently handle bold text:

But VSCode's integrated terminal takes advantage of Chrome which takes advantage of DirectWrite:

We are planning on replacing our GDI renderer with a DirectWrite renderer in the future which will allows us to (finally) render bold text, emoji, and all manner of other beautiful text effects, but until then, the best we can do is display "bold" text with a more intense color.

HTH.

[thchr]

I don't suppose there's any chance that the specific time of the 'future' could be teased here: might we see an insider build with DirectWrite in 2018 or 2019?

From an aesthetic point of view, it would be great if Windows could catch up with most standard Unix consoles in being able to print formatted text (improving text-display in WSL and some REPLs (e.g. in Python & Julia) on Windows)

[zadjii-msft]

Boy it would be great if I could give out exact timelines, but there are a lot of factors that affect how long a feature takes to get out the door.

I'd rather say nothing at all rather than give a timeline and let it slip.

[thchr]

Fair enough, understandable.

[yveslange]

Is this still planned ? Any news ? <3

[zadjii-msft]

Yep, still on the backlog. We'll make sure to post here when there's something to share :)

[leifmetcalf]

On a light background, the bold text is basically invisible. With the "One Half Light" theme it's just barely lighter than the background, and with the "Solarized Light" theme it's the same shade as the background.

[antoineco]

@leifmetcalf probably due to #293

[ghost]

🎉This issue was addressed in #10498, which has now been successfully released as Windows Terminal Preview v1.10.1933.0.:tada:

Handy links:

• Release Notes
• Store Download

[TBBle]

Looking good. Using https://github.com/jdebp/terminal-tests/blob/master/PowerShell/Attributes.ps1:

Since it's a picture, I'll note that both rapid and normal blink are the same speed (probably as-intended) but 'no rapid blink' is blinking as well, suggesting either a bug in the test script, or a failed state-clear somewhere in Terminal. But neither is a problem for this bug.

Edit: The script tries to clear rapid-blink (SGR 6) using SGR 26, but Wikipedia lists that as "Proportional Spacing". So probably a test-script error.

[riedel]

Bold works for me now on cygwin/wsl2 bash after setting intenseTextStyle": "bold" (just as a comment for anyone who stumbles on this and wants to try)

[Konfekt]

That is, add the line of "intenseTextStyle": "bold", to every item in the array profiles.list in the file settings.json.

[TBBle]

@Konfekt It doesn't work if you add it to the profile defaults? That sounds like a bug that should be raised as a new issue, rather than as a comment on a closed MR. Also, this MR actually predates it being selectable, so it's not even a relevant MR for your concern. (Although I just checked, and adding it to the profile defaults worked for me locally.)

[Konfekt]

It is me who did not understand the GUI setting, which says "Text formatting" with options "normal, bold, intense, bold and intense". I thought for example that the option "bold" changes the default text format to bold, rather than that it enables rendering ANSI escape codes for bold as bold.

This said, I wonder how to enable italic fonts under Vim in Windows? These work perfectly in Vim in WSL, but not in Vim in Powershell or cmd.

[zadjii-msft]

This said, I wonder how to enable italic fonts under Vim in Windows? These work perfectly in Vim in WSL, but not in Vim in Powershell or cmd.

This is probably a limitation of vim.exe. They're likely using the Win32 API to format the text (which doesn't support italics) vs the VT sequences that WSL vim would use (which does support italics)

[Konfekt]

Thank you, this is now filed as a feature request in the Vim issue tracker.

[kbridge]

That is, add the line of "intenseTextStyle": "bold", to every item in the array profiles.list in the file settings.json.

Or add this setting to profiles.defaults object.

[avih]

Is there a way to make the default bold color render as bright, like the first message on this issue:

I'd be fine if it's emboldened too, but I do want it brightened, because bold alone doesn't stand out enough (for my taste) , but brightened color does stand out nicely.

I do have "intenseTextStyle": "all",, but this seem to apply to the colors 0-7, but not to the default foreground color.

I.e. printf "\033[37m white \033[1m bold and bright\033[m\n" is white (7) and then bold-white which is rendered as both bold and brightened (that's great).

But this printf "default \033[1m bold only :( \033[m\n" only does bold, without bright.

One could argue that the most commonly SGR-1 color is the default foreground color, so it could be useful if the intenseTextStyle option could apply to the default color too.

It could probably either be automatically brightened, or as an additional color at the theme (near the default color).

Alternatively, can I set white (SGR 37) as the default color, so that SGR-1 on the default color ends up respecting intenseTextStyle ?

[TBBle]

I'd suggest opening a new feature request for this, as this ticket is closed.

I suspect what you want is "hard", because the "bold is bright" logic is to use the "bright" version of the colour, i.e. the second 8-colour row of the 16-colour palette, the same as adding 60 to the ANSI colour code.

However, that logic doesn't apply for the default colour (which is not an entry in the palette, but a separate slot) so we'd need a way to define "bright" for that colour specifically. It might make sense to be able to apply such generally, hence being able to enbrighten more than just the base 8 colours when using bold-is-bright. In cases like Solarized, where some implementations rely on bold-is-bright to access the full 16-colour palette, or just for users who expect the pre-defined 8 "bright" colours in the palette to apply to 'bold is bright' too, this logic does not apply, so this is a new option, it can't be a global change.

Conversely, detecting when the default colour is one of the non-bright 8 palette colours, and brightening it along with its palette-mate, would possibly resolve your issue. That's also a new feature...

So yeah, "hard", not an obvious or trivial fix.

[DHowett]

Funny enough, this is on our radar!

Right now, if your foreground matches one of the colors from 0-7 we will automatically "brighten" it using the equivalent indexed color from 8-15!

In the future, we're going to offer a specific "brightForeground" color specifier so that color schemes can indicate exactly how to brighten the foreground. That is tracked in #5682.

[avih]

I'd suggest opening a new feature request for this, as this ticket is closed.

Well, it was implemented originally, which is why this issue was opened in the first place, so I was merely asking whether it's still possible to do that ;)

Funny enough, this is on our radar!

Glad to hear!

Right now, if your foreground matches one of the colors from 0-7 we will automatically "brighten" it using the equivalent indexed color from 8-15!

That's actually quite good enough for me. Much appreciate the info!
Also, confirmed working! whooo :)

In the future, we're going to offer a specific "brightForeground" color

Right, that's what I thought would be the best general solution too.

That is tracked in #5682.

I'll follow that issue.

Thanks again!

[avih]

Conversely, detecting when the default colour is one of the non-bright 8 palette colours, and brightening it along with its palette-mate, would possibly resolve your issue. That's also a new feature...

Pardon that I didn't notice it initially at your post. Thanks :)

Right now, if your foreground matches one of the colors from 0-7 we will automatically "brighten" it using the equivalent indexed color from 8-15!

Actually, this is both very useful and also effectively undetectable to any normal user which doesn't ask on github and is lucky enough to get very useful replies...

How about adding some note or tooltip at the config pane about this feature, maybe near the foreground color box?

Maybe something like, "To allow brightening with intenseTextStyle, choose forground color identical to the white color or identical to the black color" (or some such).

And mention it's experimental/subject to change blah blah blah.