Research

Toward Better Khmer OCR with Adaptive Orthographic Unit CTC

A review of Khmer OCR research and a proposed script-aware recognition architecture built around Khmer orthographic units, mixed-script decoding, and CTC alignment.

Mixed Khmer and Latin text flowing from a scanned line through visual features into script-aware orthographic units.
AOU-CTC recognizes Khmer clusters, Latin characters, digits, and symbols at useful visual granularities while keeping open-ended word segmentation downstream.

I started working on this architecture after seeing a failure that model-level accuracy alone does not capture. A scanned Khmer page could look correctly recognized in the review interface, yet the exported PDF still behaved badly: selection covered an entire line, search highlights did not follow the visible text, and copied Khmer could lose the intended sequence. On mixed product documents, the same recognizer also had to move between Khmer, Latin names, numbers, punctuation, and units inside one line.

That made the problem larger than predicting a transcription. The recognizer needed useful units, confidence, and alignment that could survive review and document reconstruction.

Khmer optical character recognition has improved substantially, but recognizing Khmer text is still not the same problem as recognizing a sequence of Latin letters.

A Khmer line can contain consonants, dependent vowels, diacritics, coeng sequences, digits, punctuation, Latin abbreviations, measurements, and product names. What appears to a reader as one orthographic unit may be encoded as several Unicode code points and rendered through complex shaping. Spaces are not reliable word boundaries, and a modern document may switch scripts several times in a single line.

These properties affect more than model accuracy. They influence how training labels should be constructed, how errors should be measured, how confidence should be assigned, and whether recognized text can later be searched, selected, corrected, and copied without damaging its Unicode representation.

This post reviews several stages of Khmer OCR research and introduces an architecture I call Adaptive Orthographic Unit CTC, or AOU-CTC. The central proposal is simple:

The output vocabulary should adapt to the orthographic structure of each script instead of forcing every script through one universal notion of a character.

A second principle follows from that choice: visual KCC recognition should be decoupled from word segmentation. KCC labels follow a stable tokenizer and a relatively bounded orthographic inventory; words and their boundaries are contextual and continually evolving. A newly coined word should normally require a lexical update, not retraining the visual model.

For Khmer, the primary recognition unit is a Khmer character cluster (KCC). For Latin text, it can remain a character. Digits and punctuation can use their own compact units. Connectionist Temporal Classification (CTC) then aligns this mixed vocabulary with the visual sequence without requiring manually segmented character boxes.

This is an architectural proposal and an engineering direction, not a claim of a new state-of-the-art benchmark. A rigorous comparison will require published training data, controlled splits, ablations, and evaluation at code-point, orthographic-unit, and word levels.

Why Khmer OCR is structurally difficult

Khmer is an abugida with visual structure above, below, before, after, and around a base consonant. A rendered cluster can combine multiple encoded elements whose visual order does not map cleanly to a left-to-right list of isolated glyphs.

That creates several recurring difficulties:

  • Character segmentation is ambiguous. Components belonging to one cluster may be spatially detached, while neighboring clusters can touch.
  • Unicode code points are not visual characters. Evaluating or decoding one code point at a time can split a unit that readers perceive as indivisible.
  • Word boundaries are usually implicit. A recognizer cannot depend on spaces to separate every lexical item.
  • Fonts vary significantly. Mark placement, stroke proportions, and coeng forms change across typefaces and document quality.
  • Mixed-script text is normal. Khmer documents routinely contain Latin acronyms, Arabic numerals, Khmer digits, units such as mm and kg, URLs, and punctuation.
  • Normalization can hide label changes. Two code-point sequences can render identically, so pixels alone cannot reveal which original encoding produced the image. A training pipeline must publish its target-encoding policy and retain source provenance instead of silently rewriting labels.

These are not merely linguistic edge cases. They determine the most useful target representation for a recognition model.

Earlier Khmer OCR: segmentation and engineered features

Earlier OCR systems often separated the problem into character segmentation, handcrafted feature extraction, and classification. That strategy was understandable when training data and compute were limited.

Kruy and Kameyama’s preliminary Khmer OCR experiments in 2010 were followed by work on multi-feature extraction for Khmer OCR and comparisons of shape descriptors. This line of research treated robust visual features as a way to make Khmer character recognition tractable despite font and degradation differences.

Related work on re-targetable OCR with intelligent character segmentation explored building script models from font structure. The motivation remains relevant: low-resource scripts cannot always justify a large, script-specific commercial OCR effort, so systems need ways to reuse structure and reduce annotation cost.

