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

Epic: Add configuration options for font rendering things (fallback, line height, ligatures, ...) #2505

New Issue
Open
opened 2026-01-30 22:56:56 +00:00 by claunia · 12 comments
claunia commented 2026-01-30 22:56:56 +00:00
Owner
Copy Link

Originally created by @be5invis on GitHub (Jul 3, 2019).

### Tasks
- [x] #759
- [ ] #2664
- [x] #1298
- [ ] #5093
- [ ] #3498
- [ ] #956
- [x] #1751
- [x] #5828
- [x] #6049
- [ ] #10231

consider (backlog)

  • #6678 should we support fractional point sizes?

original content

This is a summary from #714 #455

  • To properly handle box drawing characters we may need ability to explicitly set line height in pixels (to avoid rounding error). We may also need baseline position settings to avoid clipping.
  • For the arrow issue, we may need the ability to support specifying a fallback sequence of fonts rather than a master font, pretty like how CSS works.
    • We may also need some method to allow WT to change how it measure characters in a fallen font?
  • Option for antialiasing modes — at least for the case that the console's background isn’t transparent.
Originally created by @be5invis on GitHub (Jul 3, 2019). ```[tasklist] ### Tasks - [x] #759 - [ ] #2664 - [x] #1298 - [ ] #5093 - [ ] #3498 - [ ] #956 - [x] #1751 - [x] #5828 - [x] #6049 - [ ] #10231 ``` ### consider (backlog) - [x] #6678 should we support fractional point sizes? #### original content This is a summary from #714 #455 - To properly handle box drawing characters we may need ability to explicitly set line height **in pixels** (to avoid rounding error). We may also need baseline position settings to avoid clipping. - For the arrow issue, we may need the ability to support specifying a fallback sequence of fonts rather than a master font, pretty like how CSS works. - We may also need some method to allow WT to change how it measure characters in a fallen font? - Option for antialiasing modes — at least for the case that the console's background _isn’t_ transparent.
claunia added the Issue-FeatureArea-RenderingProduct-Terminal labels 2026-01-30 22:56:57 +00:00
claunia commented 2026-01-30 22:56:57 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

Should we should move these things into #759 and make that the master issue for font rendering options? @miniksa.

@DHowett-MSFT commented on GitHub (Jul 8, 2019): Should we should move these things into #759 and make that the master issue for font rendering options? @miniksa.
claunia commented 2026-01-30 22:56:57 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

Congrats, this is now the epic for font rendering settings.

@DHowett-MSFT commented on GitHub (Jul 8, 2019): Congrats, _this_ is now the epic for font rendering settings.
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

@be5invis commented on GitHub (Aug 2, 2019):

I think one more interesting thing is to redefine certain characters' "width", in both rendering and cell allocation. For example, if someone is working frequently with Japanese applications, they may want box-drawing characters to become full-width.

@be5invis commented on GitHub (Aug 2, 2019): I think one more interesting thing is to redefine certain characters' "width", in both rendering *and* cell allocation. For example, if someone is working frequently with Japanese applications, they may want box-drawing characters to become full-width.
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

@obskyr commented on GitHub (Sep 20, 2019):

Eagerly awaiting this in general, but perhaps especially for disabling ligatures and changing line heights.

Source Code Pro

Lucida Sans Console

@obskyr commented on GitHub (Sep 20, 2019): Eagerly awaiting this in general, but perhaps especially for disabling ligatures and changing line heights. ![Source Code Pro](https://user-images.githubusercontent.com/4363779/65361836-59bcbf80-dc05-11e9-8220-4c2cec67cfc1.png) ![Lucida Sans Console](https://user-images.githubusercontent.com/4363779/65361903-a7d1c300-dc05-11e9-9bc1-c432ffa0a4cd.png)
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

@musm commented on GitHub (Oct 26, 2019):

I agree this would be "epic"

@musm commented on GitHub (Oct 26, 2019): I agree this would be "epic"
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

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

Colour vs Monocoloured Emoji's would be a good option to include too

@mdtauk commented on GitHub (Nov 11, 2019): Colour vs Monocoloured Emoji's would be a good option to include too
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 20, 2020):

Could this be a good away to handle the Block Drawing characters? Enable Terminal to override the font characters, so even with increased line spacing, the various shapes and lines will still connect horizontally, vertically, and diagonally. #5897 #5743 #455

@mdtauk commented on GitHub (May 20, 2020): Could this be a good away to handle the Block Drawing characters? Enable Terminal to override the font characters, so even with increased line spacing, the various shapes and lines will still connect horizontally, vertically, and diagonally. #5897 #5743 #455
claunia commented 2026-01-30 22:56:58 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 20, 2020):

@mdtauk #5897 is a better place to discuss that.

@DHowett commented on GitHub (May 20, 2020): @mdtauk #5897 is a better place to discuss that.
claunia commented 2026-01-30 22:56:59 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 20, 2020):

@mdtauk #5897 is a better place to discuss that.

Sure to discuss the implementation, but I meant would the font section of the settings be the best place to handle allowing an override option?

