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

East Asian Ambiguous Width are broken #14702

Closed
mattn opened this issue Jan 19, 2023 · 3 comments
Closed

East Asian Ambiguous Width are broken #14702

mattn opened this issue Jan 19, 2023 · 3 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

@mattn
Copy link

mattn commented Jan 19, 2023

Windows Terminal version

1.15.3466.0

Windows build number

Microsoft Windows [Version 10.0.22000.1455]

Other Software

No

Steps to reproduce

type and some ASCII characters.

Expected Behavior

should be rendered with 2 cells.

Actual Behavior

is always rendered with 1 cell. And following ASCII characters are rendered with wrong position.

screenshot

@mattn mattn added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jan 19, 2023
@lhecker
Copy link
Member

lhecker commented Jan 19, 2023

We're intentionally treating all ambiguous width glyphs as narrow. The reason for this is explained in detail in #2066, but boils down to: TUI applications don't know what font the terminal uses, so it's unknown whether any such glyphs are 1 or 2 cells wide. To allow the TUI application to place glyphs accurately on the screen other terminal emulators have opted to treat all ambiguous width glyphs as narrow and we've followed suit.

#153 contains a request to allow a user to override this default choice we make. Adding a simple override to treat all such glyphs as wide instead of narrow is rather easy to implement, which is why I've added it to the near(er) term backlog just now. But adding an override that polls the user's font instead is unfortunately a bit difficult to implement right now due to our architecture, because both WindowsTerminal.exe as well as OpenConsole.exe (a subprocess that (in basic terms) implements the TTY) need to know about the user's font choice in order for both the terminal and "TTY" (OpenConsole) to agree on the position of all glyphs on the screen.

I'd close this issue as a dup of #153. Would you agree with that?

@zadjii-msft
Copy link
Member

Yea I'll call it /dup #153. Thanks!

@ghost
Copy link

ghost commented Jan 19, 2023

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 closed this as completed Jan 19, 2023
@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 labels Jan 19, 2023
This issue was closed.
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

3 participants