[Feature Request] Bidirectional (BiDi) text support for RTL scripts — Arabic / Persian / Hebrew / Urdu

[cubepy]

Summary

WindTerm currently renders right-to-left scripts in logical order laid out left-to-right, which makes any Arabic, Persian, Hebrew or Urdu output unreadable. Glyph shaping already appears to work correctly — letters are joined in their proper contextual forms — so the missing piece is only the reordering step of the Unicode Bidirectional Algorithm (UAX #9).

This is a smaller change than full RTL support, because the hard part (contextual shaping / joining) is evidently already handled by the text engine.

Environment

• WindTerm 2.7.0, Windows 11 (also reproducible on the Linux build)
• Session type: SSH to Ubuntu 24.04, LANG=en_US.UTF-8, terminal encoding UTF-8
• Any font containing Arabic glyphs (tested with DejaVu Sans Mono, Noto Sans Mono, Vazir Code)

Steps to reproduce

echo "سلام دنیا"
echo "Error: فایل پیدا نشد"

Actual result

The characters are emitted from left to right in memory order, so words and letters read backwards. In a mixed line the RTL run also runs into the surrounding Latin text instead of forming its own visually contiguous segment.

(Attach your screenshot here — a real terminal capture makes this much more convincing than a description.)

Expected result

• RTL runs are reordered into visual order per line, following UAX when using telnet, can not use vi. #9
• Mixed lines such as Error: فایل پیدا نشد are segmented correctly, each run in its own direction
• Text stays in logical order in the screen buffer, so copy/paste, search and selection return the original string rather than the visually reordered one

Proposed implementation

1. Opt-in setting, e.g. terminal.bidirectionalText (default false), plus an optional base-direction setting with auto / ltr / rtl. Users who never see RTL output are unaffected.
2. Early-exit scan. Before invoking the algorithm, scan the line for code points in the RTL ranges (U+0590–U+08FF, U+FB1D–U+FDFF, U+FE70–U+FEFF, and the RTL supplementary blocks). If none are present, skip the BiDi call entirely. Pure-ASCII and CJK output — i.e. essentially all of the benchmark workloads in the README — then carries zero additional cost, which matters given how much of WindTerm's design is oriented around throughput.
3. Library choice. [SheenBidi](https://github.com/Tehreer/SheenBidi) is a small, dependency-free UAX when using telnet, can not use vi. #9 implementation under a permissive (Apache-2.0 / MIT-style) license, which fits the thirdparty directory better than FriBidi (LGPL). ICU's ubidi API is another option if ICU is already linked.
4. Reorder at render time only. The BiDi run is a pure function of the line's code points, so it can be applied in the renderer/layout stage while the cell buffer, cursor arithmetic and escape-sequence handling stay untouched. This keeps the change well isolated from the terminal state machine.

Prior art

Konsole and mintty both implement BiDi with contextual shaping and are perfectly readable for Persian and Arabic. There is also a working Ghostty fork combining FriBidi for UAX #9 with HarfBuzz for Arabic joining, which reports no measurable overhead for LTR-only text thanks to exactly the early-exit approach described above. On the Windows side, the absence of this feature is a long-standing and heavily upvoted complaint (see microsoft/terminal issues #538, #19076, #20156, #20302) — a terminal that gets it right has a genuine differentiator.

Current workaround

Piping output through fribidi on the server side:

php script.php 2>&1 | stdbuf -oL fribidi --nopad

This produces correctly readable output in WindTerm, which confirms that the renderer handles the presentation forms and the joining fine — only the reordering is missing. But it cannot be applied to interactive programs, TUIs, or anything mixing ANSI colour sequences with RTL text, so it is not a real substitute.

Note on contributing

I would gladly submit this as a pull request, but the text-rendering component is not part of the published source. If a plugin API or a partial open-sourcing of the layout layer ever makes this reachable, I am happy to help implement and test it.

---

---

【功能请求】支持双向文本（BiDi）——阿拉伯语／波斯语／希伯来语／乌尔都语

概述

WindTerm 目前把从右向左（RTL）的文字按内存中的逻辑顺序从左向右排列显示，因此任何阿拉伯语、波斯语、希伯来语或乌尔都语的输出都无法阅读。字形整形（shaping）似乎已经正常工作——字母的连写形式是正确的——所以缺少的只是 Unicode 双向算法（UAX #9）中的重排序步骤。

因此这比实现完整的 RTL 支持要小得多，因为最困难的上下文整形部分显然已经由文本引擎处理好了。

环境

• WindTerm 2.7.0，Windows 11（Linux 版本同样可复现）
• SSH 连接 Ubuntu 24.04，LANG=en_US.UTF-8，终端编码 UTF-8
• 任何包含阿拉伯字形的字体（已测试 DejaVu Sans Mono、Noto Sans Mono、Vazir Code）

复现步骤

echo "سلام دنیا"
echo "Error: فایل پیدا نشد"

实际结果

字符按内存顺序从左到右输出，导致单词和字母顺序颠倒、无法阅读。在混合行中，RTL 片段还会插入到周围的拉丁文字中，而不是形成一个视觉上连续的独立片段。

（请在此处附上截图。）

期望结果

• 按 UAX when using telnet, can not use vi. #9 对每一行中的 RTL 片段进行视觉顺序重排
• 像 Error: فایل پیدا نشد 这样的混合行能被正确切分，每段各自使用自己的方向
• 屏幕缓冲区中仍保存逻辑顺序的文本，使复制粘贴、搜索和选择返回原始字符串，而不是重排后的结果

实现建议

1. 可选开关，例如 terminal.bidirectionalText（默认 false），并可增加基础方向设置 auto / ltr / rtl。不需要 RTL 的用户完全不受影响。
2. 提前退出检测。 在调用算法之前先扫描该行是否包含 RTL 码位（U+0590–U+08FF、U+FB1D–U+FDFF、U+FE70–U+FEFF 及相关补充区）。若不包含，则完全跳过 BiDi 处理。这样纯 ASCII 和 CJK 输出（也就是 README 中几乎所有性能测试场景）不会有任何额外开销——考虑到 WindTerm 的设计极为重视吞吐性能，这一点很关键。
3. 库的选择。 [SheenBidi](https://github.com/Tehreer/SheenBidi) 是一个体积小、无依赖的 UAX when using telnet, can not use vi. #9 实现，采用宽松许可（Apache-2.0／MIT 风格），比 FriBidi（LGPL）更适合放入 thirdparty 目录。如果项目已链接 ICU，也可以直接使用 ICU 的 ubidi 接口。
4. 仅在渲染阶段重排。 BiDi 的结果只取决于该行的码位，因此可以只在渲染／布局阶段应用，而单元格缓冲区、光标计算和转义序列处理都无需改动，改动范围与终端状态机完全隔离。

参考实现

Konsole 和 mintty 都实现了带上下文整形的 BiDi，波斯语和阿拉伯语显示完全正常。此外还有一个可用的 Ghostty 分支，结合 FriBidi（UAX #9）与 HarfBuzz（阿拉伯语连写），并且由于采用了上文所述的提前退出策略，对纯 LTR 文本没有可测量的性能损失。在 Windows 平台上，这一功能的缺失长期以来一直是高关注度的问题（参见 microsoft/terminal 的 #538、#19076、#20156、#20302）——率先做好这一点会是 WindTerm 的一个真正差异化优势。

当前的变通方法

在服务器端通过管道处理：

php script.php 2>&1 | stdbuf -oL fribidi --nopad

这样在 WindTerm 中就能正常阅读，这也说明渲染器对呈现形式和连写处理是正确的，缺的只有重排序。但该方法无法用于交互式程序、TUI 应用，也无法处理 ANSI 颜色序列与 RTL 文本混合的情况，因此不能算真正的解决方案。

关于贡献

我很愿意直接提交 Pull Request，但文本渲染组件并不在已开源的代码中。如果将来插件 API 或布局层的部分开源让这一点成为可能，我很乐意参与实现与测试。