Unicode to Limon — Khmer Legacy Font Converter

About this tool

Most Khmer users today work in Unicode — it is the encoding phones, browsers and modern design tools render correctly. But a real slice of professional work in Cambodia still runs on legacy Khmer fonts: print shops typesetting in Adobe InDesign CS6, sign cutters whose software only reads Limon bytes, government templates authored in Khek, publishers reprinting pre-2010 books laid out in ABC-Zwsp. Those workflows cannot open a Unicode file at all — they need the text as legacy bytes. This Unicode to Khmer legacy font converter bridges that gap: paste your modern Khmer text, pick Limon, ABC-Zwsp or Khek, and copy the encoded output or download it as a Windows-1252 .txt file the legacy tool can import. A Unicode to Limon conversion, a Unicode to Khek conversion and a Unicode to ABC-Zwsp conversion are three different byte outputs from the same input — the Khmer legacy font converter applies the exact table for whichever target you select, so the file you hand to the print shop draws correctly in their font. One honest note before you start: the output looks like gibberish Latin characters until it is opened inside the matching legacy font — that is normal, it is exactly how the legacy encoding works, not a bug.

How it works

Pressing Convert runs convertUnicodeToLegacy from lib/khmer-legacy-converter/converter.ts in your browser, under the encoding you picked — there is no auto-detect here because the input is already Unicode and the question is which table to emit, not which to decode. Each Unicode Khmer codepoint has a mapped byte in the target table, but the pass cannot simply swap one for one: Khmer subscripts are two codepoints in Unicode — U+17D2 (coeng) followed by a base consonant — while the legacy font stores the subscript as a single byte drawn below its base. The converter therefore reorders every cluster into the font's visual order first (reorder.ts: legacyReorder, which also inserts U+17EA position marks the emission pass consumes), so when it meets U+17D2 it looks ahead, consumes the following consonant codepoint, and emits the one subscript byte — this is where naïve implementations silently lose characters. Anything without a table entry passes through unchanged and is counted in the unmapped chip; spacing and line breaks pass through untouched. Inputs over 10 KB convert inside a Web Worker; smaller text runs on the main thread, entirely client-side — only size counters ever appear in anonymous telemetry. The output renders correctly only inside the matching legacy font, which is why the download writes literal Windows-1252 bytes rather than UTF-8.

Use cases

• A designer preparing a leaflet in Adobe InDesign CS6 where the Khmer font is Limon-only and the copy was written in modern Unicode.
• A print shop producing a wedding invitation on a legacy workflow that still runs on Limon fonts.
• A government officer formatting a document in an older template that requires Khek-encoded text to render on an unreplaced legacy printer.
• A publisher reissuing a classic Khmer book whose typesetting is in ABC-Zwsp and whose new material was written in Unicode.
• A software developer generating fallback Limon exports for users on older Windows systems without a Unicode Khmer font installed.
• A signwriter whose cutting software only accepts Limon byte input.
• An archivist preparing a legacy-font facsimile of a Unicode document for a publication that must match an original 1990s edition.

Verified conversion examples

Frequently asked questions

• When do I need Unicode to Limon instead of the other way?

  When the receiving side runs on Limon: a print shop typesetting in Adobe InDesign or Publisher with the Limon font, sign-cutting software that only accepts Limon bytes, or a template someone built in the Limon era. If their application shows your Unicode text as Latin gibberish, this is the direction you need — it produces the bytes their font understands.

• How do I open the Limon output?

  Inside any application with the Limon font installed — InDesign, Publisher, Word or the sign cutter the file is meant for. The download button writes a Windows-1252 .txt file carrying the literal byte values, so the target application reads it exactly like text typed there directly. Viewed anywhere else, the output correctly looks like Latin gibberish.

• Why does the Limon download come as .txt and not .docx?

  Because the encoding is raw bytes, not a document format — a .docx would re-encode those bytes as UTF-8 and corrupt them for the legacy font. The .txt file preserves the exact byte values the receiving application expects; you import or paste it into the Limon document where the font is already assigned.

• Will subscript Khmer letters come out right in Limon?

  Yes — the converter reorders each Unicode cluster into Limon visual order before emitting bytes, so a two-codepoint subscript (U+17D2 plus its base consonant) becomes the single subscript byte the font draws below the base. The only exceptions are structures the Limon font itself never represented faithfully, which the unmapped chip reports.

Data and accuracy

Content last reviewed 8 November 2026