DEV Community: Jasper | PDFluent

My Journey so far (beating Docling & PyMuPDF4LLM)

Jasper | PDFluent — Fri, 23 Oct 2026 08:31:17 +0000

SDK 1.2 of PDFluent went out on 22 October. That's about nine months of work, by me, a solo founder in the Netherlands.

The release post has the changelog and the numbers: https://pdfluent.com/blog/sdk-1-2-0/. This post is about the other stuff, the things that never make it into release notes.

how it started

At the start I had no plan to write a PDF engine. The plan was lazier. There are a lot of good open source PDF tools out there, and I thought I could glue them together into one complete PDF product, call it done, and get to the part where people actually use it.

That lasted [JASPER: how long the glue phase lasted, and the specific tool or bug that made you stop gluing and start writing]. After that I started writing most of the core myself. Not all of it. Some parts are forks of existing crates, and I'm glad those crates exist. But most of the core.

The first thing I wanted to do properly was XFA. If you've never run into XFA, lucky you. It's Adobe's old dynamic form format, version 3.3, and it still lives inside tax and government systems where nobody is about to replace it. I wanted it working in Rust, properly. [JASPER: one real XFA moment, like the first form that calculated correctly, or the part of the spec that cost you a week]

From there it kept growing, which is what happens when you're one person and nobody tells you to stop. It became an SDK in Rust with bindings for Python, Node.js, .NET, Java and WebAssembly. There's a free desktop PDF editor built on the same engine. The SDK is AGPLv3 or a commercial licence. Then it grew sideways into extraction: getting text and structure out of PDF and Office files, so layout, tables, Markdown, the stuff people want to feed into LLMs now. That's when I started measuring against Docling and pymupdf4llm, because those were the two I wanted to beat.

the things I got wrong

I had written "pure Rust" everywhere. Website, README, probably in my sleep too. Then I found a C library in the build. QuickJS, for running form scripts. [JASPER: how you found out, e.g. a dependency tree, a licence scan, a build on a new machine] So it wasn't pure Rust, and I had been saying it was, in public. I pulled the claim from the website. In 1.2 form scripts run in a WebAssembly sandbox, and the copy says "written in Rust" now, which is true and boring, and I'll take that.

The benchmarks were worse, in a way. My first numbers came from the same half of the data I had been tuning on. Of course they looked good. I was grading my own homework with the answer sheet open next to it. I threw those numbers out and replaced them with results on a held-out half, data I don't touch while building.

Then the tests. I found functions that had been broken for months while tests for them existed the whole time. The tests were fine. Nothing in the CI pipeline ever ran them. A test file sitting in a folder feels nice and does nothing. So the rule now is boring: if a test doesn't run in CI, the work isn't done.

After the pure Rust thing I got a bit paranoid, which I think is healthy. Every number on the website now has an ID in a claims file. No ID, it doesn't ship. It slows me down. Fine.

where it is now

This is the part I'm a bit nervous to write. I believe PDFluent is now state of the art at extracting text from PDF and Office documents, layout included. That's my belief, and you should check it yourself.

Here are the numbers behind it. It's the average over 19 extraction measures on the holdout half, PDF only. PDFluent ran in balanced mode with the table model, which is still Preview.

