Digitizing Arabic and English records

A UAE records office holds tenancy contracts with Arabic on the right of the page and English on the left, memos typed in Arabic with English product codes running through them, employee files where the same person is spelled Mohammed in one document and Mohamed in another, and older correspondence set in a heavy calligraphic heading style. A digitization approach designed for English documents will produce clean images and an unusable text layer from all of it.

The problems are specific and each one has a specific mitigation. Below is what changes, stage by stage, when Arabic is in scope.

Why Arabic script is harder for OCR

Latin OCR can lean on an assumption that does most of the work: characters are separate shapes with white space between them. Arabic breaks that assumption at the root.

• Arabic is cursive even when printed. Letters connect along a baseline, so a word cannot be reliably cut into individual characters. Recognition works on whole words or on connected sub-word pieces instead, which is a fundamentally different problem from segmenting Latin glyphs.
• Most letters take up to four contextual shapes depending on position: isolated, initial, medial and final. The glyph inventory an engine must recognise is several times the size of the alphabet, and the same letter looks quite different at the start and the end of a word.
• Six letters, including alef, dal, ra and waw, do not join to the letter that follows them. A single word therefore breaks into several connected pieces with gaps inside it. Splitting text on white space, which is the default in almost every text pipeline, cuts words in half.
• Whole groups of letters are distinguished only by dots: their skeleton is identical and the difference is one dot above, two below, three above. Ba, ta, tha, nun and ya share a shape. So do jim, ha and kha, and sin and shin, and sad and dad, and ayn and ghayn, and fa and qaf.
• That last point is the single most consequential fact in Arabic capture. A speck of dirt, ink bleed-through from the reverse side, or an over-eager despeckle filter can add or remove a dot and silently convert one valid word into another valid word. Nothing downstream will flag it, because the result is not a spelling error.
• Diacritics, the short vowel marks, are absent from most modern administrative Arabic but present in older, religious and some legal texts. An engine not configured for them may read them as noise or as additional characters. Whether to preserve or strip them is a decision to make before production, not during.
• Hamza sits on different seats, and alef appears as a bare form or with hamza above or below or with a madda. Typists are inconsistent about all of them. So are the source documents.
• Ta marbuta and ha look similar and are routinely interchanged, as are alef maqsura and ya. These are as much a search problem as a recognition problem, and they are handled in the index rather than at capture.
• Lam followed by alef forms a mandatory ligature that is a single shape. Traditional and calligraphic typefaces add many optional ligatures and vertical stacking, which breaks the assumption that a line of text runs along a single baseline.
• Typeface variety is wide. Modern administrative Naskh is well handled. Ruqaa, common in handwriting and older headings, Kufi in logos and headings, and the ornamental styles used on seals and formal letterheads all degrade sharply on an engine trained mainly on modern print.
• Justification is achieved by stretching letters with an elongation character rather than by widening spaces. Stretched connectors change glyph widths and can be recognised as extra characters. The elongation must be stripped from indexed text while remaining perfectly normal in the image.

Handwritten Arabic is harder again for all these reasons combined. The realistic planning assumption for handwritten Arabic annotations, marginal notes and signatures is manual keying by an Arabic reader, with recognition treated as an aid rather than the method.

Capture settings change

Because dots and diacritics are small, high-frequency features, the image processing defaults that are harmless on English text are actively destructive on Arabic.

The single most useful habit: after tuning the capture profile, open the worst page in the sample, zoom to full resolution, and read the dots. Not the words. The dots. If you cannot resolve them by eye on screen, no engine will resolve them either.

Layout, reading order and bidirectional text

UAE administrative documents are frequently laid out in two languages at once. Two columns, Arabic on the right and English on the left. Or paired lines, with each field label printed in both. Or an Arabic body paragraph containing a Latin company name, a reference code and a Gregorian date.

If layout analysis does not detect the columns, the reading order interleaves them line by line and the resulting text layer is unusable in both languages. The mitigation is zoning: detect the regions first, assign a language to each region, and recognise each region separately. On a form set with a consistent layout, defining the zones once per form type is faster and far more reliable than letting automatic analysis guess on every page.

Within a line, mixed scripts introduce the distinction between logical order, which is the order the characters are stored and typed, and visual order, which is how they are painted on screen. Arabic runs right to left, embedded Latin runs left to right, and digits run left to right even inside Arabic text. Software resolves this with the Unicode bidirectional algorithm, but only if the text was stored in logical order in the first place. Some older capture pipelines wrote text in visual order. Such a file looks correct on screen and searches wrongly, because the stored character sequence is reversed.

There is a fast way to test this on any file you already hold. Open a page with a mixed Arabic and English line, select that line, copy it, and paste it into a plain text editor. If the Arabic arrives reversed or the embedded English lands in the wrong place, the text layer is stored in visual order and will need reprocessing. This one test catches a defect that no image inspection will ever reveal.

