Skip to content
Tech News
← Back to articles

Rendering complex scripts in terminal and OSC 66

read original get Termius SSH Client → more articles
Why This Matters

Rendering complex scripts like Indic and Arabic in terminal environments remains a significant challenge due to the legacy character-cell grid architecture, which cannot accommodate the dynamic shaping and reordering required by these languages. Overcoming this limitation is crucial for developers working in multilingual and language-processing fields, as it would enable more inclusive and versatile command-line tools. The ongoing efforts and new tools introduced in this article highlight potential solutions to bridge this gap, improving accessibility and functionality in terminal applications.

Key Takeaways

As a programmer, I spend most of my time in a terminal application like Kitty. I use Neovim as my code editor. I use CLI based AI agents. But the biggest pain, even in 2026, is that there is no terminal that can render complex scripts like Indic languages or Arabic. This is a significant limitation for me, as most of my work involves language processing.

In this article, I will give a brief overview of why this issue remains unsolved—covering the character-cell grid model, width measurement, and the distinction between text shaping and rendering—along with ongoing efforts and a small tool I built recently that illustrates a solution path.

Why complex script rendering is hard in terminals#

The architecture of modern terminal emulators like GNOME Terminal, Kitty, and Ghostty is a software-based reproduction of physical hardware constraints from the 1970s. The transition from electromechanical teletypewriters to video display terminals established the character-cell grid as the universal interface for command-line computing. In this model, the screen is conceptualized as a matrix of rows and columns, where each intersection—a cell—houses exactly one graphic character.

Text User Interfaces (TUIs) rely on this assumption to calculate layouts and position the cursor. When a developer uses a tool like Vim or htop, the application calculates the exact column and row for every character, assuming that moving the cursor one “step” always corresponds to one cell on the display.

The “one character to one cell” mapping represents a fundamental architectural failure when applied to complex writing systems. These scripts, which include Arabic and the Indic family (Malayalam, Tamil, Devanagari), are characterized by contextual shaping, character reordering, and non-linear glyph fusion—concepts that are inherently incompatible with a static grid. Arabic has additional characteristics of right to left writing.The Arabic Calligraphic Problem

ന ് ത ോ ⇒ ന്തോ

Monospace fonts#

This problem is compounded by how monospace fonts work. Monospace fonts are designed for working with the above constraints. But the concept of “monospace” cannot be defined for Indic scripts or Arabic. Every character in a monospace font takes exactly the same amount of horizontal space. Latin letters can fit into that design constraint, but not other scripts.

As an illustration, see the following Malayalam ligatures and observe the width it takes:

... continue reading