← Blog

The Story of Telugu in Unicode: From ISCII to Modern Encoding

The Telugu script has been in continuous use for well over a thousand years, evolving from early Brahmi inscriptions into the graceful, rounded script used by over 80 million people today. But its journey into the digital world — from typed text on early Indian computers to seamless rendering on modern smartphones — is a story of competing standards, political decisions, and eventual international consensus.

The Pre-Unicode Era: ISCII and Font Hacking

Before Unicode became the global standard, India developed its own approach to encoding the country's many scripts. The Indian Script Code for Information Interchange (ISCII), standardised in 1988 and updated in 1991, was designed to cover all major Indian scripts using a single 8-bit encoding. ISCII recognised a crucial structural similarity: Devanagari, Telugu, Kannada, Tamil, Malayalam, and the other major scripts of India all descend from Brahmi and share many organisational principles.

ISCII worked reasonably well for software applications designed with it in mind, but it never achieved widespread adoption in practice. The dominant reality on the ground was something far more chaotic: every major font vendor developed their own proprietary encoding, mapping script characters to whatever ASCII byte positions they chose. There was no coordination and no compatibility between vendors.

In Telugu specifically, companies like Anu Information Technologies, Eenadu (the newspaper group), and others each created their own font-and-encoding systems. These fonts were not "Telugu fonts" in any interoperable sense — they were Latin character sets where every glyph had been swapped out for a Telugu shape. A document typed in Anufonts could not be read by software expecting Eenadu fonts, and vice versa.

Unicode Arrives: The Telugu Block

Unicode 1.0, released in 1991, included a Telugu block occupying code points U+0C00 through U+0C7F. This block was designed following the ISCII structure — not because ISCII was the best possible design, but because it provided a ready-made framework that had already been ratified by Indian standards bodies.

The Unicode Telugu block encodes characters at the phonemic level rather than the glyph level. This is a critical distinction. The consonant "క" is a single code point (U+0C15) regardless of how it is visually rendered — whether standalone, with a vowel sign, as part of a conjunct, or with a halant. The actual visual rendering is left to the font and the text shaping engine.

Over subsequent Unicode versions, the Telugu block was refined. New characters were added to cover older literary forms, Vedic signs, and characters used in related but distinct regional traditions. The block was extended, and character properties were clarified in response to feedback from linguists and software implementors.

The Text Shaping Problem

Encoding Telugu characters in Unicode was only the first step. The much harder problem was text shaping — the process of converting a sequence of Unicode code points into the correct sequence of rendered glyphs for display or print.

Telugu shaping is complex for several reasons:

• Pre-base matras: Several vowel signs — including the commonly-used short "i" (ి) — are stored after their base consonant in Unicode but must visually appear before it. A shaping engine must reorder them.
• Conjuncts: When a consonant is followed by a halant (virama, ్) and another consonant, the pair forms a conjunct cluster. The visual form may be a completely different, pre-composed glyph, or it may use a "vattu" form stacked below or beside the first consonant.
• Nukta and special forms: Some consonants have alternate forms triggered by the Unicode Nukta character or by specific sequence rules.
• Dependent vowel splitting: Vowel signs like "ో" visually surround the base consonant (part before, part after), requiring careful glyph sequencing.

Early Unicode Telugu rendering was poor because text shaping engines did not handle these rules correctly. Windows XP (2001) brought significantly improved Indic text shaping through Uniscribe, and subsequent advances in HarfBuzz (the open-source shaping engine now used in most applications and browsers) have made high-quality Telugu rendering universal on modern systems.

Why Legacy Fonts Persisted

Despite Unicode's superiority as a standard, Anufonts and similar legacy encodings remained deeply embedded in Telugu print workflows for a straightforward economic reason: the existing tools worked. Print shops had trained operators, existing templates, compatible printing equipment, and years of archived work — all in the legacy encoding format.

Transitioning to Unicode-native workflows requires retraining staff, replacing or upgrading software, and potentially reformatting existing archives. For a small print shop running on thin margins, the short-term cost of transition outweighs the long-term benefits of standardisation.

Additionally, Anufonts offered some practical advantages in early DTP work. Because the glyphs were mapped to simple ASCII bytes, Anufonts text could be processed by any software that handled ASCII — no special Indic-aware rendering was needed. This made Anufonts paradoxically more compatible with older software than Unicode Telugu text would have been.

The Current State: Coexistence

Today, Telugu on the web and in modern applications is overwhelmingly Unicode. Noto Serif Telugu, Mandali, Ramabhadra, and other open-source Unicode Telugu fonts provide excellent quality at no cost. Android and iOS render Telugu natively. Google Search, social media platforms, and news websites all operate in Unicode.

But in print DTP — particularly in the newspaper industry, advertising, and commercial printing across Andhra Pradesh and Telangana — Anufonts remains the working standard for a significant portion of the market. This creates the conversion need that tools like AksharaTool address: bridging the Unicode content world with the legacy Anufonts production environment.

The long-term trajectory is clear. As operators retire and software is updated, Unicode-native workflows will gradually replace legacy encoding systems. But that transition will take years, and during that period, reliable conversion tools are genuinely necessary for the people doing this work every day.