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

Line height does not apply to legacy computing symbols #22838

New Issue
Open
opened 2026-01-31 08:24:55 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:24:55 +00:00
Owner
Copy Link

Originally created by @sphamba on GitHub (Feb 3, 2025).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

1.21.3231.0

Windows build number

10.0.19045.0

Other Software

Steps to reproduce

Printing legacy computing symbols (using a font that supports them), such as ▔🮂🮃▀🮄🮅🮆█ █🮋🮊🮉▐🮈🮇▕ ▏🭰🭱🭲🭳🭳🭵▕ and increase the font line height (cellHeight setting in the JSON).

Expected Behavior

There should be no visible gaps between the characters, either vertically or horizontally, as it is for block elements:

1.1 line height
Image

1.5 line height
Image

Actual Behavior

Legacy computing symbols have noticeable vertical gaps when increasing the line height. There are also smaller horizontal gaps.

1.1 line height
Image

1.5 line height
Image

Originally created by @sphamba on GitHub (Feb 3, 2025). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version 1.21.3231.0 ### Windows build number 10.0.19045.0 ### Other Software - Ubuntu 22.04.5 LTS (WSL2) - [Cascadia Code 2407.24](https://github.com/microsoft/cascadia-code/releases/tag/v2407.24) Nerd Font ### Steps to reproduce Printing legacy computing symbols (using a font that supports them), such as `▔🮂🮃▀🮄🮅🮆█ █🮋🮊🮉▐🮈🮇▕ ▏🭰🭱🭲🭳🭳🭵▕` and increase the font line height (`cellHeight` setting in the JSON). ### Expected Behavior There should be no visible gaps between the characters, either vertically or horizontally, as it is for block elements: 1.1 line height ![Image](https://github.com/user-attachments/assets/536ab7e5-709c-443d-ae6d-049eb70e8947) 1.5 line height ![Image](https://github.com/user-attachments/assets/ff9a4e51-6aab-46b6-a54c-9f48db2fd979) ### Actual Behavior Legacy computing symbols have noticeable vertical gaps when increasing the line height. There are also smaller horizontal gaps. 1.1 line height ![Image](https://github.com/user-attachments/assets/40774338-b50b-4181-8d7c-6fd7daa143de) 1.5 line height ![Image](https://github.com/user-attachments/assets/4ad5a616-3ce1-4848-9e3f-0a2e5cccf92b)
claunia added the Area-RenderingIssue-TaskProduct-Terminal labels 2026-01-31 08:24:55 +00:00
claunia commented 2026-01-31 08:24:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 3, 2025):

Thanks for the report!

@lhecker is there a compelling reason for us not to cover the Legacy Computing supplement with the built-in box drawing render?

@DHowett commented on GitHub (Feb 3, 2025): Thanks for the report! @lhecker is there a compelling reason for us not to cover the Legacy Computing supplement with the built-in box drawing render?
claunia commented 2026-01-31 08:24:56 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 10, 2025):

Currently we don't intend for the line/cell height setting to affect the rendering of glyphs. It's strictly meant to modify the line height, like in a text editor.

It does apply to some "builtin" glyphs (the box drawing ones), because they're widely used, and they're supposed to be gapless, so we added support for that. The newer Legacy Computing Supplement is significantly less widely used and would be difficult to implement as builtin glyphs due to its complexity. It's not clear yet which of the new glyphs should be builtin and which ones don't need our support.

As such, I'd like to wait until more people want support for the Legacy Computing Supplement and/or until it's more widely used. Please let me know if you disagree with my take.

@lhecker commented on GitHub (Feb 10, 2025): Currently we don't intend for the line/cell height setting to affect the rendering of glyphs. It's strictly meant to modify the line height, like in a text editor. It does apply to some "builtin" glyphs (the box drawing ones), because they're widely used, and they're supposed to be gapless, so we added support for that. The newer Legacy Computing Supplement is significantly less widely used and would be difficult to implement as builtin glyphs due to its complexity. It's not clear yet which of the new glyphs should be builtin and which ones don't need our support. As such, I'd like to wait until more people want support for the Legacy Computing Supplement and/or until it's more widely used. Please let me know if you disagree with my take.
claunia commented 2026-01-31 08:24:56 +00:00
Author
Owner
Copy Link