The limitation is that segmentation becomes part of the recognition bottleneck. Khmer marks and subscripts do not always form neat, isolated character images. If segmentation breaks a cluster incorrectly, even a strong classifier receives the wrong input.

This is one reason modern text recognition increasingly treats an entire word or line image as a sequence rather than requiring a pre-cut image for every character.

Sequence recognition reduced the segmentation burden

Deep sequence models changed the unit of processing. A convolutional encoder could transform a complete line image into a feature sequence, while a recurrent or attention-based decoder predicted text.

In 2022, Buoy, Taing, Chenda, and Kor presented Khmer printed character recognition using an attention-based Seq2Seq network. Their encoder combined convolutional blocks and recurrent units, and the attention decoder generated one target at a time. On the paper’s 6,400-image augmented validation set, the authors reported a character error rate of 0.7%, compared with 35.9% for the evaluated Tesseract setup.

Those numbers should be interpreted in the context of that dataset, augmentation process, vocabulary, and evaluation split; they are not a universal measure of Khmer OCR. Still, the result demonstrated an important point: line-level sequence learning can outperform a general OCR configuration that is not adapted to Khmer’s structure.

Attention-based autoregressive decoding also has tradeoffs. It predicts each token conditioned on previous predictions, which can model context but may accumulate errors, hallucinate plausible text, or require more sequential computation. Alignment is learned indirectly through attention and can be difficult to convert into stable per-unit geometry.

From Khmer-specific models to a non-Latin-complete baseline

A broader direction appeared in the 2023 IEEE Access paper Toward a Low-Resource Non-Latin-Complete Baseline: An Exploration of Khmer Optical Character Recognition by Buoy, Iwamura, Srun, and Kise.

The paper argues that Khmer is representative of challenges shared by complex non-Latin scripts: stacking, diacritics, ligatures, variable-width units, and writing without explicit word boundaries. Its proposed method combines convolutional visual features with Transformer-based sequence modeling and operates on local two-dimensional feature maps. It also explores synthetic training and transfer to handwritten Khmer palm-leaf manuscripts.

This work is important because it moves the discussion beyond adding one more language table to a Latin-oriented recognizer. It asks what a recognition architecture must represent if it is to support complex scripts generally.

AOU-CTC shares that motivation. KCC tokenization, CTC, CNNs, and Transformers are established ideas; the proposal is their particular combination into a mixed-script target policy, script-aware post-processing layer, and geometry-preserving document pipeline.

Data is becoming more realistic

Printed synthetic lines are useful because they make it possible to vary fonts, sizes, spacing, degradation, and language content at scale. But synthetic data cannot represent every camera, sign, document, or historical artifact.

The WildKhmerST dataset and benchmark addresses Khmer scene text in real environments. The authors describe 10,000 images containing 29,601 annotated text lines, including artistic, blurred, low-light, curved, complex-background, and occluded text. This is a meaningful shift from clean line recognition toward complete detection and recognition in the wild.

A 2025 workshop paper on cross-lingual learning for low-resource Khmer scene text further explores how knowledge from higher-resource languages can help Khmer detection and recognition. Cross-lingual transfer is especially valuable when the visual encoder can learn general text features while the decoder remains aware of the target script.

Together, this research suggests that the next useful Khmer OCR systems will need three properties at once:

  1. a visual model robust to real documents and scenes
  2. an output representation suited to Khmer orthography
  3. a deployment pipeline that preserves useful text and geometry after recognition

AOU-CTC is intended to address the second and third properties while remaining compatible with stronger visual encoders and broader datasets.

Diagram of Adaptive Orthographic Unit CTC from variable-width line input through CNN encoding, Transformer sequence modeling, CTC prediction, adaptive vocabulary, script-aware post-processing, and final text geometry
The proposed AOU-CTC architecture. Different scripts use different useful recognition units while sharing one visual sequence and one CTC objective.

What is an adaptive orthographic unit?

A fixed character vocabulary assumes that “character” means the same kind of unit in every script. Unicode makes that assumption convenient for software, but not necessarily for recognition.

AOU-CTC instead defines token families according to script behavior:

  • Khmer: observed Khmer character clusters or KCCs
  • Latin: individual characters, including accented characters where appropriate
  • Digits: Western and Khmer digits
  • Symbols: punctuation, separators, currency signs, and common units
  • CTC blank: the alignment symbol used by CTC

