Reading Arabic and English CV PDFs: a reproducible experiment

October 1, 2026 update: eight distinct content samples instead of one underlying CV

We expanded the experiment to eight independently authored synthetic CVs: a graduate, teacher, engineer and lawyer in each of Arabic and English. Each CV has four text layouts and an image-only control, giving 40 PDFs and 80 measurements across two extractors. These are not 40 independent resumes or customer files. Each language uses a different fictional career, not a matched translation.

Summary: both extractors recovered all reference words and all seven fields from the 16 English text PDFs under our rules. Across the 16 Arabic text PDFs, word recovery ranged from 74.79% to 93.02% with pypdf and 88.19% to 91.60% with PyMuPDF. Both returned empty text from the eight image-only controls without OCR. These percentages measure literal text recovery, not ATS scores or hiring probabilities.

Download the complete expansion — version 2

• Version 2 archive: all 40 PDFs, 80 raw outputs, source and repeat-extraction instructions.
• Every measurement, including complete, incomplete and empty extractions.
• All eight reference CVs, their expected fields and complete text.
• Specimen manifest, generation settings and file hashes.
• Protocol and reproduction instructions.

Names, organizations and careers are fictional; emails use example.com and phone numbers are deliberately invalid. The reference content was AI-assisted and reviewed for this experiment. We did not use customer data or real job applications.

Diverse specimens and results by profile

Each range covers the four text layouts for that profile, excluding the raster control. Specimen links open the single-column version; all other layouts are in the archive.

The CVs include education, skills, training and languages, with internships and projects for graduates and profession-specific experience and projects for the other groups. Reference tokens are Unicode letter/number units under our protocol, not a word processor's word count.

What stayed fixed and what changed?

We used Tajawal at 16 CSS pixels (12 points), A4 paper and 18mm margins, with the same research HTML generator outside Astr's CV builder. Each profile has one column, two columns, a table, a forced page break after its first three sections, and an image-only copy of every single-column page at 144dpi. This produced 32 text PDFs and eight raster controls, totaling 63 pages. Some single-column files span two pages; sparse pages were retained and settings were not changed after inspecting the results.

Extraction used pypdf 6.10.0 and PyMuPDF 1.26.7, without OCR, spelling repair or geometric reordering. The version 1 measurement and normalization code is unchanged: literal token recall with repetitions, seven complete fields and the sequence of six headings. Each CV has its own reference and denominator. Fields are the name, email, dummy phone, two date ranges, degree and employer or internship organization.

An altered or missing heading makes sequence unmeasurable, not an observed ordering failure. A field's presence does not prove entity recognition or correct association with a job. Full token recovery does not prove that every sentence is in the correct order.

Successful and incomplete outputs, without selecting only favorable cases

A successful case: all reference tokens and seven fields were recovered from the English electrical-engineer CV. Compare its PDF above with the raw pypdf text. This is success on these metrics, not acceptance by an employer's system. An omission: the Arabic lawyer PDF displays “مستشار عقود | مكتب العدالة الافتراضي”, but the raw pypdf output keeps the role without the office name. A readable page can lose an important detail during extraction. Changed characters, not a missing organization: the Arabic graduate reference contains “مركز البيانات الافتراضي”, while the raw PyMuPDF output contains “مركز البيانات االفتراضي”. The complete-field match therefore fails even though a person may infer the intended name. We did not silently repair the text to improve the result.

Both tools produced empty text for every image-only control. This is not an OCR quality finding: OCR was not run.

Interpretation limits and citation

These are eight purposively selected synthetic content samples with correlated layout variants, one font and one generator. They do not show that English always works better or that a profession has a higher failure rate. Language is confounded with different content; this is not a controlled translation comparison. It also does not measure Astr's production exports, grader scores or commercial ATS performance.

We visually reviewed all rendered pages and repeated extraction from the same PDF bytes: all 80 measurements and raw-text hashes matched. All planned cases are included. To compare with version 1, use its corresponding Tajawal/16px conditions, not a pooled average mixing its two fonts and two sizes with this expansion.

Suggested citation for this expansion: Astr Team, “Reading Arabic and English CV PDFs: a reproducible experiment,” version 2, October 1, 2026; eight synthetic CVs, 40 PDFs, 80 measurements. You may reuse the specimens and results with attribution and a link to this study. Version 1 files and results remain unchanged below so earlier citations stay verifiable.

What should you do with your own CV? Copy its name, email, organizations and dates into plain text, then review the imported fields after uploading it to an application system. If something is missing, try another extractor or re-export from the source rather than relying on appearance alone.

Version 1 archive — September 25, 2026

The following section records the separate original experiment: 20 variants of one Arabic CV. Its figures refer only to those original files, not the expansion above.

Summary: a readable page can still produce incomplete text

On September 25, 2026, Astr tested 20 PDF variants of one synthetic Arabic CV with two text-extraction tools. These are not 20 people or customer resumes. The files were generated independently of Astr's CV export engine; this is not a product-template comparison.

