Issue
The wterm DOM renderer misaligns box-drawing characters (U+2500–U+257F: ─ │ └ ┌ etc.), so TUI borders from zellij / Claude Code drift by 1–3px and the right border looks ragged. xterm.js does not have this problem.
Screenshot of the ragged wterm border to be attached.
Root cause (upstream)
@wterm/dom's renderer special-cases block elements U+2580–U+259F into fixed-width .term-block { width: 1ch } spans, but box-drawing U+2500–U+257F flows through the normal text-run path, so its rendered width depends on the font glyph advance rather than the cell grid. Tracked upstream: vercel-labs/wterm#52 (OPEN, no PR attached yet).
Our font stack makes it worse: --font-mono lists Nerd Fonts that are not @font-face-loaded, and the only loaded web font (Pure Nerd Font) is scoped to U+E000–F8FF, so box-drawing falls back to a wrong-width system glyph. Verified: the @fontsource-variable/jetbrains-mono subsets ship 0 box-drawing glyphs, so "just add a webfont" does not fix it.
Status / decision
- We are not patching wterm locally. We accept wterm's borders are broken for now and lean on xterm.js (current default renderer), which rasterizes box-drawing onto fixed cells and is immune.
- wterm stays available via the renderer dropdown (sliders menu → Renderer) for comparison.
- NOT blocked on wterm#75 — that PR fixes wide-character (CJK/emoji) desync (#54), not box-drawing. Verified by reading the diff: it leaves the
0x2580..0x259f branch unchanged and box-drawing chars are width-1, so they keep flowing as unclamped text runs.
Unblock condition
When wterm#52 ships in a released version: bump @wterm/{core,dom,react}, re-run the renderer A/B (wterm vs xterm), and decide on a fair footing.
References
Issue
The wterm DOM renderer misaligns box-drawing characters (
U+2500–U+257F:─ │ └ ┌etc.), so TUI borders from zellij / Claude Code drift by 1–3px and the right border looks ragged. xterm.js does not have this problem.Root cause (upstream)
@wterm/dom's renderer special-cases block elementsU+2580–U+259Finto fixed-width.term-block { width: 1ch }spans, but box-drawingU+2500–U+257Fflows through the normal text-run path, so its rendered width depends on the font glyph advance rather than the cell grid. Tracked upstream: vercel-labs/wterm#52 (OPEN, no PR attached yet).Our font stack makes it worse:
--font-monolists Nerd Fonts that are not@font-face-loaded, and the only loaded web font (Pure Nerd Font) is scoped toU+E000–F8FF, so box-drawing falls back to a wrong-width system glyph. Verified: the@fontsource-variable/jetbrains-monosubsets ship 0 box-drawing glyphs, so "just add a webfont" does not fix it.Status / decision
0x2580..0x259fbranch unchanged and box-drawing chars are width-1, so they keep flowing as unclamped text runs.Unblock condition
When wterm#52 ships in a released version: bump
@wterm/{core,dom,react}, re-run the renderer A/B (wterm vs xterm), and decide on a fair footing.References
qqqq), Wide characters (CJK, emoji) advance cursor by only 1 cell, desyncing the grid vercel-labs/wterm#54 (CJK width)web/src/features/home/components/organisms/terminal-panel.tsx,web/src/features/home/components/organisms/xterm-terminal.tsx