セル境界線（Cell Borders）：ターミナルと TUI に新たな視覚次元をもたらす新プロトコル

AI の多大なるご支援を承り、以下の内容を整理しました。もし内容について懸念がある場合は、タブを閉じるのも自由です。

Ratatui のメンテナンスを通じて多くの TUI（ターミナルユーザーインターフェース）を見てきましたが、単調な背景に単純な枠線しかなく、優れたデザインが見られないケースが多く見受けられました。**境界線（ボーダー）**こそがその一因です。

問題と現状

• 既存の限界
  • 従来の方法は Unicode のボックスドラウイング文字を使用しています。
  • 128 種類のライン・隅角・接続形状が存在するにもかかわらず、依然として不十分です。
  • 境界線はスペースを占有するため、パネル構築において必須の要素となりがちで、テキストの表示領域を狭める原因となります。
• フォールバックの問題点
  • セル境界線のサポートがないターミナルでは、ボックスドラウイング文字にフォールバックします。
  • 結果として、各パネルはすべての側面で 1 行・1 列失われます。
  • ログ表示の行数減少や、テキストフィールドでの改行位置の違いなど、レイアウトの不整合が発生します。

新しいアプローチ：Ghostty プロトコル

セルの縁に薄い線を引くための新しいターミナルプロトコルを開発しました。

• 動作確認済み: Ghostty（元 Rio）へのパッチとして機能を確認。
• デモ作成: Ratatui を用いたデモアプリも公開中。
• 目標: 行や列を消費することなく境界線を表示し、開発者および一般ユーザーからのフィードバックを求めています。

メリットと活用シナリオ

視覚的な利点

• 完全な占有なし: 行や列を犠牲にせず、すべての側面で境界を描画可能です。
• 洗練されたデザイン:
  • タブはパネルの上端に配置され、テキストには直下の下線、ボタンは丸みを持ったデザインが可能になります。
  • レイアウトが縁を求めたがるパネル型アプリにおいて非常に清潔感があります。
• レイヤー効果: メニューやポップアップなどのコンテンツを上面に表示しながらも、背景から「上にある」ように見せることができます。

具体的な使用例

• ウィジェット連携: テキストフィールド、ボタン、チェックボックスなどに文字と直結したラインが必要な場合に有効です。
• チャート表示:

  • btop

    風のグラフでは通常、グリッド線を入れる場所がありません（行列を失うため）。
  • セル境界線の場合、ドットの間に配置されるため、スペースの効率的な使用が可能です。

機能詳細と動作原理

技術的な仕組み

• セル属性化: 境界線は背景色と同じくセル属性の一つです。
• 柔軟な描画:
  • 各セルは最大 12 セグメントのラインを持ちます（辺の半分、中心から伸びるアームなど）。
  • セグメントごとに独自の色、太さ、配置、スタイルを設定できます。
  • テキストのスクリロールや消去、挿入、再フローにも追従します（境界線はセルに格納されているため）。
• 幾何学的整合性: 辺が半分に分かれているため、四分割ブロック文字（▖▗▘▝ など）と整合し、グリッドから半セル内側で形状を描画しつつ周囲を整った境界線を配置できます。

コマンド仕様 (DCS)

• 形式: 1 つの DCS（Device Control String）で表現されます。

  • ESC P 1 + b cell-border ; OP ; FIELDS... ESC \

• 基本動作:
  • 「ペン」を設定し、テキストを印刷すると、そのセルに境界線が付与されます。
  • 既存セルの境界線の設定・消去や、能力問い合わせも矩形コマンドで行います。
• フォールバック機構:
  • アプリは能力問い合わせ（DA1）を送信します。応答に

    cell-border

    が含まれない場合、ターミナルはサポートしていないため、アプリはフォールバックしてボックス文字を使用します。
  • DCS を理解しないターミナルは無視するため、安全な動作が保証されます。

スタイルと接合部

• ラインスタイル: 実線、二重線、破線、点線のいずれかを選択可能。
• 形状設定: 隅や中心は正方形または丸みつきで設定でき、構成可能な半径とアンチエイリアス付きの弧があります。
  • 丸い隅は外部色を指定できるため、背景色の不一致による視覚的な不自然さを解消します。
• 優先度ルールの融合:
  • 2 つの隣接セルが共有边上にラインを描画する場合、それらは 1 つのラインとして融合します。
  • 優先度の高いストロークが勝ち（次いで太い方、右または下）、フォーカスされたパネルは優先度を上げ、全体のアウトラインを保持できます。

既存技術との比較と進化

