Standards
What Unicode had to settle
ISCII carried ten scripts on a single eight-bit table; folding that into Unicode required decisions about which distinctions the universal standard would honour and which it would quietly erase.

The table before the table
India had its own answer to multi-script computing before Unicode existed. ISCII — the Indian Script Code for Information Interchange, first drafted in 1988 and standardised by the Bureau of Indian Standards as IS 13194 in 1991 — placed ten Brahmi-derived scripts onto a single 256-position code table by observing that the scripts share phonological structure. Devanagari, Bengali, Tamil, Telugu and the rest map onto the same set of positions; only the rendering changes. A document in Malayalam and a document in Gujarati occupy the same numerical addresses, distinguished only by a font-switch signal. It was an elegant compression, and C-DAC in Pune built an entire generation of multilingual computing infrastructure on top of it.
Unicode's approach was different in kind. Each script received its own dedicated block — its own contiguous range of code points — so that a Malayalam character and its phonological cousin in Kannada carry distinct numbers even when they look nearly identical on the page. For the ISCII scripts, this meant that one positional slot in the old table became ten separate entries in the new one, one per script block. The expansion was not merely arithmetic: it forced a set of editorial questions about what, exactly, had been encoded in each ISCII position.

What survived, what split, and what disappeared
Some ISCII characters had no clean Unicode equivalent because they encoded distinctions that Brahmi-script typography makes but that Unicode's initial designers did not immediately recognise. The nukta — a dot placed beneath a consonant to represent sounds borrowed from Persian and Arabic — existed in ISCII and required explicit Unicode code points if the standard was to serve Devanagari texts faithfully. It was included. The virama, the halant mark that suppresses the inherent vowel of a consonant and is the key mechanism for forming conjuncts, was likewise carried over, though its behaviour in shaping engines became far more complex once each script had its own block with its own block-specific rules.
Other distinctions were harder. ISCII's design assumed that the rendering system — the font, the software — would handle conjunct formation and matra reordering as a display-layer problem, guided by the code's phonological logic. Unicode inherited this tension: the code points encode abstract characters, not glyphs, and the shaping layer must do the work of determining which consonant sequences collapse into a single conjunct form and which do not. The Unicode Standard's Indic-specific shaping specifications, elaborated across successive versions of the standard and eventually embodied in the OpenType feature tags rphf, blwf, half and others, are the sediment of those negotiations.
Chronology
- 1988Bureau of Indian Standards publishes IS 13194, formalising ISCII
- Early 1990sUnicode Consortium assigns dedicated blocks for Devanagari, Bengali, Tamil, Telugu, and other Indic scripts
- Successive Unicode versionsOpenType shaping tags for Indic scripts (
rphf,blwf,half, etc.) elaborated in detail
Tamil posed a particular case. Unlike the other ISCII scripts, Tamil does not use conjuncts in the same way and has a smaller consonant inventory. Its ISCII positions were accordingly sparse. When the Unicode Consortium assigned the Tamil block its own range, the sparseness was preserved rather than filled with theoretical characters Tamil orthography does not use — a decision that distinguished Unicode's editorial stance from a purely mechanical transliteration of ISCII.
The encoding that two governments used
The practical stakes of these decisions became visible in procurement. Kerala and Tamil Nadu, both early adopters of Linux-based deployments in government offices and schools, had existing document workflows built around ISCII-compatible software developed in the C-DAC ecosystem. Migration to Unicode-compliant systems required not just new fonts but conversion of legacy data — and the conversion was only lossless where the Unicode block had been specified precisely enough to represent every distinction the original ISCII document contained.
The Bureau of Indian Standards document IS 13194, which formalised ISCII, remains the reference point for understanding what was being imported into Unicode and what was being left behind. Gaps between the two standards still appear in corpus work on historical texts, where characters that ISCII handled by convention and font behaviour have no single agreed Unicode representation. The negotiation, in that sense, is not entirely closed: the Unicode Standard continues to receive proposals for Indic characters, and each acceptance or rejection re-enacts, at smaller scale, the same argument that produced the original Indic blocks in the early 1990s.
For the ISCII scripts, this meant that one positional slot in the old table became ten separate entries in the new one, one per script block.

The structural contrast
- ISCII: one positional slot, ten scripts, distinguished by font/mode signal
- Unicode: one block per script, code points non-overlapping, shaping logic in the rendering layer
- Consequence: single ISCII slot → up to ten Unicode code points; conversion is lossless only where both ends are precisely specified