Add preference to customize vertical line spacing #4885

New Issue

Closed

opened 2026-01-30 23:59:06 +00:00 by claunia · 68 comments

claunia commented 2026-01-30 23:59:06 +00:00

Owner

Copy Link

Originally created by @Spongman on GitHub (Nov 9, 2019).

Originally assigned to: @lhecker on GitHub.

the space between lines is way too large.

here's a comparison of the same block of text in terminal (top-left) and windows 10 command prompt (both bottom and right). the font is 'Lucida Console' in both programs.

the block on the bottom shows that the fonts are the same size (the width is the same).

the block on the right shows that the Terminal rendering is nearly 40% larger (blue arrow) than the Command Prompt rendering. That's 40% less text i can read without scrolling.

at the very least there needs to be an option to change the leading (that scales properly), although i'd recommend making it look like Command Prompt by default.

Originally created by @Spongman on GitHub (Nov 9, 2019). Originally assigned to: @lhecker on GitHub. the space between lines is _way_ too large. here's a comparison of the same block of text in terminal (top-left) and windows 10 command prompt (both bottom and right). the font is 'Lucida Console' in both programs. the block on the bottom shows that the fonts are the same size (the width is the same). the block on the right shows that the Terminal rendering is nearly 40% larger (blue arrow) than the Command Prompt rendering. That's 40% less text i can read without scrolling. at the very least there needs to be an option to change the leading (that scales properly), although i'd recommend making it look like Command Prompt by default. 

claunia added the Help WantedArea-RenderingArea-SettingsIssue-TaskIn-PRNeeds-Tag-FixProduct-Terminal labels 2026-01-30 23:59:07 +00:00

claunia closed this issue 2026-01-30 23:59:08 +00:00

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@mdtauk commented on GitHub (Nov 9, 2019):

I think the top left line spacing is very readable, and preferable.

As long as the box and block drawing characters line up properly without gaps, then that is good.

---

Now if you are saying there should be an option to adjust the line spacing - again as long as box drawing characters line up properly - then sure add line spacing as an option.

@mdtauk commented on GitHub (Nov 9, 2019): I think the top left line spacing is very readable, and preferable. As long as the box and block drawing characters line up properly without gaps, then that is good. ---- Now if you are saying there should be an option to adjust the line spacing - again as long as box drawing characters line up properly - then sure add line spacing as an option.

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Nov 11, 2019):

Thanks for the suggestion! I could have sworn there was already an issue for this, but it looks like it was only ever mentioned as a part of #1790 (and other threads), but never tracked individually. This is now the thread for configurable line height / spacing. Thanks!

@zadjii-msft commented on GitHub (Nov 11, 2019): Thanks for the suggestion! I could have _sworn_ there was already an issue for this, but it looks like it was only ever mentioned as a part of #1790 (and other threads), but never tracked individually. This is now the thread for _configurable line height / spacing_. Thanks!

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@Rican7 commented on GitHub (Jan 15, 2020):

Just wanted to hop in here and mention that while the config/preference would be nice, @Spongman might be seeing the effect of #455 (specifically #2779) happening here, if they're running with any "Display Scaling" in Windows.

@Rican7 commented on GitHub (Jan 15, 2020): Just wanted to hop in here and mention that while the config/preference would be nice, @Spongman might be seeing the effect of #455 (specifically #2779) happening here, if they're running with any "Display Scaling" in Windows.

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Jan 22, 2020):

nope, no display scaling going on.

just too much line spacing. you can see it in all the screenshots, too. so it's not just me.

@Spongman commented on GitHub (Jan 22, 2020): nope, no display scaling going on. just too much line spacing. you can see it in all the screenshots, too. so it's not just me.

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@Rican7 commented on GitHub (Jan 22, 2020):

Ah, ok. Fair.

I just figured it might have something to do with that. But yea, I agree that there's too much line spacing, regardless of display scaling settings.

@Rican7 commented on GitHub (Jan 22, 2020): Ah, ok. Fair. I just figured it might have something to do with that. But yea, I agree that there's too much line spacing, regardless of display scaling settings.

claunia commented 2026-01-30 23:59:09 +00:00

Author

Owner

Copy Link

@Techtonictools commented on GitHub (Feb 1, 2020):

It is exciting to see MS create a new terminal. Great work, I appreciate it.

+1 for the option to reduce spacing. Not a fan of reading double spaced lines and prefer smaller font too. Much more data can be presented in the given space.

Linux and Mac don't have such wide spacing and large fonts by default.

@Techtonictools commented on GitHub (Feb 1, 2020): It is exciting to see MS create a new terminal. Great work, I appreciate it. +1 for the option to reduce spacing. Not a fan of reading double spaced lines and prefer smaller font too. Much more data can be presented in the given space. Linux and Mac don't have such wide spacing and large fonts by default.

claunia commented 2026-01-30 23:59:10 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 5, 2020):

Linux and Mac don't have such wide spacing and large fonts by default.

btw: you can use CTRL+<Mouse Wheel> to change the font size.

@Spongman commented on GitHub (Feb 5, 2020): > Linux and Mac don't have such wide spacing and large fonts by default. btw: you can use `CTRL+<Mouse Wheel>` to change the font size.

claunia commented 2026-01-30 23:59:10 +00:00

Author

Owner

Copy Link

@ethanherbertson commented on GitHub (May 5, 2020):

Another side-effect of the default spacing is that, even in the intended Cascadia font box-drawing characters do not, er... tessellate the plane.

Edit: perhaps a better example:

Compare with the legacy conhost, in Courier New:

@ethanherbertson commented on GitHub (May 5, 2020): Another side-effect of the *default* spacing is that, even in the intended Cascadia font box-drawing characters do not, er... tessellate the plane. Edit: perhaps a better example:  Compare with the legacy conhost, in Courier New: 

claunia commented 2026-01-30 23:59:10 +00:00

Author

Owner

Copy Link

@DHowett-MSFT commented on GitHub (May 5, 2020):

(Just FYI: you're reporting #455.)

@DHowett-MSFT commented on GitHub (May 5, 2020): (Just FYI: you're reporting #455.)

claunia commented 2026-01-30 23:59:10 +00:00

Author

Owner

Copy Link

@Inversion-des commented on GitHub (Jul 14, 2020):

Why it is not the same as in the classic cmd??
I cannot switch to the new terminal because of this (
I really rely on a number of visible lines on a screen in a few main cases.

@Inversion-des commented on GitHub (Jul 14, 2020): Why it is not the same as in the classic cmd?? I cannot switch to the new terminal because of this ( I really rely on a number of visible lines on a screen in a few main cases.

claunia commented 2026-01-30 23:59:10 +00:00

Author

Owner

Copy Link

@markwu commented on GitHub (Sep 3, 2020):

I prefer taller, actually I want more taller. An option for line height (line spacing) is really good.

@markwu commented on GitHub (Sep 3, 2020): I prefer taller, actually I want more taller. An option for line height (line spacing) is really good.

claunia commented 2026-01-30 23:59:11 +00:00

Author

Owner

Copy Link

@jonhue commented on GitHub (Nov 9, 2020):

@zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :)

@jonhue commented on GitHub (Nov 9, 2020): @zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :)

claunia commented 2026-01-30 23:59:11 +00:00

Author

Owner

Copy Link

@mdtauk commented on GitHub (Nov 9, 2020):

@zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :)

Does Windows Terminal draw it's own Box Drawing characters, I know it was proposed #5897 #455

If so, many of these will need to be adjusted to retain seamless lines and borders. But Full Block heights, should probably stay aligned to the text lines.

@mdtauk commented on GitHub (Nov 9, 2020): > @zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :) Does Windows Terminal draw it's own Box Drawing characters, I know it was proposed #5897 #455 If so, many of these will need to be adjusted to retain seamless lines and borders. But Full Block heights, should probably stay aligned to the text lines.

claunia commented 2026-01-30 23:59:11 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Nov 9, 2020):

@jonhue absolutely, go ahead. @miniksa is the rendering guru - he might have some thoughts of things you should keep in mind, so I'll tag him in ☺️

@zadjii-msft commented on GitHub (Nov 9, 2020): @jonhue absolutely, go ahead. @miniksa is the rendering guru - he might have some thoughts of things you should keep in mind, so I'll tag him in ☺️

claunia commented 2026-01-30 23:59:12 +00:00

Author

Owner

Copy Link

@miniksa commented on GitHub (Nov 9, 2020):

@zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :)

@jonhue absolutely, go ahead. @miniksa is the rendering guru - he might have some thoughts of things you should keep in mind, so I'll tag him in ☺️

For all of this.... most of my notes on how/why line spacing is the way that it is lies in giant comments inside the DxEngine::_GetProposedFont method. Specific callouts include aligning the baseline to rest on a full pixel, ensuring that the cells continue to be a perfect integer pixel height, watching out for High DPI scaling, and looking around at anything referring to DWRITE_LINE_SPACING structures. I believe it's all set up in the base DxEngine class and the CustomTextLayout class pulls that information out and uses it for laying out the glyphs.

@zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :)

Does Windows Terminal draw it's own Box Drawing characters, I know it was proposed #5897 #455

If so, many of these will need to be adjusted to retain seamless lines and borders. But Full Block heights, should probably stay aligned to the text lines.

No, but it does scale the glyphs to fit perfectly inside a cell so there isn't gapping when the font is authored with a mismatch between the deprecated-windows-only line spacings and the line spacings the rest of the world uses (recent notes from Dustin in #7596). That's done in CustomTextLayout::s_CalculateBoxEffect. Might have to look in there too.

