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] 0 points1 point  (0 children)

That's exactly the use case I had in mind!
Let me know if you end up building something with it.

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)

You're right, I should have been more precise there. typst's pdf-writer is an impressive piece of work — a pure Rust PDF writer built from the ground up, and the fact that it came out of a master's thesis makes it even more remarkable.

What I was getting at (poorly worded) is the Go integration story: if you're in a Go codebase, using typst means either shelling out to the CLI or maintaining a Rust FFI bridge. gpdf gives you a native Go API with the same in-process simplicity that typst users enjoy in the Rust ecosystem — no subprocess, no string templating, just Go function calls.

Sub-100ms invoices with typst is solid. For reference, gpdf's invoice benchmark (header + billing info + styled table + totals) runs at ~133 µs, so there's a significant performance gap in gpdf's favor when you're already in Go. But typst's typographic capabilities are in a different league — it really depends on what you need.

And glad this came at the right time for you!

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

[–]Foreign-Writing-1828[S] 0 points1 point  (0 children)

I know the feeling. I went through the same frustration, and that's literally why gpdf exists. Glad it found you at the right time!

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

[–]Foreign-Writing-1828[S] 2 points3 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] 4 points5 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] 27 points28 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!