some weird behavior when dealing with full-width characters

[BlueRain-debug]

Windows Terminal version

1.15.3465.0

Windows build number

10.0.19044.2546

Other Software

No response

Steps to reproduce

1. Run wt.exe
2. Open a PowerShell Tab
3. Type something like "echo Ｒ２．０１／Ｒ２．０２→Ｒ２．０３"

Expected Behavior

Actual Behavior

On the right side of the arrow symbol, the cursor appears in the center of the text.

[lhecker]

This is sort of a known issue and I'm sure there have been previous reports like this in the past, like #9940 for instance. Although I'm not entirely sure with which existing issue this one should be deduplicated. It occurs because our text renderer draws text like you would draw proportional fonts. So if your monospace font isn't actually monospace (which may happen due to font fallback), the text might start to be "misaligned". The good news is that I'm working on a proper solution in form of an ongoing "AtlasEngine" rewrite.

[zadjii-msft]

I'm fine calling this /dup #9940. Thanks!

[ghost]

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!

[BlueRain-debug]

I'm fine calling this /dup #9940. Thanks!

This issue is marked as resolved in 1.18, but it seems that I can still reproduce it in the latest version of WT from the Store (1.18.2822.0).

Do I need to do any additional work?

Update: I also tried enabling the AtlasEngine option but it still has the problem.

[lhecker]

@BlueRain-debug That's exactly how this issue is supposed to be fixed.

First, some context: In terminals the UAX #11: East Asian Width standard determines how many columns a glyph occupies. Not the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says.

With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here:

With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢

[BlueRain-debug]

@BlueRain-debug That's exactly how this issue is supposed to be fixed.

First, some context: In terminals the UAX #11: East Asian Width standard determines how many columns a glyph occupies. Not the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says.

With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here:

With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢

Thanks for your reply, but I still have some doubts.

Did a quick check and it seems that all Windows built-in East Asian (CJK) fonts have the "wrong" character width (the font in the previous screenshots is MS Gothic).

According to EastAsianWidth-15.1.0.txt, Unicode Character "→" (U+2192) is marked as A which means Ambiguous Unicode characters. And the suggestion in the report you provided is: Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default.

So I'm a little confused now: Is this an issue that the Microsoft East Asia font team needs to investigate? Or should the rendering method be modified based on the actual font context?

By the way, command prompt programs that are opened directly are not affected by this problem.

[lhecker]

conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066

We want this to be configurable though, which is tracked here: #153
Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat.

There's also the feature request to allow for the configuration of font fallback which would also help here: #2664
That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: #2664 (comment)

[BlueRain-debug]

conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066

We want this to be configurable though, which is tracked here: #153 Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat.

There's also the feature request to allow for the configuration of font fallback which would also help here: #2664 That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: #2664 (comment)

I think I understand what's going on behind this. I'm sorry to take up your time.

[DHowett]

I'm sorry to take up your time.

It's okay, you don't need to apologize! It's very helpful sometimes when we get a chance to explain what is going on. 😄