// the find
carlos7ags/folio
PDF library for Go: layout engine, HTML to PDF, forms, signatures, barcodes, and PDF/A. Apache 2.0.
Folio is a pure-Go PDF library that covers the full stack: a plan-based layout engine, HTML+CSS to PDF conversion (in-process, no headless browser), AcroForms, PAdES digital signatures, barcodes, redaction, and PDF/A compliance. It targets Go developers who need to generate or manipulate PDFs without shelling out to Chromium or pulling in a C dependency. The C ABI export and Java SDK are a bonus for polyglot shops.
- Three external dependencies, all from golang.org/x/ — image, net, text. For a library with this feature surface (RTL shaping, OpenType GSUB/GPOS, CJK, PDF/A), that's a disciplined dependency graph and means no vendoring surprises.
- The plan-based layout engine is a real design win: layout is a pure function, no mutation during rendering, elements can be measured multiple times safely. Deterministic byte-for-byte output is something most PDF libraries don't bother guaranteeing, but it matters for diffing and caching.
- The i18n pipeline is more complete than anything else in the Go ecosystem: UAX #9 bidi + Arabic contextual shaping for RTL, a five-phase OpenType pipeline for Devanagari, and JIS X 4051 kinsoku shori for CJK line-breaking. If your PDFs need to handle non-Latin scripts seriously, this is not an afterthought.
- PAdES B-B, B-T, and B-LT with an external Signer interface means you can plug in an HSM or KMS without forking the library. That's production-grade signature support, not just slapping a visual stamp on the page.
- 826 stars and 43 forks is thin for a library of this ambition. The feature list is impressive but real-world production validation is sparse — you're early-adopting something that hasn't been stress-tested by many teams yet. Bug surface for edge-case PDFs will be nonzero.
- HTML→PDF CSS coverage is always partial, and 'supports 40+ HTML elements' is deliberately vague. The CSS_SUPPORT.md file exists specifically because there are known gaps. You need to audit that doc against your actual HTML before committing; rebuilding your templates after discovering a missing property is painful.
- The PDF reader's completeness for parsing existing PDFs in the wild is not quantified. Redaction and merge work on PDFs you generated yourself will be fine; how well the parser handles malformed, encrypted, or heavily compressed source PDFs from third parties is an open question.
- GPOS LookupType 6 (mark-to-mark positioning for stacked diacritics) is openly listed as a roadmap item. Anyone generating Arabic or Devanagari with complex combining marks may hit rendering bugs today, and the fix timeline is unclear.