@miniksa commented on GitHub (Nov 9, 2020): > @zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :) > @jonhue absolutely, go ahead. @miniksa is the rendering guru - he might have some thoughts of things you should keep in mind, so I'll tag him in ☺️ For all of this.... most of my notes on how/why line spacing is the way that it is lies in giant comments inside the `DxEngine::_GetProposedFont` method. Specific callouts include aligning the baseline to rest on a full pixel, ensuring that the cells continue to be a perfect integer pixel height, watching out for High DPI scaling, and looking around at anything referring to `DWRITE_LINE_SPACING` structures. I believe it's all set up in the base `DxEngine` class and the `CustomTextLayout` class pulls that information out and uses it for laying out the glyphs. > > @zadjii-msft is an option to configure the "lineHeight" still something we'd be interested in including? If so, I'd be interested in having a go at implementing this :) > > Does Windows Terminal draw it's own Box Drawing characters, I know it was proposed #5897 #455 > > If so, many of these will need to be adjusted to retain seamless lines and borders. But Full Block heights, should probably stay aligned to the text lines. No, but it does scale the glyphs to fit perfectly inside a cell so there isn't gapping when the font is authored with a mismatch between the deprecated-windows-only line spacings and the line spacings the rest of the world uses (recent notes from Dustin in #7596). That's done in `CustomTextLayout::s_CalculateBoxEffect`. Might have to look in there too.

claunia commented 2026-01-30 23:59:12 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

+1 This is a huge problem with TUI applications, especially ones that leverage things like braille characters to render graphs.

Here's an example of Consolas 11pt in Windows Terminal vs Alacritty that shows the issue very well. I'm assuming this is do to line spacing...

Windows Terminal	Alacritty

@tarkah commented on GitHub (Feb 19, 2021): +1 This is a huge problem with TUI applications, especially ones that leverage things like braille characters to render graphs. Here's an example of Consolas 11pt in Windows Terminal vs Alacritty that shows the issue very well. I'm assuming this is do to line spacing... | Windows Terminal | Alacritty | | - | - | |  |  | |  |  |

claunia commented 2026-01-30 23:59:12 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Feb 19, 2021):

@tarkah woah, what is that application? That's the prettiest looking commandline stock tracker I've ever seen 👀 /cc @miniksa because this is like, both of his favorite things

@zadjii-msft commented on GitHub (Feb 19, 2021): @tarkah woah, what is that application? That's the prettiest looking commandline stock tracker I've ever seen 👀 /cc @miniksa because this is like, both of his favorite things

claunia commented 2026-01-30 23:59:12 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Feb 19, 2021):

(If this were due to the line spacing, I would expect the actual lines to be spaced differently. This just looks like an issue with the size of the braille characters.)

@DHowett commented on GitHub (Feb 19, 2021): (If this were due to the line spacing, I would expect the actual lines to be spaced differently. This just looks like an issue with the size of the braille characters.)

claunia commented 2026-01-30 23:59:13 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

@zadjii-msft Thanks! It's a TUI app I made in Rust https://github.com/tarkah/tickrs

@tarkah commented on GitHub (Feb 19, 2021): @zadjii-msft Thanks! It's a TUI app I made in Rust https://github.com/tarkah/tickrs

claunia commented 2026-01-30 23:59:13 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

@DHowett Good point, the windows terminal frame is 36 lines tall vs the alacritty is 38 lines tall, but it's hard to know if that's primarily due to the window decoration or any line spacing.

Windows Terminal	Alacritty

The spacing between the braille characters seems much tighter in Windows Terminal vs Alacritty, so maybe this is a different issue.

@tarkah commented on GitHub (Feb 19, 2021): @DHowett Good point, the windows terminal frame is 36 lines tall vs the alacritty is 38 lines tall, but it's hard to know if that's primarily due to the window decoration or any line spacing. | Windows Terminal | Alacritty | | - | - | |  |  | The spacing between the braille characters seems much tighter in Windows Terminal vs Alacritty, so maybe this is a different issue.

claunia commented 2026-01-30 23:59:14 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Feb 19, 2021):

Weird question- how does it look if you use Cascadia Mono? I wonder if Consolas doesn't actually have those characters and Terminal is squashing them to fit when they come from a fallback font while Alacritty is not? Are are guilty of squashing "big" characters, afterall...

@DHowett commented on GitHub (Feb 19, 2021): Weird question- how does it look if you use Cascadia Mono? I wonder if Consolas _doesn't actually have those characters_ and Terminal is squashing them to fit when they come from a fallback font while Alacritty is not? Are are guilty of squashing "big" characters, afterall...

claunia commented 2026-01-30 23:59:14 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

No real difference.

Consolas	Cascadia Mono PL

Interestingly, Cascadia Mono renders worse than Consolas in Alacritty...

Consolas	Cascadia Mono PL

@tarkah commented on GitHub (Feb 19, 2021): No real difference. | Consolas | Cascadia Mono PL | | - | - | |  |  | Interestingly, Cascadia Mono renders worse than Consolas in Alacritty... | Consolas | Cascadia Mono PL | | - | - | |  |  |

claunia commented 2026-01-30 23:59:14 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

Alacritty has a line spacing offset option:

  # Offset is the extra space around each character. `offset.y` can be thought of
  # as modifying the line spacing, and `offset.x` as modifying the letter spacing.
  offset:
    x: 0
    y: -1

I need to set it to -1 to get perfect rendering of the braille characters. I can make it look closer to windows terminal by increasing it, but then notice how it affects other characters like the borders. I'm thinking you're right about how they're getting "squished" in windows terminal.

-1 offset	5 offset

@tarkah commented on GitHub (Feb 19, 2021): Alacritty has a line spacing offset option: ``` # Offset is the extra space around each character. `offset.y` can be thought of # as modifying the line spacing, and `offset.x` as modifying the letter spacing. offset: x: 0 y: -1 ``` I need to set it to -1 to get perfect rendering of the braille characters. I can make it look closer to windows terminal by increasing it, but then notice how it affects other characters like the borders. I'm thinking you're right about how they're getting "squished" in windows terminal. | -1 offset | 5 offset | | - | - | |  |  |

claunia commented 2026-01-30 23:59:14 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 19, 2021):

the thing i don't quite understand is this: Command Prompt uses ttf fonts, and renders box-drawing characters just fine. why is it that Terminal has this issue where box-drawing characters are taller than normal and there's an extra vertical space in between lines?

@Spongman commented on GitHub (Feb 19, 2021): the thing i don't quite understand is this: Command Prompt uses ttf fonts, and renders box-drawing characters just fine. why is it that Terminal has this issue where box-drawing characters are taller than normal and there's an extra vertical space in between lines?

claunia commented 2026-01-30 23:59:15 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Feb 19, 2021):

@spongman the old Windows Console Host (thing that CMD/powershell run inside) uses legacy font measurements that have been deprecated for about 20 years. Unfortunately, typography has moved on since it was authored. Terminal uses the "correct" (this is debatable, but they are correct insofar as they are the values specified by the font designer!) design metrics.

@DHowett commented on GitHub (Feb 19, 2021): @spongman the old Windows Console Host (thing that CMD/powershell run inside) uses legacy font measurements that have been deprecated for about 20 years. Unfortunately, typography has moved on since it was authored. Terminal uses the "correct" (this is debatable, but they are correct insofar as they are the values specified by the font designer!) design metrics.

claunia commented 2026-01-30 23:59:15 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 19, 2021):

that's lovely to hear. so, can we get an option to use the old, broken, whatever font metrics? because the new ones suck.

@Spongman commented on GitHub (Feb 19, 2021): that's lovely to hear. so, can we get an option to use the old, broken, whatever font metrics? because the new ones suck.

claunia commented 2026-01-30 23:59:15 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Feb 19, 2021):

No. You're going to get configurable line spacing, like you asked for in https://github.com/microsoft/terminal/issues/3498#issue-520343001.

@DHowett commented on GitHub (Feb 19, 2021): No. You're going to get configurable line spacing, like you asked for in https://github.com/microsoft/terminal/issues/3498#issue-520343001.

claunia commented 2026-01-30 23:59:15 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 19, 2021):

so, what's the difference between what you say "correct" design metrics, fudged to fix box-drawing, and then fudged again to allow for configurable line-height, and whatever it was that conhost does?

@Spongman commented on GitHub (Feb 19, 2021): so, what's the difference between what you say "correct" design metrics, fudged to fix box-drawing, and then fudged again to allow for configurable line-height, and whatever it was that conhost does?

claunia commented 2026-01-30 23:59:16 +00:00

Author

Owner

Copy Link

@miniksa commented on GitHub (Feb 19, 2021):

The problem we're having here is biasing toward a perfect pixel cell grid, where each piece of the grid has an integer number of pixels in both the X and Y dimensions.

The primary reason for this is performance: if we can redraw only on an exact pixel boundary as characters change, then we can save ourselves from having to redraw the neighbors or the entire screen.

Does that come with compromises? Yes.

One of those compromises is that we calculate the perfect pixel width in the X dimension and then add line spacing in the Y dimension to round it out to a whole, non-fractional pixel.

One additional reason for some of the spacing has to do with something we were told by multiple typography experts inside and outside the company: the baseline of characters should sit perfectly on a pixel boundary for the crispest representation. Does someone disagree with this? Probably. Can you find another expert to disagree? Also probably. Do we try to rely on the knowledge of our peers and colleagues when we don't know what's up? Yes.

Is this different from what Conhost did? Yes. Why? Conhost used GDI. We use DirectX. Why don't we use GDI for Terminal? Because it's old and significantly less configurable and doesn't run on the GPU. Performance and configurability are key goals of ours. We also like using supported and forward-looking tech to build new code when possible. DirectWrite/DirectX fits that bucket.

So how did GDI get up into getting this to all work on perfect pixel box grids with the same font? To be honest, I'm not sure. Perhaps they decided to bias in a different direction like on character width. Perhaps because it's old code, it was simply a rounding or truncating-to-integers error that I haven't been able to replicate in the float-based DirectWrite world yet.

Will we do better in the future? Yes.

If we find a more suitable default or expert, will we change our rendering to accommodate? Yes.

When we have time and cycles, will we let people adjust the knobs on this too so they can choose the perfect rendering fidelity for themselves, even if it sacrifices some of the performance? Yes. Why is this taking so long? Because I'm probably the right person on the team to do it and my general productivity, mood, and physical/mental health are all still suffering significantly with the pandemic. Please be patient with us/me.

Because this is the internet, will someone try to prove me wrong and show me the correct union of correctness and performance for DirectWrite? I sure hope so, but it's a solid maybe.

In the mean time, @tarkah, your finance graph thing is super cool. I might keep it up in a tab to MSFT and VTI. :P I nerfed the line spacing quickly/temporarily to reduce the impact of our calculations on the drawing and it still didn't look right in my dev build. And I tried applying the box scaling effect to it and it still looked wrong. Not quite sure why, but I have other things on the agenda today so that's all I can do for now.

