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

Squots (2x3 block drawing characters) are not sized properly #15788

New Issue
Closed
opened 2026-01-31 04:48:24 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 04:48:24 +00:00
Owner
Copy Link

Originally created by @PhMajerus on GitHub (Nov 5, 2021).

Testing in Windows terminal 1.12.2931.0.

Unicode 14 includes symbols inherited from legacy computer systems (mostly 8-bit character sets), called Symbols for Legacy Computing (U+1FB00..U+1FBFF).
Squots are 2x3 block drawing characters that were originally on the TRS-80 and Teletext.
I know there is still no font in Windows that supports those, and even installing a font that does, such as UNSCII (http://viznut.fi/unscii/) does not make font-fallback work, but "unscii 16-full" can be used as the Windows Terminal font, and they are rendered.

The problem is, they are properly sized at 1 character cell when used by themselves, but as soon as there is a VT sequence to change their color, extra spaces get inserted between them.
This does not seem to be a problem with the UNSCII font, as when using Cascadia Mono, they are rendered as generic rectangles, but with the same extra spacing issue.

Reference rendering, using gnome-terminal from Ubuntu on WSL, displayed through WSLg:
image

The same files rendered in Windows Terminal using UNSCII (unscii 16-full) font:
image

And the same again, but rendered using Cascadia Mono, missing glyphs are expected, but notice the spacing still present:
image

Same but using CMD.exe instead of ActiveScript Shell, to show the problem isn't with ActiveScript Shell:
image

And here are my UTF-8 files to experiment:
Sonic (squots) (UTF-8).txt
Mario (squots) (UTF-8).txt

The Symbols for Legacy Computing are a new block of Unicode 14, but they might be important for Windows Terminal as their goal is precisely to bring into the modern character set all the legacy 8-bit text mode glyphs from historical computers. Having them properly supported might allow for example Commodore 64 (PETSCII) text screens to be displayed properly.
Also, this rendering issue might be related to a larger issue that could affect other characters blocks. Investigating it could improve Windows Terminal text rendering in other areas.

Originally created by @PhMajerus on GitHub (Nov 5, 2021). Testing in Windows terminal 1.12.2931.0. Unicode 14 includes symbols inherited from legacy computer systems (mostly 8-bit character sets), called Symbols for Legacy Computing (U+1FB00..U+1FBFF). Squots are 2x3 block drawing characters that were originally on the TRS-80 and Teletext. I know there is still no font in Windows that supports those, and even installing a font that does, such as UNSCII (http://viznut.fi/unscii/) does not make font-fallback work, but "unscii 16-full" can be used as the Windows Terminal font, and they are rendered. The problem is, they are properly sized at 1 character cell when used by themselves, but as soon as there is a VT sequence to change their color, extra spaces get inserted between them. This does not seem to be a problem with the UNSCII font, as when using Cascadia Mono, they are rendered as generic rectangles, but with the same extra spacing issue. Reference rendering, using gnome-terminal from Ubuntu on WSL, displayed through WSLg: ![image](https://user-images.githubusercontent.com/25664275/140626578-132d6b93-454d-4d01-a7a2-4853bbe7940b.png) The same files rendered in Windows Terminal using UNSCII (unscii 16-full) font: ![image](https://user-images.githubusercontent.com/25664275/140626554-bb2717a7-13e0-4eb5-a0bb-ed9f52905555.png) And the same again, but rendered using Cascadia Mono, missing glyphs are expected, but notice the spacing still present: ![image](https://user-images.githubusercontent.com/25664275/140626559-68ad16fc-867f-42ea-87e3-f594b31c63d7.png) Same but using CMD.exe instead of ActiveScript Shell, to show the problem isn't with ActiveScript Shell: ![image](https://user-images.githubusercontent.com/25664275/140626562-64d941ef-5b69-4a1c-b37a-67e7f9456459.png) And here are my UTF-8 files to experiment: [Sonic (squots) (UTF-8).txt](https://github.com/microsoft/terminal/files/7491231/Sonic.squots.UTF-8.txt) [Mario (squots) (UTF-8).txt](https://github.com/microsoft/terminal/files/7491386/Mario.squots.UTF-8.txt) The Symbols for Legacy Computing are a new block of Unicode 14, but they might be important for Windows Terminal as their goal is precisely to bring into the modern character set all the legacy 8-bit text mode glyphs from historical computers. Having them properly supported might allow for example Commodore 64 (PETSCII) text screens to be displayed properly. Also, this rendering issue might be related to a larger issue that could affect other characters blocks. Investigating it could improve Windows Terminal text rendering in other areas.
claunia commented 2026-01-31 04:48:26 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (Nov 5, 2021):

@PhMajerus on Windows 11, after installing from the Microsoft Store, WT throws an error when launching axsh:

Majerus.net ActiveScript Shell [Version 2.0.9.0]
Copyright (C) 2005-2017 Majerus.net. All rights reserved.
Using JScript Language.

Error: This version of ActiveScript Shell is too old. Please get an updated version from http://www.majerus.net.

[process exited with code 10 (0x0000000a)]

And http://www.majerus.net/axsh/ gives 404 (not found) error.

@elsaco commented on GitHub (Nov 5, 2021): @PhMajerus on Windows 11, after installing from the Microsoft Store, WT throws an error when launching `axsh`: ``` Majerus.net ActiveScript Shell [Version 2.0.9.0] Copyright (C) 2005-2017 Majerus.net. All rights reserved. Using JScript Language. Error: This version of ActiveScript Shell is too old. Please get an updated version from http://www.majerus.net. [process exited with code 10 (0x0000000a)] ``` And http://www.majerus.net/axsh/ gives `404` (not found) error.
claunia commented 2026-01-31 04:48:26 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Nov 5, 2021):

@elsaco Unfortunately, the Windows Store version doesn't work for now, it was built on the original Centennial container and was designed to refuse running if too old, but now it cannot be updated until I can turn it into an MSIX package.
The web site has been down for a while after a nearby construction destroyed most of our hardware, and I didn't have the time to rebuild that yet as I do that during my free time.

The best in the meantime is to grab the current build off my personal OneDrive public folder, it's updated whenever I have some new and stable feature: http://onedrive.phm.lu
I hope I can do a clean relaunch of my web site and Store apps, but probably not before late next year, sorry for the inconvenience 😟

@PhMajerus commented on GitHub (Nov 5, 2021): @elsaco Unfortunately, the Windows Store version doesn't work for now, it was built on the original Centennial container and was designed to refuse running if too old, but now it cannot be updated until I can turn it into an MSIX package. The web site has been down for a while after a nearby construction destroyed most of our hardware, and I didn't have the time to rebuild that yet as I do that during my free time. The best in the meantime is to grab the current build off my personal OneDrive public folder, it's updated whenever I have some new and stable feature: http://onedrive.phm.lu I hope I can do a clean relaunch of my web site and Store apps, but probably not before late next year, sorry for the inconvenience 😟
claunia commented 2026-01-31 04:48:26 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Nov 7, 2021):

