Unicode Characters are not sized consistently #16869

Closed
opened 2026-01-31 05:25:34 +00:00 by claunia · 2 comments
Owner

Originally created by @guilt on GitHub (Feb 25, 2022).

Windows Terminal version

1.11.3471.0

Windows build number

10.0.22000.493

Other Software

No response

Steps to reproduce

Have a file which has Unicode Characters.

e.g. இரவில் தூங்க இதமான பத்து கதைகள் _ Thenkachi ko swaminathan _ Indru oru thagaval _ பகுதி - 01.m4a

Expected Behavior

Expect something like:

image

Actual Behavior

It displays characters wrongly sized. I am perfectly okay if all were small or larger. Just not inconsistenty.

image

Originally created by @guilt on GitHub (Feb 25, 2022). ### Windows Terminal version 1.11.3471.0 ### Windows build number 10.0.22000.493 ### Other Software _No response_ ### Steps to reproduce Have a file which has Unicode Characters. e.g. இரவில் தூங்க இதமான பத்து கதைகள் _ Thenkachi ko swaminathan _ Indru oru thagaval _ பகுதி - 01.m4a ### Expected Behavior Expect something like: ![image](https://user-images.githubusercontent.com/195178/155660754-2789dd03-3274-4af4-b9a2-149d005a5c51.png) ### Actual Behavior It displays characters wrongly sized. I am perfectly okay if all were small or larger. Just not inconsistenty. ![image](https://user-images.githubusercontent.com/195178/155660681-39a5e940-02e9-470a-a5db-253ee592e3b0.png)
claunia added the Issue-BugResolution-Duplicate labels 2026-01-31 05:25:34 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Feb 25, 2022):

As we discussed in #9490

Yeah -- this is an unfortunate outcome of us summing up the number of cells covered by the codepoints comprising a character and then trying to render its glyph in those cells. #8000 will be a crack at making us support glyphs that take more than 2 cells. Measurement is left for a future workitem. That future workitem is #1472, which tracks getting us capable of properly measuring the space occupied by a stream of codepoints and rendering it.

I too wish that there were a separate mode for letting the Terminal figure out how wide things are without having to disagree on wcwidth/wcswidth, but I think that ship's sailed. ☹️

/dup #1472

@zadjii-msft commented on GitHub (Feb 25, 2022): As we discussed in #9490 > Yeah -- this is an unfortunate outcome of us summing up the number of cells covered by the codepoints comprising a character and then trying to render its glyph _in those cells_. #8000 will be a crack at making us _support glyphs that take more than 2 cells_. Measurement is left for a future workitem. That future workitem is #1472, which tracks getting us capable of properly measuring the space occupied by a stream of codepoints and rendering it. > > I too wish that there were a separate mode for letting the Terminal figure out how wide things are without having to disagree on wcwidth/wcswidth, but I think that ship's sailed. ☹️ > > /dup #1472
Author
Owner

@ghost commented on GitHub (Feb 25, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Feb 25, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16869