Reading a spreadsheet somebody emailed you

files/CSV, files/XLSX and files/PDF cover the formats that arrive by mail, and in the case of PDF leave as attachments too.

They exist because these are the least interesting problems in an application and the ones most likely to pull in a large dependency. A customer sends a product list as a spreadsheet. An invoice has to go out as a PDF. Neither is a feature anyone describes in a pitch, and both are load-bearing.

The readers do the tedious part: CSV working out whether the file uses commas or semicolons, XLSX unpacking its zip container and shared string table, both handing back rows you can loop over. Combined with the ORM that makes an import a short route rather than a project.

files/PDF goes both ways: generate a document, and read text back out of one. Generation is what invoicing needs, and factuur.software drove that. Reading is what a document workflow needs, where a PDF arrives and something has to be pulled out of it.

The design rule for all three is the same and worth stating: they are readers, and in one case a writer, not abstractions. There is no document object model in front of the format, no attempt to unify a spreadsheet and a PDF into one idea of a file. You get the rows, or you get the bytes. Anything cleverer would be a second thing to learn on top of a format you already understand.

Engine 1.0. See the files group in the manual.