CJK (Chinese, Japanese, Korean) and Emoji character width issues in ASCII rendering

[zenyr]

Summary

ASCII rendering has width calculation issues with CJK characters (full-width, 2-byte) and emoji, causing misaligned boxes and potential text overflow.

Problem Description

Issue 1: CJK Character Width Miscalculation

CJK characters (Chinese, Japanese, Korean) are full-width characters that occupy 2 columns in terminal/monospace displays. However, the ASCII renderer treats them as single-width characters.

Reproduction:

import { renderMermaidAscii } from 'beautiful-mermaid'

// Korean example
const svg = renderMermaidAscii(`graph TD
  A[시작] --> B{결정}
  B -->|예| C[처리]`)

console.log(svg)

Actual Output:

┌───┐           
│   │           
│ 시작 │  ← Box too narrow for CJK
│   │           
└─┬─┘           

Issues:

• CJK text appears cramped in boxes
• Boxes don't properly accommodate full-width characters
• Long CJK text may overflow boundaries

Issue 2: Emoji Width Inconsistency

Emoji characters also have variable width that isn't properly handled.

Expected Behavior

CJK characters should be counted as 2 columns for proper box sizing:

# Expected for "시작" (2 CJK chars = 4 columns)
┌────────┐
│        │
│  시작  │
│        │
└────┬───┘

Environment

• Package: beautiful-mermaid v0.1.3
• Runtime: Bun/Node.js
• Affected: Korean, Chinese, Japanese, Emoji

Possible Solutions

1. Use string-width or wcwidth library for proper Unicode width calculation
2. Detect CJK Unicode ranges and count as width 2:
   • Chinese: \u4e00-\u9fff
   • Hiragana: \u3040-\u309f
   • Katakana: \u30a0-\u30ff
   • Korean: \uac00-\ud7af
3. Document limitation and recommend SVG output for CJK/Emoji

Impact

Affects users working with CJK languages or emoji in ASCII/terminal mode.

[994AK]

I'll try to fix it.

[994AK]

Hey buddy, I'm about to submit the proposal.

[zenyr]

Note

Author of this issue — sharing an update after seeing multiple community PRs attempting fixes.

Great to see community interest in fixing this! There are currently three PRs (#15, #17, #19) all addressing this CJK width issue with different trade-offs. Here is a comparison for reference:

PR	Strategy	Coverage	Canvas Handling	Completeness
#15	Zero-width placeholder (\u200b)	CJK + emoji	Proper 2-col reservation	⭐⭐⭐⭐
#17	Width calc only	CJK only	No canvas changes (broken)	⭐⭐
#19	Empty string placeholder	CJK + fullwidth	Clears next cell	⭐⭐⭐

Recommendation: #15"'s approach is the most sound — the zero-width placeholder pattern properly reserves the second column without visual artifacts.

Performance opportunity: If Bun.stringWidth() is available (Bun v1.5.8+), it provides a native fast path that handles all Unicode edge cases. Worth adding as a tiered strategy: Bun → Intl.Segmenter → fallback.

My offer: I have implemented a complete solution in my local branch with:

• Full Unicode 16.0 EAW compliance (Extension B-I, Tangut, Khitan, etc.)
• 4-tier strategy: Bun native → Intl.Segmenter → get-east-asian-width pkg → inline
• Same placeholder pattern as fix(ascii): handle CJK/fullwidth label width correctly #15

If #15 merges first, I will open a follow-up PR to swap in the more comprehensive width calculation while keeping the placeholder rendering logic. This gives us working CJK support immediately, with correctness and full Unicode coverage next.

To maintainers: Suggest reviewing #15 as the base implementation, with potential follow-up for edge-case Unicode coverage.

PR Previews: (for easier bird eye views)

• fix(ascii): handle CJK/fullwidth label width correctly #15
• fix: CJK character width calculation for proper alignment #17
• feat: add CJK/fullwidth character support for ASCII rendering #19