Some simpler tests to repro the issue without the test files:

echo -e '()'
echo -e '\e[32m(\e[31m)\e[m'
echo -e '\U0001FB24\U0001FB17'
echo -e '\e[32m\U0001FB24\e[31m\U0001FB17\e[m'

gnome-terminal:
image

Windows Terminal 1.12.2931.0:
image

Windows Terminal with UNSCII font:
image

Note how the last line has an extra space even though the only difference with the previous line is some VT color commands.

@PhMajerus commented on GitHub (Nov 7, 2021): Some simpler tests to repro the issue without the test files: `echo -e '()'` `echo -e '\e[32m(\e[31m)\e[m'` `echo -e '\U0001FB24\U0001FB17'` `echo -e '\e[32m\U0001FB24\e[31m\U0001FB17\e[m'` gnome-terminal: ![image](https://user-images.githubusercontent.com/25664275/140656910-55e27935-ac3e-4d8b-b55e-a8ca78119b7d.png) Windows Terminal 1.12.2931.0: ![image](https://user-images.githubusercontent.com/25664275/140656950-e16a1365-674d-435b-be73-5a788519accb.png) Windows Terminal with UNSCII font: ![image](https://user-images.githubusercontent.com/25664275/140656979-0f74b559-2285-4ac7-955c-70b50aa1943f.png) Note how the last line has an extra space even though the only difference with the previous line is some VT color commands.
claunia commented 2026-01-31 04:48:27 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 8, 2021):

