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

[qqkookie]

I have same problem with Bold attribute of character. Using WT preview build and Windows 10 + WSL 2 Ubuntu nano editor. I set nano to use bold face instead of reverse video character attribute. then the text become invisible on light color theme screen. On dark color theme it is displayed in normal face. I tested it with various fixed width fonts like Consolas, Lucida Console, D2Coding, same problem.

Interestingly, with dark color theme ("Scheme" like "Campbell", "One Half Dark"), the bold characters are displayed anyway in normal face (not bold), but with Light color Scheme like "Solarised Light" or "One Half Light", the bold characters become totally invisible. So I suspect some problem related to this #571 (Some colors are swapped in Terminal), problem in color mapping.

So I suggest that the bold characters should be rendered in normal face for the time being with light color scheme, same as it does with dark color scheme, ie. ignore bold attributes as if WT has no bold character capability , as interim stopgap solution until it is fixed completely.

[leifmetcalf]

I used to edit the 'One Half Light' colourscheme so that the 'bright white' colour was black, which fixed it for me. Dunno how to do that now that the default colourschemes aren't in the config.

[qqkookie]

That may be the reason that reverse video character attribute does not work in Light color scheme.

In dark color scheme, the reverse video does work correctly ( character => background color(black in dark scheme), character background +> foreground color (white in dark scheme) But in light color scheme, doing same processing for reverse video does not work, because the fore/back assignment combination is already reversed. (i.e character => black, background => white) . So revere video text part does not stand out from normal text in Light color scheme.

Correct processing should do the opposite (i.e character =>background (white in Light scheme) , character background => (black in Light scheme) in Light color scheme. There seems that the reverse video part of the code is using wrong colors, using color-0/color-15 directly instead of foreground/background color indirectly. Reverse video should use color specified as background color for charter color and foreground color for filling character background.

[jdebp]

Attributes.ps1 shows the level of attribute support in Windows Terminal. Currently, several things are missing, or implemented in the way that M. Turner noted earlier.

[Qix-]

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

I believe the wikipedia page states that because microsoft did it wrong for so many years. Most implementations I've ever come across change the glyph weight without touching the foreground color.

Keep in mind, there are few, if any real, standards on these escape codes.

Perhaps Microsoft can retire the old cmd.exe behavior. This would be a good chance to make things right.

[heftig]

I believe the wikipedia page states that because microsoft did it wrong for so many years. Most implementations I've ever come across change the glyph weight without touching the foreground color.

I took a sample of the terminals available to me, in their default configuration:

PuTTY - only bright Linux fbcon - only bright XTerm - both bright and bold urxvt - both bright and bold Konsole - both bright and bold Terminology - both bright and bold VTE (GNOME Terminal) - only bold (past versions used to be both bright and bold) Alacritty - only bold OSX Terminal - only bold iTerm2 - only bold

[zadjii-msft]

oh man, I guess I'll summon @egmontkob and @j4james into this thread as well, to maybe summarize #5682/#5384/#2661

[j4james]

Yeah, I don't want to get into another long argument about this. I just want to say two things:

1. A lot of the statements that have been made on this subject are simply false.
2. At some point after #2661, assuming this issue is still open, I would like to submit a PR which adds bold font weight support for the ITU indexed and RGB colors, which I think is a reasonable compromise (and I believe would match Mintty's default behaviour). That's as far as I'm willing to go.

[agocke]

As the original filer of this issue I'll note that I did screw up porting my Xresources and the behavior after I fixed that was fine.

[egmontkob]

The recent trend is to fully separate the font weight from the color. Foreground color is set by SGR 30-38 and 90-97 (39 or 0 turns it off); whereas bold lives on as the previously ambiguous bold-or-bright SGR 1 (22 or 0 turns it off). [It's a common misbelief that 21 turns it off; no it doesn't, it's 22.]

This makes a lot of sense ever since 256-color and later truecolor support was introduced in many terminals, and is also the mode required for the popular Solarized theme. I believe this mode is the only reasonable way to get rid of legacy's no longer relevant limitations and to move forward. This behavior comes with backwards compatibility issues, though, even in the Linux world, and probably much more prominently in the Windows world.

For VTE, the discussions are mainly at bugs 762247 (this one is more about the current technical side) and 791596 (this one is more about the legacy and the philosophical side).

What in my opinion every terminal should do:

• Internally, track for each character cell the SGR 1 state, and independently from this, the SGR 3x/9x state. (And while at it, SGR 3 for italic.)

• Implement painting bold typeface. (And while at it, italic too.) [It's indeed a bit unfortunate that there's no additional room for bold chars, it's up to each terminal to fine tune the look, e.g. pick the bold characters' width for the cell, or the average of the regular and bold, or whatever that looks the best. In VTE we pick the regular characters' width, thus bold text is a bit squeezed.]

• Implement a couple of possible mappings from the internal logical SGR 1 and 3x/9x states to the physical boldness and color display mode; including one or more traditional behaviors where SGR 1 brightens the legacy first 8 colors, maybe boldens everything, maybe doesn't use bold typeface anywhere at all, etc., and also a trivial direct mode where SGR 1 specifies the font weight and SGR 3x/9x specifies the color without overhearing.

[Qix-]

@j4james

A lot of the statements that have been made on this subject are simply false.

I mean, meh. There are no relevant standards to refer to for today's emulators. Linguistically, "bold" does not mean changing the color. That's always been a Microsoft behavior, in my head at least.

[rbeesley]

@leifmetcalf

I used to edit the 'One Half Light' colourscheme so that the 'bright white' colour was black, which fixed it for me. Dunno how to do that now that the default colourschemes aren't in the config.

You can use the shortcut to open the default settings profile, and then introduce a new scheme to your settings which override the defaults, copying the values from the default. The way the settings are applied, this will allow you to make changes. Similarly, if you don't want to directly override the default scheme, you can create a new scheme using those values and then apply them to the profiles you want to modify.

[zachmatson]

I find myself just going into VS Code for the terminal much of the time because of this... It renders bold text perfectly

[tigerinus]

I believe the wikipedia page states that because microsoft did it wrong for so many years. Most implementations I've ever come across change the glyph weight without touching the foreground color.

I took a sample of the terminals available to me, in their default configuration:

PuTTY - only bright Linux fbcon - only bright XTerm - both bright and bold urxvt - both bright and bold Konsole - both bright and bold Terminology - both bright and bold VTE (GNOME Terminal) - only bold (past versions used to be both bright and bold) Alacritty - only bold OSX Terminal - only bold iTerm2 - only bold

VSCode Integrated Terminal - only bold

[rbeesley]

@tigerinus, while I suppose that could be why Wikipedia says that, that seems unlikely to be the real reason. ANSI.SYS was necessary to use any of the SGR attributes like intensity. So I don't know why that would have been the case for other POSIX terminals.

The standard just has SGR 1 as increased intensity or bold, so it's pretty open. Interestingly 90-97 for bright foreground and 100-107 for bright background isn't actually part of ECMA-084 that I could see.

One of the benefits of using SGR 1 for bold instead of increasing the intensity is that it would provide a lot more control over the output. As it is right now SGR 1 and 90-97 effectively overlap with the same result. As long as the non-standard attributes provide access to the bright foreground and background, SGR 1 is less useful on its own.

[gordonmessmer]

I wanted to expand @heftig 's results, with a few corrections. (I can provide screenshots for most of these if they would be helpful)

I compared the output of colored text, bold colored text, bright colored text, and bold bright colored text with this command:

for x in 3 9 ; do for y in $(seq 0 7) ; do echo -e "\033[0;${x}${y}mblah \033[1;${x}${y}mblah" ; done ; done

Terminal	Bold	Bold and Bright
alacritty	ok	ok
gnome-terminal	ok	ok
kitty	no [1]	no [1]
konsole	ok	no [2]
mate-terminal	ok	no [2]
rxvt	ok	no [2]
terminator	ok	ok
xfce4-terminal	ok	no [2]
xterm	ok	no [2]
Linux console	no [3]	no [2]
OS X Term	ok	ok
PuTTY	no [3]	ok
Windows Term	no [3]	no [2]

1: bold has no effect 2: bold and bright is the same as bold 3: bold is treated as bright

All of the terminals tested supported a standard and a bright color palette.

Of the terminals tested, other than Windows Terminal, only the Linux FB console and PuTTY (and its derivative mintty) will used the bright color palette for bold colored text.

However, Windows Terminal has one unique flaw. Windows Terminal is the only terminal tested that (as best as I understand its behavior) uses "bright white" text when the bold attribute is supplied alone, regardless of the color of the background. This makes all of the light-background themes supplied with Windows Terminal unusable, or very bad. When using common tools like "top", many fields are difficult or impossible to read.

Lacking support for bold text, it would be much better in the short term if Windows Terminal simply ignored bold, the way that kitty does.

Later, when bold text support is added, Windows Terminal should adopt the common behavior of using the standard color palette for bold colored text, and bright color palette only when it is specified.

[DHowett]

@gordonmessmer i recall seeing a “bright default” color entry in gnome-terminal some months ago, for use in the 1;39 case. Have you seen anything like that in the terminal emulators you’ve profiled?

The specific behavior you're seeing with WT compressing 1;39 into 97 and 39 into 37 is a legacy compatibility behavior; see #293 and #2661 for more.

[gordonmessmer]

"i recall seeing a “bright default” color entry in gnome-terminal some months ago, for use in the 1;39 case. Have you seen anything like that in the terminal emulators you’ve profiled?"

Do you mean the "bold color" preference? I didn't look for that setting in the other terminals. That seems like a preference that only makes sense for terminals that don't support bold weight fonts. In #5682, @egmontkob suggested that the preference doesn't make sense any more and was likely to be deprecated.

I can go through them again if it would help.

"The specific behavior you're seeing ... is a legacy compatibility behavior"

I'm sure. My purpose was to demonstrate that WT is nearly alone in implementing that behavior. gnome-terminal supports it as an optional behavior, and other terminals probably do too. I didn't look.

I guess I'd have to ask whether WT is intended to be a legacy support tool, or in the words used in the README, "a new, modern, feature-rich, productive terminal application". The current behavior is at odds with that description, and if the current behavior is a bug, then that's fine. Reasonable people don't expect anything to be perfect, especially in early releases. However, some of the bug reports that I've read suggest that at least one developer is unwilling to consider supporting the standard behavior, and that is disappointing.

[DHowett]

As I’m sure you’re aware, it’s never quite so crisply-defined into buckets like “legacy support software” or “shiny new thing.”

Without color elision, every application written targeting the console API looks terrible (https://github.com/PowerShell/PSReadLine/issues/830#issuecomment-650508857 or some variation thereof; CMD gets more black bars, powershell gets fewer, FAR demolishes your buffer). Like as not, those applications are our “legacy”. I don’t mean that as a perjorative—there are applications being written today that don’t or can’t or won’t use VT, and they are an important part of our ecosystem.

Of course, that doesn’t mean we aren’t improving what we can. #6506 and #6698 are a huge step in the right direction; with those, and thanks entirely to @j4james, we can finally tell the difference between 39 and 37 and 97 and the Win32 API SetConsoleTextAttribute(0x07). Once those land, we’ll be in a better place to make plans around supporting typographical bold versus brightening.

Which one we’ll end up doing and how configurable it will be should be the topic of a specification and not a GitHub issue comment written up on my phone.

Regardless, this request wouldn’t still be open if we weren’t going to do something about it.

The strangest part is...

... that this thread is coming up again on the day I decided to hack typographical bold into the text renderer: 

[j4james]

@gordonmessmer i recall seeing a “bright default” color entry in gnome-terminal some months ago, for use in the 1;39 case. Have you seen anything like that in the terminal emulators you’ve profiled?

I know XTerm, VTE, Mintty, Tera Term, iTerm2, PuTTY, ZOC, IVT, and VTStar all have an option like that.

[gordonmessmer]

To be clear, I regard the inability to render text with bold font weight as a superficial issue. I also regard the conversion of bold+color to bright color as a superficial issue.

However, converting bold alone to bright white unconditionally seems like a bug if users can configure a light color background. I'm not sure this is the right bug report in which to continue that discussion. #5682 might be, but I dislike the practice of framing a bug in terms of one possible solution.

I see your screenshots in #6698 and I can't tell if that change is an improvement to this situation, because it looks like you're only testing the change in terminals with a dark background. If you're not testing any of the light themes, I think you're likely to continue to blame a minor flaw in Solarized Light for a significant flaw in Terminal.

[j4james]

@gordonmessmer Below are some screenshots showing the effects of the #6506/#6698 PRs on the bold attribute in a couple of light color schemes. Comparing before and after (first and second screenshot from each scheme) you can see the bold attribute is no longer mapping to white. That was simply a conpty narrowing bug. And while the default bold color interpretation may still have room for improvement, that's best discussed in #5682.

[edyu]

For people who use terminal versions of vim and nvim, it would be super useful to have this "feature" implemented or this bug fixed along with the problem with italics.

[swinder0161]

Fluent Terminal on windows can show Bold + Bright

Windows terminal seems to do nothing

[DHowett]

@swinder0161 yes, that is the basic premise of this open issue titled “enable bold text in Windows Terminal”. If you want to register your support for it, consider clicking on the 👍 button below the top comment.

[zadjii-msft]

@bsidhipong If you'd like to "+1" this feature, the best way to do that is by hitting the 👍 button on this issue

That way, you avoid unnecessarily pinging everyone following this thread. Thanks!

[DanielAtKrypton]

I was able to achieve the functionality I wanted with Vs Code, bold is working perfectly fine and rendered as DOM. It would be great to have the same possibility with windows terminal.

More information

[jm33-m0]

I can't believe this is still open after almost 3 years... When using lazygit in Windows Terminal, bold has absolutely no effect, causing the cursor location undetectable. I have to add that in default console of powershell, lazygit works quite well, with bright color as bold

[MrInfusion]

I can't believe this is still open after almost 3 years... When using lazygit in Windows Terminal, bold has absolutely no effect, causing the cursor location undetectable. I have to add that in default console of powershell, lazygit works quite well, with bright color as bold

When do Windows Terminal Devs implement that? It does take so long and still nothing. Cant they just switch to DirectWrite? Is it that hard?

[DanielAtKrypton]

I can't believe this is still open after almost 3 years... When using lazygit in Windows Terminal, bold has absolutely no effect, causing the cursor location undetectable. I have to add that in default console of powershell, lazygit works quite well, with bright color as bold

When do Windows Terminal Devs implement that? It does take so long and still nothing. Cant they just switch to DirectWrite? Is it that hard?

There might be not enough community appeal to develop that at the moment. The more people vote here, the more likely devs will focus on this feature rather than on others. The very same technology VS Code uses could be used here too, I believe. Maybe someone could dehydrate VS Code to make a standalone terminal too.

[mdtauk]

I can't believe this is still open after almost 3 years... When using lazygit in Windows Terminal, bold has absolutely no effect, causing the cursor location undetectable. I have to add that in default console of powershell, lazygit works quite well, with bright color as bold

When do Windows Terminal Devs implement that? It does take so long and still nothing. Cant they just switch to DirectWrite? Is it that hard?

There might be not enough community appeal to develop that at the moment. The more people vote here, the more likely devs will focus on this feature rather than on others. The very same technology VS Code uses could be used here too, I believe. Maybe someone could dehydrate VS Code to make a standalone terminal too.

Terminal does use Direct Write AFAIK - and support for Bold text is being worked on.

There are some complications when a user chooses a bold weight font in their settings, which need working out.

And not every feature in Windows Terminal, can be ported back to the version of console that is backwards compatible

[j4james]

I actually hacked together a POC implementation of this in conhost a while back - it doesn't require a lot of code. I didn't look at the DX engine, but I can't imagine it'd be that much more effort.

And you're right about the complications when you start with a bold font. I just did a quick test now with various weights of Cascadia - the SemiBold version showed no difference when having a heavier weight applied to it as far as I could tell. It's possible that's just a limitation of that font though, or maybe the GDI renderer.

You can see some screen shots below demonstrating the behaviour with different weights: default, ExtraLight, and Semi-Bold.

[TBBle]

Terminal does use Direct Write AFAIK - and support for Bold text is being worked on.

Am I correct in understanding that a needed bold text support feature in DirectWrite blocks Windows Terminal from supporting bolded text for inline \e[1m?

There haven't been any updates to DirectWrite since Windows 10 1903. Is bold text support still being worked on for DirectWrite?

Or is future DirectWrite feature work now focussed on DWriteCore and so Windows Terminal will have to migrate to it to gain new text rendering features, once it is up-to-spec?

[DHowett]

Nope, this is totally blocked on us. DWrite is an excellent piece of software and I hope that it never changes (because changes inevitably break things for us :smile:).

@skyline75489 is slowly marching towards bold text support -- we just haven't been reviewing his PRs fast enough.

[skyline75489]

For those who're subscribing, I'd like you all to know that after 3 years of development, most of the obstacles have been cleared for this feature.

It does take so long and still nothing

This is simply not true, Three years ago this is a huge backlog item, and now this should be considered as a simple feature, thanks to all the previous work.

At the moment of writing, the underlying font handling code needs a bit of refactoring to better support bold & bold italic. I've filed #9096 and #9201 to support the work. Hopefully bold will be supported before/at version 2.0. Personally I love to see it supported, because it's the last eye-candy thing (I'm aware of) that's missing in WT, comparing to all the well-known Linux terminals.