Urdu Nastaliq OCR for Printed Books and Newspaper Archives with Searchable Output

The problem: a century of Urdu print that nobody can search

University libraries, newspaper archives and private collections hold shelves of Urdu books, magazines and newspapers. When they are digitised at all, they usually become page images. A researcher looking for one phrase still has to read page after page, a blind reader cannot have the text read aloud, and none of it shows up in search.

Urdu is hard for OCR because most of it is printed in Nastaliq. Letters join into ligatures that slope diagonally, overlap each other and sit at different heights on the line. Dots move around. Old scans add noise, bleed-through and broken characters. A system trained on clean, modern Naskh text does badly here.

What already exists and the gap

• General OCR engines such as Tesseract ship an Urdu model, and large cloud OCR services accept Urdu. Research on Urdu OCR, including the paper below, describes how general systems struggle with Nastaliq's slanted, overlapping ligatures.
• Research models and datasets for printed Urdu exist, with open code and benchmark sets of text lines.
• Digital libraries of Urdu books often publish page scans for reading, not searchable text.

The gap is a complete, open pipeline that a library can actually run on its own scans: page layout, recognition, correction and a review loop, measured on messy archive pages rather than only on clean lines.

Inspiration

"UTRNet: High-Resolution Urdu Text Recognition in Printed Documents" by Abdur Rahman, Arjun Ghosh and Chetan Arora (IIT Delhi), published at ICDAR 2023, introduced a high-resolution recognition model, a real-world dataset of annotated Urdu lines (UTRSet-Real), a synthetic set and a text line detection benchmark (UrduDoc), with open code. Your project starts from that work and asks what it takes to make it useful for a real archive.

What you build

• Librarians and archivists upload scanned pages and get searchable text and PDFs back, with a screen to correct mistakes.
• Researchers and students search a collection by word or phrase and jump to the highlighted line on the original page.
• Blind and low-vision readers get real Unicode text that a screen reader can read.

The system keeps the link between every recognised line and its position on the page image, so search results can be shown on the original scan and a reader can always check the text against the source.

The technically interesting part

• Layout and reading order. Newspapers have columns, headlines and adverts. Detecting lines is not enough: you must order them right to left and column by column.
• Domain shift. A model trained on modern book lines will meet 1970s newsprint. Fine-tuning on a few hundred of your own labelled lines, plus synthetic lines rendered in old fonts with added noise, is the core experiment.
• Correction without inventing text. A language model can fix obvious errors, but it can also "correct" a rare name into a common word. Restrict changes to low-confidence spans, log every change and measure how often correction makes things worse.
• Human review as training data. Every correction a librarian makes becomes a new labelled line, so the system improves with use.

How to evaluate it

• Character and word error rate on your own test set, split by source: modern books, older books, newspapers, magazines.
• Before and after correction, including the number of correct words the correction pass broke.
• Layout accuracy: share of pages where the reading order was right.
• Review effort: minutes a librarian needs to correct a page, compared with typing it.
• Search usefulness: for a set of known phrases, how often search finds the right page.

Suggested plan

• Weeks 1 to 4: read the UTRNet paper, run the published model on sample scans, collect pages from a partner library and agree on permissions.
• Weeks 5 to 9: line detection, reading order and a labelling workflow; label your first few hundred lines.
• Weeks 10 to 14: fine-tuning, synthetic data and the first evaluation.
• Second semester, weeks 1 to 6: correction pass, search, PDF output and the review screen.
• Weeks 7 to 10: full evaluation, librarian testing, screen reader check.
• Weeks 11 to 14: report, demo and a public release of code and, where allowed, the test set.

Path to a product

Libraries, publishers, newspapers and government record rooms all hold Urdu print they cannot search. An open pipeline with a paid hosted service or paid digitisation projects is a realistic model. A labelled test set of real archive lines is also a contribution other researchers can build on, and the work fits research assistant and computer vision roles well.

Scope warning

Do not build a recognition model from scratch; fine-tune a published one. Do not try to handle handwriting, poetry layouts or every font in one project. Get written permission before you use or publish any scans, and keep copyrighted books out of any public demo.

Learn what you need on Sefism

• Machine learning roadmap: the training, validation and error analysis habits this project needs.
• Machine learning cheat sheet: quick reference while you run experiments.
• PyTorch: Learn the Basics: the framework the published model is written in.
• CS231n: Deep Learning for Computer Vision: CNNs and sequence models for images of text.
• Label Studio: labelling text lines and building your test set.
• FastAPI Tutorial: User Guide: serving the pipeline to the review screen.

Get help with this idea

The risk is a model that looks good on benchmark lines and fails on real archive pages. Tauseef can help you plan the labelling, keep the scope to printed text and design an evaluation a library will trust. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session