特徴	従来のボックス文字	セル境界線 (新プロトコル)
スペース占用	テキスト領域を犠牲にする（行・列消費）	0 クライアンク。既存のセル内で表示。
ライン配置	固定されたグリッドのみ。間隔調整困難	柔軟。共有边上に競合するラインを優先度で解決可能。
編集操作への追従	複雑な再描画が必要。	自動。スクリロールや挿入時、境界線も追随。
コピー＆ペースト	ボックス文字自体がコピーされる（後処理必要）	テキストのみ。境界線はコピーされず、チャットなどへの貼り付けに最適。

先行技術との違い

• DEC ルールライン: テキストに追随するが、画面消去時に残存し、常に 1 ピクセル幅で単色。
• SGR 51〜65: オン/オフ属性のみで、色や太さ、接合部の詳細指定不可。
• Win32/X/Open curses: 下端の欠けや、独自の色・太さ指定の非サポートなど機能に限界がある。

本プロトコルはこれらから得られない**「各辺ごとの独自の色と太さ」**を実現しています。

実装コストと性能について

メモリ使用量

• 構造: 各セルに 16 ビットのボーダー ID が割り当てられ、元々あったパディングに収まるため、セル自体が大きくなりません。
• 共有テーブル: ID は共通テーブル（各約 100 バイトの個別ボーダーセット群）を参照。
  • TUI は少数のセットしか使用しないため実用的な範囲内。
  • 最悪の場合（全 65,535 ID 使用中）でも、約 10〜15 MB程度です。

レンダリング負荷

• 追加処理: 境界線を持つセルのみで追加処理を行います。
• 共有辺解決: 4 つの隣接セルを確認して共有辺を解決するため、行変更に伴う前後の行の再構築が発生します。
• 形状描画コスト:
  • 直線：セルあたり数個のソリッドクアドレイト（四角形）で表現。
  • 丸みつき隅・アンチエイリアス：エッジピクセルごとに小さなクアドレイトの列として描画されるためコストは高まります。

試してみる（インストールと実行）

Ghostty で確認する

仕様書と根拠文書は joshka/ghostty のブランチにあります。macOS 上で構築・実行可能（GTK/OpenGL は未テスト）。

ビルドと実行:

git clone -b joshka/cell-borders https://github.com/joshka/ghostty.git
cd ghostty
zig build -Doptimize=ReleaseFast -Dxcframework-target=native
open zig-out/Ghostty.app

ギャラリースク립トでの確認: スタイルギャラリーを表示し、フォールバック動作や機能を確認します。

# デフォルト表示（サポート検出）
python3 scripts/cell-borders.py

# ラインスタイル、接合部、外部充填の詳細確認
python3 scripts/cell-borders.py --styles

• 操作方法: 動作中に

  p

  (配置),

  c

  (色),

  h

  (ブロック),

  j

  (接合部),

  e

  (半端),

  s

  (スタイル) を押してビューを切り替えられます。

  w

  でストローク幅循環、

  b

  で境界線オフ（比較）、

  q

  で終了します。

Ratatui で確認する

Ratatui のブランチにて、タイル分割パネルのデモを公開しています。セル境界線をサポートしないターミナルでは自動でフォールバックします。

ビルドと実行:

git clone -b joshka/cell-borders https://github.com/joshka/ratatui.git
cd ratatui
cargo run -p tiling-panes

• タイル操作: マウスでパネルをドラッグして再タイル。

  n

  ,

  v

  で分割、

  x

  で閉じる。右クリックでメニュー。
• 切り替え:

  b

  キーでセル境界線とボックス描画の間を切り替え。

チャートデモ (bslop)

btop 風のモニターも同一ブランチにあり、実際のシステムリソースを表示します。

ビルドと実行:

cargo run -p cell-border-top

• 操作:

  1

  〜

  4

  でボックスの表示/非表示切り替え。

  b

  (境界線),

  g

  (陰影),

  h

  (?でヘルプ) などのキーバインドがあります。

開発者向けに：ディスカッションとフィードバック

これは唯一の解決策ではありませんが、解決する価値のある問題であると確信しています。単一のターミナルの機能を超えるべきであり、もしあなたが開発者であれば導入を検討してほしいです。

• コストへの懸念: レンダリング負荷やメモリ使用量について、どの部分が特に重いと感じますか？
• TUI ライブラリ: どのウィジェットでこれを使用したいですか？また、どのような機能追加が必要ですか？
• マルチプレクサ対応: tmux などの理解のある環境での動作確認も重要です。

Ghostty のディスカッションや、本仕様書へのコメントを歓迎します。