PDFluent 0.721
pymupdf4llm 0.693
Docling 0.672
(Yes, I'm pretty proud of this result)

The harness is public, pdfluent-bench on GitHub (github.com/pdfluent/pdfluent-bench), so if you think I set it up in my own favour, go and look, and tell me where.

Traction is small. About 38 GitHub stars and a few hundred PyPI downloads a month. I'm not going to dress that up. After nine months, that's where it is.

If any of this is useful to you, use it, and let me know. Feedback, ideas, someone who wants to work on it together, all welcome. The full list of what changed in 1.2 is at https://pdfluent.com/blog/sdk-1-2-0/ if you want the dry version;-)

XFA forms won't die, so I wrote a flattener for them in pure Rust

Jasper | PDFluent — Wed, 23 Sep 2026 15:07:12 +0000

XFA is Adobe's old dynamic form format. Adobe deprecated it in PDF 2.0, and it still refuses to go away. Tax authorities and immigration offices built entire form systems on it years ago, and nobody is rewriting those systems just because a spec moved on. Most PDF tools, open source or commercial, dropped XFA support a while back. I didn't, because a decent chunk of the forms real users need to open are still XFA.

XFA has its own layout model (subforms, dynamic instances that can appear or repeat at runtime) and its own scripting language, FormCalc, for form calculations. That's what makes it dynamic: a field can resize itself, a section can add a row, a calculation can run before you even click save. It's also why so few tools bother with it. Most PDF readers just show a blank page or a wall of unrendered XML when you open one.

The approach that actually ships today is flattening: run the form's layout and its FormCalc scripts once, then bake the result into a plain static PDF. You lose the interactivity, but you get a document any PDF reader can open, print, or archive without complaint. Full interactive XFA, live and editable inside a viewer, is still experimental on my end and I wouldn't put it in front of production users yet. Flattening is the boring, reliable part, and boring and reliable is what you want for a tax form.

Getting there in Rust took longer than I expected. The layout model has enough edge cases that "just parse the XML" gets you maybe halfway, and FormCalc scripts show up with quirks nobody documents. I ended up writing and re-writing the calculation engine more times than I'd like to admit before it stopped falling over on real-world forms, not just the clean examples in the spec.

Here's a rough sketch of what using it looks like:

use pdfluent::prelude::*;

fn main() -> pdfluent::Result<()> {
    let mut doc = PdfDocument::open("input.pdf")?;

    // simplified for illustration; check the docs for the exact
    // XFA-flatten call and its feature flag
    if doc.has_xfa() {
        doc.flatten_xfa_forms()?;
    }

    doc.save("output.pdf")?;
    Ok(())
}

I'm simplifying on purpose here. PdfDocument and the ?-based error handling are real and match the actual API, but I shortened the XFA-specific method names for readability. Check the Rust quickstart linked below if you want the exact calls.

This is one piece of PDFluent, the PDF SDK I've been building in Rust, with bindings for Python, Node.js, .NET, Java, and WASM. It's AGPLv3, with a commercial license for teams that can't take on the copyleft.

If you're stuck with an XFA form right now, there's a WebAssembly build of the flattener running at the PDFluent playground. No signup, nothing uploaded anywhere: drag in a form and watch it flatten in the browser. For the Rust side, the quickstart docs are one cargo add pdfluent away.

XFA isn't disappearing on its own timeline. It disappears when someone bothers to support it properly, and until then, flattening is the honest answer.

Building a PDF engine from scratch in Rust

Jasper | PDFluent — Sat, 22 Aug 2026 20:30:11 +0000

Why build another PDF engine

Hi Folks, my name is Jasper. I spent the last year writing a PDF engine from scratch in Rust. Not wrapping an existing C++ library, not forking an open source project - 48 pure Rust crates with zero C or C++ dependencies. The SDK is now solid, and a new version of the free desktop editor ships next week. Here's what broke along the way.

The brutal parts

XFA forms were the first obstacle. Adobe deprecated XFA in PDF 2.0, but deprecated doesn't mean gone. XFA has its own layout model, scripting language, and data binding - all documented in a 756-page specification. Implementing it meant writing a JavaScript interpreter (QuickJS) for form calculations while ensuring scripts in documents never execute.

Rendering was another challenge. Existing Rust PDF crates only parsed files, so I had to build a rasterizer using vello_cpu. The first PDF/A conversions passed validation while quietly dropping content. The validator checked structure, not whether text was preserved. I caught it by counting words with mutool against the original - one escaped backslash cost an entire page.

What actually works now

After processing 50,000 real PDFs with zero crashes, I measured rendering performance on a 5,000-document test set and PDF/A compliance on a separate 1,000-document holdout set:

94% render at SSIM 0.95 or better against mutool (mean SSIM 0.9869)
0.16% crash rate (8 crashes), all on adversarial fuzzing input
98.9% PDF/A-2b conformance on a 1,000-document holdout set
Text retention median 100.0%, 5th percentile 99.3%, none below 95%

These numbers are reproducible using veraPDF and mutool against the published benchmarks.

Testing traps I fell into

A binding in the WebAssembly build had been broken since May. A test for it existed but wasn't running in CI - like 198 other method tests sitting unused. Now nothing ships without its test running in the pipeline.

Three "passing" tests didn't actually test anything: one used ASCII fixtures that never hit Unicode paths, another counted uncompressed streams as zero, and a third positioned text where no blocks were detectable. The rule now: break the function on purpose and see if the suite notices.

Silent test skips hid problems too. A duplicated character-mapping table survived because missing fixtures failed quietly. Now any skip must log to stderr.

The privacy approach

The editor makes three outbound connections: update checks, opt-in crash reports, and opening links in your browser. Document content never leaves your machine. You can verify this:

Monitor network traffic while using the tool
Check that reqwest only appears in the updater (cargo tree -i reqwest)
Compare against my published packet capture

The limitation: TLS obscures content, and unpublished source can't be verified. You can run this same check on any PDF tool you use to compare the results.

What's next

The new editor version removes non-functional e-signature controls and fixes save-state indicators. It stays free for all uses, no accounts or telemetry. The SDK licenses start at €699 with a 30-day evaluation. The SDK runs with all features enabled but adds a watermark to the output until you apply a license key.