Two related details. Arabic punctuation has its own code points for the comma, semicolon and question mark, and brackets are mirrored in display, so an opening bracket in logical order appears as the mirrored shape. And in a searchable PDF, the invisible text must sit in the same coordinates as the visible glyphs, running right to left. When it does not, search hits highlight the wrong words, which users read as a broken search rather than a positioning fault.

Designing bilingual index fields

The instinct to save effort by keeping one field per concept and letting operators type in whichever language the document used is the most expensive mistake available in a bilingual project. Sorting, validation, deduplication and search all behave differently per script, and a mixed column supports none of them properly.

• Pair the fields. Party name in Arabic and party name in Latin script as two fields, each with its own rules, rather than one field containing whichever the source used.
• Treat the Arabic original as authoritative and the Latin form as a rendering. One Arabic spelling of a common given name maps to a long list of Latin spellings, and the reverse mapping is not deterministic. Indexing only the Latin form loses information permanently.
• Do not force Arabic personal names into a Western first-name and last-name schema. Names commonly run given name, father, grandfather, then family or tribal name, and the split is not reliable. Index the full name as recorded, and add components only where a specific process genuinely needs them.
• Normalise numerals in the index while preserving what was printed. Documents mix Arabic-Indic digits with the Western digits used elsewhere on the same page, often within one reference number. Range queries and sorting need one form. The displayed value should still show what the document actually said.
• Handle both calendars explicitly. Hijri and Gregorian dates both appear in UAE records, sometimes on the same page. Store a machine-readable date for querying, record which calendar the printed value used, and never let an indexer silently convert one to the other without the source value being retained.
• Agree a file-naming convention early. Arabic characters in file names break some legacy systems, some transfer protocols and some path-length limits. The usual answer is Latin-script file names with the Arabic held in index fields, where it belongs anyway.

Search and sorting in two scripts

A correct text layer still produces poor retrieval if the search platform treats Arabic as an undifferentiated string of characters. Three configurations matter.

1. 1Normalisation at index time. Strip the elongation character and any diacritics, unify the alef variants, unify ta marbuta with ha and alef maqsura with ya, and unify the digit sets. Apply this to the search index only, leaving the stored text exactly as recognised. Without it, a user searching one legitimate spelling misses documents that used another.
2. 2Morphological analysis. Arabic attaches the definite article and several conjunctions and prepositions directly to the front of a word, and attaches pronouns to the end. A plain substring search for a company word will miss every instance carrying the definite article. The platform needs an Arabic analyser, not a generic one, and this needs to be verified rather than assumed. Test it with a word you know appears with and without the article.
3. 3Collation for sorting. Arabic alphabetical order is not code point order, and a list mixing Arabic and Latin entries has no natural single sequence. Choose the collation deliberately, decide where the two scripts sit relative to each other in a mixed list, and write the decision into the index specification. Otherwise every user gets a different mental model of why the list is ordered as it is.

Quality control has to be bilingual

An operator who does not read Arabic can check image quality, page count, skew and crop. They cannot check text fidelity, and they certainly cannot catch a dot error, because a dot error produces a different but perfectly valid word that no spellcheck will flag. Field-level verification on Arabic content requires Arabic readers, and that requirement should appear in the staffing plan and in the price rather than being discovered at the first QC review.

Build the sampling plan around document classes rather than around the archive as a whole. Arabic print from a modern laser printer, Arabic from an older typewriter or dot-matrix printer, calligraphic headings, handwritten annotations and bilingual forms are five different populations with five different failure profiles. A single blended figure across all of them tells you nothing actionable.

A bilingual pilot that produces usable answers

1. 1

   Sample by class, not by convenience

   Pull pages from each distinct population: modern Arabic print, older or degraded Arabic print, calligraphic or heavy display headings, bilingual two-column forms, and pages with handwritten Arabic annotations. Twenty to thirty pages per class is enough to see the failure modes.

2. 2

   Key ground truth manually

   An Arabic reader types what the page actually says, in logical order, with a stated rule on diacritics and elongation. This is the reference everything is measured against, so it has to be produced independently of the OCR output.

3. 3

   Measure per class and per script

   Report word-level error rates separately for the Arabic and Latin content on the same pages, and separately per class. A blended figure hides the fact that one class is fine and another is unusable.

4. 4

   Test the text layer, not just the text

   Copy mixed-script lines out of the delivered PDFs into a plain editor, and run searches that should hit. This is where bidirectional and coordinate faults surface, and they are invisible in an accuracy report.

5. 5

   Test retrieval with real search terms

   Have Arabic-reading users search for documents they know exist, using the spellings they would naturally type, including a name with and without the definite article and a name with a different hamza seat. Failures here are index configuration faults, not OCR faults, and they are fixed in a different place.

6. 6

   Decide the split before production

   The pilot output tells you which classes go to automated recognition with sampled verification, which go to recognition with full verification, and which go straight to manual keying. Setting that split from evidence is the whole point of the exercise.

None of this is exotic. It is the same discipline any careful digitization project applies, with the specific knowledge that in Arabic the smallest marks on the page carry the most meaning, and that a bilingual document is two documents sharing a sheet of paper.