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
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
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 5- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (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.