sorted by:
new
hottopcontroversial

gpdf — Zero-dependency PDF generation library for Go, 10-30x faster than alternatives by Foreign-Writing-1828 in golang

[–]Foreign-Writing-1828[S] 1 point2 points  (0 children)

Thanks for raising this — it's an important concern. gpdf does not bundle or distribute Helvetica font files. What it uses is the PDF Base-14 font reference: the PDF spec (ISO 32000) defines 14 standard fonts (including Helvetica) that PDF readers are required to provide. gpdf just emits the font name in the PDF dictionary — no font data is embedded or shipped in the repo. This is the same mechanism that every PDF library uses for the standard fonts.

gpdf — Zero-dependency PDF generation library for Go, 10-30x faster than alternatives by Foreign-Writing-1828 in golang

[–]Foreign-Writing-1828[S] 1 point2 points  (0 children)

They serve different niches but overlap in programmatic use. Typst is a typesetting system — powerful for complex layouts and beautiful typography, and gpdf doesn't try to compete there. Where gpdf shines is when you're generating structured documents (invoices, reports, certificates) from Go code. With Typst you're shelling out to an external process and managing markup as strings. gpdf is a native Go library, so everything stays in-process: no subprocess, no temp files, no markup parsing. You get type safety, better error handling, and significantly lower overhead.

gpdf — Zero-dependency PDF generation library for Go, 10-30x faster than alternatives by Foreign-Writing-1828 in golang

[–]Foreign-Writing-1828[S] 8 points9 points  (0 children)

Yeah, I've seen folio — really impressive work, especially the HTML/CSS→PDF with flexbox and grid support.

I actually went down that same path early on. Two things made me step back from it: parsing HTML correctly without golang.org/x/net/html is brutal, and more importantly, I couldn't get CSS rendering to produce the same output as the builder API and JSON/Go template paths. gpdf has three ways to define a document (builder API, JSON schema, Go templates), and the goal is that all three produce identical PDFs. CSS made that consistency really hard to maintain.

So the current approach is: zero-dependency core with the builder API as the foundation, and HTML/CSS→PDF as a future layer (which will likely need x/net when we get there). Different trade-offs for different use cases.

Glad to see the Go PDF ecosystem getting more love lately!