@miniksa commented on GitHub (Feb 19, 2021): The problem we're having here is biasing toward a perfect pixel cell grid, where each piece of the grid has an integer number of pixels in both the X and Y dimensions. The primary reason for this is performance: if we can redraw only on an exact pixel boundary as characters change, then we can save ourselves from having to redraw the neighbors or the entire screen. Does that come with compromises? Yes. One of those compromises is that we calculate the perfect pixel width in the X dimension and then add line spacing in the Y dimension to round it out to a whole, non-fractional pixel. One additional reason for some of the spacing has to do with something we were told by multiple typography experts inside and outside the company: the baseline of characters should sit perfectly on a pixel boundary for the crispest representation. Does someone disagree with this? Probably. Can you find another expert to disagree? Also probably. Do we try to rely on the knowledge of our peers and colleagues when we don't know what's up? Yes. Is this different from what Conhost did? Yes. Why? Conhost used GDI. We use DirectX. Why don't we use GDI for Terminal? Because it's old and significantly less configurable and doesn't run on the GPU. Performance and configurability are key goals of ours. We also like using supported and forward-looking tech to build new code when possible. DirectWrite/DirectX fits that bucket. So how did GDI get up into getting this to all work on perfect pixel box grids with the same font? To be honest, I'm not sure. Perhaps they decided to bias in a different direction like on character width. Perhaps because it's old code, it was simply a rounding or truncating-to-integers error that I haven't been able to replicate in the float-based DirectWrite world yet. Will we do better in the future? Yes. If we find a more suitable default or expert, will we change our rendering to accommodate? Yes. When we have time and cycles, will we let people adjust the knobs on this too so they can choose the perfect rendering fidelity for themselves, even if it sacrifices some of the performance? Yes. Why is this taking so long? Because I'm probably the right person on the team to do it and my general productivity, mood, and physical/mental health are all still suffering significantly with the pandemic. Please be patient with us/me. Because this is the internet, will someone try to prove me wrong and show me the correct union of correctness and performance for DirectWrite? I sure hope so, but it's a solid maybe. In the mean time, @tarkah, your finance graph thing is super cool. I might keep it up in a tab to MSFT and VTI. :P I nerfed the line spacing quickly/temporarily to reduce the impact of our calculations on the drawing and it still didn't look right in my dev build. And I tried applying the box scaling effect to it and it still looked wrong. Not quite sure why, but I have other things on the agenda today so that's all I can do for now.

claunia commented 2026-01-30 23:59:16 +00:00

Author

Owner

Copy Link

@tarkah commented on GitHub (Feb 19, 2021):

@miniksa That's exactly why I created it, to keep a tab on things in the far corner of the screen :)

Thanks for taking a quick look into it. Appreciate all you and the team have done to make this awesome terminal for Windows!

@tarkah commented on GitHub (Feb 19, 2021): @miniksa That's exactly why I created it, to keep a tab on things in the far corner of the screen :) Thanks for taking a quick look into it. Appreciate all you and the team have done to make this awesome terminal for Windows!

claunia commented 2026-01-30 23:59:16 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 23, 2021):

@miniksa thanks for the explanation, but i still have one question: are you saying that, since conhost uses GDI, its font rendering doesn't align on pixel boundaries? because that doesn't (err) align with what i'm seeing.

here's a screenshot of conhost (winver: 10.0.19042.746), rendering Lucida Console 'size' 12, the same settings as the screenshots in comment 1, above:

if you load that into paint.net and blow it up you'll see that each row is identical to the next. maybe the baseline doesn't align exactly with the pixel boundary, but whatever offset there is it's the same for each row, so it looks like it's using an whole-pixel line-height. and maybe it's an accident, but if GDI isn't aligning the baseline on a pixel boundary, it's still doing a pretty good job of making up for it, for example: all the pixels highlighted in red here are 0x000000 on every row:

maybe the DirectX font rendering code doesn't do as good a job as GDI when the baseline isn't precisely on a pixel boundary. that would be interesting to see.

or... maybe conhost is using pixel-aligned baselines and yet still able to render without the additional vertical whitespace. maybe someone with access to the conhost source code could answer that?

@Spongman commented on GitHub (Feb 23, 2021): @miniksa thanks for the explanation, but i still have one question: are you saying that, since conhost uses GDI, its font rendering doesn't align on pixel boundaries? because that doesn't (err) align with what i'm seeing. here's a screenshot of conhost (winver: 10.0.19042.746), rendering Lucida Console 'size' 12, the same settings as the screenshots in comment 1, above:  if you load that into paint.net and blow it up you'll see that each row is identical to the next. maybe the baseline doesn't align exactly with the pixel boundary, but whatever offset there is it's the same for each row, so it looks like it's using an whole-pixel line-height. and maybe it's an accident, but if GDI isn't aligning the baseline on a pixel boundary, it's still doing a pretty good job of making up for it, for example: all the pixels highlighted in red here are 0x000000 on every row:  maybe the DirectX font rendering code doesn't do as good a job as GDI when the baseline isn't precisely on a pixel boundary. that would be interesting to see. or... maybe conhost _is_ using pixel-aligned baselines and yet still able to render without the additional vertical whitespace. maybe someone with access to the conhost source code could answer that?

claunia commented 2026-01-30 23:59:16 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Feb 23, 2021):

someone with access to the conhost source code could answer that

I've got good news! That's this whole repository. Terminal and conhost share like 80% of their code, and the full living source for conhost is in here too. 😄

@DHowett commented on GitHub (Feb 23, 2021): > someone with access to the conhost source code could answer that I've got good news! That's this whole repository. Terminal and conhost share like 80% of their code, and the full living source for conhost is in here too. :smile:

claunia commented 2026-01-30 23:59:17 +00:00

Author

Owner

Copy Link

@miniksa commented on GitHub (Feb 24, 2021):

or... maybe conhost is using pixel-aligned baselines and yet still able to render without the additional vertical whitespace. maybe someone with access to the conhost source code could answer that?

No, you see, conhost doesn't have the choice. It just shunts it all over to GDI and GDI makes super opaque choices without asking us any further.

DirectWrite, on the other hand, gives us all of the choices in the world and also does all its math in floats the whole way up and down. Sometimes we're forced to make choices in DirectWrite that have no default where GDI would have just picked something for us. Those are the sorts of things that I think are giving us the variation.

@miniksa commented on GitHub (Feb 24, 2021): > or... maybe conhost _is_ using pixel-aligned baselines and yet still able to render without the additional vertical whitespace. maybe someone with access to the conhost source code could answer that? No, you see, conhost doesn't have the choice. It just shunts it all over to GDI and GDI makes super opaque choices without asking us any further. DirectWrite, on the other hand, gives us all of the choices in the world and also does all its math in floats the whole way up and down. Sometimes we're forced to make choices in DirectWrite that have no default where GDI would have just picked something for us. Those are the sorts of things that I think are giving us the variation.

claunia commented 2026-01-30 23:59:17 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Feb 24, 2021):

yeah, sorry, maybe my comment wasn't clear enough. my question is still: if GDI is constrained how come it can still render good-looking text AND, at the same, render text without the vertical space?

@Spongman commented on GitHub (Feb 24, 2021): yeah, sorry, maybe my comment wasn't clear enough. my question is still: if GDI is constrained how come it can still render good-looking text AND, at the same, render text without the vertical space?

claunia commented 2026-01-30 23:59:17 +00:00

Author

Owner

Copy Link

@miniksa commented on GitHub (Feb 24, 2021):

yeah, sorry, maybe my comment wasn't clear enough. my question is still: if GDI is constrained how come it can still render good-looking text AND, at the same, render text without the vertical space?

A mystery I do not understand yet. I hope to get time to spelunk the inside of GDI and DirectWrite's code, solve it in Terminal against DirectWrite, and reveal the answer to the world at some point.

@miniksa commented on GitHub (Feb 24, 2021): > yeah, sorry, maybe my comment wasn't clear enough. my question is still: if GDI is constrained how come it can still render good-looking text AND, at the same, render text without the vertical space? A mystery I do not understand yet. I hope to get time to spelunk the inside of GDI and DirectWrite's code, solve it in Terminal against DirectWrite, and reveal the answer to the world at some point.

claunia commented 2026-01-30 23:59:17 +00:00

Author

Owner

Copy Link

@rbeesley commented on GitHub (Mar 26, 2021):

@Spongman, I'd be curious how things look with antialiasing turned off. It also looks like you have ClearType enabled, rather than grayscale. It would also be worth knowing if you have any DPI scaling on that monitor. Last time I looked at it ClearType was being applied before any DPI scaling, and maybe true of grayscale too, meaning that these are all factors which might come into play.

Considering that the GDI font rendering pipeline was written along side any of the antialiasing and early DPI adjustments, and the DirectX pipeline was more about making games look good. Crisp text in a game may actually be less desirable than being sightly offset to make text look smoother and leveraging antialiasing... an artifact of the past which has carried over to other applications of the technology.

But this is just speculation on my part.

@rbeesley commented on GitHub (Mar 26, 2021): @Spongman, I'd be curious how things look with antialiasing turned off. It also looks like you have ClearType enabled, rather than grayscale. It would also be worth knowing if you have any DPI scaling on that monitor. Last time I looked at it ClearType was being applied _before_ any DPI scaling, and maybe true of grayscale too, meaning that these are all factors which might come into play. Considering that the GDI font rendering pipeline was written along side any of the antialiasing and early DPI adjustments, and the DirectX pipeline was more about making games look good. Crisp text in a game may actually be less desirable than being sightly offset to make text look smoother and leveraging antialiasing... an artifact of the past which has carried over to other applications of the technology. But this is just speculation on my part.

claunia commented 2026-01-30 23:59:18 +00:00

Author

Owner

Copy Link

@SidWorks commented on GitHub (Apr 21, 2021):

@miniksa Any update on line spacing part?

@SidWorks commented on GitHub (Apr 21, 2021): @miniksa Any update on line spacing part?

claunia commented 2026-01-30 23:59:18 +00:00

Author

Owner

Copy Link

@SidWorks commented on GitHub (Apr 21, 2021):

With use of padding I made it look like VSCODE Zen Mode

With an option of line-Spacing, it will be perfect.

@SidWorks commented on GitHub (Apr 21, 2021): With use of padding I made it look like VSCODE Zen Mode  With an option of line-Spacing, it will be perfect.

claunia commented 2026-01-30 23:59:18 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2021):

Any update on line spacing part?

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Apr 21, 2021): > Any update on line spacing part? Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?  That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

claunia commented 2026-01-30 23:59:18 +00:00

Author

Owner

Copy Link

@ffflick-gh commented on GitHub (Aug 31, 2021):

+1 to customizing line height.

The current line spacing for me is smaller compared to the original windows console, and it makes for some very awkward TUIs. It's quite inconvenient since many people use terminal-based editors for a lot of their work.

Original Windows Console:

Windows Terminal:

It's especially worse in fullscreen/focus mode.