Here, a KCC is the tokenizer’s deterministic orthographic unit: a Khmer base together with its dependent signs and COENG sequences. It is not claimed to be identical to every Unicode grapheme-cluster implementation or to a linguistic syllable. Spaces remain explicit tokens; Latin letters, digits, punctuation, and symbols remain Unicode scalar units. The tokenizer performs no normalization, reordering, spelling correction, or malformed-cluster repair.

The vocabulary is adaptive because target granularity changes by script—not because classes change during inference. The deployed vocabulary is fixed and versioned. Its Khmer inventory is corpus-driven, and missing complete KCCs are audited before training or fine-tuning. Approved additions are append-only so existing output IDs and classifier rows remain stable. Labels containing an out-of-vocabulary KCC fail dataset validation; the current model does not disguise them behind an unknown token.

This gives the model a vocabulary closer to visible writing units without requiring it to predict complete words, while making coverage limits explicit.

Why not predict complete Khmer words?

Word-level recognition can incorporate strong language knowledge, but it creates a large and brittle vocabulary. Names, technical terms, inflections, loanwords, addresses, and spelling variation quickly become out-of-vocabulary cases.

Khmer also does not normally place spaces between every word. Training labels therefore require a segmentation policy, and disagreements in segmentation can become recognition errors even when the visible text is otherwise correct.

KCC-level prediction occupies a useful middle ground:

  • it is more visually meaningful than isolated code points
  • it has a much smaller open-vocabulary problem than words
  • it supports later word segmentation rather than forcing segmentation into the visual decoder
  • it gives CTC a practical unit for confidence and approximate horizontal alignment

The model recognizes orthographic evidence first. Lexical interpretation remains a separate, reviewable stage.

KCC recognition and word segmentation should be decoupled

This separation is one of the main arguments behind AOU-CTC.

It is useful to distinguish two meanings of “deterministic.” The neural recognizer is not deterministic in the linguistic sense: given a noisy image, it produces probabilities and can make mistakes. However, decomposing a known label into KCCs is deterministic under a fixed, published tokenizer policy. The same Unicode sequence always becomes the same sequence of complete Khmer base, dependent-sign, and COENG units.

The inventory is also relatively bounded. Khmer has a finite writing system with a constrained set of bases, signs, and productive combinations. A real model does not need a class for every arbitrary Unicode permutation. It needs coverage of valid and observed KCCs, plus an explicit policy for rare or malformed sequences. The current AOU-CTC vocabulary contains 4,096 output classes across Khmer KCCs, Latin characters, digits, punctuation, symbols, and the CTC blank. Its exact contents are versioned and auditable.

Words have a different lifecycle. Word segmentation is contextual and lexically open-ended. Khmer normally omits spaces between words, and the same KCC sequence may admit different boundaries depending on context. Personal names, organizations, products, scientific terms, abbreviations, and loanwords are created or adopted continuously. A dictionary that is useful today will not contain every expression users write tomorrow.

If the visual recognizer and word vocabulary are fused into one prediction problem, lexical change becomes a model-maintenance problem. Adding a newly coined word may require changing the output vocabulary, generating training examples, updating model weights, and checking that the update did not regress older words. Language evolution becomes coupled to expensive visual training.

A KCC recognizer avoids that dependency. A new word is usually a new sequence of already known orthographic units, not a new visual primitive. The visual model can continue recognizing those units while the word segmenter, dictionary, or language model learns the new lexical entry independently.

line image
    → stable visual KCC recognition
    → evolving word segmentation and lexical analysis

This leads to different update schedules:

  • recognizer updates are occasional: fine-tune when real evidence reveals a poorly learned KCC, font, degradation pattern, or other visual edge case
  • segmenter updates can be frequent: add new words, names, domains, and usage evidence without changing recognizer weights
  • review updates are immediate: a user can correct semantic text without pretending that the correction was raw visual recognition

The boundary also improves testing. Recognition can be measured against exact orthographic-unit labels, while segmentation can be evaluated against a separately versioned boundary policy. When a new dictionary entry changes segmentation, it should not change what the image model claims to see.

This does not mean lexical context is useless to OCR. A segmenter or language model can rank alternatives, identify suspicious spans, and suggest corrections. The requirement is that lexical reasoning remains a visible downstream layer rather than silently redefining the recognizer’s visual output.

The proposed AOU-CTC pipeline

