Lucid CV generic résumé: three variants compared

Introduction

The three variants

All three variants present the same Cybersecurity & AI Researcher résumé. The number before c is the number of columns and the number before p the number of pages, so 1c1p is one column on one page. The one-page variants are shortened versions of the full two-page text. In 2c1p the left column holds About, Experience, Education and Projects, and the right column holds the remaining sections.

A phrase is one piece of text that must survive extraction intact: a heading, an entry, a bullet, a contact field. Each variant is checked against its own phrases.

How the résumé is read back

Before an ATS can recognize a name, a job title or a date, it has to pull the text out of the PDF, and extraction software differs in how it does that. Every PDF is therefore read by thirteen engines: the libraries behind common PDF viewers and Linux tools (poppler, MuPDF, PDFium, pdf.js, Ghostscript), Python and Java document pipelines (pdfminer, PDFBox, Tika), several in more than one mode, and Tesseract, an OCR engine that reads the rendered page like a scanner.

Strict and advisory engines

Each engine is either strict or advisory for a given layout.

• A strict engine is expected to read the layout perfectly; missing or scrambling even one phrase fails the test.
• An advisory engine has a known limitation no résumé can fix; its results are reported but never fail a test.

Tesseract is advisory everywhere: it reads pixels, not the PDF’s text, so its errors measure the OCR rather than the document. In two columns, the engines that rebuild lines across the full page width merge the columns, so they are advisory there, and two engines that sort text by position are advisory for reading order only. In one column, every engine except Tesseract is strict.

Scoreboard

Five tests can fail a résumé; the word-gap test only reports. Every variant was built and tested from scratch.

1 · Real word spaces

What it tests. Whether each gap between words is stored in the PDF as an actual space character, not just as extra distance between letters. Without one, an extractor has to guess where words end, and some guess wrong and run words together. The table counts space characters per text font.

Discussion. All three variants store every word gap as a real space character, so no extractor has to guess where words end. The totals only follow the amount of text. Neither the compressed style nor two columns changes how gaps are stored, since that is set by the typesetting engine and the template, not by the layout.

2 · Word-gap characters

What it tests. Test 1 checks how word gaps are stored in the PDF; this one checks what each engine returns for them. It lists any gap that comes back as something other than an ordinary space, above all the no-break space, which Java-based parsers do not treat as a separator and so read the two words as one. It only reports and never fails.

Discussion. All thirteen engines, Tesseract included, return a plain space for every word gap in all three variants, consistent with test 1: a real space character leaves nothing an engine could turn into a no-break space. No Java-based parser would run two words together.

3 · Icons extract as whitespace

What it tests. The contact line marks each field with a small icon (an envelope, the LinkedIn logo). Every icon must extract as a blank space, not as a stray letter or icon name that would corrupt the email or link next to it.

Discussion. All three variants share the same contact block (two brand icons for LinkedIn and GitHub, four solid icons for the other fields), and all six icons extract as a plain space in every build. This is expected: icon extraction is set by the template, so layout choices cannot change it.

4 · PDF/A-2B conformance

What it tests. PDF/A is the archival PDF standard: every font embedded, no outside dependencies, a file that opens the same everywhere. The reference validator veraPDF confirms that each file really conforms to PDF/A-2B, since the PDF/A label in the metadata proves nothing on its own.

Discussion. All three files are valid PDF/A-2B. The photo, about 2.6 MB of 1c2p and 2c1p, does not affect conformance, but it is the whole size difference, so the photo-less 1c1p suits portals that limit upload size.

5 · Text extraction

What it tests. The core test: every phrase must appear, complete, in each engine’s text. Differences that do not change the meaning (dash and quote styles, ligatures, letter case) are ignored.

Two-column splicing in 2c1p

The three engines that lose phrases in 2c1p rebuild each printed line across the full page width, so a phrase that wraps in one column gets the other column’s text inserted where it breaks. Accordingly, 21–23 of the missing phrases are long, wrapping ones, spread over every section.

• Built a federated learning anomaly-detection and classification                Personal: Data-driven, Independent,  PoC for payment fraud detection, uncovering undetected fraud                   Organized, Systematic, Adaptable  and cutting detection time from weeks to minutes.

Discussion: two columns. Every strict engine returns every phrase in all three variants, so the text stored in the PDF is complete whatever the layout. The only difference comes from two columns: in 2c1p, poppler-layout, ghostscript and pdfbox-sorted recover only 67–68% of the phrases. This is not a fault in the PDF: these engines cannot separate side-by-side columns, and they return 100% of both one-column variants. The compressed style causes no losses.