@ffflick-gh commented on GitHub (Aug 31, 2021): +1 to customizing line height. The current line spacing for me is smaller compared to the original windows console, and it makes for some very awkward TUIs. It's quite inconvenient since many people use terminal-based editors for a lot of their work. Original Windows Console:  Windows Terminal:  It's especially worse in fullscreen/focus mode.

claunia commented 2026-01-30 23:59:19 +00:00

Author

Owner

Copy Link

@Spongman commented on GitHub (Dec 12, 2021):

You’d have thought that > 100 votes and 2 years would be enough… but no.

@Spongman commented on GitHub (Dec 12, 2021): You’d have thought that > 100 votes and 2 years would be enough… but no.

claunia commented 2026-01-30 23:59:19 +00:00

Author

Owner

Copy Link

@joakin commented on GitHub (Dec 12, 2021):

I’ve had to learn fontforge and how to adjust fonts to have higher fixed
dimensions to be able to use windows terminal 😂

@joakin commented on GitHub (Dec 12, 2021): I’ve had to learn fontforge and how to adjust fonts to have higher fixed dimensions to be able to use windows terminal 😂

claunia commented 2026-01-30 23:59:19 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Dec 13, 2021):

You’d have thought that > 100 votes and 2 years would be enough… but no.

Sorry about that, there are just a few (40) things higher on the priority list: https://github.com/microsoft/terminal/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc+

We'd absolutely welcome a PR though! There's this great font object we introduced to the settings a few releases ago, that's the prefect place for someone to stick a setting to configure this. The only bit that's tricky is actually changing the line spacing with DirectWrite. I dunno how to do that, but I'm sure it's probably trivial (maybe this?). I'm just not the DWrite expert 😅. Then it's just a matter of plumbing the setting through TerminalSettings -> TermControl/ControlCore -> DxEngine, and presto!

@zadjii-msft commented on GitHub (Dec 13, 2021): > You’d have thought that > 100 votes and 2 years would be enough… but no. Sorry about that, there are just a few (40) things higher on the priority list: https://github.com/microsoft/terminal/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc+ We'd absolutely welcome a PR though! There's this great `font` object we introduced to the settings a few releases ago, that's the prefect place for someone to stick a setting to configure this. The only bit that's tricky is actually changing the line spacing with DirectWrite. I dunno how to do that, but I'm sure it's probably trivial (maybe [this](https://docs.microsoft.com/en-us/windows/win32/api/dwrite_3/ns-dwrite_3-dwrite_line_spacing)?). I'm just not the DWrite expert 😅. Then it's just a matter of plumbing the setting through `TerminalSettings` -> `TermControl`/`ControlCore` -> `DxEngine`, and presto!

claunia commented 2026-01-30 23:59:20 +00:00

Author

Owner

Copy Link

@mdtauk commented on GitHub (Dec 13, 2021):

If line spacing becomes an option, it should probably be introduced hand in hand with allowing Terminal to draw the block drawing glyphs, to prevent "UI" elements from showing gaps when they are intended to be flush with full character heights and widths.

@mdtauk commented on GitHub (Dec 13, 2021): If line spacing becomes an option, it should probably be introduced hand in hand with allowing Terminal to draw the block drawing glyphs, to prevent "UI" elements from showing gaps when they are intended to be flush with full character heights and widths.

claunia commented 2026-01-30 23:59:20 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Dec 13, 2021):

it should probably be introduced hand in hand

I'm gonna play devil's advocate: I don't think the two are strongly linked. I'd rather have incremental progress rather than entirely block some goodness (line spacing) because we couldn't figure out a hard thing (block drawing). So I'd happily welcome PRs for both things, independently. If someone is motivated to try and fix this, they shouldn't feel worried about needing to also solve box drawing. (Of course, if they want to, they're welcome to!)

(for linking: #5897)

@zadjii-msft commented on GitHub (Dec 13, 2021): > it should probably be introduced hand in hand I'm gonna play devil's advocate: I don't think the two are strongly linked. I'd rather have incremental progress rather than entirely block some goodness (line spacing) because we couldn't figure out a hard thing (block drawing). So I'd happily welcome PRs for both things, independently. If someone is motivated to try and fix this, they shouldn't feel worried about needing to also solve box drawing. (Of course, if they want to, they're welcome to!) (for linking: #5897)

claunia commented 2026-01-30 23:59:20 +00:00

Author

Owner

Copy Link

@mdtauk commented on GitHub (Dec 13, 2021):

it should probably be introduced hand in hand

I'm gonna play devil's advocate: I don't think the two are strongly linked. I'd rather have incremental progress rather than entirely block some goodness (line spacing) because we couldn't figure out a hard thing (block drawing). So I'd happily welcome PRs for both things, independently. If someone is motivated to try and fix this, they shouldn't feel worried about needing to also solve box drawing. (Of course, if they want to, they're welcome to!)

(for linking: #5897)

I take your point, they are two distinct asks, but tackling the line spacing ask, will increase the amount of feedback received for the Block Drawing elements showing gaps.

So this is why I suggested the virtuous linking of the two. The Block Drawing ask, is more complicated in that there is an artistic expectation, as well as the technical side of it, having "glyph" drawing extending outside of the cell - and the potential problems in handling highlighting those Block Element cells, inverting the foreground and background.

But the Cell height is something that would fall under the Line Spacing too, as a decision would need to be made whether the height includes the line-height as a padding inside the cell, or margin between cell rows.

@mdtauk commented on GitHub (Dec 13, 2021): > > it should probably be introduced hand in hand > > I'm gonna play devil's advocate: I don't think the two are strongly linked. I'd rather have incremental progress rather than entirely block some goodness (line spacing) because we couldn't figure out a hard thing (block drawing). So I'd happily welcome PRs for both things, independently. If someone is motivated to try and fix this, they shouldn't feel worried about needing to also solve box drawing. (Of course, if they want to, they're welcome to!) > > (for linking: #5897) I take your point, they are two distinct asks, but tackling the line spacing ask, will increase the amount of feedback received for the Block Drawing elements showing gaps. So this is why I suggested the virtuous linking of the two. The Block Drawing ask, is more complicated in that there is an artistic expectation, as well as the technical side of it, having "glyph" drawing extending outside of the cell - and the potential problems in handling highlighting those Block Element cells, inverting the foreground and background. But the Cell height is something that would fall under the Line Spacing too, as a decision would need to be made whether the height includes the line-height as a padding inside the cell, or margin between cell rows.

claunia commented 2026-01-30 23:59:21 +00:00

Author

Owner

Copy Link

@Diablo-D3 commented on GitHub (Aug 11, 2022):

Throwing this in here, and I haven't seen anyone else make this argument: getting consistent cell width and height is hard to do across programs (different font engines, different interpretations of width and height, round up or to nearest, etc): just do what every other good terminal does, allow an signed offset to the calculation.

@Diablo-D3 commented on GitHub (Aug 11, 2022): Throwing this in here, and I haven't seen anyone else make this argument: getting consistent cell width and height is hard to do across programs (different font engines, different interpretations of width and height, round up or to nearest, etc): just do what every other good terminal does, allow an signed offset to the calculation.

claunia commented 2026-01-30 23:59:21 +00:00

Author

Owner

Copy Link

@rewrking commented on GitHub (Sep 17, 2022):

Bumping to say I was surprised as a user to not find this setting. it seems completely dependent on the font you're using right now.

@rewrking commented on GitHub (Sep 17, 2022): Bumping to say I was surprised as a user to not find this setting. it seems completely dependent on the font you're using right now.

claunia commented 2026-01-30 23:59:21 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Sep 17, 2022):

Well, good news! We're significantly moving up the timeframe for this feature thanks to the new text rendering engine :)

@DHowett commented on GitHub (Sep 17, 2022): Well, good news! We're significantly moving up the timeframe for this feature thanks to the new text rendering engine :)

claunia commented 2026-01-30 23:59:22 +00:00

Author

Owner

Copy Link

@lhecker commented on GitHub (Oct 11, 2022):

I've implemented a version of line height customization in https://github.com/microsoft/terminal/tree/dev/lhecker/3498-line-heights. I'm proposing the following:

1. Instead of just allowing line height adjustments I think we should also allow cell width adjustments.
2. The size adjustment can be specified as /^[+-]?\d+(?:\.\d+)?(?:%|px|pt)?$/, or in other words:
   • Sizes are mostly specified the same way line-height works in CSS. For instance:
     • 1.23 sets the size to 123% of the font size.
     • 123% works identical to 1.23
     • 1.23ch sets the size to 123% of the glyph advance (native width) of the "M" character.
     • 15pt sets the size to exactly 15pt. pt is in 72 DPI, so 15pt equals 20 physical pixels at 100% display scale (= 96 DPI).
     • 15px sets the size to exactly 15px. px is a "CSS pixel" and not physical pixels to avoid ambiguity. It's thus in 96 DPI, so 15px equals 30 physical pixels at 200% display scale.
3. The size adjustment can be specified per profile as:

   {
       "cellSize": {
            "height": "...",
            "width": "..."
       }
   }
   

I'm not particularly happy about the design of the 3rd point and I'd be happy to hear suggestion how to better specify it. I'm not intending to write a settings UI control for this in an initial PR and only add it in a follow-up PR.

@lhecker commented on GitHub (Oct 11, 2022): I've implemented a version of line height customization in https://github.com/microsoft/terminal/tree/dev/lhecker/3498-line-heights. I'm proposing the following: 1. Instead of just allowing line height adjustments I think we should also allow cell width adjustments. 2. The size adjustment can be specified as `/^[+-]?\d+(?:\.\d+)?(?:%|px|pt)?$/`, or in other words: * Sizes are mostly specified the same way `line-height` works in CSS. For instance: * `1.23` sets the size to 123% of the font size. * `123%` works identical to `1.23` * `1.23ch` sets the size to 123% of the glyph advance (native width) of the "M" character. * `15pt` sets the size to exactly 15pt. `pt` is in 72 DPI, so 15pt equals 20 physical pixels at 100% display scale (= 96 DPI). * `15px` sets the size to exactly 15px. `px` is a "CSS pixel" and not physical pixels to avoid ambiguity. It's thus in 96 DPI, so 15px equals 30 physical pixels at 200% display scale. 3. The size adjustment can be specified per profile as: ```json { "cellSize": { "height": "...", "width": "..." } } ``` I'm not particularly happy about the design of the 3rd point and I'd be happy to hear suggestion how to better specify it. I'm not intending to write a settings UI control for this in an initial PR and only add it in a follow-up PR.

claunia commented 2026-01-30 23:59:22 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Oct 11, 2022):

CSS pixel