1. Variable-width line input

A detected text region is perspective-sampled into a line image with a fixed height and variable width. Keeping the width variable preserves horizontal detail and avoids forcing a short label and a long sentence into the same geometry.

In the architecture shown above, the normalized height is 48 pixels. The exact resolution is an engineering parameter rather than a defining property of AOU-CTC.

2. Visual encoding

A two-dimensional convolutional network extracts local stroke and texture features. Pooling collapses the vertical dimension, producing a one-dimensional sequence along the reading direction:

line image H × W × C
    → convolutional feature map
    → height collapse
    → sequence W′ × C′

This stage learns visual invariances shared across scripts: edges, curves, junctions, spacing, and local arrangements of marks.

3. Lightweight sequence modeling

A compact Transformer encoder models relationships across the feature sequence. Khmer clusters can span multiple visual columns, and context helps distinguish marks or shapes that are ambiguous in isolation.

The goal is not to put a large language model inside the recognizer. It is to provide enough bidirectional visual context for robust line recognition while keeping inference practical on ordinary hardware and, eventually, in a browser.

4. CTC prediction

A linear layer and softmax produce a probability distribution over the adaptive vocabulary at each timestep. CTC sums over monotonic alignments between those timesteps and the shorter target sequence.

This has several practical advantages:

  • training needs a line transcription but not a box for every KCC
  • decoding is monotonic and non-autoregressive
  • repeated units are represented through CTC blanks
  • timestep ranges provide approximate positions for recognized units
  • greedy decoding is inexpensive, while beam search remains possible

The last property is particularly useful for document reconstruction. If a token occupies timesteps 20 through 25 of a 100-step line, that interval offers a coarse horizontal estimate after the line has been rectified. It is not a character box, typographic advance, or substitute for aligned ground truth. It is nevertheless more informative than treating the complete line as one indivisible semantic span.

5. Adaptive vocabulary

The model’s final layer covers the union of the script-specific token families. The architecture diagram illustrates a large Khmer KCC inventory alongside Latin characters, Western and Khmer digits, punctuation, symbols, and the CTC blank.

The exact inventory size should be treated as a versioned model property. Adding every theoretically possible Unicode sequence would waste capacity, while excluding all rare clusters would make faithful transcription impossible. A practical vocabulary builder should therefore report:

  • frequency of each observed KCC
  • provenance of its training examples
  • whether it is orthographically valid, rare, or malformed
  • explicit rejection or vocabulary-expansion behavior for unseen sequences
  • coverage on held-out real documents

Vocabulary design is part of the model, not a preprocessing detail.

6. Script-aware post-processing

After CTC decoding, the token stream is divided into Khmer, Latin, digit, and symbol runs. Only Khmer runs are passed to a Khmer word segmenter and spelling-analysis layer.

This separation is intentional. A Khmer dictionary should not “correct” AI FARM CO., LTD. or reinterpret 40 mm as Khmer. Likewise, Latin token rules should not split a Khmer KCC into code points.

The lexical layer produces suggestions rather than silently replacing recognition. Raw OCR remains immutable; a reviewer can keep it, confirm that a warning is false, or apply corrected semantic text. This distinction is important for names, specialist vocabulary, historical spelling, and source text that is genuinely malformed.

7. Text and geometry as joint output

The final output is not only a string. It is a sequence of logical units with:

  • text under the model’s documented target-encoding policy
  • confidence
  • CTC timestep interval
  • script identity
  • approximate source geometry
  • optional lexical diagnostics

For an image, CTC intervals can estimate coarse horizontal KCC spans inside a rectified detected line. For a PDF, an existing text layer—even one with corrupt Unicode mappings—may provide stronger baselines, heights, and run positions when those objects can be recovered and aligned reliably. OCR supplies the semantic text while recoverable PDF text objects serve only as geometric anchors.

This distinction matters when creating a searchable PDF. A document can look correct but still fail when a user searches, highlights, or copies Khmer. The problem is not having one PDF text object for a line; one text object can contain many positioned codes. The problem is an undifferentiated line-sized overlay with no per-unit advances. Encoding semantic units with individual widths gives viewers much better caret and highlight geometry.

Why CTC instead of an autoregressive decoder?

CTC is not universally superior. An autoregressive decoder can learn stronger language dependencies and may resolve visually ambiguous sequences by using context. A large pretrained vision-language model can also transfer broad knowledge.

