Component
Backend (FastAPI server)
What problem does this solve?
Generated resumes and cover letters currently only come out as .docx — target_format is a hard Literal["docx"] in schemas.py, and both document_generator.py and docx_generator.py only know how to produce that one format. Meanwhile the backend already parses PDF just fine on the upload side (file_parser.py, via pypdf), so PDF isn't a foreign concept to this codebase, just a one-directional gap.
Practically: some application forms only accept PDF uploads, not DOCX, and plenty of people just prefer submitting a PDF regardless of what the ATS accepts, so they don't have to worry about the recipient's Word version mangling formatting.
Proposed solution
Extend target_format to accept "pdf" alongside "docx", and add a PDF rendering path. Before diving into implementation, this probably needs a quick decision on approach, since there are a couple of reasonable ways to do it:
- Render PDF from the same intermediate structure
docx_generator.py builds, using something like reportlab or weasyprint, independent of the DOCX path.
- Or generate the DOCX first (as today) and convert DOCX → PDF as a second step.
The first keeps both renderers independent (no risk of a conversion step introducing its own formatting bugs) but means maintaining two renderers in parallel; the second reuses one source of truth but adds a conversion dependency and whatever fidelity quirks come with it. Leaning toward the first, but wanted to flag it rather than just pick one silently.
To verify: uv run pytest with new coverage for the PDF path (coverage gate is 85%, so this needs real tests, not just a manual check), plus generating a resume with format=pdf end-to-end and opening the output to confirm it's readable and reasonably formatted.
Alternatives considered
Doing the PDF conversion client-side in the extension (e.g. print-to-PDF on the rendered document) instead of server-side — rejected since the backend already owns document generation and formatting fidelity, and keeping that logic in one place matches how the rest of generation is centralized.
Additional context
This is a schema + backend change (new target_format value, new renderer), so flagging it for discussion first per the contributing guide rather than jumping straight to a PR — mainly want agreement on the rendering approach above before writing the renderer.
Component
Backend (FastAPI server)
What problem does this solve?
Generated resumes and cover letters currently only come out as
.docx—target_formatis a hardLiteral["docx"]inschemas.py, and bothdocument_generator.pyanddocx_generator.pyonly know how to produce that one format. Meanwhile the backend already parses PDF just fine on the upload side (file_parser.py, viapypdf), so PDF isn't a foreign concept to this codebase, just a one-directional gap.Practically: some application forms only accept PDF uploads, not DOCX, and plenty of people just prefer submitting a PDF regardless of what the ATS accepts, so they don't have to worry about the recipient's Word version mangling formatting.
Proposed solution
Extend
target_formatto accept"pdf"alongside"docx", and add a PDF rendering path. Before diving into implementation, this probably needs a quick decision on approach, since there are a couple of reasonable ways to do it:docx_generator.pybuilds, using something likereportlaborweasyprint, independent of the DOCX path.The first keeps both renderers independent (no risk of a conversion step introducing its own formatting bugs) but means maintaining two renderers in parallel; the second reuses one source of truth but adds a conversion dependency and whatever fidelity quirks come with it. Leaning toward the first, but wanted to flag it rather than just pick one silently.
To verify:
uv run pytestwith new coverage for the PDF path (coverage gate is 85%, so this needs real tests, not just a manual check), plus generating a resume withformat=pdfend-to-end and opening the output to confirm it's readable and reasonably formatted.Alternatives considered
Doing the PDF conversion client-side in the extension (e.g. print-to-PDF on the rendered document) instead of server-side — rejected since the backend already owns document generation and formatting fidelity, and keeping that logic in one place matches how the rest of generation is centralized.
Additional context
This is a schema + backend change (new
target_formatvalue, new renderer), so flagging it for discussion first per the contributing guide rather than jumping straight to a PR — mainly want agreement on the rendering approach above before writing the renderer.