Users who want to use a font like Terminus might want to specify a physical pixel size rather than a virtual one. Should we consider another suffix (and borrow from the Android resource language, or something else that offers px and dip?)

@DHowett commented on GitHub (Oct 11, 2022): > CSS pixel Users who want to use a font like Terminus might want to specify a physical pixel size rather than a virtual one. Should we consider another suffix (and borrow from the Android resource language, or something else that offers `px` and `dip`?)

claunia commented 2026-01-30 23:59:22 +00:00

Author

Owner

Copy Link

@lhecker commented on GitHub (Oct 11, 2022):

Users who want to use a font like Terminus might want to specify a physical pixel size rather than a virtual one. Should we consider another suffix (and borrow from the Android resource language, or something else that offers px and dip?)

I've thought about this and initially considered to add a physical pixel unit, but then realized: Bitmap fonts like that already require you to enter font sizes in exact pixels and not points, but we don't even allow anything but point sizes (just like most text editors). So basically if you want to use Terminus TTF you already need to know that 18px map to 13.5pt and once you know that you can write this given my proposal:

{
    "cellSize.y": "13.5pt",
    "font":
    {
        "face": "Terminus (TTF) for Windows",
        "size": 13.5
    }
}

@lhecker commented on GitHub (Oct 11, 2022): > Users who want to use a font like Terminus might want to specify a physical pixel size rather than a virtual one. Should we consider another suffix (and borrow from the Android resource language, or something else that offers px and dip?) I've thought about this and initially considered to add a physical pixel unit, but then realized: Bitmap fonts like that already require you to enter font sizes in exact pixels and not points, but we don't even allow anything but point sizes (just like most text editors). So basically if you want to use Terminus TTF you already need to know that 18px map to 13.5pt and once you know that you can write this given my proposal: ```json { "cellSize.y": "13.5pt", "font": { "face": "Terminus (TTF) for Windows", "size": 13.5 } } ```

claunia commented 2026-01-30 23:59:22 +00:00

Author

Owner

Copy Link

@Diablo-D3 commented on GitHub (Oct 12, 2022):

It would be nice being able to specify CSS px (== 100% 96 dpi) along with pt to disallow any ambiguity, not only in cell height/width but also font size in general.

@Diablo-D3 commented on GitHub (Oct 12, 2022): It would be nice being able to specify CSS `px` (== 100% 96 dpi) along with `pt` to disallow any ambiguity, not only in cell height/width but also font size in general.

claunia commented 2026-01-30 23:59:22 +00:00

Author

Owner

Copy Link

@joakin commented on GitHub (Oct 13, 2022):

I'm not particularly happy about the design of the 3rd point and I'd be happy to hear suggestion how to better specify it.

A couple of suggestions:

{
    "cellSize": {
        "x": "...",
        "y": "..."
    }
}

I personally think that width and height are more understandable as settings, so, one of these would be nice:

{
    "cellSize": {
        "width": "...",
        "height": "..."
    }
}

{
    "cellSizeWidth": "...",
    "cellSizeHeight": "...",
}

@joakin commented on GitHub (Oct 13, 2022): > I'm not particularly happy about the design of the 3rd point and I'd be happy to hear suggestion how to better specify it. A couple of suggestions: ``` { "cellSize": { "x": "...", "y": "..." } } ``` I personally think that *width* and *height* are more understandable as settings, so, one of these would be nice: ``` { "cellSize": { "width": "...", "height": "..." } } ``` ``` { "cellSizeWidth": "...", "cellSizeHeight": "...", } ```

claunia commented 2026-01-30 23:59:23 +00:00

Author

Owner

Copy Link

@cool-RR commented on GitHub (Mar 6, 2023):

New to this thread, and to this project. I just tried to use this feature. I ran the command "Open settings file (JSON)", and in the "defaults" item I've put this:

    "cellSize": {
         "height": "20",
         "width": "20"
    }

I launched Windows Terminal but saw no effect. Am I doing something wrong?

@cool-RR commented on GitHub (Mar 6, 2023): New to this thread, and to this project. I just tried to use this feature. I ran the command "Open settings file (JSON)", and in the `"defaults"` item I've put this: ``` "cellSize": { "height": "20", "width": "20" } ``` I launched Windows Terminal but saw no effect. Am I doing something wrong?

claunia commented 2026-01-30 23:59:23 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Mar 6, 2023):

@cool-RR What version did you try that on? This hasn't shipped in 1.16 or 1.17 - it's only checked in to main to be shipped in 1.18.

@zadjii-msft commented on GitHub (Mar 6, 2023): @cool-RR What version did you try that on? This hasn't shipped in 1.16 or 1.17 - it's only checked in to `main` to be shipped in 1.18.

claunia commented 2026-01-30 23:59:23 +00:00

Author

Owner

Copy Link

@cool-RR commented on GitHub (Mar 8, 2023):

Ah, I see. Indeed I tried it on 1.16.10261.0. I'm not good at building... Is there a way for me to run the latest main code without having to go through a technical building process, and without affecting the currently-installed version of Windows Terminal on my computer?

@cool-RR commented on GitHub (Mar 8, 2023): Ah, I see. Indeed I tried it on 1.16.10261.0. I'm not good at building... Is there a way for me to run the latest `main` code without having to go through a technical building process, and without affecting the currently-installed version of Windows Terminal on my computer?

claunia commented 2026-01-30 23:59:23 +00:00

Author

Owner

Copy Link

@Diablo-D3 commented on GitHub (Mar 11, 2023):

It seems a lot of people want this feature. Any chance of it arriving early in a 0.17-and-a-half release, or are there too many invasive changes to get it to land here?

@Diablo-D3 commented on GitHub (Mar 11, 2023): It seems a lot of people want this feature. Any chance of it arriving early in a 0.17-and-a-half release, or are there too many invasive changes to get it to land here?

claunia commented 2026-01-30 23:59:24 +00:00

Author

Owner

Copy Link

@o-glethorpe commented on GitHub (Mar 19, 2023):

"Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users."
Can't vertically shrink line...

@o-glethorpe commented on GitHub (Mar 19, 2023): "Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users." Can't vertically shrink line...

claunia commented 2026-01-30 23:59:24 +00:00

Author

Owner

Copy Link

@alcm-b commented on GitHub (Jul 18, 2023):

Windows terminal's line spacing is obviously too large when compared to what other command line tools have (user of Putty, XShell, mintty, Gnome terminal here). I'd like to have it either fixed (optimally) or made configurable (acceptable).

@alcm-b commented on GitHub (Jul 18, 2023): Windows terminal's line spacing is obviously too large when compared to what other command line tools have (user of Putty, XShell, mintty, Gnome terminal here). I'd like to have it either fixed (optimally) or made configurable (acceptable).

claunia commented 2026-01-30 23:59:24 +00:00

Author

Owner

Copy Link

@zadjii-msft commented on GitHub (Jul 18, 2023):

@alcm-b as discussed in literally the last 5 comments, this is already configurable as of version 1.18. Try something like:

"font":
{
    "face": "Consolas",
    "size": 12,
    "cellHeight": ".9"
}

@zadjii-msft commented on GitHub (Jul 18, 2023): @alcm-b as discussed in literally the last 5 comments, this is already configurable as of version 1.18. Try something like: ```jsonc "font": { "face": "Consolas", "size": 12, "cellHeight": ".9" } ```

claunia commented 2026-01-30 23:59:24 +00:00

Author

Owner

Copy Link

@alcm-b commented on GitHub (Jul 18, 2023):

@zadjii-msft thanks for pointing that out - it really is there in 1.18 👍

Moving the ticket away from backlog would help near-sighted people like me.

cellHeight = 1.1 looks great:

@alcm-b commented on GitHub (Jul 18, 2023): @zadjii-msft thanks for pointing that out - it really is there in 1.18 👍 Moving the ticket away from `backlog` would help near-sighted people like me. `cellHeight = 1.1` looks great: 

claunia commented 2026-01-30 23:59:25 +00:00

Author

Owner

Copy Link

@khushal123 commented on GitHub (Oct 9, 2023):

cellHeight does not work, tried multiple options. This should be a straight forward setting.

@khushal123 commented on GitHub (Oct 9, 2023): cellHeight does not work, tried multiple options. This should be a straight forward setting.

claunia commented 2026-01-30 23:59:25 +00:00

Author

Owner

Copy Link

@youk commented on GitHub (Oct 9, 2023):

Is "Line height" in Settings not straightforward enough for you?

@youk commented on GitHub (Oct 9, 2023): Is "Line height" in Settings not straightforward enough for you?

claunia commented 2026-01-30 23:59:25 +00:00

Author

Owner

Copy Link

@Gonkers commented on GitHub (Dec 6, 2023):

cellHeight does not work, tried multiple options. This should be a straight forward setting.

I just came upon this thread, and I found that cellHeight worked for my needs. It does take decimal values.

            "font": {
                "face": "Cascadia Mono",
                "size": 10,
                "weight": "normal",
                "cellHeight": "1.3"
            }

@Gonkers commented on GitHub (Dec 6, 2023): > cellHeight does not work, tried multiple options. This should be a straight forward setting. I just came upon this thread, and I found that `cellHeight` worked for my needs. It does take decimal values. ```json "font": { "face": "Cascadia Mono", "size": 10, "weight": "normal", "cellHeight": "1.3" } ```

claunia commented 2026-01-30 23:59:25 +00:00

Author

Owner

Copy Link

@liuyang12 commented on GitHub (Jun 14, 2024):

I confirm that cellWidth and cellHeight under font are exactly what I want and work perfect for me. Here is a example of Fira Code.

"font": 
{
    "cellWidth": "0.58",
    "cellHeight": "1.15",
    "face": "Fira Code Retina"
},

screenshot of Windows Terminal

@liuyang12 commented on GitHub (Jun 14, 2024): I confirm that `cellWidth` and `cellHeight` under `font` are exactly what I want and work perfect for me. Here is a example of Fira Code. ```json "font": { "cellWidth": "0.58", "cellHeight": "1.15", "face": "Fira Code Retina" }, ``` screenshot of Windows Terminal <img width="670" alt="image" src="https://github.com/microsoft/terminal/assets/8788563/492006c2-f781-422f-9c2a-3c8ba3d3cbb5">

claunia commented 2026-01-30 23:59:26 +00:00

Author

Owner

Copy Link

@knileshh commented on GitHub (Sep 22, 2025):

I want more margin, between the lines, how can I do that? I tried line height and cell Height didn't work.