@sphamba commented on GitHub (Feb 10, 2025):

I agree that Legacy Computing symbols are not widely used yet. Still, I was surprised to see that they were not displaying correctly on my side, even though the cascadia-code team seems to demonstrate the integration of the new symbols in their font using Windows Terminal, see cascadia-code#728 and blog post.

When you say that the line height applies to "builtin" glyphs, do you mean that these symbols, when drawn, do not rely on the current font's glyphs and are instead rendered using a different method?

In any case, I guess the sets of eights blocks, sextans, octans, and diagonals, would not be too complex to implement (rather, time-consuming). The same method as the one currently used for the symbols shown in the original post could be adopted (and I'd be happy to contribute if welcome). Other characters like the "large type pieces" are also supposed to be rendered gap-less, but if glyphs cannot be stretched, that would be more challenging...

Basically, I think there could be at least a partial support, potentially progressively expanding, starting with the sets that clearly represent blocks.
Looking forward to seeing your perspective on this!

@sphamba commented on GitHub (Feb 10, 2025): I agree that Legacy Computing symbols are not widely used yet. Still, I was surprised to see that they were not displaying correctly on my side, even though the cascadia-code team seems to demonstrate the integration of the new symbols in their font using Windows Terminal, see [cascadia-code#728](https://github.com/microsoft/cascadia-code/discussions/728) and [blog post](https://devblogs.microsoft.com/commandline/cascadia-code-2404-23/). When you say that the line height applies to "builtin" glyphs, do you mean that these symbols, when drawn, do not rely on the current font's glyphs and are instead rendered using a different method? In any case, I guess the sets of eights blocks, sextans, octans, and diagonals, would not be too complex to implement (rather, time-consuming). The same method as the one currently used for the symbols shown in the original post could be adopted (and I'd be happy to contribute if welcome). Other characters like the "large type pieces" are also supposed to be rendered gap-less, but if glyphs cannot be stretched, that would be more challenging... Basically, I think there could be at least a partial support, potentially progressively expanding, starting with the sets that clearly represent blocks. Looking forward to seeing your perspective on this!
claunia commented 2026-01-31 08:24:56 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 24, 2025):

When you say that the line height applies to "builtin" glyphs, do you mean that these symbols, when drawn, do not rely on the current font's glyphs and are instead rendered using a different method?

Yes exactly. They're drawn using Direct2D via programmatic primitives. This allows them to perfectly fill all gaps, as this helps them look visually consistent when used for e.g. backgrounds or other, visually larger, arrangements.

Other characters like the "large type pieces" are also supposed to be rendered gap-less, but if glyphs cannot be stretched, that would be more challenging...

In my opinion the change in line height is just like changing the line height in e.g. Word. It results in a line height that does not match what the font was designed for, and so it will look incorrect. While builtin glyphs don't have this issue, I consider builtin glyphs a workaround, because many fonts don't contain well-designed box drawing glyphs to begin with.

Basically, I think there could be at least a partial support, potentially progressively expanding, starting with the sets that clearly represent blocks.

That said, I don't really disagree with you. Builtin glyphs will fundamentally always look better than those declared in a font, precisely because we can scale them to a perfect fit. However, our text renderer is in a shared codebase with conhost (a system component) and I don't want to put any more into the text renderer than necessary, to avoid increasing its binary size.

All of the above combined, makes me hesitant to add these glyphs to our set of builtin ones at this time:

  • They're not widely used yet
  • Fonts may end up having these as well-designed glyphs, making builtin ones unneccessary
  • My concern about the binary size

If you'd like to try it anyway, you can try integrating a subset into our rendering code, while ideally not increasing its size too much: https://github.com/microsoft/terminal/blob/main/src/renderer/atlas/BuiltinGlyphs.cpp

If you need directions for how to compile and work with the code, please let me know!

@lhecker commented on GitHub (Feb 24, 2025): > When you say that the line height applies to "builtin" glyphs, do you mean that these symbols, when drawn, do not rely on the current font's glyphs and are instead rendered using a different method? Yes exactly. They're drawn using Direct2D via programmatic primitives. This allows them to perfectly fill all gaps, as this helps them look visually consistent when used for e.g. backgrounds or other, visually larger, arrangements. > Other characters like the "large type pieces" are also supposed to be rendered gap-less, but if glyphs cannot be stretched, that would be more challenging... In my opinion the change in line height is just like changing the line height in e.g. Word. It results in a line height that does not match what the font was designed for, and so it will look incorrect. While builtin glyphs don't have this issue, I consider builtin glyphs a workaround, because many fonts don't contain well-designed box drawing glyphs to begin with. > Basically, I think there could be at least a partial support, potentially progressively expanding, starting with the sets that clearly represent blocks. That said, I don't really disagree with you. Builtin glyphs will fundamentally always look better than those declared in a font, precisely because we can scale them to a perfect fit. However, our text renderer is in a shared codebase with conhost (a system component) and I don't want to put any more into the text renderer than necessary, to avoid increasing its binary size. All of the above combined, makes me hesitant to add these glyphs to our set of builtin ones at this time: * They're not widely used yet * Fonts may end up having these as well-designed glyphs, making builtin ones unneccessary * My concern about the binary size If you'd like to try it anyway, you can try integrating a subset into our rendering code, while ideally not increasing its size too much: https://github.com/microsoft/terminal/blob/main/src/renderer/atlas/BuiltinGlyphs.cpp If you need directions for how to compile and work with the code, please let me know!
claunia commented 2026-01-31 08:24:57 +00:00
Author
Owner
Copy Link

@Wukuyon commented on GitHub (Jun 23, 2025):

Before I found this issue, I intended to file an issue requesting that Windows Terminal support built-in rendering of the new PETSCII semigraphics characters, which are included in Symbols for Legacy Computing, Symbols for Legacy Computing Supplement, and Geometric Shapes.

PETSCII text art and animation have always been a part of the demoscene for Commodore and BBS computers. However, in recent years, text art that utilizes the new Unicode characters has become increasingly common as new Unicode characters are added.

For instance, Chafa is a popular new CLI tool that people use to generate PETSCII text today.

The PETSCII rendering issue is particularly significant in Windows Terminal because Cascadia Mono does not “properly” render certain characters crucial to PETSCII text art: the filled corner triangles U+25E2..U+25E5 in the Geometric Shapes block, which were unified with the block triangles from Symbols for Legacy Computing. See microsoft/cascadia-code#783.

Currently, a Windows Terminal user must switch to a font that supports full-height corner triangles, such as Unscii, GNU Unifont, or Kreative Korp Fairfax HD.

Current precedents for at least some built-in rendering of the new semigraphic block characters include:

  • GNOME Terminal
  • Kitty
  • WezTerm
  • Ghostty
  • Foot
  • Maybe more

Should there be a new issue dedicated to adding built-in rendering for the new Unicode semigraphic blocks? Or does this issue cover that?

@Wukuyon commented on GitHub (Jun 23, 2025): Before I found this issue, I intended to file an issue requesting that Windows Terminal support built-in rendering of the new PETSCII semigraphics characters, which are included in Symbols for Legacy Computing, Symbols for Legacy Computing Supplement, and Geometric Shapes. PETSCII text art and animation have always been a part of the demoscene for Commodore and BBS computers. However, in recent years, text art that utilizes the new Unicode characters has become increasingly common as new Unicode characters are added. For instance, [Chafa](https://hpjansson.org/blag/2021/09/16/chafa-1-8-terminal-graphics-with-a-side-of-everything/) is a popular new CLI tool that people use to generate PETSCII text today. The PETSCII rendering issue is particularly significant in Windows Terminal because Cascadia Mono does not “properly” render certain characters crucial to PETSCII text art: the filled corner triangles U+25E2..U+25E5 in the Geometric Shapes block, which were unified with the block triangles from Symbols for Legacy Computing. See microsoft/cascadia-code#783. Currently, a Windows Terminal user must switch to a font that supports full-height corner triangles, such as [Unscii](http://viznut.fi/unscii/), [GNU Unifont](https://en.wikipedia.org/wiki/GNU_Unifont), or [Kreative Korp Fairfax HD](https://www.kreativekorp.com/software/fonts/fairfaxhd/). Current precedents for at least some built-in rendering of the new semigraphic block characters include: * GNOME Terminal * Kitty * WezTerm * Ghostty * Foot * Maybe more Should there be a new issue dedicated to adding built-in rendering for the new Unicode semigraphic blocks? Or does this issue cover that?
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-Task 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#22838
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?