Persian Has 110 Million Speakers and Almost No OCR Data. This Paper Fakes 343,000 Pages to Fix That

Try this: take the Persian letter ب (the equivalent of "b") and picture it appearing four different ways depending on whether it starts a word, sits in the middle, ends a word, or stands alone. Now do that for most of the alphabet. Now add optional diacritic marks that change pronunciation but aren't required in normal writing, so a model has to guess whether their absence means "not needed" or "the scanner missed it." Now render the whole thing in Nastaliq, a calligraphic style where letters swoop diagonally and stack on top of each other, and good luck drawing a clean bounding box around anything.

That's Persian OCR in one paragraph, and it's why a script spoken by more than 110 million people still trails Latin-script languages badly in text recognition quality. A new paper, "Persian Pixel," doesn't propose a new model architecture to fix this. It does something more boring and, I'd argue, more useful: it manufactures 343,000 fake document images so that existing architectures have something decent to learn from.

The problem was never the models, it was the data

Modern OCR systems, the transformer-based ones like TrOCR and Donut that the paper name-checks, are hungry. They need huge volumes of paired data: an image of text on one side, the correct transcription on the other. English has this in abundance, scraped from decades of scanned books, forms, and websites, then hand-corrected by armies of annotators. Persian doesn't.

Part of that gap is just economics. Annotating OCR data means someone (or some pipeline) has to look at an image and type out exactly what it says, character for character, including where the diacritics landed. That's slow, it's expensive, and it doesn't scale the way a scraped English corpus does. But part of the gap is the script itself. Persian, like Arabic and Urdu, is written cursive by rule, not by style choice, and every letter subtly reshapes itself based on what's next to it. A dataset built from a handful of clean, modern fonts won't prepare a model for the ligatures and glyph variants it'll hit in the wild, let alone for the two dominant writing traditions, Naskh (more upright, print-like) and Nastaliq (the flowing calligraphic form common in Persian literature and signage), which look close to unrelated scripts if you're a model that's only seen one of them.

So you end up stuck: real annotated data is too expensive to produce at scale, and small datasets don't cover enough of the script's variation to train a robust model. Persian Pixel's answer is to stop waiting for real data and generate synthetic data instead, then work hard to make the synthetic data behave like real data once a model sees it.

How they built 343,000 fake documents that (mostly) act like real ones

The pipeline starts with a seven-million-word Persian text corpus, curated rather than scraped wholesale, which becomes the raw material for everything downstream. A rendering framework the authors call SynthOCR-Gen then turns that text into images, and this is where the script-specific engineering actually happens. The system has to get contextual character joining right (which shape of a letter to draw based on its neighbors), place positional glyph variants correctly, handle diacritic placement, and do all of it across multiple representative Persian typefaces spanning both Naskh and Nastaliq styles.

The output isn't just word-level snippets. The dataset spans three layout scales: sentences, paragraphs, and full-page documents. That range matters more than it sounds. A model trained only on isolated words has no idea how to handle line breaks, paragraph justification, or the layout noise of a real scanned page, where text doesn't sit in a tidy single line waiting to be read.

Rendering clean text is the easy half. The harder problem, and the one that actually determines whether any of this is useful, is the synthetic-to-real domain gap: a model trained on pristine computer-rendered text tends to fall apart the moment it meets an actual scanned or photographed document, because real documents are full of physical imperfections a renderer doesn't produce by default. Persian Pixel attacks this with more than twenty-five stochastic degradation models layered onto the rendered images: ink bleed, paper aging, blur, uneven illumination, scanner artifacts, compression noise, and several other noise processes, applied probabilistically so no two images degrade identically. It's the OCR equivalent of training a self-driving system in a simulator, then randomizing the simulated weather, lighting, and road grime until the model stops being able to tell simulation from reality.

What's actually in the box

Strip away the pipeline description and the dataset itself is straightforward to describe: over 343,000 image-text pairs, generated from a seven-million-word corpus, split across sentence, paragraph, and page-level layouts, rendered in multiple Persian typefaces covering both major script styles, and degraded with 25-plus artifact models to simulate real-world capture conditions. It's built to be a training or fine-tuning resource for transformer OCR architectures like TrOCR and Donut specifically, rather than a general-purpose benchmark.

What the paper's abstract does not include is the part I most wanted to see: actual numbers on how a model trained on Persian Pixel performs against real, non-synthetic Persian documents. No character error rate, no word error rate, no comparison to whatever Persian OCR baselines already exist. That's not a knock on the dataset's usefulness so much as a flag for how to read the claim. "We built a large, carefully engineered synthetic dataset" and "we proved this dataset closes the real-world accuracy gap" are two different claims, and only the first one is fully backed by what's described here.

Why it matters for anyone building or choosing OCR

If you're picking an OCR engine and Persian is anywhere in your document mix, receipts, government forms, historical manuscripts, whatever, the practical takeaway isn't "go use Persian Pixel directly." It's that the field now has a credible, purpose-built training resource for a script that was badly underserved, and any vendor or open model claiming decent Persian support in the next year or two plausibly trained on data like this, since hand-annotated Persian data at this scale basically doesn't exist elsewhere.

The bigger lesson generalizes past Persian. A huge share of the world's writing systems, Arabic, Urdu, Thai, Amharic, and dozens more, face the exact same bottleneck: complex scripts, thin annotated data, and OCR quality that lags Latin scripts as a result. Persian Pixel is a working example of the fix being applied at scale: instead of waiting for manual annotation to catch up, model the script's rendering rules precisely enough that synthetic data can stand in, then spend real engineering effort closing the gap between "looks like text" and "looks like a document that's been through a scanner, a decade, and a bad photocopier."

If you're evaluating an OCR provider's Persian (or Arabic, or Thai) claims, the honest question to ask is whether their reported accuracy came from a benchmark like this synthetic one, or from real documents pulled from the kind of pipeline you'll actually run. Synthetic-trained models can be genuinely strong, but "trained on 343,000 synthetic pages" and "tested on 343,000 synthetic pages" is a much weaker claim than "tested on real invoices nobody built the renderer to anticipate." Ask for the real-world number, not just the dataset size.

What's still missing

A few gaps are worth naming plainly. First, and most obvious: no benchmark results in the materials available for this piece. We don't know the actual error rates a TrOCR or Donut model achieves after fine-tuning on Persian Pixel, either on held-out synthetic data or, more importantly, on real scanned Persian documents. That's the number that would tell you whether this dataset actually moves the needle or just looks impressive on paper.

Second, synthetic degradation, however sophisticated, is still a simulation of real-world wear, not the thing itself. Twenty-five stochastic degradation models is a lot of engineering effort, and probably enough to meaningfully narrow the domain gap, but "narrow" isn't "close." Historical manuscripts in particular, one of the use cases the paper explicitly names, involve degradation patterns (centuries of ink fading, physical damage, non-standard historical typefaces and handwriting) that a modern rendering pipeline calibrated on contemporary Naskh and Nastaliq fonts probably doesn't fully capture.

Third, handwriting isn't mentioned at all. Everything described here is rendered, typeset text. Persian handwriting recognition, arguably an even harder problem given the script's cursive baseline gets more extreme in handwritten form, isn't addressed by this dataset.

None of that erases the contribution. Persian document digitization has been stuck behind a data wall for a long time, and a carefully engineered synthetic dataset that models the script's actual typographic rules, rather than treating Persian as "Latin text but right-to-left," is a real step. Just treat the headline number, 343,000 image-text pairs, as a measure of scale and engineering effort, not as a proxy for how well the resulting models will read your actual documents. That second question still needs an answer, and it's the one worth asking before you build on top of this.