OCR Challenges Specific to Arabic's Cursive Script

Arabic OCR is harder than Latin OCR in a way that more training data does not fix, because three properties of the script remove assumptions that Latin-script recognition is built on. Knowing which three tells you what your pipeline can and cannot recover from.

The word is one connected shape

Arabic is cursive in print, not only in handwriting. Letters join along a baseline, and the joining is obligatory rather than stylistic: there is no printed Arabic in which the letters of a word stand apart the way Latin type does.

Classical OCR pipelines have a segmentation stage that cuts a line into characters, usually by finding vertical gaps between connected components. On Latin type, a connected component is nearly always one character. In Arabic a connected component is a whole word, or a piece of one, and there is no gap to find. Segmenting it requires knowing where one letter ends and the next begins, which requires knowing what the letters are — the circular dependency that made per-character Arabic OCR unreliable for decades.

Six letters break the chain and are the reason a word is often several pieces rather than one: alif, dal, dhal, ra, zay and waw join only to the letter on their right, never to the one on their left. So a word splits into what the literature calls pieces of Arabic word, and the number of pieces varies with the letters involved rather than with the number of words. A gap in the ink is therefore evidence of very little: it might be a word boundary, or it might be one of those six letters mid-word.

Modern engines mostly sidestep this by recognising a whole text line as a sequence, using a recurrent or transformer model with a connectionist temporal classification loss, so no explicit character segmentation happens at all. That is why line-level models improved Arabic disproportionately. It also means a layout stage that cuts your page into the wrong line boxes is more damaging here than in Latin script, because there is no per-character fallback underneath.

A second consequence is spacing. Arabic justification traditionally stretches the joining stroke — the kashida — rather than the word spaces, so the distance between two glyphs in a justified line is a typographic decision and not a boundary signal. Heuristics tuned on inter-word spacing in Latin type do not transfer.

Four forms per letter

Most Arabic letters take up to four contextual shapes: isolated, initial, medial and final. These are not slight variations. The initial and medial forms of many letters are reduced to a small hook or tooth on the baseline, while the isolated and final forms carry a large tail or bowl. Visually, the initial form of one letter can resemble the initial form of a different letter far more than it resembles its own isolated form.

For a classifier this multiplies the class count and, worse, it makes the classes unequally distributed: some forms are common and some are rare, so the tail of the distribution is thin exactly where the shapes are least distinctive. The alternative framing — treat each contextual form as its own class — is what most engines effectively do, and it is why an Arabic model needs a wider output layer than a Latin one for the same alphabet size.

The alphabet is 28 letters, which sounds small until the forms are counted, and one combination is an obligatory ligature: lam followed by alif is written as a single fused shape rather than as two letters side by side. Some typefaces add many more optional ligatures, particularly in Nastaliq styles used for Persian and Urdu, where the baseline itself slopes and the shapes stack diagonally. A model trained on Naskh type degrades sharply on Nastaliq, and treating “Arabic script” as one problem across Arabic, Persian and Urdu is a common and expensive mistake.

Dots carry the letter identity

This is the property that makes Arabic OCR errors different in kind, not only in rate. Several letters share an identical skeleton and are distinguished solely by dots — the i’jam — placed above or below it: one dot below, two above, three above, and so on across a family. Another family of three letters is separated only by a dot above, a dot below, or none at all.

So a dot lost to a speck of dust, a scanning artefact, a fold in the paper or aggressive binarisation does not produce a garbled character. It produces a different, perfectly valid letter, and therefore a different, perfectly valid word. The output is fluent and wrong, which means a spell-checker will not flag it and a human proofreader without the source page cannot detect it. Compare a Latin OCR error, which typically produces a non-word and announces itself.

Short vowels compound this from the other direction. Ordinary Arabic text omits them, so the reader supplies them from context; when they do appear — Qur’anic text, children’s books, poetry, teaching material — they are small marks above and below the line that a recogniser must distinguish from the identity-bearing dots and from noise. Many engines are configured to discard them, which is correct for search and wrong for a text where the vowelling is the point. The equivalent problem in Hebrew is OCR and Hebrew niqqud.

What comes out of the extractor

Two encoding problems arrive after recognition and are frequently mistaken for OCR errors.

The first is presentation forms. Unicode contains the Arabic Presentation Forms-A and Presentation Forms-B blocks, which encode the positional shapes as separate code points. They exist for compatibility with older encodings and are not how Arabic text should be stored: the correct representation uses the base letters and lets the rendering engine choose shapes. An extractor that emits presentation forms produces text that looks correct on screen and fails every search, because the initial form of a letter is a different code point from the letter. Compatibility normalisation maps them back, which is one of the few cases where NFKC is clearly the right choice rather than a destructive one — the distinction is explained in the difference between NFC and NFKC.

The second is ordering. Arabic is written right to left, and a recogniser that emits glyphs in the order it scanned them produces text in visual rather than logical order. It renders correctly in some viewers and reverses in others, and any substring operation on it is wrong. PDF extraction is the usual source. That problem, and how to detect it, is reordering extracted Arabic text.

Measuring it on your own documents

Published accuracy figures for OCR are overwhelmingly quoted on Latin-script corpora, and where an Arabic figure exists it is tied to a specific corpus, typeface and scan quality that almost certainly is not yours. Rather than trusting a headline number, measure three things on a few hundred lines of your own material.

• Character error rate, not word error rate. Word error rate on Arabic conflates recognition with the tokenisation of a script whose word boundaries are not reliably visible in the ink.
• A confusion matrix restricted to the dot families. If your errors concentrate there, the fix is scan quality — higher resolution, gentler binarisation, no aggressive despeckling — rather than a different model. Despeckling filters remove dots.
• A separate score per typeface. Naskh, Kufi and Nastaliq are effectively different problems, and an average across a mixed corpus hides a typeface the engine cannot read at all.