Hi HN, I'm Carlos. I built Folio because the PDF generation landscape hasn't changed in years.
In Go: gofpdf was the standard library but it was archived in 2021 and never had a real layout engine. Nothing serious filled the gap.
In Java: iText is excellent but switched to AGPL. Using it commercially without their license is a violation. Apache PDFBox exists but the API is genuinely painful for anything beyond basic use.
The common workaround is Puppeteer. Spin up headless Chrome, render HTML, print to PDF. It works but you're shipping a 300MB Chrome binary, cold starts are 2-5 seconds, and it can't do digital signatures, AcroForms, or PDF/A compliance.
So I built Folio against the ISO 32000 spec. Full layout engine, HTML to PDF converter, PDF reader/merger, forms, barcodes, signatures, and PDF/A. Apache 2.0, no fees.
The part I'm most happy with is the WASM build. The whole library compiles to WebAssembly and runs in the browser. The playground at https://folio-playground.pages.dev lets you paste any HTML and get a PDF in milliseconds, no server, no signup, your documents never leave your machine. No other PDF library has this.
A few technical notes for those curious:
The layout engine is plan-based. Layout is a pure function with no mutation during rendering. This makes page break splitting clean and lets elements be measured multiple times safely.
Font subsetting was the hardest part. Getting TTF parsing, glyph ID mapping, and CMap generation right took longer than everything else combined.
One external dependency: golang.org/x/image. That's it.
What's next: a template library (invoice, report, resume, the shadcn model where you own the code), a Java SDK via Panama FFI, and a hosted API for teams that don't want to self-host.
carlos7ags•1h ago
In Go: gofpdf was the standard library but it was archived in 2021 and never had a real layout engine. Nothing serious filled the gap.
In Java: iText is excellent but switched to AGPL. Using it commercially without their license is a violation. Apache PDFBox exists but the API is genuinely painful for anything beyond basic use.
The common workaround is Puppeteer. Spin up headless Chrome, render HTML, print to PDF. It works but you're shipping a 300MB Chrome binary, cold starts are 2-5 seconds, and it can't do digital signatures, AcroForms, or PDF/A compliance.
So I built Folio against the ISO 32000 spec. Full layout engine, HTML to PDF converter, PDF reader/merger, forms, barcodes, signatures, and PDF/A. Apache 2.0, no fees.
The part I'm most happy with is the WASM build. The whole library compiles to WebAssembly and runs in the browser. The playground at https://folio-playground.pages.dev lets you paste any HTML and get a PDF in milliseconds, no server, no signup, your documents never leave your machine. No other PDF library has this.
A few technical notes for those curious:
The layout engine is plan-based. Layout is a pure function with no mutation during rendering. This makes page break splitting clean and lets elements be measured multiple times safely.
Font subsetting was the hardest part. Getting TTF parsing, glyph ID mapping, and CMap generation right took longer than everything else combined.
One external dependency: golang.org/x/image. That's it.
What's next: a template library (invoice, report, resume, the shadcn model where you own the code), a Java SDK via Panama FFI, and a hosted API for teams that don't want to self-host.
Playground: https://folio-playground.pages.dev Repo: https://github.com/carlos7ags/folio
Happy to talk about the PDF internals, the WASM build, or the layout engine architecture.