Weird. Thanks for the report! I don't believe I ever heard of that particular range of unicode before ☺️

@zadjii-msft commented on GitHub (Nov 8, 2021): Weird. Thanks for the report! I don't believe I ever heard of that particular range of unicode before ☺️
claunia commented 2026-01-31 04:48:27 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Nov 8, 2021):

Maybe a hint, Notepad renders a single character of that range as two unknown character rectangles:

image

I suspect this means lower-level APIs are getting confused and measure those as two characters (probably two unhandled UTF-16 surrogates in NT's internal string format, or assumed to be double-width).
Windows Terminal probably renders a cluster of characters with same attributes as a single draw call, so they are properly rendered next to each other, but then measures the width to align the next cluster when attributes change, and gets a wrong width.

echo -e '#\U0001FB24\U0001FB17#\x1B[32m#' show that the next cluster after an attributes change isn't properly aligned, even if it isn't between U+1FBxx characters, but just if the previous cluster contains any of those characters.
image

@PhMajerus commented on GitHub (Nov 8, 2021): Maybe a hint, Notepad renders a single character of that range as two unknown character rectangles: ![image](https://user-images.githubusercontent.com/25664275/140747910-d837f7fa-303e-43ff-8a26-871545dc9a4e.png) I suspect this means lower-level APIs are getting confused and measure those as two characters (probably two unhandled UTF-16 surrogates in NT's internal string format, or assumed to be double-width). Windows Terminal probably renders a cluster of characters with same attributes as a single draw call, so they are properly rendered next to each other, but then measures the width to align the next cluster when attributes change, and gets a wrong width. `echo -e '#\U0001FB24\U0001FB17#\x1B[32m#'` show that the next cluster after an attributes change isn't properly aligned, even if it isn't between U+1FBxx characters, but just if the previous cluster contains any of those characters. ![image](https://user-images.githubusercontent.com/25664275/140747782-88a51b2f-865d-4e3a-a8ac-1ab50e46cd78.png)
claunia commented 2026-01-31 04:48:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 8, 2021):

Windows Terminal probably renders a cluster of characters with same attributes as a single draw call,

You're totally right. WriteCharsLegacy (the as yet refactoring-defying function that powers all of the traditional windows console) measures surrogate pairs individually and then inserts them into the buffer individually. Each of them takes up "one column".

This has significant overlap with #8000 😄

@DHowett commented on GitHub (Nov 8, 2021): >Windows Terminal probably renders a cluster of characters with same attributes as a single draw call, You're totally right. `WriteCharsLegacy` (the as yet refactoring-defying function that powers all of the traditional windows console) measures surrogate pairs _individually_ and then inserts them into the buffer individually. Each of them takes up "one column". This has significant overlap with #8000 :smile:
claunia commented 2026-01-31 04:48:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 9, 2021):

Just FYI, there are a number of different character ranges effected by this. You can see a bunch of them in the notcurses-info app, which displays a kind of test pattern using a various block and line-drawing characters. This is what it currently looks like in the Windows console.

image

I've just been assuming all of these issues will be fixed by #8000 though.

