mirror of
https://github.com/anomalyco/opentui.git
synced 2026-04-25 04:55:58 +03:00
[GH-ISSUE #255] bug: CJK char corruption in text rendering #834
Labels
No labels
bug
core
documentation
feature
good first issue
help wanted
pull-request
question
react
solid
tmux
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/opentui#834
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zenyr on GitHub (Nov 3, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/255
Problem
Both Solid and React reconcilers corrupt certain CJK characters during rendering.
Core handles them correctly.Emoji & ASCII unaffected.
Root Cause
Encoding/displayWidth mismatch in JSX→TextNode conversion path. Likely culprit: reconciler text handling vs core displayWidth calc.
Investigation Notes
Next Steps
Created with assistance from OpenCode & Claude Haiku 4.5
@kommander commented on GitHub (Nov 3, 2025):
Thanks for looking into this. I think the root cause for something like this would rather be in the renderer.zig for the ansi output, or width calculations in utf8.zig. Setting a default background prevents text from ever being rendered on transparent terminal background.
@kommander commented on GitHub (Nov 3, 2025):
I can't seem to be able to reproduce that. What terminal are you using?
@zenyr commented on GitHub (Nov 4, 2025):
Oh, okay. I'll attach my system configuration here:
I also found this issue on
Windows 11 Powershell / CMDenvironment too.I've made a tangent PR (adding React test suite with skipped tests) on #262.
Update:
t)@kommander commented on GitHub (Nov 4, 2025):
Ahh tmux might be the culprit, it has some Unicode quirks, will try to reproduce.
The issue with the overlapping "t" is a different one, that needs flexShrink=0 and is handled in an issue on opencode.
@zenyr commented on GitHub (Nov 5, 2025):
Hmm while I do agree with the reasoning I could 100% reproduce this on my
Windows 11 device, which does not have any tmux related stuff available.@kommander commented on GitHub (Nov 5, 2025):
Yes, the windows terminals calculate Unicode width differently and not complete to the standard as well, like tmux. Proper Unicode support is lacking in many implementations unfortunately.
@kommander commented on GitHub (Nov 6, 2025):
@zenyr commented on GitHub (Nov 6, 2025):
Ah sure, Windows native terminal is notorious for CJK users already :)
Hoever,I think I could reliably reproduce grapheme error, with or without chunk streaming.
For example:
This rendering issue persists regardless of being streamed or not.
This is another screenshot of the same session loaded
without tmux: (opencode --continue)@DonKongPaPa commented on GitHub (Nov 11, 2025):
check this out
https://github.com/user-attachments/assets/64da545e-368a-454d-be11-be5e229a69a9
@kommander commented on GitHub (Nov 11, 2025):
@DonKongPaPa can you add the raw text you pasted here as well. I haven't gotten to the bottom of this yet, I suspect some grapheme byte offsets are miscalculated somewhere.
@DonKongPaPa commented on GitHub (Nov 12, 2025):
@DonKongPaPa commented on GitHub (Nov 12, 2025):
Not only that, I've also found that the cursor behavior is abnormal.
@zenyr commented on GitHub (Nov 13, 2025):
I can confirm that the input editor now supports CJK way better than before (especially when I try to mention an agent mid-prompt)
But the display part issue is still somewhat there(always at the line-break?), while the majority of this issue went away (just got my hands on the latest version, needs more test).
→ https://opencode.ai/s/F1wEN23v
@kommander commented on GitHub (Nov 13, 2025):
I see, I think I know where to look. I'll give this another go asap.
@zenyr commented on GitHub (Nov 18, 2025):
Using opencode .70 and it seems very promising so far. (not seeing any glitches)
@zenyr commented on GitHub (Nov 18, 2025):
I could see a few consistent glitches on line-breaks.
Original
Rendered
"흐름도" → "흐\n흐 도"
"초기화" → "초\n초 화"
Extracted with ascii sequence via tmux
This particular case came from
opencode v1.0.72using tmux + ghostty. but I think still relevant here.Reproduced without tmux (ghostty)
플러그인became플러\n러 인@kommander commented on GitHub (Nov 18, 2025):
Alright, let's do this again, I'll get it right at some point. So many edge cases.
@kommander commented on GitHub (Dec 10, 2025):
I haven't forgotten about this, just didn't get through to it yet.
@kskang commented on GitHub (Jan 11, 2026):
I created a PR that may fix this issue: #512
The root cause seems to be
char_offsetvscol_offsetmismatch in word wrap boundary detection. CJK characters have display width 2, but the code was using character count (width 1) for wrap calculations.Would appreciate if someone could test this fix.
@kommander commented on GitHub (Jan 18, 2026):
This should be better now?
@zenyr commented on GitHub (Jan 20, 2026):
https://opncd.ai/share/73TBWAXf (Last message contains a summary)
It's MUCH MUCH better now, the only edge case that I found was the Keycap emojis, which Haiku 4.5 often uses.
Other than that I think... it's fixed!
@zenyr commented on GitHub (Jan 20, 2026):
Thanks for fixing up the majority of issues. Please refer to the shared session above for the remaining edge cases. @kommander