Three parsers lost the same three fields. The links.

When did anyone last check, field by field, what a PDF parser hands the model? On my resume, three plain text extractors each found 26 of 29 hand-listed fields, and all three missed the same three: the links.

pdftotext gave back line two as three words, LinkedIn, Portfolio, GitHub, with none of the three links behind them. PyMuPDF and pdfminer.six did the same. The URLs lived in link annotations rather than in the visible text.

The run put one resume PDF through five parsers, with no model involved, against 29 fields built by hand: 7 contact, 16 role, 6 education.

Read against the page, the output looked complete: all 26 fields printed on it came back. The links never did. Printing the URLs as visible text in the header took all three extractors to 29 of 29.

The two resume-specific parsers did worse on both versions. One returned 7 correct fields and 12 wrong on the first PDF, 9 and 11 on the second. The other returned 2 correct and 22 garbled, then 2 and 24.

Limits. One resume with one two-column layout, and a field list built by hand from that same resume. The text extractors score a field as found if the string appears anywhere in the output, while the structured parsers are scored by field slot, a stricter test. The five are the parsers that ran; others failed to run or duplicated one of these.

If a recruiter can click a field and the parser cannot see it, is that field on the resume or not?

Where the numbers live

• reports/parser_test.md
• reports/parser_test_v4_1_real.md
• reports/RESULTS.md
• canon/resume_fields.yaml
• resume/v4_1_A.txt

The parser round, with per-field tables for all five

One resume, one two-column layout, a hand-built field list. Structured parsers scored by field slot, a stricter test.