Two silent Arabic rendering failures worth checking if you generate synthetic training text
Not an issue with the model - a warning about generating Arabic training data, which
may be useful if any of your pipeline renders Arabic text to images.
I benchmarked Arabic text rendering across 3 fonts and 4 rendering paths this week and
found two failure modes that produce plausible-looking but malformed Arabic:
1. The standard arabic_reshaper + python-bidi preprocessing, which is the advice
almost every tutorial gives, now CORRUPTS Arabic on any renderer that already does
complex-text layout. Pillow 12 links Raqm/HarfBuzz, so shaping and the bidi reorder
happen twice. The word is "welcome":
| rendered as | |
|---|---|
| correct (no preprocessing) | مرحبا بكم |
| after reshaper + bidi | مكب ابحرم |
15/15 correct without it, 14/15 broken with it. The recipe is still required on a
renderer WITHOUT shaping - so the right question is which of the two you have, not
whether Arabic "needs" reshaping.
2. Font coverage. SF Arabic and Geeza Pro contain no Latin letters or digits at all,
so a sentence containing the year 2026 renders the digits as .notdef boxes. Checked
against the cmap tables, not by eye.
Both matter for synthetic data specifically: text rendered through either path looks like
Arabic at a glance, so it survives review, and a model trained on it learns malformed
letterforms or missing numerals.
Quick check for the first one: PIL.features.check("raqm").
The harness and per-case results are open (CC BY 4.0) if useful for validating a
rendering pipeline: https://huggingface.co/datasets/syamjithnk/arshape
Happy to run it against whatever renderer you use and share the result.
Edited: the original version put the two Arabic strings on one line either side of an
arrow. The bidi algorithm reordered them, so it read as the broken form producing the
correct one - the exact failure this post is about. They are in a table now, one per
row, which cannot reorder.