The school deployments

The policy layer that made it possible

Indian school computing programmes do not arise from individual teachers choosing software; they arise from state-level policy, central-government scheme funding, and the procurement rules that follow. The programme that created most of the footprint is the Information and Communication Technology (ICT) scheme under the Ministry of Education — formerly run under the Sarva Shiksha Abhiyan umbrella and later consolidated under Samagra Shiksha. Under that scheme, states submit project proposals, receive central and matching state funds, and then issue tenders specifying hardware, operating system, and language requirements. The resulting contracts are public documents, and they carry precise version numbers, font lists, and localisation mandates — which is why school computing is the most legible part of India's Linux deployment history.

The funding model matters for the technical record because it pushed states to justify every line of a specification. A state that wanted to mandate a particular distribution had to write a rationale into its project approval, and that rationale survives in planning commission documents, state IT department circulars, and tender notices published in official gazettes. Kerala, Tamil Nadu, and several other states produced specifications detailed enough that the font and input method requirements can be read directly off the procurement document rather than inferred from the installed base.

Kerala: the IT@School architecture

Kerala's IT@School project is the most extensively documented school Linux deployment in the country. The project began deploying Linux-based systems into government high schools from the early 2000s, and by the middle of the following decade it had covered the overwhelming majority of the state's government and aided secondary schools. The distribution it developed — originally based on Debian and later producing its own derivative — shipped with Malayalam font and input-method configuration as a first-class requirement, not an afterthought. The Malayalam rendering stack at that time required careful attention to the shaping engine: Malayalam conjuncts are numerous and the script's reformed and traditional orthographies differ substantially in the conjunct set they require, which meant that the font bundled with the deployment had to be specified by name and version in the procurement document to guarantee that what a student saw matched what the curriculum materials expected.

IT@School published its own content in Malayalam, which in turn forced the project to confront code-point-level decisions that a purely English-language deployment never faces. A worksheet rendered through one version of a shaping engine could reflow or produce incorrect conjuncts through another; the project's technical team worked with C-DAC and with upstream font developers to fix shaping bugs and contributed those fixes back through the normal channels. Because school content had to be authored, printed, and displayed consistently, the Malayalam Unicode block and the behaviour of the shaping layer — the software that converts a sequence of code points into positioned glyphs — received more real-world testing in Kerala classrooms than in almost any other single deployment context.

The procurement documents from IT@School's expansion phases specified not only the operating system but the version of the OpenType shaping engine, the minimum glyph coverage for the bundled Malayalam font, and the input method to be pre-configured. That level of specification is unusual in government contracts and reflects the project's internal technical capacity, which grew over the course of the deployment into a team capable of maintaining a distribution fork, filing upstream bug reports, and training teachers in the state's own language.

Tamil Nadu and the question of which standard

Tamil Nadu's school computing programme took a different path through the same policy framework. The state's IT deployments in schools ran partly through ELCOT, the Electronics Corporation of Tamil Nadu, which acted as the procurement agency and published tender specifications. Tamil script has a large character set — the Unicode Tamil block encodes the full set of vowel signs, or matras, plus the Grantha letters used for Sanskrit loanwords — and the font requirements in Tamil Nadu's school tenders reflect that complexity. Early tender documents specified fonts by name and required that they carry the full Tamil block as defined by the Unicode Consortium, a requirement that ruled out several widely distributed fonts that were missing Grantha coverage.

The Tamil computing environment also carried the legacy of ISCII, the eight-bit standard developed through the Bureau of Indian Standards in the 1980s that placed ten Brahmi-derived scripts on one code table. Tamil's relationship with that table was complicated: Tamil does not use aspirated consonants or the full set of vowel distinctions that ISCII inherited from Devanagari, so the mapping between ISCII Tamil and Unicode Tamil involves positions that are simply absent or repurposed. State-level procurement in the Unicode era had to specify unambiguously that the Unicode encoding was required — that older ISCII-encoded content in legacy fonts not be treated as equivalent — and the Tamil Nadu school tender language eventually reflected that distinction explicitly.

The funding model matters for the technical record because it pushed states to justify every line of a specification.

Pune and the national picture

Pune's role in school deployments is less a single project and more an infrastructure node. C-DAC's headquarters there produced BOSS — Bharat Operating System Solutions — the distribution built at C-DAC that was among the options available to states writing national-scheme project proposals. BOSS was engineered with Indic localisation as a core requirement rather than an optional locale package, which meant that its font and input-method defaults were set for Indian-language use from installation. States that specified BOSS in their tender documents were, in effect, inheriting C-DAC's decisions about which Unicode code points to support, which OpenType shaping behaviour to require from the font stack, and which input method framework to pre-configure.

The National Mission on Education through ICT, which ran in parallel with the school hardware scheme, also funded digital content production, and much of that content had to be rendered in Devanagari and other scripts on whatever distribution a state had deployed. The interaction between centrally produced content and state-deployed rendering stacks exposed shaping incompatibilities that were, in the end, resolved at the font and engine level rather than through re-encoding the content — a technically correct outcome that nonetheless required coordination between C-DAC in Pune, state IT departments, and upstream communities.

What the contracts establish

The practical consequence of reading school procurement documents alongside font and shaping history is that the deployment record becomes traceable. A tender notice from a Kerala expansion phase names a font version; that version corresponds to a specific point in the font's development history when a particular conjunct-formation bug was fixed; that bug fix corresponds to a commit with a date and an author. The school lab is the end of a chain that begins with a Unicode code-point assignment and runs through a shaping-engine specification, a font binary, a distribution package, a state tender, a purchase order, and a delivery receipt.

The millions of students who used these machines were not the audience for any of that documentation, and they were not expected to be. But the documentation exists, it is specific, and it establishes that the rendering choices visible in those classrooms were not defaults inherited from an upstream distribution but deliberate decisions made in government offices and encoded into contracts — decisions whose technical consequences are still visible in the Indic font ecosystem today.