ManuelGarcia
Hi everyone,
I’m excited to share PaperForge, an open-source PDF platform built entirely in Elixir.
Build, secure, validate, and transform documents entirely in Elixir.
PaperForge started from a simple idea: generating professional documents should be a first-class capability of the BEAM. Applications should not need a browser, a headless rendering service, native compilation, or an external PDF executable to produce reliable PDFs.
PaperForge provides both a programmatic API and a declarative .paperforge format for reusable document templates.
What it supports
- Flow-based document layout with automatic pagination.
- Tables, lists, headers, footers, page templates, and navigation.
- Embedded fonts, Unicode text, images, SVG/vector output, QR codes, and barcodes.
- Charts, mathematical expressions, bibliographies, notes, references, and scientific-document features.
- Links, named destinations, outlines, annotations, attachments, and AcroForms.
- Document encryption, permissions, watermarks, content fingerprints, and digital-signature workflows.
- Declarative
.paperforgetemplates with variables, validation, conditions, loops, reusable components, themes, imports, and Design Systems. - HTML, Markdown, SVG, and PDF interoperability.
- Concurrent rendering, supervised jobs, telemetry, batch workflows, and production-oriented performance tooling.
The project remains pure Elixir by default. The core library does not require a browser, native rendering engine, or external executable.
Quick example
document =
PaperForge.new()
|> PaperForge.Flow.heading("Quarterly report", level: 1)
|> PaperForge.Flow.paragraph("Generated directly by the BEAM.")
PaperForge.write(document, "report.pdf")
For reusable, data-driven documents, templates can also live in a .paperforge file and be validated, compiled, and rendered without evaluating arbitrary Elixir code.
Why I built it
I wanted a document system that fits naturally into Elixir applications: deterministic, composable, observable, and safe to run under load.
The goal is not just to draw PDF pages. It is to make document generation, validation, security, accessibility, and production rendering feel like normal parts of an Elixir system.
1.4.1
This patch release focuses on rendering stability and declarative workflow hardening:
- Improved layout behavior across text, tables, charts, formulas, and forms.
- More robust declarative validation and error reporting.
- Rendering edge-case fixes and compatibility improvements.
- Deterministic output and public API compatibility preserved.
- Expanded regression coverage for document-generation workflows.
Links
- Hex: https://hex.pm/packages/paper_forge
- HexDocs: https://hexdocs.pm/paper_forge
- Changelog: https://github.com/Manuel1471/paper_forge/blob/main/CHANGELOG.md
- GitHub:
I would genuinely appreciate feedback from the community, especially around API ergonomics, PDF compatibility, declarative templates, and production usage patterns.
Thanks for taking a look.
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Werner
Wow, that’s really great…
A few days ago, there was a post about Tincture, now we have two PDF libraries written entirely in Elixir.
That’s really fantastic.
Thank’s a lot.
roflbobl
Really nice with the PHOENIX.md with great examples!
ManuelGarcia
Thank you both for the kind comments! I really appreciate it, and I’m glad the
PHOENIX.mdexamples were useful.For now, I’m planning to keep this version as the stable base for a while. I want to focus on fixing bugs, improving compatibility, and addressing any issues that come up before adding another large set of features. So if you try PaperForge and find anything strange, feedback and bug reports are very welcome.
There’s actually a bit of history behind the project. The first PaperForge code has been sitting on my computer for around a year and a half. At the time, the architecture was pretty bad, responsibilities weren’t separated properly, and I was also dealing with a fairly heavy workload, so I never really felt motivated to turn it into something public.
Over the last few weeks I’ve finally had the time to revisit it properly. I’ve also been using AI as a development tool to help me review the architecture, organize the refactoring, look for potential vulnerabilities and edge cases, and challenge some of my implementation decisions. That made it much easier to turn the old prototype into something I felt comfortable testing, documenting, and releasing publicly.
I’m also working on PaperForge Studio, a desktop visual editor built on top of PaperForge. I’m hoping to have an early beta available in the next few weeks. It will be completely optional — PaperForge itself will remain usable independently — but if anyone here is interested in trying the Studio beta when it’s ready, I’d be very happy to get feedback from Elixir users.
Thanks again for taking the time to check out the project!
ManuelGarcia
Small PaperForge 1.4.2 Maintenance update
Following up on the stabilization work I mentioned above, I’ve released PaperForge 1.4.2.
This is intentionally a small maintenance release rather than a feature release. Most of the work went into architecture, security, and making the internals easier to maintain going forward.
A few highlights:
Reorganized the internal source tree into explicit authoring, document, resources, layout, rendering, PDF, security, runtime, and legacy layers, while keeping the existing public API stable.
Added
ARCHITECTURE.mddocumenting the internal layers and dependency rules.Isolated the maintained legacy flow/table implementations from the current unified Flow layout engine.
Prevented untrusted
.paperforgetemplates from creating arbitrary BEAM atoms. Declarative identifiers now use bounded/internal or binary representations where appropriate, without changing the existing atom-based Elixir API.Tightened PDF page-import validation so malformed or out-of-range selections fail deterministically.
Reduced some temporary allocations in legacy rendering and added additional regression coverage.
There are no major new user-facing features in this release — and that’s intentional. For the moment I’m trying to keep the 1.4.x line stable, fix issues as I find them, and strengthen the foundations before moving on to larger additions.
As always, if anyone is using PaperForge and finds an edge case or something that behaves unexpectedly, reports are very welcome.
Thanks again for the feedback!
stocks29
This is great! I have a PDF generation project coming up so I’ll give this a whirl.
kenny-evitt
This looks amazing – thanks for sharing!
psantos
I was exactly looking for this … Thanks for sharing
ManuelGarcia
Thanks @stocks29, @kenny-evitt and @psantos! Really glad to hear PaperForge may be useful for actual projects.
If you end up trying it, I’d love to hear about any PDFs or workflows that behave unexpectedly. Real-world files have a way of finding cases that test suites don’t.
PaperForge 1.4.3 — Validation & Diagnostics
I’ve released PaperForge 1.4.3.
After the architecture and security work in 1.4.2, I wanted to make the next question a simple one:
When something goes wrong with a document, how much can PaperForge tell you about what actually happened?
PaperForge.inspect_document/1now provides a structured inventory of a document — pages, PDF objects, fonts, images, forms, links, bookmarks, destinations, security information and reusable resources.PaperForge.render/2can generate the PDF while returning diagnostics about the operation, including serialization time, memory, reductions, garbage collections, resource counts, output size and a SHA-256 fingerprint.Validation is also more expressive now.
PaperForge.ValidationResultdistinguishes structural errors that prevent serialization from authoring warnings that may deserve attention without making the document invalid.I also continued hardening untrusted input. PDF parsing can now be constrained by file size, object count, nesting depth and stream size, and new StreamData property tests fuzz declarative identifiers to verify that untrusted
.paperforgetemplates cannot grow the BEAM atom table.The goal of 1.4.3 isn’t to add more ways to create PDFs. It’s to make PaperForge easier to understand when something goes wrong and safer when the input isn’t under your control.
I’m intentionally keeping the 1.4.x line focused on making the existing platform more predictable and dependable before calling it a stable baseline.
And for those of you planning to try it: please send me the weird PDFs. Those are useful.
alvinkatojr
@ManuelGarcia, this is a pretty amazing project! You don’t know how many programmers’ lives you have saved by releasing this because PDF generation is a nightmare! Thank you for this!
ManuelGarcia
@alvinkatojr Thank you! That genuinely means a lot.
I actually went through something very similar a few years ago. We needed PDF generation, and solving that problem ended up meaning having an entirely separate microservice just for PDFs.
It worked, but having another service, another deployment, another runtime, and another piece of infrastructure to maintain just to fill that gap was frustrating.
That experience stayed with me, and it’s part of the reason PaperForge exists. I wanted PDF generation to be something an Elixir project could just do, without having to leave the BEAM or introduce another service simply because PDF tooling wasn’t there.
So hearing that PaperForge might save other developers from going through the same thing is incredibly motivating. Thank you!
And please keep the feedback coming — real projects are exactly what I want PaperForge to be tested against.
PaperForge 1.4.4 — Performance & Memory
I’ve just released PaperForge 1.4.4.
I actually developed much of this work alongside 1.4.3, but decided to split the releases rather than turn one update into a giant changelog.
While 1.4.3 was about understanding what happens during a render, 1.4.4 asks a different question:
How much unnecessary work are we doing while producing the PDF?
Quite a bit, as it turns out.
This release focuses on removing repeated computation and temporary allocations from some of the hotter paths in the rendering pipeline.
Repeated text measurements are now cached using a bounded process-local cache. Parsed TrueType programs and font subsets can be reused, and subset reconstruction is skipped entirely when text doesn’t introduce any new glyphs.
Some less obvious problems showed up too.
Footnotes and endnotes had quadratic list accumulation in part of their materialization path. Pagination was doing more list work than necessary. Large tables could repeatedly calculate the same default column widths. Those paths have now been changed to avoid that repeated work.
PDF serialization also keeps objects as iodata while calculating offsets instead of creating an intermediate binary for every object before final assembly.
I also changed the cache behavior itself. Reaching capacity no longer throws away the entire cache; entries are evicted incrementally using FIFO. Large compression inputs (>256 KiB) bypass the compression cache altogether so long-running render processes don’t unnecessarily retain large binaries.
There is also now an official
BENCHMARKS.mddefining small, medium, large, and concurrent workloads. The goal is to establish a reproducible baseline for future optimization work rather than relying on isolated benchmark numbers.PaperForge.RenderStatsformalizes the measurements returned byrender/2, including serialization duration, process memory, reductions, garbage collections, cache statistics, resource counts, output size, and a SHA-256 fingerprint.The theme of 1.4.4 is pretty simple:
do less work, allocate less, retain less.
I’m still deliberately keeping the 1.4.x line focused on strengthening what PaperForge already does rather than racing to add more features.
And as always: weird PDFs, large documents, ugly tables, unexpected behavior — send them my way.