@knileshh commented on GitHub (Sep 22, 2025): <img width="604" height="155" alt="Image" src="https://github.com/user-attachments/assets/a7d5aaa1-333f-46cc-8b87-5a6d8694a928" /> I want more margin, between the lines, how can I do that? I tried line height and cell Height didn't work.

claunia commented 2026-01-30 23:59:26 +00:00

Author

Owner

Copy Link

@DHowett commented on GitHub (Sep 22, 2025):

This is exactly what line/cell height are for.

Can you share your settings file? And please file a new bug if a feature is not working for you; do not resurrect one from six years ago.

@DHowett commented on GitHub (Sep 22, 2025): This is exactly what line/cell height are for. <img width="1847" height="958" alt="Image" src="https://github.com/user-attachments/assets/903135a8-1db9-40d9-bcce-5c27deb56196" /> Can you share your settings file? And please file a new bug if a feature is not working for you; do not resurrect one from six years ago.

claunia referenced this issue 2026-01-31 05:51:49 +00:00

Control key modifier chords interpreted incorrectly when using custom keyboard layout #17733

claunia referenced this issue 2026-01-31 05:51:50 +00:00

Control key modifier chords interpreted incorrectly when using custom keyboard layout #17733

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev/cazamor/bugfix/window-root-memory-leak

dev/lhecker/11509-kitty-keyboard-protocol-wip

automated/loc-update

feature/llm

dev/pabhoj/actions_editor_visual

dev/cazamor/selfhost/2026-01-29

dev/lhecker/11509-kitty-keyboard-protocol

dev/cazamor/sui/search

dev/duhowett/no-blank-issues-you-lost-privileges-for-that-fam

dev/lhecker/benchcat-fix

dev/lhecker/dcs-perf

dev/duhowett/eoy-25/allow-set-foreground

release-1.24

release-1.23

dev/cazamor/bot/deprecate-area-atlasengine

dev/pabhoj/actions_editor_followups

dev/cazamor/selfhost/2026-01-20

dev/cazamor/selfhost/2026-01-12

dev/cazamor/spec/auto-save

dev/duhowett/eoy-25/underline-colors-in-atlas-bug-redux

dev/duhowett/fhl-2024/asciicast-recorder

dev/duhowett/eoy-25/underline-colors-in-atlas-bug

dev/duhowett/hax/serial-port-support

dev/duhowett/connection-utf8

dev/lhecker/fused-event

dev/lhecker/18928-wip

dev/duhowett/fhl-2024/clang

dev/cazamor/uia-leak

dev/duhowett/win7-wpf-termcontrol-squash

release-1.22

dev/cazamor/selfhost/11-18-v3

dev/cazamor/selfhost/11-18

dev/duhowett/fhl-2025/bitmap-fonts

dev/duhowett/server-2025-vms

dev/duhowett/cant-believe-gotta-do-this-shit

dev/lhecker/1410-large-scrollback

dev/lhecker/dark-mode

dev/cazamor/sui/invert-cursor-color

dev/duhowett/fhl-2025/wt-command-palette-cmdpal-integration

dev/duhowett/fhl-2025/wt-json-relative-icons

dev/lhecker/fucking-service-locator

dev/duhowett/unicode-17

dev/duhowett/multi-blern

dev/lhecker/wellp2-alt

dev/duhowett/wellp2

dev/lhecker/1860-horizontal-scrollbar

dev/lhecker/fix-window-count

dev/cazamor/sui/tab-color-old

dev/duhowett/hax/conhost-icon

dev/duhowett/hax/sui-color-chip-border

dev/duhowett/hax/terminalsettings-as-a-lib-/with-types-merged-into-tsm

dev/pabhoj/page_control_input_cleanup

dev/duhowett/padding-in-atlas-rebase-20250729

dev/lhecker/attach-thread-input

dev/duhowett/portable-shader-members

msbuildcache-reenable

dev/cazamor/selfhost/1.24-2025-06-10

dev/cazamor/upgrade-settings-containers

dev/cazamor/sui/ext-page/powershell-stub

dev/cazamor/selfhost/1.24-2025-05-15

dev/pabhoj/sui_action_overhaul

dev/cazamor/selfhost/1.24-2025-05-06

dev/cazamor/selfhost/1.24-2025-04-29

dev/cazamor/sui/ext-page/lazy-load-objects

dev/cazamor/sui/ext-page/badge

dev/cazamor/selfhost/1.24

dev/lhecker/sdk-26100

dev/duhowett/testing

dev/jadelaga/VS-Pty.Net-1.22

dev/duhowett/fhl-2025/what-if-no-content-ids

dev/cazamor/a11y/vt-seq-prototype

dev/lhecker/18584-part2

dev/lhecker/get-lang-id

dev/duhowett/hax/clogs

release-1.21

dev/pabhoj/featurellm_fix_paste

dev/lhecker/grapheme-backup

dev/jadelaga/VS-Pty.netFixes

dev/lhecker/atlas-engine-compute-shader

dev/migrie/s/ai-providers

dev/lhecker/animated-cursor-wip

dev/pabhoj/featurellm_timeout

dev/lhecker/dark-mode-alt

dev/duhowett/osc-strided-table

dev/lhecker/bugbash

dev/pabhoj/featurellm_improve_parsing

dev/duhowett/coast-to-coast

dev/lhecker/curly-improvements

dev/duhowett/net8

dev/duhowett/onebranch-custom-pool

dev/lhecker/renderer-overhaul-2nd-attempt

dev/lhecker/cleanup

dev/cazamor/sui/confirmation-announcements

dev/lhecker/theme-quality

dev/duhowett/hax/cmake

dev/lhecker/winconpty-cleanup

dev/duhowett/learn/rewrite-highlights

dev/migrie/b/no-nesting-when-searching

release-1.20

dev/lhecker/14165-conhost-font-size

dev/duhowett/sel-2-spans

dev/lhecker/7118-cursor-color

dev/lhecker/remove-glyph-width

dev/lhecker/igfw-scroll-region

dev/lhecker/17656-win32im-double-encoding

dev/duhowett/fhl-2024/merge-idls

dev/duhowett/feed-forward-variables

dev/lhecker/remove-chrome-math

dev/duhowett/copylink

dev/duhowett/applicableactions

gh-readonly-queue/main/pr-17566-de50310295b7d92ed3d51f07974a2a945776bf9d

dev/lhecker/atlas-engine-stride-copy

dev/migrie/b/bump-nuget-in-c

dev/migrie/f/992-redux-redux

dev/migrie/f/filter-weight-input-too

dev/migrie/f/disable-nesting

dev/migrie/f/local-snippets-cleaner

dev/migrie/s/1553-mouse-bindings

selfhost-1.22-bugbash-2024-06-04

selfhost/1.22-bugbash-2024-06-04

dev/lhecker/15689-tab-drag-crash-fix

dev/migrie/f/sxnui-font-size-change

dev/migrie/f/local-snippets-on-action-refactor

dev/migrie/f/just-local-snippets

dev/migrie/save-input-patches

dev/migrie/f/md-pane-official

dev/migrie/base-pane

dev/migrie/fhl/tasks-pane

release-1.19

dev/migrie/b/17130-clear-marks-2

dev/migrie/b/17075-its-me-the-killer

dev/duhowett/i-figured-out-why-sometimes-the-publish-build-failed

dev/duhowett/nuget-publication-with-aad-app-id

selfhost-1.20

dev/duhowett/graph

dev/migrie/b/15803-activate-dont-copypasta

dev/duhowett/is-pgo-broken-because-of-sui-being-slower

dev/migrie/b/remove-terminaltab

dev/migrie/fhl/md-pane

dev/migrie/fhl/local-tasks-2024

dev/migrie/fhl/2024-inline-notebook

dev/duhowett/interface-projects

dev/duhowett/dead-loc

release-1.18

dev/migrie/fhl/2024-spring-merge-base

dev/duhowett/hax/l9

inbox

dev/migrie/14073-on-main

dev/duhowett/hax/conhost_dump_replay

user/lhecker/atlas-engine-srgb

dev/migrie/fhl/sxnui-tooltips-3

dev/migrie/7718-notifications-experiments

dev/migrie/fhl/7718-notifications

dev/migrie/fhl/7718-notifications-reboot

dev/lhecker/remove-gsl

dev/lhecker/16575-TerminateProcess

dev/lhecker/window-thread-climate-control

dev/lhecker/client-context-input-output-mode

dev/lhecker/ring-buffer-input-buffer

release-1.17

dev/lhecker/propsheet-fontdlg-refactor

dev/lhecker/renderer-overhaul

dev/pabhoj/test

dev/duhowett/chop

dev/lhecker/til-ulong-cleanup

dev/lhecker/til-env-cleanup

dev/migrie/f/16005-a11y-pane

dev/cazamor/a11y/fastpass

dev/migrie/b/15487-push-cwd

dev/migrie/b/15536-or-15219-idk

dev/duhowett/move-timers-down-into-core-interactivity-etc

dev/migrie/b/15812-broadcast-paste-two

dev/migrie/fhl-fall-2023/11162-quake-III-arena

dev/migrie/fhl-fall-2023/1620-automatic-tab-progress

dev/migrie/fhl-fall-2023/9992-quake-II

dev/migrie/fhl-fall-2023/9992-default-quake-settings

dev/migrie/fhl-fall-2023/9992-window-name-settings

dev/migrie/fhl-fall-2023/oceans

dev/lhecker/ColorScheme-improvements

dev/migrie/search-v2-v3

dev/migrie/pr-15717/its-dangerous-to-go-alone

dev/migrie/f/4768-taskbar-icons

dev/duhowett/padding-in-atlas

dev/migrie/f/3121-tooltips

dev/duhowett/sticky-control

dev/duhowett/fix-tracing-2

dev/migrie/b/add-support-for-vsc-marks

dev/migrie/f/1860-this-is-literally-what-less-is-for

dev/migrie/s/5916-draft

dev/lhecker/tracy

dev/migrie/s/north-star

dev/cazamor/tag-youre-it

dev/migrie/f/12336-let-it-mellow

dev/migrie/f/now-with-more-compat-settings

dev/migrie/f/compatibility-sui

dev/duhowett/hax/wpf-atlas

dev/duhowett/fgb

dev/migrie/b/15487-relative-paths-are-hard

dev/lhecker/colrv1

loc-update

dev/migrie/fhl/dyndep-csharp

dev/migrie/fhl/dyndep

dev/migrie/fhl-clickable-send-input

dev/migrie/f/cwd-hijinks-5506-15173

dev/lhecker/openconsole-async-start

