starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 07:54:35 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

When Line Height is set to 1.4, there's an extra gap at the bottom #22935

New Issue
Closed
opened 2026-01-31 08:27:49 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:27:49 +00:00
Owner
Copy Link

Originally created by @ni554n on GitHub (Feb 16, 2025).

Windows Terminal version

1.21.10351.0

Windows build number

10.0.22631.0

Other Software

No response

Steps to reproduce

In Windows Terminal settings Defaults > Appearance page, set:

  1. Window Padding: 0
  2. Font face: JetBrains Mono
  3. Font size: 12
  4. Line height: 1.4
  5. Restart Terminal
  • My laptop display scaling is set to 125%

Expected Behavior

When Line height is set to 12, 13, or 15:

Image
Neovim

Actual Behavior

When Line height is set to 14:

Image
Neovim

Originally created by @ni554n on GitHub (Feb 16, 2025). ### Windows Terminal version 1.21.10351.0 ### Windows build number 10.0.22631.0 ### Other Software _No response_ ### Steps to reproduce In Windows Terminal settings `Defaults > Appearance` page, set: 1. Window Padding: 0 2. Font face: JetBrains Mono 3. Font size: 12 4. Line height: 1.4 5. Restart Terminal * My laptop display scaling is set to 125% ### Expected Behavior When Line height is set to 12, 13, or 15: ![Image](https://github.com/user-attachments/assets/227f4b3b-9a44-451b-9d2d-049ac348bed8) `Neovim` ### Actual Behavior When Line height is set to 14: ![Image](https://github.com/user-attachments/assets/c07036b5-1954-41c6-8c47-f6387a605732) `Neovim`
claunia added the Issue-BugNeeds-Tag-FixProduct-TerminalArea-Windowing labels 2026-01-31 08:27:50 +00:00
claunia commented 2026-01-31 08:27:51 +00:00
Author
Owner
Copy Link

@canh25xp commented on GitHub (Feb 17, 2025):

I think this is normal behaviour, since the terminal must display a round number of lines, so if your screen height is not divisible by your font size, it gonna result in the last line being truncated. You can try and calculate your self:

First calculate the font height in pixel

font height =  12 * 4/3 * 1.4 * 1.2

Then divide your screen height by the font height:

number of lines = (screen height)/(font height)

Then compare with the actual buffer size of your terminal (you should do this in a full screen), assuming you using powershell:

$Host.UI.RawUI.BufferSize

Note the buffer height, this is the actual number of lines that your terminal can display

Width Height
----- ------
  160     50
@canh25xp commented on GitHub (Feb 17, 2025): I think this is normal behaviour, since the terminal must display a round number of lines, so if your screen height is not divisible by your font size, it gonna result in the last line being truncated. You can try and calculate your self: First calculate the font height in pixel ``` font height = 12 * 4/3 * 1.4 * 1.2 ``` Then divide your screen height by the font height: ``` number of lines = (screen height)/(font height) ``` Then compare with the actual buffer size of your terminal (you should do this in a full screen), assuming you using powershell: ```pwsh $Host.UI.RawUI.BufferSize ``` Note the buffer height, this is the actual number of lines that your terminal can display ``` Width Height ----- ------ 160 50 ```
claunia commented 2026-01-31 08:27:51 +00:00
Author
Owner
Copy Link

@ni554n commented on GitHub (Feb 17, 2025):

Thanks for the detailed explanation. However, I'm confused about the terms used in the font height calculation.

font height =  12 * 4/3 * 1.4 * 1.2
font height =  font-size * display-aspect-ratio? * line-height * display-scaling-factor?

Additionally, my full-screen buffer size is:

Width Height
----- ------
  160     35

Through trial and error, I found that setting Startup > Launch Size Rows to 28 eliminates the gap. Any value above 28 (tested up to 38) results last line being truncated.

@ni554n commented on GitHub (Feb 17, 2025): Thanks for the detailed explanation. However, I'm confused about the terms used in the font height calculation. ``` font height = 12 * 4/3 * 1.4 * 1.2 font height = font-size * display-aspect-ratio? * line-height * display-scaling-factor? ``` Additionally, my full-screen buffer size is: ``` Width Height ----- ------ 160 35 ``` --- Through trial and error, I found that setting `Startup > Launch Size Rows` to 28 eliminates the gap. Any value above 28 (tested up to 38) results last line being truncated.
claunia commented 2026-01-31 08:27:51 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 1, 2025):

Just noticed this issue myself. It looks like custom cell sizes (the Line Height and Cell Width settings) are not taken into account when calculating the initial window size. It works for me with the following patch:

diff --git a/src/cascadia/TerminalControl/TermControl.cpp b/src/cascadia/TerminalControl/TermControl.cpp
index 60833fdd9..7118c7a86 100644
--- a/src/cascadia/TerminalControl/TermControl.cpp
+++ b/src/cascadia/TerminalControl/TermControl.cpp
@@ -2825,6 +2825,8 @@ namespace winrt::Microsoft::Terminal::Control::implementation
         const auto fontSize = settings.FontSize();
         const auto fontWeight = settings.FontWeight();
         const auto fontFace = settings.FontFace();
+        const auto cellWidth = CSSLengthPercentage::FromString(settings.CellWidth().c_str());
+        const auto cellHeight = CSSLengthPercentage::FromString(settings.CellHeight().c_str());
         const auto scrollState = settings.ScrollState();
         const auto padding = settings.Padding();
 
@@ -2836,6 +2838,7 @@ namespace winrt::Microsoft::Terminal::Control::implementation
         //      not, but DX doesn't use that info at all.
         //      The Codepage is additionally not actually used by the DX engine at all.
         FontInfoDesired desiredFont{ fontFace, 0, fontWeight.Weight, fontSize, CP_UTF8 };