The AOU-CTC proposal chooses a different balance:

  • faithfulness over fluency: the visual model should not silently rewrite unfamiliar names into common words
  • parallel decoding over token-by-token generation: browser and CPU inference benefit from a compact non-autoregressive path
  • monotonic alignment over implicit attention: timestep ranges are useful for review and document reconstruction
  • separable language knowledge: Khmer segmentation and spelling can evolve independently of the visual recognizer

A future system could combine these approaches. A CTC branch could provide alignment and faithful raw text while a language-aware rescoring branch ranks alternative sequences. The interface should still expose which layer produced each decision.

Training labels need an explicit encoding policy

A KCC vocabulary is only as reliable as its label pipeline. OCR cannot infer an unknowable source encoding when multiple Unicode sequences produce the same pixels. It can only learn the target representation defined by its labels.

Khmer training text often comes from PDFs, websites, office documents, legacy encodings, and manually entered corpora. Visually identical strings may use different code-point order. Some text is malformed but rendered through forgiving fonts. Automatic normalization can make a dataset look cleaner while disconnecting labels from their recorded provenance.

For this reason, I would keep three representations separate:

  1. source text — the exact collected sequence
  2. model label text — the sequence used to build orthographic units, with every transformation recorded
  3. reviewed semantic text — a human-confirmed correction when one exists

No normalization should be invisible. If canonicalization is used for a specific experiment, both the rule and the original string should remain available.

Synthetic generation also needs shaping-aware rendering. The generator should produce complete line images using real font shaping, then apply document-like variation such as blur, compression, uneven illumination, scanning noise, perspective, and background interference. It should not construct Khmer by placing isolated code-point glyphs side by side.

Evaluation should use more than one error rate

Code-point character error rate remains useful because Unicode strings are ultimately stored as code points. But CER alone can overstate or understate the human significance of an error in a complex script.

A useful evaluation suite for AOU-CTC should include:

  • code-point CER for interoperability with conventional OCR reporting
  • KCC error rate for orthographic recognition quality
  • word error rate after a fixed, published Khmer segmentation policy
  • mixed-script accuracy by Khmer, Latin, digit, and symbol runs
  • target-encoding fidelity tests for code-point order, provenance, and malformed-sequence handling
  • geometry error for token-span locations inside each line
  • confidence calibration so review thresholds have a measurable meaning
  • document-level tests for search, selection, and copy/paste from exported PDFs

Results should be separated by synthetic versus real data, printed versus handwritten text, font families, degradation levels, and scene conditions. A single aggregate number can hide the exact cases in which a system fails users.

Ablations are equally important. To justify the architecture, experiments should compare at least:

  • Unicode code-point targets versus KCC targets
  • recurrent versus lightweight Transformer sequence modeling
  • CTC versus autoregressive decoding under comparable capacity
  • fixed Khmer-only vocabulary versus adaptive mixed-script vocabulary
  • greedy decoding versus beam search or lexical rescoring
  • with and without script-aware post-processing

What our current runtime benchmarks show

The repository currently includes reproducible inference benchmarks for the exported AOU-CTC model. These results measure speed and deployment cost, not recognition accuracy. The committed project does not contain a publishable test-set CER report yet, so I am not presenting one here.

The workstation benchmark used an Intel Core i9-11900F, an NVIDIA RTX 3080 Ti, ONNX Runtime GPU 1.23.2, input height 48, batch size 1, five warmup runs, and twenty measured runs. Times include passing NumPy inputs into ONNX Runtime and returning logits to CPU memory. They exclude image loading, resizing, normalization, and CTC decoding.

Input width CPU FP32 CPU INT8 CUDA FP32 CUDA INT8
256 3.09 ms 2.62 ms 0.82 ms 2.31 ms
512 5.40 ms 4.46 ms 1.06 ms 3.38 ms
1024 10.84 ms 8.53 ms 1.46 ms 5.23 ms
2048 24.22 ms 18.73 ms 2.42 ms 9.21 ms

Dynamic INT8 reduced the model from 31.54 MiB to 11.84 MiB—a 62.4% reduction—and improved CPU latency at every tested width. CUDA FP32 was fastest on this workstation. CUDA INT8 was slower because unsupported quantized operations introduced 39 CPU/GPU copy nodes, an example of why “quantized” does not automatically mean “faster” on every provider.

A separate browser test used graphical Chrome 149, ONNX Runtime Web 1.23.2, a real NVIDIA Ampere WebGPU adapter, batch size 1, three warmup runs, and ten measured session.run() calls per width. It included browser tensor upload and output readback.

