Khmer script breaks your design tools
A practical account of setting Cambodian type in software that was never built for it.
By Sovandarapor (James) Kong · · Craft
Set a line of Khmer in most professional design software and something quietly goes wrong. Not everywhere. Not obviously. A subscript consonant renders as a small plus sign, or a floating box, or it detaches and sits beside the letter it belongs under instead of beneath it.
If you do not read Khmer, you will not notice. The line looks like Khmer. It has the right density and rhythm. It is simply, in places, not words.
Why it happens
Khmer is not a script where letters sit in a row. Consonants stack. A subscript form tucks under the character before it, vowels attach above, below, before and after the consonant they modify, and the correct visual result depends on rules the software has to apply, not just glyphs it has to place.
Latin typesetting is mostly a matter of putting shapes next to each other with the right gaps. Khmer typesetting is a computation. If the layout engine in your software is not running the right one, you get shapes next to each other — which is exactly the wrong answer, rendered confidently.
In Adobe tools specifically, this comes down to which composer the text frame is using. The default one does not do complex script shaping. There is a world composer that does. Switching it is a single setting, and until you switch it, everything you export is subtly broken.
The software will not warn you. It has no idea it is producing nonsense. It thinks it drew the glyphs you asked for, and technically it did.
The three places it bites
First, at design time. You type or paste a Khmer string, it renders wrong, and you spend an hour assuming the font is broken when the font is fine.
Second, at handoff. The file opens on another machine, without your fonts, and the substitution collapses the stacking. This one is vicious because the file was correct when you sent it.
Third, and worst, at print. You outline the type to make the file printer-safe. Outlining freezes whatever was on screen into vector shapes. If it was wrong on screen, it is now permanently, unfixably wrong, and it is going to plate.
The working discipline
Set the composer correctly before typing a single character, not after.
Get the text from the client as text, not as a screenshot. A screenshot of Khmer is a picture of a decision you cannot verify.
Before outlining, have a Khmer reader check the artwork. Not skim it. Read it aloud. Reading aloud catches stacking errors that the eye passes over.
After outlining, check again against the original text, character by character. This feels excessive. It is not. The outlined file is the only file the printer sees, and it is the last moment the error is free to fix.
Keep both versions. Live text for editing, outlined for output, never overwrite one with the other.
What this is really about
It would be easy to file this under technical trivia. I think it is something else.
Design tools encode assumptions about whose language matters. Latin script gets decades of refinement, hinting, kerning tables, and a support ecosystem. Khmer gets a checkbox in a dialog you have to know exists, and a default setting that produces broken output.
The practical consequence is that a huge amount of Khmer-language packaging in this market carries small typographic errors. Not because anyone was careless. Because the tools shipped with the wrong default and nobody told the person using them.
Getting it right is not a flourish or a nicety. It is the difference between a bag somebody can read and a bag that is using their alphabet as a texture.