1.17

dev/migrie/bump-scratch

dev/migrie/f/3726-restartConnection

dev/migrie/b/cxn-restarting-attempt-1-backport

dev/migrie/b/9053-part-3-the-actual-doing-of-the-thing

dev/migrie/b/13388-focus-logger

dev/migrie/b/9053-part-4-i-guess-defterm

dev/migrie/oop/3/of-the-silmarils

of-the-darkening-of-valinor

dev/migrie/fhl/notebook-proto-000

dev/migrie/f/narrator-buddy

dev/migrie/mux-2.8.2-march-2023

dev/migrie/f/roast-mutton

dev/migrie/f/12861-preview-input

dev/lhecker/clang-tidy

dev/migrie/f/3121-wE-dOnT-hAvE-dEv-DaYs

dev/duhowett/compiler-compliance

dev/duhowett/i-have-a-burning-hatred-for-ntstatus-of-later-so-why-not-fix-it

dev/duhowett/shorthand-namespaces

dev/duhowett/rename-all-dlls

dev/duhowett/errordialog

dev/lhecker/gsl-narrow

dev/migrie/b/11522-dumb-idea

release-1.16

dev/miniksa/env

dev/duhowett/hax/embed-everything

dev/migrie/b/13388-attempt-003

dev/migrie/b/14512-test-research

dev/migrie/b/13388-attempt-002

dev/migrie/b/14464-copyOnSelect-moving-text

dev/migrie/s/thema-schema-for-1.16

dev/migrie/s/theme-pair-schema

dev/migrie/b/13388-experiments-1

dev/cazamor/spec/a11y-vt-seq

dev/migrie/b/14557-empty-folder-dropdown

dev/cazamor/spec/a11y-vt-seq-v2

release-1.15

dev/migrie/f/process-model-v3-test-0

dev/lhecker/vsconfig

dev/migrie/s/5000-presentation

dev/lhecker/5907-startup-perf

dev/lhecker/winrt-file-api-benchmark

dev/duhowett/128-bit-compiler

dev/duhowett/hax/arm64-native-build

dev/migrie/fhl/more-shell-integration

dev/migrie/b/13388-experiments-0

dev/lhecker/til-to-ulong-improvements

dev/migrie/s/markdown-notebooks

dev/cazamor/a11y/nav-by-page

dev/cazamor/a11y/system-menu-support

dev/duhowett/no-private-registry-keys

dev/cazamor/wpf/uia-expose-enable-events

dev/cazamor/wpf/uia-events

extendAISpec

dev/migrie/fhl/clickSendInput

dev/migrie/fhl/save-command

dev/migrie/b/theme.profile

dev/migrie/b/13943-a-test-for-this

dev/migrie/oop/2/endgame

dev/duhowett/hax/merge_idl

dev/migrie/oop/2/infinity-war

dev/migrie/spellbot-cve

dev/cazamor/a11y-sev3/new-profile-announcement

dev/migrie/fhl/upside-down-mode

release-1.14

dev/migrie/f/9458-startupInfoToTerminal

dev/migrie/fhl/5916-triggers

dev/migrie/b/13523-context-menu

dev/migrie/b/6523-endpaint-outside-lock

dev/migrie/b/12413-OnUnhandledException

dev/lhecker/render-snapshot

dev/cazamor/1.15/scroll-to-point

dev/migrie/mux-2.8-aug-2022

dev/lhecker/lock-console-guard

dev/migrie/f/1504-final

dev/pabhoj/sui_follow_ups

dev/migrie/f/til-winrt.h

dev/cazamor/color-picker-redesign

dev/migrie/fhl/vscode-autocomplete-prototype

dev/migrie/f/1504-prototype

dev/migrie/oop/2/loki

dev/migrie/oop/2/wandavision

dev/migrie/b/8698-YOURE-OUT-OF-ORDER

fabricbot-configuration-migration

dev/migrie/b/12788-did-it-work

dev/migrie/b/localtests-ci-2022

dev/cazamor/1.14/replace-compareInBounds

dev/pabhoj/preview_string

dev/cazamor/ks/switchSelectionEndpoint

dev/migrie/oop/2/COM-ISwapChainProvider-attempt-1

dev/migrie/b/dxd-marker

release-1.13

dev/migrie/b/13066-for-defterm

dev/cazamor/revert-dwm

dev/migrie/b/13066-sw_flash_repeatedly

dev/migrie/b/no-cloaky-cloak

dev/migrie/f/apples-to-oranges

dev/migrie/f/no-custom-caption-btns

dev/migrie/f/10509-mica-and-transparent-titlebars

dev/migrie/b/12911-wpf-focus-fg

dev/migrie/titebar-colors

dev/lhecker/4015-cursor

dev/migrie/fhl/rgb-rainbow-window-frame

dev/migrie/fhl/scroll-marks-prototype

release-1.12

dev/miniksa/compliance

dev/migrie/f/default-icons

dev/migrie/fhl/10175-web-search-for-text

dev/migrie/fhl/menu-complete-prototype

dev/migrie/b/2988-merged-prototypes

dev/migrie/b/2988-niksa-msgs-prototype

dev/migrie/fhl/9583-colorSelection

dev/migrie/b/10609-sui-leak

dev/migrie/b/32-attempt-3

dev/migrie/release-1.12-rejuv-attempt-2

dev/migrie/demo-for-presentation

dev/migrie/b/32-but-im-here-for-12567

dev/duhowett/conpty_first_frame_blug

dev/migrie/b/11092-unfocused-acrylic-settings

dev/migrie/localtests-in-ci

dev/migrie/b/12356-attempt-2

dev/migrie/b/12353-with-null

dev/migrie/b/12387-trim-spaces

dev/migrie/b/5033-bad-start

dev/lhecker/12351-broken-locales

dev/migrie/b/8663-input-to-oem-crash

dev/migrie/b/11743-win10-opacity-is-hard

dev/migrie/f/ctrl-click-elevate

dev/migrie/b/12196-shim-localization

dev/lhecker/issue-4015-til-rect

dev/cazamor/eim/mvvm

dev/migrie/f/--elevate

dev/migrie/b/11668-i-think

dev/migrie/b/11994-wsl-mangline

dev/migrie/eim/3475-action-xmacros

dev/migrie/eim/incremental-build-000

dev/cazamor/a11y/fake-uia-data

dev/migrie/f/non-terminal-content-elevation-warning

dev/migrie/f/632-on-warning-dialog

dev/lhecker/rgba

dev/migrie/b/8480-keybindings-in-tabs

release-1.11

dev/migrie/b/11561-dead-ends

dev/migrie/oct-21-roadmap-update

dev/migrie/fhl/adaptive-card-extension

dev/cazamor/test/11440

dev/migrie/f/warning-dlg-automation

dev/migrie/b/1.12-crash-on-exit

dev/migrie/b/11146-next-tab-in-cmdpal

release-1.10

dev/migrie/5ff9a24-and-75e2b5f

dev/duhowtt/hax/cpal-jumplist-async

dev/lelian/actionid/1

dev/migrie/f/just-elevated-state

dev/lhecker/terminal-settings-cleanup

dev/migrie/gh-10824

dev/pabhoj/cursor_light

dev/migrie/oop/wandavision

dev/migrie/oop/endgame

dev/migrie/oop/infinity-war

dev/lhecker/app-state-actually-hidden

dev/migrie/b/6160-dynamic-default-warning

dev/mgirie/b/more-nchhittest-ideas

dev/migrie/b/9320-interfacial-separation

cinnamon/fhl/find-contextmenu

dev/lhecker/wsl-distro-generator-cleanup

dev/migrie/b/10875-but-more-clever

dev/migrie/b/broken-globalsummon-overloading

dev/duhowett/hax/rle-row

dev/migrie/fhl-2021/cmdpal-select-list

dev/migrie/fhl-2021/differential-pixel-shading

dev/duhowett/hax/no-writable-glyphat

dev/migrie/fhl-2021/more-shader-variables

dev/migrie/titlebar-shenannigans

dev/miniksa/win10_font_matching

dev/lhecker/conhost-oom

dev/migrie/b/10332-less-snappy-scrolling

dev/migrie/b/7422-1px-top-border

release-1.9

dev/cazamor/move-scratch

release-1.8

dev/miniksa/manifest_2

release-1.6

release-1.7

dev/migrie/oop/the-whole-thing

dev/migrie/oop/connection-factory

dev/migrie/f/quake-dropdown-2

dev/miniksa/rle2

dev/migrie/f/quake-toCurrent-experiments-2

dev/migrie/f/quake-toCurrent-experiments

dev/migrie/f/quake-dropdown

dev/cazamor/actions-page/template

dev/duhowett/hax/cursor_stamp_foreground_background

dev/migrie/f/1860-hey-might-was-well-hack-during-a-hackathon

dev/migrie/oop-terminal.control-split-control

dev/duhowett/hax/build-with-wholearchive

dev/cazamor/spec/tsm-actions-temp

dev/migrie/oop-tear-apart-control

dev/migrie/oop-scratch-3

dev/cazamor/sui/bugfix-reload-crash

dev/migrie/f/xmacro

dev/cazamor/sui/proto/profile-nav-view

dev/migrie/f/name-windows

dev/migrie/dol/messing-with-shaders-take-1

release-1.5

dev/cazamor/sui/inheritance-hyperlinks-test

dev/migrie/r/commandline-lib-002

dev/migrie/f/com.fabrikam.toaster

dev/cazamor/adaptive-cards-prototype

dev/migrie/f/commandline-lib

dev/miniksa/zipzoom2

dev/migrie/f/remote-commandlines

dev/migrie/f/632-elevated-profiles

dev/migrie/oop-broker-000

dev/migrie/fix-pr-7015

dev/duhowett/clang

dev/miniksa/input_tests_2

dev/miniksa/input2

dev/migrie/oop-rpc-000

release-1.4

dev/migrie/oop-mixed-elevation-1

dev/migrie/oop-window-content-1

cinnamon/open-json

dev/miniksa/input_tests

dev/duhowett/hax/tsm-graphviz

dev/miniksa/input

dev/duhowett/hax/caption_buttons

release-1.3

dev/cazamor/a11y/expand-line-under-viewport

dev/cazamor/acc/ch/word-nav-perf

dev/cazamor/spec/settings-ui-architecture-draft

dev/duhowett/hax/tap_upgrade

dev/migrie/f/pane-exit-animation

release-1.2

dev/migrie/move-lib-up-and-dll-down

release-1.1

dev/migrie/f/branch-2-backup

