Documents
Why Persian documents are hard to read
Every tool claims to do OCR. The difference shows on a Persian document that has been scanned badly — and these are the five technical reasons why.
6 min read
The problem isn't the language, it's the script
When a vendor says “Persian OCR supported”, it usually means the model can recognise Persian letters. That is the smallest part of the job. The difficulty is elsewhere: in the shape of the script, in numeral conventions, and in the shape of the documents that actually circulate in Iran.
The five problems below are independent of each other, and any one of them can make a page unusable on its own.
Five problems
What makes a Persian page hard
1. Letters join, and change shape when they do
A letter has three different forms depending on whether it starts, sits inside, or ends a word. Unlike Latin, where letters stand apart, the boundary between two Persian letters is not always a visual gap — which turns character segmentation from a simple problem into a contextual one.
2. Numerals come in three forms
Persian ۱۲۳, Arabic ١٢٣ and Latin 123, often on the same page. An invoice may write the amount in Persian and the invoice number in Latin. If numeral detection doesn't know that, the figures are either missed or misread.
3. Tables have no rules
Many Persian administrative tables are built with whitespace rather than lines. Table structure then has to be inferred from column alignment — and one skewed column in a scan breaks the whole grid.
4. Stamps land on top of the text
A company stamp usually falls on exactly the line carrying the amount or the date. To a model that is two visual layers on top of each other, and to a reader it is the figure that matters most.
5. Reading order is right-to-left, except when it isn't
Text runs right to left while embedded numerals and Latin phrases run left to right. A bilingual page has a reading order that must be reconstructed, or the output is “correct” and meaningless.
In this product
What can be done about it
PulseUp was built for this case rather than the easy one. Persian numeral parsing is part of the document pipeline, and the search index was built for Persian — ی versus ي, ک versus ك and zero-width non-joiners fold together in the index, or half of all searches return nothing and nobody works out why.
But more important than any accuracy claim: every figure that comes out carries the page and line of its source document. No system is right one hundred per cent of the time on a bad scan, and the only honest answer is to make checking cheap rather than to pretend the errors don't exist.
- Persian numeral parsing in the document pipeline
- A Persian-verified search index folding ی/ي and ک/ك
- A source-page citation on every figure
- Human review before a figure enters the work
- ## Statement of financial position
- | Account | 1403 | 1402 |
- | Cash and equivalents | 84,120 | 61,540 |
- | Trade receivables | 402,880 | 366,210 |
Page 12 validated by Sara
Common questions
What accuracy do you get?
We don't publish a number, because any number is meaningless without saying what set it was measured on, and your documents differ from our test set. What you can do instead: bring the worst scan you have and see the result yourself.What happens when it reads something wrong?
That is exactly why the source-page citation exists. Every figure is one click from the original document, and human review happens before anything enters the work. A system claiming review is unnecessary has made a bigger claim than it can keep.Does it read handwriting?
No. Handwriting is outside what the product does today and we won't pretend otherwise.
Try it on your own data
The free plan has no time limit. Bring the hardest document you have.