Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicode Characters are not sized consistently #12575

Closed
guilt opened this issue Feb 25, 2022 · 2 comments
Closed

Unicode Characters are not sized consistently #12575

guilt opened this issue Feb 25, 2022 · 2 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@guilt
Copy link

guilt commented 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

@guilt guilt added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Feb 25, 2022
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 25, 2022
@guilt guilt changed the title Unicode Characters are not sized correctly Unicode Characters are not sized consistently Feb 25, 2022
@zadjii-msft
Copy link
Member

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

@ghost
Copy link

ghost commented 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 ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants