ISCII put ten Brahmi-derived scripts on one code table

The logic of a shared skeleton

By the mid-1980s, the Bureau of Indian Standards faced a problem that had no obvious precedent in encoding work elsewhere: India used not one writing system but more than a dozen, several of them in daily official use, and the government wanted computers to handle them all. The answer that emerged — finalised as IS 13194:1991 — was architecturally bold. Because Devanagari, Bengali, Gujarati, Gurmukhi, Kannada, Malayalam, Oriya, Tamil, Telugu and Assamese all derive ultimately from Brahmi, they share a deep phonological skeleton. Consonants occupy roughly the same phonetic slots across every script; vowels follow consistent patterns; the inventory of conjunct forms, though visually different in each script, obeys the same grammatical logic. ISCII — the Indian Script Code for Information Interchange — exploited that structural fact. One layout, ten scripts.

The table occupies the upper half of an eight-bit byte, code positions 0xA0 through 0xFF. Each position is assigned not a character from one particular script but a phonological function: position 0xA6, for example, carries the short vowel sound that Devanagari writes as इ, Bengali as ই, Tamil as இ. A software layer — and, later, a font — determines which glyph is actually drawn. A single plain-text file can switch among scripts using a two-byte ATR (Attribute) sequence that precedes a run of text, much as a colour code precedes a run of coloured terminal output. The byte values themselves never change; only the rendering interpretation does. This made ISCII files small and, within its intended domain, elegant.

The scheme worked because the scripts it covered are genuinely related. All ten treat the syllable, not the letter, as the primary unit. All ten use a base consonant modified by a matra — a dependent vowel mark — rather than writing full vowel letters after every consonant. All ten form conjunct consonants by joining two or more base consonants, suppressing an inherent vowel between them. ISCII encoded that logic once and let the rendering layer handle the visual divergence. Tamil was the hardest fit: its phonological inventory is smaller and its conjunct conventions differ from the northern scripts, but the designers accommodated it rather than excluding it, accepting some positional compromises in the table.

What the table contained, and what it deferred

The upper 96 positions of ISCII are divided into clear regions. A cluster of code points near 0xA1–0xAF carries vowel letters (the independent forms used at the start of a word or after another vowel). The consonant rows follow, arranged in the traditional Sanskrit phonological order — velar stops first, then palatals, retroflexes, dentals, labials — the same order any Devanagari primer uses and the same order that was later carried, largely intact, into the Unicode Devanagari block. Matras occupy their own cluster, and the halant — the diacritic that suppresses the inherent vowel and signals a conjunct — sits at 0xE8, a position that would later map cleanly to the Unicode virama concept.

C-DAC, the Centre for Development of Advanced Computing established in Pune in 1988, was the primary institutional force turning ISCII into working software. Its GIST technology (Graphics and Intelligence-based Script Technology) implemented the ATR switching mechanism and provided the rendering engine that state governments and central ministries used through the 1990s. C-DAC also produced the fonts — bitmap first, then outline — that gave ISCII text its visible form on screen and in print. Kerala and Tamil Nadu both ran substantial government data-entry operations on ISCII-based systems before Unicode infrastructure was mature enough to replace them, and the conversion of those legacy databases became a documented procurement problem in its own right through the 2000s.

The table's elegance, however, was also its constraint. Eight bits give 256 positions; 96 usable slots serve ten scripts only if each slot means one phonological unit rather than one script-specific character. That works for shared phonology but breaks for script-specific marks, numerals and punctuation. ISCII addressed this with a small set of extension bytes and the ATR mechanism, but the result was stateful encoding: to decode a byte correctly you had to know which ATR code had preceded it. Stateful encodings transfer poorly across systems and cannot be easily concatenated, sorted or searched. A string comparison between two ISCII files only makes sense if both parsers agree on the current script state. For file exchange within a controlled government system, this was manageable. For the open internet, it was not.

What Unicode inherited from the negotiation

When the Unicode Consortium began absorbing Indic scripts in the late 1980s and early 1990s, it could not simply copy ISCII wholesale. Unicode is stateless: every code point carries its own identity regardless of context. That means ten scripts need ten separate blocks, each with its own vowel letters, consonants, matras and virama. The negotiation between what ISCII had unified and what Unicode had to separate was not purely technical; it involved decisions about which distinctions were phonologically real and which were rendering conventions. Several characters that ISCII encoded once — because the phoneme was the same even if the glyph differed — needed to be duplicated across Unicode blocks to give each script independent code points.

The ISCII consonant order survived the crossing almost entirely intact. The Unicode blocks for Devanagari (U+0900–U+097F), Bengali, Gujarati, Gurmukhi, Kannada, Malayalam, Oriya, Tamil, and Telugu are arranged in the same phonological sequence that IS 13194 had fixed at almost the same time, in the same Sanskrit grammatical tradition. That continuity was deliberate: the Unicode Technical Committee acknowledged the ISCII work and used it as a primary reference. The mapping between ISCII byte values and Unicode code points is close enough that automated conversion is largely mechanical — a lookup table with a small number of one-to-many expansions where ISCII's single byte needs to become two Unicode code points to preserve script identity.

The table occupies the upper half of an eight-bit byte, code positions 0xA0 through 0xFF.

The shaping requirements that ISCII had handled through its ATR-aware rendering engine had to be recast as explicit Unicode shaping rules: the virama-based conjunct mechanism, the reordering of certain matras to positions visually left of the base consonant, the split-matra forms in Malayalam and Tamil. OpenType tables carry those rules today in every compliant font. The logic is the same logic ISCII's rendering layer implemented; the form is different because the encoding is stateless and the font must therefore carry the contextual intelligence that ISCII's ATR sequences once provided externally.

IS 13194:1991 is now a superseded standard, its direct deployment confined to legacy systems and historical archives. But its architecture shaped everything that followed: the block structure of Unicode's Indic range, the phonological ordering that makes sorting across scripts tractable, and the shaping model that OpenType still implements script by script. A single eight-bit table for ten scripts was a constraint that generated solutions, and those solutions outlasted the table.