Accuracy and supported formats

Want to understand how these numbers are produced? Read the testing methodology. It explains profile identification, source/licence checks, differential references, round-trip testing, fuzzing and live browser QA.

Kruti Dev 010 ↔ Unicode Devanagari

The Kruti Dev engine is built specifically for Kruti Dev 010 and Unicode Devanagari, including matras, half forms, conjuncts, reph, nukta characters, digits, punctuation and long text blocks.

• 15,980 / 15,980 real Hindi words passed canonical Unicode → Kruti Dev → Unicode round trips.
• 89,760 / 89,760 structured Devanagari cases covering consonant-vowel forms, reph and conjunct patterns passed.
• 2,124 / 2,124 public Hindi UI/document strings passed mixed-text preservation checks.
• 20,000 / 20,000 deterministic mixed Hindi/English/symbol fuzz cases passed.
• A live-browser round trip with approximately 120,000 characters completed without meaningful text loss.

DevLys 010 ↔ Unicode Devanagari

DevLys 010 is exposed as a separate user-facing profile but reuses the already validated 010 Devanagari conversion core. Independent DevLys 010 references were used to verify that this profile follows the same legacy character positions as the supported Kruti Dev 010 mapping; no DevLys font binary is bundled.

• 8 / 8 DevLys 010 profile reference vectors passed legacy → Unicode checks.
• Common reph, matra, conjunct, nukta and reverse-conversion samples passed DevLys 010 round trips.
• The shared 010 engine retains its 15,980 / 15,980 real-word and 89,760 / 89,760 structured Devanagari validation coverage.
• A DevLys-labelled 120,000-character mixed-text round trip completed without truncation.

Bamini ↔ Unicode Tamil

The Bamini engine uses a separately researched Tamil mapping and accepts regular Bamini layout sequences plus documented historical aliases. It is not derived from the Kruti Dev converter.

• 63,896 / 63,896 words from a public Tamil dictionary corpus passed Unicode → Bamini → Unicode round-trip validation.
• 300 / 300 canonical Bamini mapping entries passed individual round-trip checks.
• 286 / 286 structured Tamil consonant-vowel forms passed canonical round-trip checks.
• Published Bamini reference text such as mwKk; murpaYk; converts to அறமும் அரசியலும் and back exactly.

SunTommy ↔ Unicode Tamil

The SunTommy engine uses the MIT-licensed SunTommy table from the same public Tamil font-converter project used as a primary Bamini reference, but SunTommy is implemented as its own profile. Current Azhagi documentation independently lists SunTommy as a distinct supported non-Unicode Tamil encoding.

• 298 / 301 published source aliases decode to their stated Unicode form. The remaining three aliases are all the same historically overloaded bare * token; forward conversion intentionally resolves it to the source-order canonical ழூ.
• 286 / 286 structured Tamil consonant-vowel forms were data-preserving; 283 were safely representable as SunTommy legacy text and 3 used Unicode-preservation fallback.
• 89,401 / 89,401 ordered pairs of the 299 source mapping entries were data-preserving in recommended mode. 27 pairs required an invisible compatibility boundary to prevent token merging.
• 20,000 / 20,000 deterministic mixed Tamil/English/symbol cases passed, plus a 120,000-character mixed-text round trip and 5,000 / 5,000 malformed legacy stability cases.

Nudi ↔ Unicode Kannada

The Nudi engine follows the documented Kannada ASCII/Nudi-Baraha mapping and conversion rules published by Kannada Ganaka Parishat (KAGAPA), with separate reverse-conversion and preservation logic for browser use.

• 95 / 95 published KAGAPA ASCII → Unicode reference cases passed.
• 9 / 9 published KAGAPA Unicode → ASCII reference cases passed.
• 685 / 685 canonical reverse-mapping entries passed recommended Unicode → Nudi → Unicode round trips.
• 469,225 / 469,225 ordered pairs of canonical mapping atoms passed recommended-mode round-trip stress testing.
• 20,000 / 20,000 deterministic mixed Kannada/English/symbol fuzz cases passed.
• A deterministic mixed-text round trip with 120,000 characters completed without truncation or content loss.

Chanakya ↔ Unicode Devanagari

The Chanakya engine targets the common legacy Chanakya profile. Its primary mapping basis is an ISC-declared public bidirectional implementation, with independent public references used for differential checks and variant separation.

• 10 / 10 common public reference examples passed legacy → Unicode checks.
• 201 / 201 validated canonical reverse-mapping atoms passed Unicode → Chanakya → Unicode round trips.
• 4,576 / 4,576 consonant-vowel and reph consonant-vowel forms passed strict legacy round trips.
• 75,504 / 75,504 two-consonant structured cases and 6,600 / 6,600 deterministic three-consonant cases were data-preserving in recommended mode.
• 20,000 / 20,000 deterministic mixed Hindi/English/symbol cases passed, plus a 120,000-character mixed-text round trip without truncation.