@mdtauk commented on GitHub (May 20, 2020): > @mdtauk #5897 is a better place to discuss that. > Sure to discuss the implementation, but I meant would the font section of the settings be the best place to handle allowing an override option?
claunia commented 2026-01-30 22:56:59 +00:00
Author
Owner
Copy Link

@waf commented on GitHub (Nov 4, 2020):

I suspect the "font fallback" task may become more highly requested when oh-my-posh v3 is released (it's currently in beta). It defaults to using characters that aren't in Cascadia Code, so without font fallback many people will have to switch to one of:

  • Meslo, as recommended by the oh-my-posh project
  • Caskaydia Cove, the nerd-font patched version of Cascadia Code

Another alternative is adding the missing characters directly to Cascadia Code, which would sidestep the font fallback. @aaronbell was trying to get approval for that in https://github.com/microsoft/cascadia-code/issues/210#issuecomment-561490170

@waf commented on GitHub (Nov 4, 2020): I suspect the "font fallback" task may become more highly requested when [oh-my-posh v3](https://www.powershellgallery.com/packages/oh-my-posh/) is released (it's currently in beta). It defaults to using characters that aren't in Cascadia Code, so without font fallback many people will have to switch to one of: - Meslo, as recommended by the oh-my-posh project - Caskaydia Cove, the nerd-font patched version of Cascadia Code Another alternative is adding the missing characters directly to Cascadia Code, which would sidestep the font fallback. @aaronbell was trying to get approval for that in https://github.com/microsoft/cascadia-code/issues/210#issuecomment-561490170
claunia commented 2026-01-30 22:56:59 +00:00
Author
Owner
Copy Link

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

I'd really like to see the option of handling 1m and 2m attributes as bold/light font weights and/or brighten/diminish intensity. Looking across the landscape of terminal programs for different platforms, bold/intensify is implemented differently, sometimes as font weight, sometimes as intensify, using brblack instead of black for instance, and sometimes both.

With the implementation of 2m/dimming it applies across all terminal colors. Obviously if the terminal color is already floored, like black #000, then it can't go lower, but brblack doesn't render the same as black. With 1m/bold/intensify, it doesn't try to brighten 30m-37m, but instead the range just shifts up to 90m-97m and 90m-97m remain the same. In this case black becomes brblack. This means that while 1m and 2m are somewhat complimentary, they aren't in their current implementations.

Font weight would be a good solution which gives the attributes meaning across the entire range of terminal colors. Likewise an intensity attribute implemented in a similar way to diminish would also give value across the full range. I think maintaining a compatibility mode would be appropriate, but for modern terminals with a palette of more than 16 colors, these changes would benefit the user. If using a Solarized theme for instance, 1;31m wouldn't be expected to be orange, it should be a bold/intensified red. It almost certainly shouldn't shift into different hues as some of the base* colors might with the current implementation, green for instance.

Edit: Looking at the links zadjii-msft added below, I'm not sure I'm contributing further to the discussion. I had already left some comments in those threads and someone else called out the problem with Solarized. Leaving this comment here as it is still relevant, but I'll redirect my efforts to one of these other issues as appropriate.

@rbeesley commented on GitHub (Mar 26, 2021): I'd really like to see the option of handling 1m and 2m attributes as bold/light font weights and/or brighten/diminish intensity. Looking across the landscape of terminal programs for different platforms, bold/intensify is implemented differently, sometimes as font weight, sometimes as intensify, using brblack instead of black for instance, and sometimes both. With the implementation of 2m/dimming it applies across all terminal colors. Obviously if the terminal color is already floored, like black #000, then it can't go lower, but brblack doesn't render the same as black. With 1m/bold/intensify, it doesn't try to brighten 30m-37m, but instead the range just shifts up to 90m-97m and 90m-97m remain the same. In this case black becomes brblack. This means that while 1m and 2m are somewhat complimentary, they aren't in their current implementations. Font weight would be a good solution which gives the attributes meaning across the entire range of terminal colors. Likewise an intensity attribute implemented in a similar way to diminish would also give value across the full range. I think maintaining a compatibility mode would be appropriate, but for modern terminals with a palette of more than 16 colors, these changes would benefit the user. If using a Solarized theme for instance, 1;31m wouldn't be expected to be orange, it should be a bold/intensified red. It almost certainly shouldn't shift into different hues as some of the base* colors might with the current implementation, green for instance. Edit: Looking at the links zadjii-msft added below, I'm not sure I'm contributing further to the discussion. I had already left some comments in those threads and someone else called out the problem with Solarized. Leaving this comment here as it is still relevant, but I'll redirect my efforts to one of these other issues as appropriate.
claunia commented 2026-01-30 22:56:59 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 26, 2021):

@rbeesley FYI #109 has a much longer and specific discussion of 1m than this thread - it's dedicated to just the "bold text" discussion.

actually, after looking through #6879, the discussions are in:
#109, #5682, #6703 / #6873, https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423

@zadjii-msft commented on GitHub (Mar 26, 2021): @rbeesley FYI #109 has a much longer and specific discussion of `1m` than this thread - it's dedicated to just the "bold text" discussion. actually, after looking through #6879, the discussions are in: #109, #5682, #6703 / #6873, https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423
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-Rendering Issue-Feature 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#2505
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?