Tesseract: OCR misses by cause

Discussion: Tesseract OCR. Tesseract reads a rendered image of the page, not the text stored in the PDF, so its misses are OCR character errors rather than layout problems. As the table shows, they concentrate on the capital AI, which the sans-serif face makes hard to tell from Al, and on Czech and Slovak diacritics. Their number follows how often these strings occur, so the shortest variant, 1c1p, has the fewest. One stray character is new since the previous report: the 1c2p surname, set in Source Sans 3 instead of Source Sans Pro, comes back as Goldschmiadt. Rendering at 600 dpi does not help: the AI, diacritic and URL errors recur unchanged, and a few different stray characters replace the old ones, for 13 / 9 / 9 misses against 13 / 6 / 8 at 300 dpi.

Possible fix. The AI errors, and the Scholar URL, whose capital I comes back as l, have one cause: in Inter, the capital I and the lowercase l are both a plain vertical stroke, so OCR has to guess. The fix is a body typeface whose capital I and lowercase l differ in their regular shapes, for example an I with serifs or an l with a tail. The dropped diacritics are a different matter: they come from OCR running with an English-only language model, as in this test setup, and no change of font would fix them.

Practical relevance. In practice, the OCR errors matter little. ATS parsers work primarily with the text stored in the PDF, and since this file is tagged, PDF/A-2B-compliant and its text reads back completely, a fallback to pure OCR is unlikely. The OCR results are therefore for informational purposes only.

6 · Reading order

What it tests. Finding every phrase is not enough if they come back scrambled: an ATS that reads a date after the wrong employer files it under the wrong job. The test scores how much of each engine’s output keeps the order the text is stored in, from 0 to 1 (perfect). The body must score 1.00 in every strict engine; the contact header is only reported, since the order of contact fields carries no meaning.

In brackets: phrases in order / phrases found, so an engine that lost phrases is scored on fewer of them. The reference order comes from poppler-raw, which outputs the text exactly as stored.

AboutExperienceEducationProjectsSkillsCourses & CertificationsSelected PublicationsVolunteering

About Skills Researcher with 9 years of applied research and R&D experience,… (rest of the About paragraph) Professional: Artificial Intelligence &…Tools: Python for AI (numpy, pandas,…Personal: Data-driven, Independent,…Languages: English (full professional…Experience

Discussion. In both one-column variants every engine returns the body in document order, so order is a problem only in two columns. There, the seven engines that output text as stored (poppler-raw, mupdf, pdfium, both pdf.js builds, pdfbox, tika) keep a perfect 1.00, because the template stores each column as one continuous block. The engines that re-sort text by position depart from it to different degrees: pdfminer still reaches 1.00, poppler moves one block (0.86), and the three side-by-side engines also scramble what they recover (0.71).

Summary

• Passed in all three variants: every test. Real word spaces, icons, PDF/A-2B, and phrase extraction and body order in every strict engine. Every engine returns plain U+0020 word gaps.
• One column reads back perfectly. In both one-column variants, compressed or not, all twelve text-reading engines return every phrase with the body in order. The only deviation is cosmetic: poppler lists LinkedIn last in the compressed variant’s header, which is reported but never fails.
• Two columns is the only layout with real extraction issues. Three engines merge the columns and recover only 49–50 of 73 phrases. They and poppler also reorder the body. An ATS using one of them would receive merged columns, yet the PDF is sound: the seven engines that keep the stored order read it perfectly.
• OCR errors do not depend on the layout or resolution. Tesseract misreads the same characters in one and two columns, at 300 and 600 dpi alike; its miss count follows the amount of text, give or take a stray character.
• Recommendation: where the ATS is unknown, submit a one-column variant. Keep two columns for human readers or systems known to keep the stored text order.

Limits

• Three documents, as written today. The variants differ in content as well as layout, so count differences partly reflect the text.
• Order is measured against the stored order (read by poppler-raw, which therefore always scores 1.00). A PDF that stored its text in the wrong order would shift the reference rather than fail the test.
• The OCR diagnosis is automatic, from the first differing character after the tests’ normalization; the one ambiguous case (the 1c1p skills line) was checked by hand.
• Hosted commercial parsers cannot be measured locally. Each runs one of these engines, or a similar one, before its own analysis.

Appendix

All three pipeline runs exited 0. Every figure here comes from their run.log, pipeline.json, order.json and the 13 per-engine extractions. The 2c1p loss breakdown and the Tesseract diagnosis were computed from those files with the tests’ own normalization.