Walkman-Chanakya 905 ↔ Unicode Devanagari

The Walkman-Chanakya tool targets the SIL-documented W-C-905 profile, separate from common Chanakya and Walkman-Chanakya 901. The primary mapping is MIT-licensed and an independent BSD-licensed implementation was used to cross-check byte mapping and reorder behavior.

• 15 / 15 SIL/BSD reference vectors passed legacy → Unicode checks.
• 2,992 / 2,992 base consonant-vowel and reph forms were data-preserving in recommended mode.
• 12,716 / 12,716 two-consonant structured forms were data-preserving in recommended mode.
• 20,000 / 20,000 deterministic mixed Hindi/English/symbol fuzz cases passed.
• A 120,000-character mixed-text round trip completed without truncation, and 5,000 / 5,000 malformed legacy fuzz inputs completed without a crash.

Shusha v1.0 ↔ Unicode Devanagari

The Shusha engine targets the exact SIL-documented Shusha v1.0 profile. Its forward JavaScript port mirrors the multi-pass TECkit map and was differential-tested against SIL's compiled converter. The reverse path is conservative: it emits only legacy sequences that the same verified forward engine converts back to the original Unicode exactly.

• 256 / 256 possible single legacy bytes matched the official SIL TECkit forward output exactly.
• 65,536 / 65,536 possible two-byte legacy sequences matched the official TECkit forward output exactly.
• 20,000 / 20,000 deterministic longer legacy byte strings matched the official TECkit forward output exactly.
• 3,264 / 3,264 structured consonant-vowel and reph forms were data-preserving and represented by verified Shusha legacy sequences.
• 13,872 / 13,872 two-consonant structured forms were data-preserving and represented by verified Shusha legacy sequences.
• 20,000 / 20,000 deterministic mixed Devanagari/English/symbol cases passed, plus a 120,000-character mixed-text round trip and 5,000 / 5,000 malformed legacy stability cases.

Preeti v0.1 ↔ Unicode Devanagari

The Preeti engine targets the exact SIL-documented SAG-Preeti / Preeti Devanagari v0.1 profile. Its forward JavaScript port mirrors the multi-pass TECkit map. The reverse path is conservative: it emits a legacy sequence only when the same verified forward engine converts it back to the original Unicode exactly.

• 256 / 256 possible single legacy bytes matched the SIL TECkit forward oracle exactly.
• 65,536 / 65,536 possible two-byte legacy sequences matched the SIL TECkit forward oracle exactly.
• 20,000 / 20,000 deterministic longer legacy byte strings matched the SIL TECkit forward oracle exactly.
• 3,264 / 3,264 structured consonant-vowel and reph forms were data-preserving; 3,036 were strict Preeti-representable and 228 used Unicode-preservation fallback.
• 13,872 / 13,872 two-consonant structured forms were data-preserving; 13,035 were strict Preeti-representable and 837 used fallback.
• 20,000 / 20,000 deterministic mixed Devanagari/English/symbol cases passed, plus a 120,000-character mixed-text round trip and 5,000 / 5,000 malformed legacy stability cases.

GujaratiLS v1.0 ↔ Unicode Gujarati

The Gujarati tool targets the exact SIL-documented GujaratiLS v1.0 profile. The forward engine was differential-tested against the official compiled TECkit converter, while the reverse engine emits only sequences that reproduce the original Unicode exactly; otherwise recommended mode keeps that Gujarati run as Unicode.

• 256 / 256 possible single legacy bytes matched the official SIL TECkit converter exactly.
• 65,536 / 65,536 possible two-byte legacy sequences matched the official TECkit converter exactly.
• 20,000 / 20,000 deterministic longer legacy byte strings matched the official TECkit forward output exactly.
• 3,536 / 3,536 consonant-vowel and reph forms were data-preserving; 1,584 were representable as verified GujaratiLS legacy sequences and 1,952 used Unicode-preservation fallback.
• 15,028 / 15,028 two-consonant structured forms were data-preserving; 8,592 were representable as verified legacy sequences and 6,436 used Unicode-preservation fallback.
• 20,000 / 20,000 deterministic mixed Gujarati/English/symbol fuzz cases passed. 1,387 of those cases used at least one preservation fallback.
• A 120,000-character mixed-text round trip completed without truncation, and 5,000 / 5,000 malformed legacy fuzz inputs completed without a crash.

ANU Telugu / AnupamaMedium v1.00 ↔ Unicode Telugu

The ANU Telugu engine targets the SIL-documented “Telegu Anu” / AnupamaMedium v1.00 profile. The forward JavaScript port was differential-tested against SIL's compiled TECkit converter; the reverse path emits a legacy sequence only when the forward engine reproduces the original Unicode exactly.