dev/migrie/f/settings-getters-only

dev/duhowett/hax/command_palette_search

dev/migrie/f/6856-let-terminalpage-expandcommands

dev/migrie/f/theming-2020

dev/migrie/oop-scratch-4

dev/duhowett/hax/punchout

dev/migrie/s/action-ids

dev/migrie/f/lets-just-generate-these

dev/migrie/oop-scratch-2

dev/miniksa/dcomp

dev/miniksa/gotta_go_fast_spsc

dev/miniksa/gotta_go_fast

dev/miniksa/perf_skip_checks

dev/miniksa/perf_buffer_dig

dev/migrie/s/1203-cursorTextColor

dev/migrie/f/fix-intellisense-i-guess-backup

release-1.0

dev/migrie/f/execute-commandlines

dev/migrie/f/2046-Command-Palette-v2

dev/migrie/b/6421-passthrough-alt

dev/migrie/b/moving-focus-is-hard

dev/miniksa/set

dev/migrie/f/1203-phase-1

dev/migrie/f/get-localtests-in-ci

dev/cazamor/drag-panes

dev/cazamor/tile-background

release-0.11

dev/duhowett/dev/duhowett/hax/appstate_remember

dev/duhowett/load_condrv

dev/duhowett/hax/wpf_win_8_hax

dev/migrie/b/3088-weird-exact-wrap-resize

release-0.10

dev/migrie/b/4591-custom-scaling-bug

dev/duhowett/hax/attr_smuggling

dev/migrie/b/5161-mingw-vim-fix

dev/miniksa/dx_bitmap

dev/migrie/b/1503-try-messing-with-cooked-read

dev/duhowett/eyebeam

dev/migrie/b/5113-experiments

dev/duhowett/hax-selection-exclusive

dev/migrie/f/more-vt-renderer-tracing

dev/miniksa/bitmap

dev/duhowett/wprp

dev/miniksa/bitmap-mad-with-power

dev/migrie/f/resize-quirk

dev/migrie/f/reflow-buffer-on-resize-002

wpf-renderer-revert

dev/miniksa/draw

release-0.9

dev/miniksa/tabs-color-fix

dev/miniksa/4309

dev/migrie/f/just-wrapping

dev/migrie/b/3490-try-another-resize-algo

release-0.8

dev/migrie/b/3490-a-simpler-resize

dev/migrie/b/3490-resize-down

dev/miniksa/4254

dev/migrie/f/conpty-wrapped-lines-2

dev/migrie/b/be-better-at-hiding

dev/migrie/f/3327-xaml-theming-proto

dev/miniksa/gardening2

release-0.7

dev/duhowett/conpty-flags

dev/migrie/f/603-vintage-opacity

dev/migrie/PR#3181-comments

dev/duhowett/font-64

release-0.5

dev/migrie/b/663-paste-lf-always

dev/migrie/b/2011-reordered-fallthrough-strings

dev/migrie/b/411-init-tab-stops

dev/migrie/b/json-patching-is-hard

dev/migrie/b/2455-try-getting-tests-working

dev/migrie/b/1223-change-256-table

dev/migrie/f/2171-openterm.cmd

dev/migrie/f/drag-panes

dev/migrie/f/2046-command-palette

release-0.3

dev/miniksa/manager

dev/migrie/f/non-terminal-panes

dev/migrie/f/passthrough-2019

dev/miniksa/shared_pch

dev/migrie/f/1897-less-duplicated-work

release-0.2

dev/cazamor/mcs/viewport-selection

dev/duhowett/version_hack

v1.24.10212.0

v1.23.20211.0

v1.24.3504.0

v1.23.13503.0

v1.24.2812.0

v1.23.12811.0

v1.24.2682.0

v1.23.12681.0

v1.24.2372.0

v1.23.12371.0

v1.23.12102.0

v1.22.12111.0

v1.23.11752.0

v1.22.11751.0

v1.22.11141.0

v1.23.11132.0

v1.23.10732.0

v1.22.10731.0

v1.21.10351.0

v1.22.10352.0

v1.23.10353.0

v1.22.3232.0

v1.21.3231.0

v1.22.2912.0

v1.21.2911.0

v1.22.2702.0

v1.21.2701.0

v1.22.2362.0

v1.21.2361.0

v1.21.1772.0

v1.20.11781.0

v1.21.1382.0

v1.20.11381.0

v1.21.1272.0

v1.20.11271.0

v1.20.11215.0

v1.19.11213.0

v1.20.10822.0

v1.19.10821.0

v1.20.10572.0

v1.19.10573.0

v1.20.10303.0

v1.19.10302.0

v1.18.10301.0

v1.20.10293.0

v1.19.10292.0

v1.18.10291.0

v1.18.3181.0

v1.19.3172.0

v1.19.2831.0

v1.18.2822.0

v1.19.2682.0

v1.18.2681.0

v1.18.1462.0

v1.17.11461.0

v1.18.1421.0

v1.17.11391.0

v1.17.11043.0

v1.16.10261.0

v1.17.1023

v1.16.10231.0

v1.15.3465.0

v1.16.3463.0

v1.15.2712.0

v1.15.2874.0

v1.16.2641.0

v1.16.2523.0

v1.15.2524.0

v1.15.2282.0

v1.14.2281.0

v1.14.1962.0

v1.15.2002.0

v1.15.2001.0

v1.15.1862.0

v1.14.1861.0

v1.14.1451.0

v1.14.1432.0

v1.13.11431.0

v1.13.10983.0

v1.12.10982.0

v1.13.10733.0

v1.12.10732.0

v1.13.10395.0

v1.12.10393.0

v1.13.10336.0

v1.12.10334.0

v1.12.3472.0

v1.11.3471.0

v1.12.2931.0

v1.12.2922.0

v1.11.2921.0

v1.11.2731.0

v1.10.2714.0

v1.11.2421.0

v1.10.2383.0

v1.10.1933.0

v1.9.1942.0

v1.9.1523.0

v1.8.1521.0

v1.9.1445.0

v1.8.1444.0

v1.8.1092.0

v1.7.1091.0

v1.8.1032.0

v1.7.1033.0

v1.7.572.0

v1.6.10571.0

v1.5.10411.0

v1.6.10412.0

v1.6.10272.0

v1.5.10271.0

v1.5.3242.0

v1.4.3243.0

v1.5.3142.0

v1.4.3141.0

v1.4.2652.0

v1.3.2651.0

v1.3.2382.0

v1.2.2381.0

v1.1.2233.0

v1.2.2234.0

v1.1.2021.0

v1.2.2022.0

v1.1.1812.0

v1.0.1811.0

v1.1.1671.0

v1.0.1401.0

v0.11.1333.0

v0.11.1251.0

v0.11.1191.0

v0.11.1111.0

v0.11.1121.0

v0.10.781.0

v0.10.761.0

v0.9.433.0

v0.8.10261.0

v0.8.10091.0

v0.7.3451.0

v0.7.3382.0

v0.7.3291.0

v0.7.3252.0

v0.6.3181.0

v0.6.2951.0

v0.6.2911.0

v0.5.2762.0

v0.5.2761.0

v0.5.2681.0

v0.5.2661.0

v0.3.2321.0

v0.4.2342.0

v0.4.2382.0

v0.3.2171.0

v0.3.2142.0

v0.2.1831.0

v0.2.1715.0

v0.2.1703.0

v0.1.1621.0

v0.1.1581.0

v0.1.1502.0

v0.1.1431.0

v0.1.1361.0

v0.1.1093.0

v0.1.1161.0

v0.1.1204.0

experiment-master

v0.1.1025.0

experiment-OutsideBuild

broken-tabstops

RS2-final

v0.1.1002.0

experiment-rel-windows-inbox

experiment-f-ServerApp

v0.1.1211.0

1904.29002

1810.02002

1708.14008

Labels

Clear labels

⛺ Reserved

A11yCO

A11yMAS

A11ySev1

A11ySev2

A11ySev3

A11yTTValidated

A11yUsable

A11yVoiceAccess

A11yWCAG

Area-Accessibility

Area-AtlasEngine

Area-AzureShell

Area-Build

Area-Build

Area-Chat

Area-CmdPal

Area-CodeHealth

Area-Commandline

Area-CookedRead

Area-DefApp

Area-Extensibility

Area-Fonts

Area-GroupPolicy

Area-i18n

Area-Input

Area-Interaction

Area-Interop

Area-Localization

Area-Output

Area-Performance

Area-Portable

Area-Quality

Area-Remoting

Area-Rendering

Area-Schema

Area-Server

Area-Settings

Area-SettingsUI

Area-ShellExtension

Area-ShellExtension

Area-ShellExtension

Area-Suggestions

Area-Suggestions

Area-TerminalConnection

Area-TerminalControl

Area-Theming

Area-UserInterface

Area-VT

Area-Windowing

Area-WPFControl

AutoMerge

Blocking-Ingestion

Culprit-Centennial

Culprit-WinUI

Disability-All

Disability-Blind

Disability-LowVision

Disability-Mobility

External-Blocked-WinUI3

Fixed

Gathering-Data

good first issue

HCL-E+D

HCL-WindowsTerminal

Help Wanted

Impact-Compatibility

Impact-Compliance

Impact-Correctness

Impact-Visual

In-PR

InclusionBacklog

InclusionBacklog-Windows TerminalWin32

InclusionCommitted-202206

Issue-Bug

Issue-Docs

Issue-Feature

Issue-Feature

Issue-Question

Issue-Samples

Issue-Scenario

Issue-Task

Needs-Attention

Needs-Author-Feedback

Needs-Bisect

Needs-Discussion

Needs-Repro

Needs-Tag-Fix

Needs-Tag-Fix

Needs-Triage

No-Recent-Activity

Priority-0

Priority-1

Priority-2

Priority-3

Product-Cmd.exe

Product-Colortool

Product-Colortool

Product-Colortool

Product-Conhost

Product-Conpty

Product-Meta

Product-Powershell

Product-Terminal

Product-WSL

pull-request

Mirrored from GitHub Pull Request

Resolution-Answered

Resolution-By-Design

Resolution-Duplicate

Resolution-External

Resolution-Fix-Available

Resolution-Fix-Committed

Resolution-No-Repro

Resolution-Won't-Fix

Severity-Blocking

Severity-Crash

Severity-DataLoss

spam

this-will-be-a-breaking-change

Tracking-External

WindowsTerminal_Win32

Work-Item

zAskModeBug

zInbox-Bug

No Label Area-Rendering Area-Settings Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Terminal

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

claunia

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/terminal#4885