@j4james commented on GitHub (Nov 9, 2021): Just FYI, there are a number of different character ranges effected by this. You can see a bunch of them in the `notcurses-info` app, which displays a kind of test pattern using a various block and line-drawing characters. This is what it currently looks like in the Windows console. ![image](https://user-images.githubusercontent.com/4181424/140936083-c21d9e90-530a-4fcb-a198-7f28df97fe6c.png) I've just been assuming all of these issues will be fixed by #8000 though.
claunia commented 2026-01-31 04:48:28 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Jan 24, 2023):

This is now fixed in Windows Terminal Preview 1.17.1023.
We still don't have support for the squots characters in Cascadia, but Terminal calculates characters sizes properly and renders them properly if the font supports them.

Here's the rendering in Terminal using UNSCII (unscii 16-full) font :
image

@PhMajerus commented on GitHub (Jan 24, 2023): This is now fixed in Windows Terminal Preview 1.17.1023. We still don't have support for the squots characters in Cascadia, but Terminal calculates characters sizes properly and renders them properly if the font supports them. Here's the rendering in Terminal using UNSCII (unscii 16-full) font : ![image](https://user-images.githubusercontent.com/25664275/214445666-d33107db-0ac2-4084-8d89-d359f8c656ff.png)
claunia commented 2026-01-31 04:48:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 25, 2023):

Oh wow! I think I completely forgot that this was a "surrogate pairs are stored in two columns" issue. Thanks for checking it again. Fixed in #13626 :)

@DHowett commented on GitHub (Jan 25, 2023): Oh wow! I think I completely forgot that this was a "surrogate pairs are stored in two columns" issue. Thanks for checking it again. Fixed in #13626 :)
claunia commented 2026-01-31 04:48:29 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 25, 2023):

Actually, I'm sorry, @j4james fixed this in #14640. With WriteCharsLegacy out of the way, we can measure strings properly. Missed the credit there. :)

@DHowett commented on GitHub (Jan 25, 2023): Actually, I'm sorry, @j4james fixed this in #14640. With WriteCharsLegacy out of the way, we can measure strings properly. Missed the credit there. :)
claunia commented 2026-01-31 04:48:29 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Jan 28, 2023):

Thanks @j4james for fixing it!
Now I really want those squots characters in Cascadia.

Here are some examples of better looking squots ansi-arts using the 256-color palette:
image

Sonic (8-bit).txt (original sprite by SЄGΔ, Sonic 2 on Game Gear)
Shion (Monster World III).txt (original sprite by SЄGΔ, Wonder Boy V in Monster World III on Mega Drive/Genesis)

@PhMajerus commented on GitHub (Jan 28, 2023): Thanks @j4james for fixing it! Now I really want those squots characters in Cascadia. Here are some examples of better looking squots ansi-arts using the 256-color palette: ![image](https://user-images.githubusercontent.com/25664275/215230016-5e023c3a-59da-4b79-8bf4-9f2a94218521.png) [Sonic (8-bit).txt](https://github.com/microsoft/terminal/files/10524011/Sonic.8-bit.txt) (original sprite by SЄGΔ, Sonic 2 on Game Gear) [Shion (Monster World III).txt](https://github.com/microsoft/terminal/files/10523124/Shion.Monster.World.III.txt) (original sprite by SЄGΔ, Wonder Boy V in Monster World III on Mega Drive/Genesis)
claunia commented 2026-01-31 04:48:29 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 28, 2023):

For the record, I think it was Leonard's #13626 PR that did most of the hard work necessary to fix this issue - I just stole the credit by hooking up his code to the VT PrintString routine. I'm thrilled my PR ended up fixing a bunch of stuff, but I have to admit it wasn't entirely intentional. 😊

@j4james commented on GitHub (Jan 28, 2023): For the record, I think it was Leonard's #13626 PR that did most of the hard work necessary to fix this issue - I just stole the credit by hooking up his code to the VT `PrintString` routine. I'm thrilled my PR ended up fixing a bunch of stuff, but I have to admit it wasn't entirely intentional. 😊
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 Help Wanted Issue-Bug Needs-Tag-Fix Priority-3 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#15788
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?