<h2>Where it all starts</h2>
In the 1980s, producing a formatted report felt more like an exercise in coordinate geometry than in programming. In Clipper, you placed a piece of text with <code>@ 10, 20 SAY &quot;Report Title&quot;</code>. In Fortran, the same idea came from the <code>FORMAT</code> column descriptor: <code>FORMAT(T20, 'Report Title')</code>. In COBOL, the Report Writer used clauses like <code>LINE 10 COLUMN 20</code> in the report group definition. Different languages, same reasoning: you spelled out exactly which line and column every piece of text should land on.
In 2026, generating a PDF still follows that same <code>(x,y)</code> pattern in most libraries.
For years I generated PDFs across several languages and libraries — iText, PDFKit, pdfmake, jsPDF, React-pdf, and plenty of others. Even today, with LLM agents helping, positioning and formatting things inside a PDF is still hard and takes many rounds of fine-tuning.
The problem runs straight into PDF itself: it is a low-level format that describes the final output, not a smart layout format. For a PDF library, that turns into hundreds of geometric decisions: coordinates, fonts, heights, page breaks, margins, tables, images, and so on. Unlike HTML/CSS or Word, PDF was never designed for you to say “put this paragraph here and let the rest flow naturally”. A PDF is essentially a list of layout and content instructions, written after every position has already been computed.
Even for LLMs, pagination is surprisingly hard. The AI has to know how much space each element will take before placing it. A paragraph may be 3 lines or 7 depending on the font, the width, the language and so on. If it doesn’t fit, you have to open another page, move the content, repeat headers and maybe avoid an orphan line. Text depends on real font metrics. Knowing the font is size 12 isn’t enough — computing layout correctly requires the width of each glyph, ascent, descent, line height and character fallback.
For humans and for LLMs alike, a line of PDF generation code (say, <code>setText('Lorem Ipsum', 38, 92)</code>) means nothing semantically. We humans still fall back on the loop: generate the PDF, check whether the text landed in the right place, adjust. But the PDF format is especially bad for LLMs — the agent is essentially laying out a page blindfolded.
There’s no denying LLMs are very good at symbolic work:
<ul>
<li>“generate a table with this data”</li>
<li>“write this report”</li>
<li>“compute these metrics”</li>
</ul>
But page layout demands reasoning that is spatial, iterative and precise down to the pixel or point.
And there’s an irony here: PDF itself is not (not by a long shot) the hard part. Layout is. If an AI could produce a genuinely good intermediate model — something like a “DOM for PDF”, with semantic symbols — emitting the final file would be almost trivial.
<h2>The innovation</h2>
In 2015, enter Eric Seidel. Together with their team, and inspired by HTML/CSS Flexbox, they built the layout system for Sky (which would later become Flutter). Put very briefly, it defines a declarative layout as a tree, where each parent passes layout constraints down to its children, and each child reports back the space it needs in order to be drawn later. It was a huge innovation, and it went on to influence Jetpack Compose and SwiftUI.
That layout system is what made David PHAM-VAN (DavBfr) think outside the box and create dart_pdf (“A Widgets system similar to Flutter’s, for easy high-level Pdf creation”).
Let’s restate one premise:
<blockquote>
To generate a PDF, someone has to solve the layout first.
</blockquote>
That is where dart_pdf innovated. It brought a Flutter-style declarative layout system to a format that never had one. The idea came from Flutter, but applying it to PDF was genuinely original. That’s why so many people (myself included) consider it superior to the traditional libraries — and why it is the innovation formatted report generation needed in order to finally leave the 1980s behind.
In dart_pdf, “Flutter’s layout” was reimplemented for a completely different domain: PDF generation. That is one of the reasons dart_pdf turned out so elegant. Instead of emitting PDFs through absolute coordinates, it brought Flutter’s declarative paradigm to a format that is traditionally far lower level.
<h2>The motivation</h2>
Since I discovered dart_pdf (some six or seven years ago), I’ve used it in many projects. Not because it is the fastest or the lightest library (anyone who has run Dart on a server knows what I’m talking about), but because of the way it lets you think about layout. You compose a document exactly the way you would compose a UI in Flutter or on the web (<code>Column</code>, <code>Row</code>, <code>Container</code>, <code>Table</code>), and pagination, layout and text flow simply work.
I’ve used this library in mobile apps, on servers, on the desktop and on the web, and the ease of building documents has always outweighed the challenges specific to each technology.
Over those years I also had to examine the source code (more than once) to debug real production issues. I wasn’t just using the library from the outside (this matters for what comes next); to some extent I had to understand how it worked internally, and that’s how I knew almost nothing in it actually depended on Dart.
But it has one big problem: you can’t use it from pure JavaScript.
<blockquote>
For the record: I have built HTML projects that ran Flutter Web + dart_pdf inside an iframe purely to generate a PDF.
</blockquote>
In the JS ecosystem, the closest thing to that declarative style is React-pdf, but it drags React along with it.
I wanted something framework-free that would run in a browser with nothing but an importmap, in Node, or inside a bare V8 host embedded in an application through ClearScript.
So I ported the library. The result is <a href="https://github.com/romulocrj/js_pdf" target="_blank" rel="noopener nofollow">js_pdf</a>, now at its first release candidate.
<blockquote>
Before anything else, let me be unambiguous about credit: every good idea in this library is <a href="https://github.com/DavBfr" target="_blank" rel="noopener nofollow">David PHAM-VAN (DavBfr)</a>'s. The widget model, the layout protocol, the pagination algorithm, the API surface. All of it is his design, refined over years of real use.
</blockquote>
<blockquote></blockquote>
<blockquote>
I only translated the code, and where I diverged it was to satisfy a constraint he never had. Without <a href="https://github.com/DavBfr/dart_pdf" target="_blank" rel="noopener nofollow">dart_pdf</a>, <a href="https://github.com/romulocrj/js_pdf" target="_blank" rel="noopener nofollow">js_pdf</a> simply would not exist. It is a port, and the license and attribution headers make that clear in every single file.
</blockquote>
<h2>The experience</h2>
I didn’t want a library that works in Node. I wanted a 100% JavaScript API that runs in Node, in the browser, in ClearScript, in Deno, and so on.
No DOM. No Canvas. No <code>Buffer</code>. No <code>fetch</code>. No filesystem. No timers. The library’s only job is to turn a widget tree into a <code>Uint8Array</code>.
This sounds like an aesthetic preference, but it isn’t. It is what lets the exact same file — byte for byte — run in a browser importmap, in Node and inside ClearScript with no shim, no bundler and no polyfill.
Actually making that hold turned out to be an interesting part of the work. I compile against ES2020 with <code>types: []</code>, so <code>document</code>, <code>window</code>, <code>fetch</code>, <code>setTimeout</code>, <code>Buffer</code> and <code>process</code> become compile errors, not lint warnings. On top of that there is a verification script (the source gate) that scans the built bundle for forbidden names. A rule is only worth something if it is checked deterministically. Had it only been written down in <a href="http://AGENTS.md" target="_blank" rel="noopener nofollow">AGENTS.md</a> or <a href="http://CLAUDE.md" target="_blank" rel="noopener nofollow">CLAUDE.md</a>, something would have slipped through across nearly 40,000 lines of code.
<h3>The parts that were harder than I expected</h3>
1. Memory
Early on, my PNG decoder was eating half a gigabyte of heap for a single large image. The cause was a bad porting decision: accumulating bytes into an ordinary <code>number[]</code>. V8 spends about eight bytes per element on an array of numbers, so a 60 MB pixel buffer ended up occupying 480 MB.
Today, every binary path in the port accumulates into a <code>Uint8Array</code> that grows as needed. That is now one of the rules the source gate checks, because it is exactly the kind of thing that looks harmless in code review.
2. An architectural divergence: “layout/paint”
<blockquote>
Flutter’s magic: <code>Constraints go down. Sizes go up. Parents set positions.</code>
</blockquote>
Earlier I mentioned the layout model Flutter introduced. <code>layout()</code> and <code>paint()</code> are two phases of the same drawing cycle: the widget measures itself and stores the result in the <code>size</code> field of its own <code>RenderObject</code>, and <code>paint()</code> reads that value right afterwards, still within the same cycle. Redoing that measurement for every one of 60 frames per second would be expensive, so the value stays cached until something calls <code>markNeedsLayout()</code>.
dart_pdf imports that contract: <code>layout()</code> writes to the “cache”, and every <code>paint()</code> is always called right after the <code>layout()</code> that just filled in that <code>box</code>, within the same cycle. In _<code>multipage.dart</code> the pagination phase and the drawing phase are separate, and each one redoes its own <code>layout()</code> immediately before using the <code>box</code> — the read always happens paired with the write that produced it.
The catch is that this guarantee lives in the order in which the code calls <code>layout()</code> and <code>paint()</code>, across hundreds of places in 37,000 lines. In the port, some of those calls ended up happening out of order, and the end result was PDFs with clipped content, broken tables and misaligned images.
As an architectural choice (since we don’t need the cache), <code>box</code> in js_pdf stopped being a mutable property and became a value returned by <code>layout()</code> and passed as a parameter to <code>paint()</code>.
<h3>How I actually did it</h3>
Obviously: LLM agents were a large part of how this became possible. I’m not going to pretend otherwise. But I want to be precise about what they gave me.
I already had years of using dart_pdf and many debugging sessions inside its source. I knew what it did internally, I knew how little of it was actually tied to Dart, and I was convinced a pure JavaScript version was possible. That conviction is old. What I never had was time. A translation this size represents thousands of hours that a person simply doesn’t find. So much so that, until now, no JavaScript port existed.
The real ground truth is the examples. dart_pdf ships a set of them, which I kept as a benchmark, and “done” for any phase meant those examples generated the document end to end, under Node, the browser and ClearScript. Around that sits a test suite: 447 tests over roughly 7,300 lines, against approximately 36,900 lines of TypeScript in 148 source files. The end result is a single ES module, ~400 KB minified, with type declarations included.
As for the hours of work, that is what changed. The agents didn’t tell me what to build; they gave me the hours to build the thing I already knew was there. And an agent that translates 37,000 lines will also translate a bug with total confidence, invent behaviour that never existed upstream, or produce something that doesn’t run in the target environment. That is exactly why the examples and the test suite are what make the result trustworthy, not the model.
Knowing what to do, and how to verify that what was done is correct: that is the work.
<h2>Leaving the 1980s</h2>
Back at the start I described an irony: PDF itself is not the problem, layout is. And I said that if a genuine intermediate model existed — a kind of “DOM for PDF”, with semantic symbols instead of coordinates — emitting the final file would be almost trivial, especially for an AI.
That model already exists. It is called dart_pdf. When you write <code>Column</code>, <code>Row</code>, <code>Container</code>, <code>Table</code>, <code>Text</code>, you are not saying “draw at x, y” — you are describing intent, and the layout engine itself resolves constraints, sizes and positions underneath. It is the “DOM for PDF” I described above, except David had already built it years ago, borrowing Flutter’s widget tree for a format that never had one.
Asking an LLM agent to write <code>pw.Column({ children: [...] })</code> is a symbolic task. Asking that same agent to work out which pixel each glyph lands on is not.
Porting dart_pdf to JavaScript did not solve the layout problem — David had already solved that. The port solved the problem of that semantic model existing only in Dart.
The original project, which deserves your star far more than mine: <a href="https://github.com/DavBfr/dart_pdf" target="_blank" rel="noopener nofollow">https://github.com/DavBfr/dart_pdf</a>
js_pdf: <a href="https://github.com/romulocrj/js_pdf" target="_blank" rel="noopener nofollow">https://github.com/romulocrj/js_pdf</a>
Apache-2.0, same as upstream. Unofficial and unaffiliated. This is my port of David’s work, not a project of his, and any bug you find here is mine, not his.
Thank you, David. I hope this port sends even more people your way.
<hr>

Romulo Campos

A developer has ported dart_pdf — a Flutter-inspired declarative PDF generation library — to pure JavaScript (js_pdf). The motivation was that dart_pdf's widget-based layout model (Column, Row, Container, Table) is far superior to coordinate-based PDF libraries, but was only available in Dart. The port produces a single ES module (~400 KB minified) with no DOM, Canvas, Buffer, or runtime dependencies, running identically in Node, browsers, Deno, and ClearScript. Key engineering challenges included memory management (replacing number[] with Uint8Array to avoid 480 MB heap bloat for large images) and preserving the layout/paint ordering contract from Flutter's render model. LLM agents accelerated the translation of ~37,000 lines, but correctness was validated through 447 tests and a benchmark suite ported from the original dart_pdf examples. The library is released as Apache-2.0 and explicitly credits David PHAM-VAN as the original author of all design decisions.

I ported dart_pdf (the best PDF generation library) to pure JavaScript.