+        desiredFont.SetCellSize(cellWidth, cellHeight);
         FontInfo actualFont{ fontFace, 0, fontWeight.Weight, desiredFont.GetEngineSize(), CP_UTF8, false };
 
         // Create a DX engine and initialize it with our font and DPI. We'll
@j4james commented on GitHub (May 1, 2025): Just noticed this issue myself. It looks like custom cell sizes (the _Line Height_ and _Cell Width_ settings) are not taken into account when calculating the initial window size. It works for me with the following patch: ```diff diff --git a/src/cascadia/TerminalControl/TermControl.cpp b/src/cascadia/TerminalControl/TermControl.cpp index 60833fdd9..7118c7a86 100644 --- a/src/cascadia/TerminalControl/TermControl.cpp +++ b/src/cascadia/TerminalControl/TermControl.cpp @@ -2825,6 +2825,8 @@ namespace winrt::Microsoft::Terminal::Control::implementation const auto fontSize = settings.FontSize(); const auto fontWeight = settings.FontWeight(); const auto fontFace = settings.FontFace(); + const auto cellWidth = CSSLengthPercentage::FromString(settings.CellWidth().c_str()); + const auto cellHeight = CSSLengthPercentage::FromString(settings.CellHeight().c_str()); const auto scrollState = settings.ScrollState(); const auto padding = settings.Padding(); @@ -2836,6 +2838,7 @@ namespace winrt::Microsoft::Terminal::Control::implementation // not, but DX doesn't use that info at all. // The Codepage is additionally not actually used by the DX engine at all. FontInfoDesired desiredFont{ fontFace, 0, fontWeight.Weight, fontSize, CP_UTF8 }; + desiredFont.SetCellSize(cellWidth, cellHeight); FontInfo actualFont{ fontFace, 0, fontWeight.Weight, desiredFont.GetEngineSize(), CP_UTF8, false }; // Create a DX engine and initialize it with our font and DPI. We'll ```
claunia commented 2026-01-31 08:27:52 +00:00
Author
Owner
Copy Link

@ni554n commented on GitHub (May 1, 2025):

@j4james Thank you so much for fixing this. But I'm seeing another padding issue that may be somewhat related to it.

The setup:

On Defaults > Appearance page:

  • Window Padding is set to 0
  • Scrollbar visibility is set to Visible.

When I run nvim via PowerShell, I see the padding reserved for the scrollbar area, which is understandable. But I wish it would take over the whole window.

Image

So, I set the default Scrollbar visibility to Hidden to eliminate the gap. I like the scrollbar on PowerShell, so I override it to "Visible" on its Appearance profile and restart the terminal. Now when I run nvim from PowerShell, it shows the scrollbar padding as expected.

Now here's the issue: If I run nvim.exe directly via double click, there's this tiny gap on the right. It is smaller than the scrollbar padding. The gap fixes itself if I resize the window a bit from the right edge.

Image

Do you think it's a bug? Should I create a new issue?

@ni554n commented on GitHub (May 1, 2025): @j4james Thank you so much for fixing this. But I'm seeing another padding issue that may be somewhat related to it. The setup: On **Defaults** > _Appearance_ page: - **Window Padding** is set to _0_ - **Scrollbar visibility** is set to _Visible_. When I run `nvim` via PowerShell, I see the padding reserved for the scrollbar area, which is understandable. But I wish it would take over the whole window. ![Image](https://github.com/user-attachments/assets/aa500b31-816b-4463-b574-944107b01b85) So, I set the default **Scrollbar visibility** to _Hidden_ to eliminate the gap. I like the scrollbar on PowerShell, so I override it to "Visible" on its Appearance profile and restart the terminal. Now when I run `nvim` from PowerShell, it shows the scrollbar padding as expected. Now here's the issue: If I run nvim.exe directly via double click, there's this tiny gap on the right. It is smaller than the scrollbar padding. The gap fixes itself if I resize the window a bit from the right edge. ![Image](https://github.com/user-attachments/assets/6bd2182c-610c-463f-b217-f39707e24d33) Do you think it's a bug? Should I create a new issue?
claunia commented 2026-01-31 08:27:52 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 2, 2025):

I assume what's happening here is you've set your default profile as PowerShell, so when opening a new instance of the terminal, the initial size is based on the PowerShell profile, i.e. with a visible scrollbar.

However, when launching an arbitrary executable, the tab that will be created for that app will use the profile default settings, which have the scrollbar hidden. And if the window is already created at that point, a tab without a scrollbar will not fill the available space.

Now it's arguable that if you're creating a brand new terminal with an arbitrary executable, the initial window size should have been based on the default settings, rather than the settings of the default profile. So that may well be a bug, although it might also be by design.

If it bothers you, I'd recommend opening an issue for this and see what the core devs have to say.

@j4james commented on GitHub (May 2, 2025): I assume what's happening here is you've set your default profile as PowerShell, so when opening a new instance of the terminal, the initial size is based on the PowerShell profile, i.e. with a _visible_ scrollbar. However, when launching an arbitrary executable, the tab that will be created for that app will use the profile default settings, which have the scrollbar _hidden_. And if the window is already created at that point, a tab without a scrollbar will not fill the available space. Now it's arguable that if you're creating a brand new terminal with an arbitrary executable, the initial window size should have been based on the default settings, rather than the settings of the default profile. So that may well be a bug, although it might also be by design. If it bothers you, I'd recommend opening an issue for this and see what the core devs have to say.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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-Windowing Issue-Bug Needs-Tag-Fix Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22935
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?