Both tools recovered the email address, including underscores, in all 16 text PDFs. However, pypdf did not return the complete employer name in any of them, while PyMuPDF changed character sequences in some Arabic words. Four image-only PDFs produced no text with these non-OCR extraction settings.

This is not an ATS acceptance test or a measure of a candidate's quality. Findings apply to the published specimens, tool versions and settings, not recruitment probabilities or every PDF reader.

Download the evidence

• Complete archive: all 20 PDFs, raw text, source and reproduction instructions.
• All 40 measurements in JSON.
• Reference text and expected fields.
• File manifest, SHA-256 hashes and generation environment.

The email uses example.com, the phone number is deliberately invalid, and the names and organizations are fictional. We test literal recovery, not whether the contact details are valid.

Experimental design

We held the content of a fictional mathematics teacher's CV constant and varied:

Two fonts × two sizes × four layouts produced 16 text PDFs, plus four image-only controls. There are 28 pages in total. Some 16px one-column files naturally span two pages; “one column” does not mean “one page.” These sizes are experimental variables, not readability recommendations.

Generation used HTML, Puppeteer 24.4.0 and Chrome 134.0.6998.35 on Windows, A4 paper, 18mm margins and embedded fonts. This records our installed generator, not the latest browser. Raster controls retain every source page at 144 dpi.

Extraction used pypdf 6.10.0, calling extract_text(), and PyMuPDF 1.26.7, calling get_text('text', sort=False). Both used direct plain-text extraction without OCR, geometric reordering, spelling repair or AI cleanup. These libraries are not recruitment systems.

What the metrics mean

• Word recovery: count matching Unicode letter/number tokens against the reference, including repetitions. There are 136 reference tokens, including Latin words and numbers but excluding punctuation. This is literal recall, not an ATS score, semantic accuracy or a word-order test. Joined or damaged words may not count even if a person can infer them.
• Seven complete fields: name, email, dummy phone, two date ranges, degree and employer. Presence does not establish that a parser recognized a field's role or associated a date with the right employer.
• Six section headings: test exact normalized presence and declared sequence. For two columns, the reference reads the full right column before the left. If any heading changes or disappears, order is not measurable, rather than automatically incorrect. This does not test every sentence within sections.

Normalization uses Unicode NFKC, removes Arabic diacritics, tatweel and directional control characters, and collapses whitespace. It does not fix reversed letters, join split words or correct hamza sequences. Raw outputs are included so normalization cannot conceal the evidence.

Measured results

The 16 text PDFs

Field presence does not establish complete extraction. PyMuPDF retained all seven fields in eight specimens, but their word recovery was still 90.44%, not 100%.

Layout and font within this experiment

This does not establish that Cairo is unsuitable for resumes, or that two columns are universally better. The outcome reflects an interaction between the specific font file, generator, extractor, settings and selected text. Higher recall is not proof of semantic understanding or complete reading order.

The four image-only controls

Both tools returned empty text in all four controls. OCR was not run, so this is not an OCR performance finding. A different pipeline with optical character recognition may read the images; its accuracy needs a separate experiment.

Two examples behind the numbers

An employer visible on the page but absent from extracted text

The one-column Tajawal specimen visibly contains “معلم رياضيات | مدرسة المثال التجريبية”. The raw pypdf output retains the role but not the school name. A visually intact line did not imply complete extraction.

A changed character sequence in the name

The reference name in the two-column Cairo specimen is “سالم المثال التجريبي”. The PyMuPDF output returns its final word as “التجرييب”. We did not silently correct it or assume that other readers would reproduce the same issue.

For a text-versus-image comparison, open the image-only specimen and try selecting its name. The content looks similar but is not stored as extractable characters.

Practical checks before sending a CV

• Follow the employer's requested file format first.
• Copy the PDF into a plain-text editor. Check the name, email, employers and dates, not only the first line.
• Try another reader if output is incomplete. Different extraction does not mean your original information changed.
• For an image-only file, export text from the original document where possible, or use OCR and review its output manually.
• Do not turn a word-recovery percentage into an employment promise or a verdict on experience.

You can organize your information in the CV builder and review a file with the CV grader. This experiment does not validate Astr's scores or test its production exports; those require separate evaluation.

Limitations and reproducibility

This is a small, correlated set from one underlying CV and one generator. We did not test Word exports, every font, every CV length, commercial ATS vendors or hiring outcomes. We do not report confidence intervals or a general ranking of extractors.

We reviewed rendered pages and raw text, then repeated extraction on the same bytes: the measurements matched. The archive includes versions, hashes and executable source. A different environment, tool version or regenerated PDF can change results. The methodology log also discloses pilot harness issues corrected before these final findings.

Suggested citation: Astr Team, “Reading Arabic CV PDFs: a reproducible 20-file experiment,” September 25, 2026, version 1. Specimens and results may be reused with attribution and a link to this study. Fonts and third-party tools retain their own licenses.

Tool references

• pypdf text-extraction documentation explains extraction limitations and the distinction from OCR.
• PyMuPDF text documentation describes why plain output may differ from expected reading order.

The references explain the tools; our downloadable experiment, not an external study, is the source of the table values. For corrections, contact Astr with the specimen ID, tool version and output.