Idea: one-line fontenc hardening for the pdflatex fallback (accented CVs)

[9scorp4]

Idea: one-line fontenc hardening for the pdflatex fallback (accented CVs)

TL;DR: this does not reproduce on the documented lualatex path. It only bites
users who fall back to pdflatex, where the CV's text layer comes out decomposed and
tools/verify_pdf.py --require silently fails on any accented string. Asking whether a
one-line defensive \usepackage[T1]{fontenc} is wanted before I open a PR, per
CONTRIBUTING's "an Idea thread costs nothing".

How I hit it

lualatex broke on my machine (luatexbase.sty not found, no PDF produced), so I fell
back to pdflatex, which compiles the stock template cleanly. Everything looked correct:
2 pages, right colours, clean visual inspection, and the extracted text read fine in the
terminal. The ATS keyword check still failed on every accented term.

What's actually happening

Without fontenc, pdflatex writes accented characters into the text layer decomposed
(NFD) rather than precomposed (NFC):

	code points for è
pdflatex, no T1	U+0065 U+0300 (e + combining grave)
pdflatex, T1	U+00E8
lualatex, either way	U+00E8

It hides well because it renders correctly twice — the PDF page looks right, and most
terminals display e+U+0300 as è. Only exact comparison fails. normalize_text() in
tools/verify_pdf.py is whitespace-only (" ".join(text.split())), so a --require
string typed as NFC never matches an NFD text layer.

Reproduction on the real path

Stock cv/main_example.tex at 79cd383, placeholders filled with the kind of accented
content /apply produces for a non-English market (Genève, Université, Lefèvre,
Zürich, Chargée). Compiled per the documented commands, extracted through both
backends verify_pdf.py uses:

engine	fontenc	pdftotext	pypdf	--require "Genève"
lualatex	none	NFC	NFC	PASS
lualatex	T1	NFC	NFC	PASS
pdflatex	none	NFD	neither form found	FAIL
pdflatex	T1	NFC	NFC	PASS

Both extractors agree under lualatex, so there's no backend-dependence to worry about.
5/5 accented keywords intact with T1 under pdflatex; 0/5 without.

Why I'm not just opening a PR

Because on your documented path this isn't a bug. 05-cv-templates.md says compile with
lualatex, CI smoke-tests with lualatex, and lualatex is correct with or without the change.
By the standard in CONTRIBUTING — reproduce on the real path, not a constructed input — the
premise fails, and I'd rather ask than send you a PR whose framing is wrong.

The counter-argument, which is why I'm raising it at all: the repo already acknowledges
pdflatex gets used (05-cv-templates.md notes pdflatex "often fails on modern MiKTeX with
fontawesome5 font-expansion errors", which implies people try it), and a broken lualatex
install pushes users there with no warning that their text layer is now degraded. The
failure is silent and passes every existing check.

What a PR would contain, if wanted

1. \usepackage[T1]{fontenc} in cv/main_example.tex and in the documented preamble in
   05-cv-templates.md. No-op under lualatex, protective under pdflatex.
2. A short note in the ATS Parseability section explaining the NFD failure mode.
3. framework_version bump on 05-cv-templates.md, CHANGELOG entry under Fixed.

Roughly ten lines, one concern.

Two alternatives that may fit your philosophy better, and I have no attachment to mine:

• Normalize in tools/verify_pdf.py instead — unicodedata.normalize("NFC", ...) in
  normalize_text(). Fixes the detection rather than the cause, helps any CV regardless of
  engine or template, and is arguably where the bug really is: the verifier's job is to
  catch text-layer problems and this one slips through it.
• Do nothing to the template, document it only — one line in the compile section saying
  a pdflatex fallback needs fontenc and why.

Happy to build whichever, or none. Also happy to be told the answer is "install lualatex
properly", which is fair.

[MadsLorentzen]

Confirmed from your writeup plus the repo's own layout - and the diagnosis pattern (renders correctly twice, fails only on exact comparison) is well caught. Two notes for the PR you're offering: (a) the one-line \usepackage[T1]{fontenc} belongs guarded for the pdflatex path in the stock templates, and it must not change lualatex output (your table says it doesn't - the test should pin that); (b) since #385 (yours as well) proposes normalize_text folding, consider whether NFC-normalizing in normalize_text() is the more root-cause fix that makes the CVs robust regardless of engine - if so, one PR covering both discussions with unicodedata.normalize("NFC", ...) plus the substitution folding may be cleaner than two. Invitation is yours either way - per the reservation norm.