Then somebody had to write it into a purchase order

From standard to tender

A code point is assigned. A shaping engine handles the conjuncts. A font ships with the correct glyphs. And then, for years, none of it reaches a government office unless somebody puts a script compliance requirement into a Request for Proposal. That is the gap procurement is supposed to close, and in India the gap was wide and slow to narrow.

The foundational layer was ISCII — the Indian Script Code for Information Interchange, published by the Bureau of Indian Standards as IS 13194 in 1988 and revised in 1991. ISCII mapped ten Brahmi-derived scripts onto a single eight-bit table, with a font-switching mechanism rather than separate code ranges. It was an elegant compression, designed at a time when eight bits was an engineering constraint, not a choice. C-DAC in Pune built the GIST (Graphics and Intelligence-based Script Technology) cards and software that made ISCII usable on the hardware of the late 1980s, and those products entered government tenders first — hardware tenders, not software standards tenders. The distinction matters: the procurement documents of that period were buying a device that happened to carry Indian-language capability, not specifying a standard and then sourcing to it.

Unicode changed the logic. Once the Devanagari block (U+0900–U+097F), the Tamil block (U+0B80–U+0BFF), the Malayalam block (U+0D00–U+0D7F), and the other Indic ranges were stable in Unicode 1.0 (1991) and the subsequent revisions, it became possible to write a language-neutral compliance requirement — "the system shall encode text in Unicode" — that implied script support without naming a vendor. Government procurement doctrine everywhere prefers that kind of specification because it keeps the field open to competition. The problem in India through the 1990s was that Unicode support for Indic scripts was nominal in many products: the code points existed, but the shaping — the rendering logic that assembles a matra to its base consonant, or suppresses a virama to form a conjunct — was absent or wrong. Writing "Unicode-compliant" into a tender did not yet guarantee a usable system.

The documents that enforced it

The period that turned policy into paper runs roughly from 2002 to 2012. The Government of India's National Language Technology Mission, and later the Technology Development for Indian Languages (TDIL) programme under the Ministry of Electronics and Information Technology (then called the Department of Information Technology), produced specifications and funded tools. TDIL's published localization standards for government websites — mandating Unicode encoding and specifying font formats — are the clearest example of a requirement that tenders could cite rather than derive themselves.

Kerala moved earliest among the states. The IT@School project, which began deploying computers into government schools in the early 2000s and later moved to GNU/Linux-based systems, included Malayalam interface requirements in its procurement scope. The project worked with the Unicode Malayalam block and required that the operating system and applications display Malayalam correctly — a shaping requirement embedded in what was formally a hardware-and-software supply tender. The IT@School project is still the documented case that procurement specialists cite when they want an example of script compliance specified at point of purchase rather than retrofitted afterward.

Tamil Nadu followed a comparable path through its ELCOT (Electronics Corporation of Tamil Nadu) procurement framework. ELCOT managed state-level bulk purchasing of computers for government offices and schools, and its tender documents through the mid-2000s progressively tightened the language around Tamil script display. The Tamil99 keyboard layout — standardised by the Tamil Nadu government and registered as an Indian Standard — was eventually written into interface requirements, which meant that any software bid had to demonstrate a conforming input method, not merely claim Unicode support.

C-DAC's BOSS (Bharat Operating System Solutions), built in Chennai and documented as a localised Linux distribution with Indic support as its stated purpose, entered state procurement in this period. BOSS's significance in the procurement record is that it gave evaluating officers a reference implementation: a system known to handle conjuncts, matras, and the right shaping behaviour for the scheduled languages. When a state tender specified BOSS compatibility or used BOSS as the evaluation benchmark, it was — whether the drafting officer knew it or not — writing a shaping requirement into the contract.

The foundational layer was ISCII — the Indian Script Code for Information Interchange, published by the Bureau of Indian Standards as IS 13194 in 1988 and revised in 1991.

What the papers actually said

Reading the tender documents from this period is instructive in a specific way: the gap between what the standard required and what the language of the tender specified. Early documents say "support for Indian languages" without defining which languages, which encoding, or which shaping model. Later documents say "Unicode 4.0 or later, with OpenType shaping for the scripts listed in Schedule VIII of the Constitution" — a formulation that is technically precise and cross-references a real legal instrument. That evolution is visible in the archived tender notices from state IT departments, digitised and held by India's National Informatics Centre, though the archive is uneven and coverage before 2005 is sparse.

The Unicode Consortium's own conformance framework — the Unicode Standard's definition of what a conforming implementation must and must not do — gave procurement officers external authority to cite. A tender could say "the system shall conform to the Unicode Standard, version current at date of contract," and that sentence imported the Consortium's shaping requirements by reference. Whether evaluators were equipped to test conformance is a different question, and the answer for most of the 2000s was no. Testing Indic shaping requires a test suite and a reviewer who can read the script; the procurement infrastructure to do that systematically did not exist in most state IT departments.

What did exist, and what the record shows working, was a quieter mechanism: the reference installation. A state government would deploy a known-good system — often through a C-DAC technical assistance arrangement — and then use that installation as the conformance benchmark against which subsequent bids were evaluated. It is not the most rigorous procurement methodology, but it moved shaping requirements into contracts at a moment when formal test suites were not available. The Unicode Standard's discussion of Indic script rendering has grown substantially more precise with each version, and later procurement documents could and did cite specific chapters.

By the time the National Policy on Open Standards for e-Governance was notified in 2010, the basic requirement — Unicode encoding, OpenType shaping, named script blocks — was legible to any competent drafter. The policy did not create the requirement; it named and standardised what years of state-level procurement experiments had already established by practice. The standard had been written into the purchase order. It just took a decade to learn how.