fullbleed.dev

How it began…

I set out to create the best transactional document generator I could. I spent years in transactional/Variable Data printing, and the hardest part was always what one would think would be easy: Document authoring and layout. Ingesting data, formatting it to spec etc was all done with a few lines of code, but actually placing it ended up being multiple imports, system dependency installs, system font management, and drawString to x,y over and over. I thought it was crazy that we had access to insanely complex abstraction (today you can run an LLM locally!), that document authoring was not a solved problem, so I made fullbleed, an end-to-end document authoring library in rust, with a python CLI. In order to test and validate the library, I chose IRS tax documents, as they are widely available, highly standardized, and a real pain to do. What I ended up with was a system with so much observability and iterability that an AI agent could use it to lay out every form covered in publications 1141, 1167, and 1179, completely autonomously.

AI created page plan for one of the documents

Accidental Agent Enablement

In order to accomplish my goal of having fullbleed be the best end-to-end authoring platform possible, I added a ton of observability features. Glyph misses, CSS selector misses, a Just in Time Compiler that reports every object draw, etc. all as JSON. I also added a render preview image because previewing/viewing PDFs tends to cause file locks, and I just wanted to be able to spot-check my work. I also implemented all of the Bootstrap 5.0.0 selectors that made sense for a static document, and immediately abstracted away from them. HTML/CSS are great document design standards, but not very ergonomic to work in. As part of this component-first abstraction, I mirrored a familiar library’s “on component mount” semantics, which lets me do an engine render of individual components with their variable data during development, so that the above metrics are captured, and warnings/errors are emitted at the component level. I’ve also added per-page source PDF templating, so that we wouldn’t have to use a PDF manipulation library as an additional step, as most authoring libraries don’t compose, and most composition libraries don’t author. All of this, combined with the image preview, gave agentic AI an absolute game-changing edge when it came to iteratively tackling VDP documents

Metrics and metrics and metrics!

The experiment..

Once I had the engine in a place where I felt it could be genuinely productive, I decided to try something out: I wanted to see how useful agentic AI would be at laying out some documents. I figured it could probably get some fields on the page, and I could iterate to success. I passed it the relevant publications and asked it to give it a try. It ended up treating the entire project as a batch-processing job, pulled samples of every document, and made gold- or near-gold-plated repos for every single one. Most of them are ready for production.. You can understand my hesitation in sharing fully rigged VDP assets that are IRS documents, so the blog will be image-heavy from here

Setting up the repot for iteration

Self correcting layout

A lot of fields to get right!

Conclusion

In the end, it laid out 55 tax documents (I had already started on an I-9 which I dont believe is covered in the publications I provided it). That is including regression tests, covering all permutations of the data AND because we emit all this data anyway, it was kind enough to collect performance results, including documents that were slow, pages per second, etc. All in a single evening!