get_character_cell_size returns 1 for EAW='A' chars; CJK terminals render them as 2

[eating-saint]

Bug

rich/cells.py:get_character_cell_size() returns width=1 for Unicode East Asian Width = A (Ambiguous) characters that fall through the binary search. On CJK terminals, these characters actually render as 2 cells wide.

Affected characters

• U+2026 (HORIZONTAL ELLIPSIS)
• U+201C (LEFT DOUBLE QUOTATION MARK)
• U+201D (RIGHT DOUBLE QUOTATION MARK)
• Many others in the General Punctuation block (U+2000-U+206F)

How to reproduce

from rich.cells import get_character_cell_size
import unicodedata

for ch in [chr(0x2026), chr(0x201C), chr(0x201D)]:
    print(f"U+{ord(ch):04X} EAW={unicodedata.east_asian_width(ch)} cells={get_character_cell_size(ch)}")
# All print cells=1, but on CJK terminals they occupy 2 columns

Impact

Any Rich widget or downstream consumer (Textual TextArea) doing cell-width layout gets wrong widths. In TextArea WrappedDocument, this causes widget height inflation — each keystroke of an affected character adds spurious line-break calculations and blue separator lines.

Fix

In the two return 1 fallthrough paths in get_character_cell_size(), add an East Asian Ambiguous check:

import unicodedata

if unicodedata.east_asian_width(character) == "A":
    return 2
return 1

The function is @lru_cache(maxsize=4096), so the unicodedata call (~170 ns) is amortized.

Note

wcwidth treats EAW=A as width=1 per the Unicode standard default, but real CJK terminals render them as width=2. A terminal-aware or opt-in approach may be needed for full correctness, but the immediate fix solves the layout corruption for CJK users.

[eating-saint]

Additional environment detail: reproduced on Windows 10 Pro 10.0.19041, Chinese (Simplified) locale, Windows Terminal. The affected Chinese punctuation … “ ” each render as 2 columns wide in this environment, causing visible layout corruption in Textual TextArea (blue separator lines, widget height inflation).

[dish-j]

Hi
I tested this on Windows (English locale, Windows PowerShell/Windows Terminal). I confirmed that get_character_cell_size() returns 1 for EAW="A" characters, but I couldn't reproduce the visual layout issue because these characters render as width 1 in my environment.

I'd be happy to work on a fix. Before opening a PR, would you prefer the unconditional east_asian_width(character) == "A" change suggested above, or would you rather have a terminal-aware/configurable approach?

[dish-j]

I tried the unconditional east_asian_width(character) == "A" fallback suggested in the issue.

It makes the new test_cells cases pass, but it also causes 13 existing tests to fail (including test_rule, test_markdown, test_table, and test_card). Those failures appear to come from layout calculations now treating characters such as … as width 2 instead of width 1.

This suggests the unconditional change would alter Rich's existing rendering behavior for non-CJK environments.

Would you prefer an opt-in or terminal-aware approach instead? I'm happy to work on that if it's the intended direction.

[eating-saint]

Apologies for the delayed reply — I've been dealing with some personal matters and wasn't able to follow up here sooner. I want to say, genuinely, that I'm impressed by how quickly you guys responded and by how thorough your test coverage turned out to be. It's a great reminder of how effective open-source collaboration can be. Looking back, my earlier fix — the "just return 2 whenever we hit A" approach — was clearly too blunt. I hadn't properly considered compatibility outside CJK environments, and it took your full test suite to reveal that it broke 13 test cases. Lesson learned. On that note, I'd like to ask if you might have time to take a look at another issue I filed — this one is more clear-cut and, I'd argue, more severe. On Win32, in a Chinese IME environment, Shift + symbol keys (e.g., Shift+; for a colon, Shift+/ for a question mark) simply don't register at all — the characters never reach the application layer. I traced the root cause to the VK=0 filter in textual.drivers.win32.py: IME composition events carry a valid Unicode character but report a VirtualKeyCode of 0, and are unconditionally skipped via a `continue` statement in that filter. This should already be in your issue tracker — the title likely references Shift, IME, or win32. If you have a chance to take a look, I'd really appreciate it. Thanks again for all the work you've put into this. Dishita Jain ***@***.***> 于2026年7月25日周六 01:12写道：

…

*dish-j* left a comment (Textualize/rich#4197) <#4197 (comment)> I tried the unconditional east_asian_width(character) == "A" fallback suggested in the issue. It makes the new test_cells cases pass, but it also causes 13 existing tests to fail (including test_rule, test_markdown, test_table, and test_card). Those failures appear to come from layout calculations now treating characters such as … as width 2 instead of width 1. This suggests the unconditional change would alter Rich's existing rendering behavior for non-CJK environments. Would you prefer an opt-in or terminal-aware approach instead? I'm happy to work on that if it's the intended direction. — Reply to this email directly, view it on GitHub <#4197?email_source=notifications&email_token=BLOCDD7ITVHOP5HKXJMD3OD5GOKIZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGI2DSMJZHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5072491985>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLOCDD3HYLS2FM2T7A53A735GOKIZAVCNFSNUABFKJSXA33TNF2G64TZHMZDEMBYGA4TGOJTHNEXG43VMU5TIOJVHA4DCOJRGU2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BLOCDD43BQTJ5SCHKQBB33T5GOKIZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGI2DSMJZHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BLOCDD5VAWY6P6RVM5BLLJT5GOKIZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGI2DSMJZHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[eating-saint]

Apologies for the delayed reply — I've been dealing with some personal matters and wasn't able to follow up here sooner.

I want to say, genuinely, that I'm impressed by how quickly you guys responded and by how thorough your test coverage turned out to be. It's a great reminder of how effective open-source collaboration can be.

Looking back, my earlier fix — the "just return 2 whenever we hit A" approach — was clearly too blunt. I hadn't properly considered compatibility outside CJK environments, and it took your full test suite to reveal that it broke 13 test cases. Lesson learned.

On that note, I'd like to ask if you might have time to take a look at another issue I filed — this one is more clear-cut and, I'd argue, more severe. On Win32, in a Chinese IME environment, Shift + symbol keys (e.g., Shift+; for a colon, Shift+/ for a question mark) simply don't register at all — the characters never reach the application layer.

I traced the root cause to the VK=0 filter in textual.drivers.win32.py: IME composition events carry a valid Unicode character but report a VirtualKeyCode of 0, and are unconditionally skipped via a continue statement in that filter. This should already be in your issue tracker — the title likely references Shift, IME, or win32.

If you have a chance to take a look, I'd really appreciate it. Thanks again for all the work you've put into this.

I tried the unconditional east_asian_width(character) == "A" fallback suggested in the issue.

It makes the new test_cells cases pass, but it also causes 13 existing tests to fail (including test_rule, test_markdown, test_table, and test_card). Those failures appear to come from layout calculations now treating characters such as … as width 2 instead of width 1.

This suggests the unconditional change would alter Rich's existing rendering behavior for non-CJK environments.

Would you prefer an opt-in or terminal-aware approach instead? I'm happy to work on that if it's the intended direction.

[eating-saint]

I think a terminal-aware approach would be ideal for the user experience — CJK users get correct rendering out of the box without discovering a config option. But I'll defer to the maintainers on the implementation strategy. The contributor who tested this seems motivated, so whichever direction the project prefers, I can help verify on a CJK Windows environment.
Thanks for digging into this!