PDF

A PDF is a fixed page. Everything in it, text, rules, a table's alignment, a form field's box, is placed at a coordinate and stays there. That is the whole reason to reach for the format and the whole reason it is awkward: a PDF is right when the layout is part of the message (a filled form, a signed-looking statement, a tear sheet that must print identically everywhere) and wrong when the user will want to edit the content later.

Two jobs live here and they barely overlap. Reading a PDF the user hands you: find out what it is, pull the text and tables, look at the pages that matter. Producing one: fill an existing form, assemble pages, or draw a new document. Both end the same way, by rendering to PNG and looking, because nothing else in this toolchain can see the page.

User preferences override these defaults. A template the user supplies, a house font, a filename convention, a specific page size: those outrank every rule here. The rules below are for when nothing has been specified.

Decide: Which Output?

Want	Use
Read, search or summarise a PDF the user supplied	this skill: info.py, then extract.py, then render.py
Fill in a fillable form the user supplied	this skill: forms.py inspect, fill, then render and look
Merge, split, rotate or password-protect existing PDFs	this skill: pages.py
A fixed-layout artifact built from data: a tear sheet, a filled form, a certificate, a cover page	this skill: reportlab, below
A long prose document the user may edit or that must match a house Word template	build the docx, then soffice --convert-to pdf (below). The docx is the deliverable; the PDF is a rendering of it
A research note with charts the user will read on screen and may print	html-report, then the browser's print to PDF
A model the user will keep working in	xlsx
A dataset for another program	.csv, not a PDF