• 65,536 / 65,536 possible two-byte legacy sequences matched the official SIL TECkit forward output exactly.
• 20,000 / 20,000 deterministic longer legacy byte strings matched the official TECkit forward output exactly.
• 980 / 980 structured base/reph forms were data-preserving; 964 were strict legacy-representable and 16 used Unicode-preservation fallback.
• 17,150 / 17,150 two-consonant structured forms were data-preserving; 16,636 were strict legacy-representable and 514 used fallback.
• 20,000 / 20,000 mixed Telugu/English/symbol fuzz cases passed, plus a 120,000-character mixed-text round trip and 5,000 / 5,000 malformed-input stability cases.

How conversion is checked

The engines are checked against permissively licensed mapping references, independent public implementations, public examples and regression suites. Difficult ordering and ambiguity cases are kept as permanent regression tests so later changes do not silently break known behavior.

Known limitations

Legacy font encodings reuse ordinary Latin character positions. English words embedded inside legacy text can therefore be inherently ambiguous when the original document formatting is unavailable. URLs and email addresses receive extra protection, and the Unicode → legacy tools provide a recommended preservation mode for mixed modern text.

Some historical Bamini tables overload the bare * character for several rare forms. A bare * in external Bamini text cannot always be disambiguated from characters alone. IndicConverter uses an unambiguous canonical sequence when generating those rare forms and warns when an overloaded bare * is detected on Bamini input.

Recommended Unicode → Bamini mode also inserts an invisible compatibility boundary only when adjacent valid Bamini tokens would otherwise merge into a different legacy token. This keeps IndicConverter round trips lossless for those edge cases. Strict legacy mode omits the boundary for workflows that require only traditional Bamini character positions.

SunTommy has its own mapping profile. Its published table overloads bare * for ழூ, ஞூ, ஞு and ஙு. IndicConverter follows the source-order forward interpretation for external bare *, emits * only for ழூ on reverse conversion, and preserves the other unsafe rare forms as Unicode. Recommended mode also inserts compatibility boundaries where adjacent valid SunTommy tokens would otherwise merge.

Some Unicode text can also have more than one canonically equivalent internal representation. A round trip may normalize code-point ordering while preserving the same text.

Kruti Dev variants are not interchangeable. The Hindi tool is labelled for Kruti Dev 010; unsupported variants may produce different results.

The DevLys tool is scoped to DevLys 010. DevLys 020, 030 and other family variants are not assumed byte-compatible with the 010 profile.

Nudi and other Kannada legacy workflows can also contain version-specific or customized mappings. The Kannada tool follows the documented KAGAPA Nudi/Baraha-style mapping and does not claim universal compatibility with every legacy Kannada font.

The Chanakya tool targets the common profile only. Walkman-Chanakya 905 now has its own W-C-905 converter; Walkman-Chanakya 901 remains outside the supported profiles.

Recommended Unicode → Walkman-Chanakya 905 mode can retain a rare unsupported Unicode run instead of silently mutating it. Such retained text is data-preserving but is not claimed to be strict W-C-905 legacy bytes.

The Shusha converter is scoped to Shusha v1.0. It does not assume every customized Shusha-family font is byte-compatible. A reverse sequence is emitted only when the verified Shusha v1.0 forward engine reproduces the original Unicode exactly; otherwise recommended mode keeps that Devanagari run as Unicode instead of silently changing it.

The Preeti converter is scoped to the exact SAG-Preeti / Preeti Devanagari v0.1 profile. SIL notes that this historical map is not completely reversible: some sequences canonicalize to equivalent conjunct or stack forms. A reverse legacy sequence is emitted only when the verified forward engine reproduces the original Unicode exactly; otherwise recommended mode keeps that Devanagari run as Unicode.

The Gujarati converter is scoped to GujaratiLS v1.0. Harikrishna, Gopika, LMG, Sulekh and other Gujarati legacy families are not assumed compatible. When Unicode → GujaratiLS encounters a Gujarati sequence with no verified v1.0 representation, recommended mode keeps that run as Unicode; a data-preserving fallback is not counted as strict legacy coverage.

The ANU Telugu converter is scoped to SIL's “Telegu Anu” / AnupamaMedium v1.00 profile. It is not a universal ANU Script Manager converter. Other ANU-family fonts or Priyanka/Anupama variants may use different glyph mappings. Unsupported Telugu runs can remain Unicode in recommended reverse mode rather than being silently corrupted.

For important official, legal, academic, publishing or archival material, proofread the converted result against the source document.

Reference basis

Conversion logic is based on documented or permissively licensed mapping resources and cross-checked against independent public references. IndicConverter does not need to bundle proprietary font binaries for text conversion.