DEV Community: Wadifa Info

OCR for 1,700 scanned exam papers in Arabic and French with Tesseract (and the traps we hit)

Wadifa Info — Thu, 01 Oct 2026 08:51:15 +0000

We run Wadifa Info, a Moroccan site that lists public-sector recruitment exams in Arabic and French. One part of the site is a free library of past exam papers: more than 1,700 of them, from police and customs exams to teacher-training and engineering-school entrance exams (French index).

Most of these papers arrive as photos or scans. A page that is only an image can't be searched, can't be quoted in a page description, and tells a search engine almost nothing. So every page needs its text. This post covers how we OCR'd the whole library on one Windows machine with Tesseract, and the four traps that made "done" turn out to be not done.

Setup: Tesseract 5 with the right language data

Tesseract 5.4 installs on Windows with one command:

winget install --id UB-Mannheim.TesseractOCR -e

It ships with English only. Arabic and French data come from the tessdata_fast and tessdata_best repositories, and you point Tesseract at them with --tessdata-dir (handy when you can't write to Program Files).

We measured the options on a real bilingual page, counting recognised Arabic and Latin characters:

Setting	Arabic chars	French chars
`ara+fra` (fast models), raw image	674	914
`ara_best+fra`, preprocessed	805	998
`ara_best` alone	good	French destroyed

Two lessons: the best Arabic model is clearly better on photographed pages, and a single-language model mangles the other script, so bilingual pages need both (-l ara_best+fra).

Preprocessing that actually helped

Three cheap steps, in Pillow, before every page:

def prep(src):
    im = Image.open(src).convert("L")                  # grey
    if im.width < 1800:                                # small phone photos
        im = im.resize((im.width * 2, im.height * 2), Image.LANCZOS)
    return ImageOps.autocontrast(im)

Then tesseract page.jpg stdout -l ara_best+fra --psm 6. Page segmentation mode 6 ("a single uniform block of text") beat the automatic mode on exam sheets, which are mostly dense paragraphs and numbered questions.

On the first pass this filled 286 of 289 papers that had no text, median about 2,900 characters per paper.

Trap 1: photographed pages that return only our own footer

A few phone photos came back with exactly one line: the footer we add to every page. Tesseract found no text blocks at all, at any --psm, at any scale. The page wasn't blurry; it had uneven lighting, so a global threshold turned half the sheet into one dark blob.

The fix was an adaptive threshold, done in Pillow without OpenCV: compare each pixel with a heavily blurred copy of the page, and keep only what is darker than its local background.

bg   = im.filter(ImageFilter.GaussianBlur(20))
diff = ImageChops.subtract(bg, im)            # ink is darker than the local background
th   = diff.point(lambda v: 0 if v > 12 else 255)

We now try four variants per page (plain or adaptive, --psm 4 or 6) and keep the one with the most real words. "Real word" is deliberately crude: Arabic words of three letters or more, and Latin words of three letters or more that contain a vowel. Our worst three papers went from a single footer line to 4,800–5,600 characters each.

Scoring trap inside the trap: we first stripped footer lines before scoring the old text. A one-line OCR result is the footer line, so stripping it scored the old text as zero and every comparison looked like a huge win. Strip the footer phrase, not the line.

Trap 2: a page cap we forgot about

The first script had MAX_PAGES = 8 to keep test runs short. It never came out. Fifty-eight papers longer than eight pages had pages 9+ silently skipped, about 400 pages in total.

What caught it was a simple health check: for each paper, compare the number of images we publish with the highest page marker in its text. Our OCR writes a marker between pages (— صفحة N —), so a 12-page paper whose text stops at page 8 is easy to spot. We now run that check after every import.

Trap 3: papers that are only half there

This one wasn't an OCR bug; OCR found it. Many official papers print their own footer: Page 2 sur 5, or الصفحة 2 من 5. If the paper says "page 1 of 9" and we publish 4 images, we are missing pages.

Matching that pattern across the library found nine incomplete papers. One of them showed only "Page 2 sur 2": visitors were opening the paper halfway through, at exercise 3.

Two things made the detector usable:

Never match a bare N/M. Moroccan exams are marked out of 20 or 10, so 14/20 is a score, not a page number. The naive pattern produced 34 candidates, almost all wrong. Only explicit forms count: Page N sur M, Page N | M, الصفحة N من M.
Read the context. "Répondre sur le document réponse (page 06/10)" is a cross-reference, not a footer.

Trap 4: duplicates that look different, and different papers that look the same

The same paper often reaches us twice: a clean PDF and a phone photo of a printout, or the same engineering-school subject adapted for two streams. Image hashing on a page region gave false positives (shared headers), and comparing only the first 3,000 characters did too: the adapted version shares the opening, then diverges.

What worked was comparing the full OCR text at the word level:

from difflib import SequenceMatcher
same = SequenceMatcher(None, a.split(), b.split()).ratio() >= 0.84

Above 0.84 it was always a true copy in our checks; below it, a genuinely different paper. Seven copies were hidden this way.

Where it ended up

Every published paper has text, except a handful of genuinely unreadable photos that we leave empty on purpose rather than fill with noise.
Each paper page shows the transcription in a collapsed "text of the questions" box, with a note that it was extracted automatically and the images remain the reference. Candidates can search and copy the questions, and search engines can finally read what each paper covers.
The same text drives our duplicate check when new papers come in.
The health checks (page count vs. last marker, very short texts, printed "Page N sur M") run after every batch.

If you're digitising scanned documents in Arabic, or any mixed-script material, the short version is: use the best model, always pair the scripts, preprocess, keep an adaptive-threshold fallback, and never trust "100% done" until a check you didn't write for the happy path agrees.

The papers themselves are free to browse at wadifa-info.com.

Written with the help of an AI assistant from our own code and logs; all figures are from our production data.

One C# renderer for every social image: job cards in Arabic and French with GDI+

Wadifa Info — Wed, 30 Sep 2026 13:23:02 +0000

We run Wadifa Info, a Moroccan site that lists public-sector recruitment exams and job offers in Arabic and French. Every job page needs a preview image: for link previews on WhatsApp and Facebook, for square social posts, and for portrait pins. We used to have a white rectangle with a logo. Now one renderer draws all of them on the server, from the job's own data, with no design tool and no stock photos.

This post covers the parts that were harder than expected: fitting text of unknown length, Arabic right-to-left, picking a layout without randomness, and not letting the endpoint become an abuse vector. The stack is plain ASP.NET MVC and System.Drawing (GDI+).

One card model, three formats

The renderer takes a small object (institution, job title, specialty, number of posts, deadline, language) and a canvas size:

og 1200×630 for link previews
sq 1080×1080 for social posts
pt 1080×1350 for portrait feeds

Nothing in the layout is hard-coded to a size. Everything is expressed in a unit U = min(width, height) / 100, and the layout is decided from the shape: a wide canvas gets a text column with an art panel beside it, a tall canvas gets an art band on top with the text stacked below.

bool wide = W >= H * 1.5f;
var c = new WfCtx(g) { U = Math.Min(W, H) / 100f, Rtl = d.Rtl };

Adding the portrait format later was one line in the size switch. The layout code did not change.

Text that always fits

A job title can be "Technicien" or a 120-character ministry name. The rule we settled on is: shrink, then wrap, then drop optional rows, then ellipsis.

WFit tries font sizes from the maximum down to the minimum, wraps at each size, and returns the first size where the text fits the allowed number of lines:

static Font WFit(WfCtx c, string text, FontFamily fam, float maxPx, float minPx,
                 float maxW, int maxLines, out List<string> lines)
{
    float step = Math.Max(2, (maxPx - minPx) / 10);
    for (float px = maxPx; px >= minPx; px -= step)
    {
        var f = c.F(fam, px); var ls = WWrap(c, text, f, maxW);
        if (ls.Count <= maxLines && ls.All(l => WTW(c, l, f) <= maxW * 1.001f))
        { lines = ls; return f; }
    }
    // still too long at the minimum size: keep maxLines and end with an ellipsis
    ...
}

One case survives all of that: a single word wider than the column at the minimum size. For that, the draw call condenses the line horizontally instead of overflowing:

float w = WTW(c, s, f), sx = (maxW > 0 && w > maxW) ? maxW / w : 1f;
c.G.TranslateTransform(left, y);
if (sx < 1) c.G.ScaleTransform(sx, 1);

A slightly condensed word looks far better than a clipped one.

Arabic and French in the same card

Two things made bilingual rendering work:

Direction per string, not per card. A card in Arabic can contain a Latin acronym, and a French card can contain an Arabic institution name. Each string is measured and drawn with a right-to-left StringFormat if it contains Arabic characters, and left-to-right otherwise. GDI+ then does the shaping and joins the letters correctly.
One font family for both scripts. We load Tajawal (an open-licence family with Arabic and Latin glyphs) from the app's own folder with PrivateFontCollection, so the server does not need any font installed. Arabic lines also get more line height (1.30 against 1.14), because the letterforms need it.

The whole layout mirrors for Arabic: the art panel, the alignment anchor, the arrow in the call-to-action button.

One GDI+ detail to know: Font and StringFormat objects are not thread-safe, so they live in a per-request context object, never in static fields.

Variety without randomness

A feed where every card looks identical is dull, but a card that changes every time it is fetched breaks caching and confuses people who share it. So the template is chosen from a stable hash of the job:

static uint WfHash(string s)
{ uint h = 2166136261; foreach (char ch in s ?? "") { h ^= ch; h *= 16777619; } return h; }

t = cands[(int)(seed % (uint)cands.Count)];

The candidate list depends on the data. A card only gets the "key figure" template if there is a real figure to show (number of posts, days left when the deadline is within five days). There is no invented urgency: the status badge is computed from the real deadline.

The background art is vector, drawn in code: a network for IT jobs, arches for teaching, a pulse line for health, an eight-point star lattice as the default. Recently we added a "document" drawing (a white sheet with a CV-like skeleton) for pages that are about a document, such as CV and cover-letter templates.

Do not render arbitrary text on your domain

Generic pages (guides, salary tables) also get a card, built from the page title. The title travels in the image URL, which means anyone could request an image with any text on it, served from our domain. So the title is signed with an HMAC, and the endpoint refuses anything whose signature does not match:

if (t.Length == 0 || t.Length > 120 || !string.Equals(s, WfSig(t), StringComparison.Ordinal))
    return Redirect("/img/og-default");

If you build an image endpoint that takes text from the query string, do this from day one.

Caching

Rendering takes real CPU, so each image is written to disk under a key made of every input that affects the pixels, and served as a static file afterwards. Cards near a deadline include the date in the key, because their "N days left" badge changes daily. Everything else is sent with a one-week cache header.

What we would do differently

System.Drawing is Windows-only in modern .NET. It suits our hosting, but on Linux we would start with SkiaSharp.
We would design the portrait format first. Link previews are forgiving; tall formats expose every spacing mistake.
An earlier, unrelated endpoint on the site accepted unsigned tokens and had to be fixed after an audit. That is why this one was signed from its first version.

You can see the result on any page of the site, for example the civil-service salary grid: its link preview is one of these cards.

Have you built server-side image generation with right-to-left text? We would like to hear how you handled mixed-direction lines.