Input width INT8 WASM FP32 WebGPU WebGPU speedup
80 14.08 ms 9.93 ms 1.42×
256 37.95 ms 10.36 ms 3.66×
512 73.72 ms 10.93 ms 6.74×
1024 149.00 ms 12.92 ms 11.53×
2048 324.77 ms 14.57 ms 22.29×

The WebGPU result remains nearly flat as width grows and reaches a 22.29× speedup over INT8 WASM at width 2048. INT8 WASM remains valuable as a smaller compatibility path, but this benchmark suggests that FP32 WebGPU is the better performance target on a genuine hardware adapter.

These are measurements from one machine and software stack, not guarantees. Browser, driver, provider, thermal state, line width, and preprocessing all affect end-to-end latency. The benchmark is useful because it exposes deployment tradeoffs; it does not establish OCR quality.

The browser is part of the research problem

My practical target is not only an offline benchmark. It is a browser-local OCR workflow where documents remain on the user’s device.

That constraint changes engineering priorities. Model size, quantization, memory ownership, page scheduling, and export semantics become part of the system design. A long PDF should begin OCR as soon as its first page is rendered rather than waiting for the final page. Detection can run through WebGPU when available, while a quantized recognizer can use a broadly compatible WebAssembly path.

The browser workflow also supports review at the point where uncertainty is visible. Users can inspect a detected line, compare immutable raw OCR with editable semantic text, adjust the recognition crop, and export a searchable PDF. If a user explicitly consents, a single reviewed crop can become a training example without uploading the source document.

This creates a feedback loop that is more useful than collecting unreviewed OCR output:

local inference
    → confidence or lexical warning
    → human review
    → explicit correction or confirmation
    → optional, consented sample
    → future training and evaluation

Privacy is not separate from model development. It determines what data can be collected responsibly and what evidence is available for improvement.

What AOU-CTC does not solve

Choosing better units does not remove the hard parts of OCR.

The detector can still merge adjacent lines, split one line into several boxes, or confuse dotted form leaders with text. Small Khmer marks can disappear under blur or compression. CTC can collapse repeated units incorrectly. A corpus-driven vocabulary can underrepresent rare names and historical orthography. A word segmenter can flag correct specialist terms as misspellings.

Scene text, handwriting, palm-leaf manuscripts, and clean digital print are also different domains. One visual encoder may not serve all of them equally well.

The proposal should therefore be evaluated as a set of explicit tradeoffs, not as a universal Khmer OCR solution. Its strongest claim is architectural:

Script-aware output units can preserve Khmer orthographic structure without giving up efficient line-level sequence recognition or mixed-script support.

Whether that produces better accuracy must be demonstrated experimentally.

A research agenda

The next steps I consider most important are:

  1. publish the vocabulary-construction rules and coverage statistics
  2. document synthetic rendering and every Unicode transformation
  3. establish reproducible Khmer printed-text splits
  4. evaluate on real scans and scene text, not only generated lines
  5. measure code-point, KCC, word, script-run, and geometry errors
  6. compare code-point CTC, KCC CTC, and attention-based decoding
  7. calibrate token confidence for human review
  8. publish failure cases, especially rare and malformed clusters
  9. test searchable-PDF extraction across multiple viewers
  10. release enough artifacts for independent reproduction when licensing permits

Khmer OCR research has already moved from handcrafted descriptors to line-level neural recognition, attention, two-dimensional Transformer features, realistic scene-text datasets, and cross-lingual transfer. AOU-CTC builds on that progress by asking a narrower question:

What should the recognizer predict when a Unicode character is too small, a word is too large, and a document contains several scripts at once?

My proposed answer is an adaptive orthographic unit: KCCs for Khmer, characters for Latin, dedicated units for digits and symbols, and CTC to align all of them with one visual sequence. Word segmentation remains downstream, where new vocabulary and contextual boundary rules can evolve without forcing a new set of visual model weights.

The long-term goal is not merely to read Khmer pixels. It is to produce text under a transparent encoding policy that remains reviewable, searchable, selectable, and useful in the documents people actually work with.

Explore the implementation

The model and application are active engineering work. Benchmark scripts, vocabulary rules, and failure reports are more valuable at this stage than unsupported claims of general accuracy. Reproducible evaluations and difficult Khmer documents are welcome.

References and further reading