CGLTyping
Unicode to Kruti Dev Converter
Going the other direction — turning real Hindi Unicode text into Kruti Dev-compatible output for older systems that still expect it.
🚧 The interactive converter isn't live yet
Same reasoning as the reverse direction: getting the matra-reordering and conjunct logic wrong would silently produce incorrect output. We're being deliberate about testing this properly before publishing it as a tool people can rely on. This page explains how it works conceptually in the meantime.
On This Page
Why You'd Go From Unicode to Kruti Dev
This is the less common direction, but it does come up — usually when you have real Hindi Unicode text (typed on a modern system, or copied from somewhere digital) that needs to feed into an older system, printer, or document template built specifically around Kruti Dev, which can't correctly interpret standard Unicode Devanagari input. Some government departments and legacy publishing workflows still work this way.
Why It's Not Just the Reverse Font Trick Either
The same logic that makes Kruti Dev → Unicode require real character mapping applies here in reverse: you can't just apply the Kruti Dev font to Unicode Hindi text and expect it to display correctly, because Unicode Devanagari and Kruti Dev's Latin-range codes aren't the same underlying data. A real converter has to read the actual Unicode Devanagari characters, work out how Kruti Dev would represent the same visual result (including the matra reversal in the opposite direction from before), and output the correct Kruti Dev-compatible character sequence.
Where the Complexity Lives
- Matra reordering — matras stored in normal (post-consonant) order in Unicode need to be reordered to Kruti Dev's pre-consonant typing convention for certain vowel signs.
- Conjunct decomposition — Unicode conjuncts (formed via virama/halant sequences) need to map to Kruti Dev's specific half-consonant key sequences, which don't always follow an obvious one-to-one pattern.
- Character coverage — not every Unicode Devanagari character necessarily has a clean Kruti Dev equivalent, which the conversion needs to handle gracefully rather than silently dropping or mismapping.
What You Can Do in the Meantime
- If you're producing new content and have a choice, prefer keeping it in Unicode where possible — it's more broadly compatible, searchable and future-proof than Kruti Dev.
- See the Kruti Dev to Unicode Converter page for the other direction and the shared reasoning behind why both are being built carefully rather than quickly.
- See the main Kruti Dev Hindi Typing guide for the full picture of what's live now versus pending.
Frequently Asked Questions
Some older government systems, printers, or document templates were built specifically around Kruti Dev and can't correctly handle Unicode Devanagari input, so content sometimes needs to go the "backward" direction into Kruti Dev format.
Conceptually similar in complexity — both directions require the same matra-reordering and conjunct-mapping logic, just applied in reverse. Neither direction is meaningfully easier to get right.
A correct converter should produce output that renders identically once the Kruti Dev font is applied, since it's targeting the same character codes a direct Kruti Dev typist would produce.
Not yet — see the main Kruti Dev Hindi Typing guide for why we're being deliberate about shipping conversion tools only once they're properly tested.
