DEV Community: EbookForge

Why relying on a raw LLM to build structured PDFs is a nightmare (and how I fixed it)

EbookForge — Sun, 26 Jul 2026 14:02:03 +0000

If you’ve ever tried to generate a polished, production-ready PDF directly from an LLM, you already know the pain.

You ask for a clean layout, maybe some headers and a specific margin, and the model confidently spits back an unformatted wall of markdown. Or worse, you try to pipe its output directly into a PDF library like ReportLab or PDFKit, and the layout breaks completely. The fonts are wrong, the page breaks happen in the middle of sentences, and any structured data you had is now a chaotic mess.

Here's why raw LLMs fail at structured PDF generation, and the pipeline I built to fix it.

The Problem: LLMs are writers, not designers

Large Language Models are incredible at generating text, summarizing data, and even reasoning through logic. But they have zero spatial awareness. When an LLM generates a document, it doesn't "see" a 8.5x11 inch page. It sees a continuous stream of tokens.

Trying to get an LLM to reliably output precise spacing, page breaks, or complex tables that fit perfectly on a printed page is like asking a novelist to typeset their own book while blindfolded.

The typical naive approach looks like this:

Prompt the LLM to generate content.
Tell it to output HTML.
Pass the HTML to a PDF generator.

This breaks because LLMs hallucinate HTML tags, forget closing tags, and completely ignore pagination logic.

The Solution: A Decoupled Architecture

To fix this, I stopped treating the LLM as a designer and started treating it strictly as a content engine. The solution was a decoupled pipeline:

1. Structured Data Generation (JSON/Markdown)
Instead of asking the LLM for HTML or layout instructions, I prompt it to return strictly structured JSON or clean Markdown. I use function calling (or structured outputs) to enforce a strict schema. The LLM's only job is to provide the content (titles, paragraphs, data points).

2. The Templating Engine (HTML/CSS)
I created a robust templating layer (using Jinja2/Handlebars) that holds the actual design. This layer knows exactly how to handle margins, fonts, and headers. It takes the structured JSON from the LLM and maps it to predefined, heavily tested HTML components.

3. The PDF Rendering Engine
Finally, the rendered HTML is passed to a headless browser (like Puppeteer/Playwright) or a dedicated rendering engine (like WeasyPrint) that actually understands CSS paged media. This handles the page breaks, headers, and footers flawlessly.

The Result

By decoupling the content generation from the layout rendering, the nightmare stopped. The LLM focuses on what it does best (writing and structuring data), and the rendering engine handles the visual layout. No more broken tables, no more mid-sentence page breaks.

If you are building an AI-powered document generator, stop trying to make the LLM do everything. Build a pipeline.

I built a book generator that runs entirely in your browser — no server, no account, no backend

EbookForge — Sat, 21 Mar 2026 14:02:23 +0000

A few months ago I posted here about EbookForge — a JSON-to-PDF engine I built because formatting ebooks was driving me insane.

That post got zero comments. Fair enough. The product was rough, the pitch was confusing, and honestly — asking people to write books as JSON was a hard sell.

But the formatting problem was real. So I kept building. And the project got completely out of hand.

What started as a formatter became something else

The original pain: I had structured content and no clean way to turn it into a typeset PDF with a cover page, justified text, embedded fonts, and a table of contents with actual page numbers. Everything I tried required a server, looked terrible, or both.
So I built a client-side PDF engine. That worked. But then I realized: the formatting was the easy part. The hard part was making the input worth formatting.

So I kept going.

EbookForge today

EbookForge now generates complete books from scratch — entirely in your browser.

You describe your taste:

Pick up to 3 genres
Place a dot on a 2D emotional axis (comforted ↔ disturbed, devastated ↔ euphoric)
Describe your protagonist in one sentence
Drop in a "wildcard seed" — a sensory image, a memory, a vibe

The AI then architects a full book blueprint (title, plot, chapter arcs, themes, trigger warnings), generates a painterly cover illustration, and writes the first chapter. You read it, then forge the next chapters one by one.

The twist: between chapters, you can inject "Director's Notes" — creative instructions like "a sudden betrayal" or "the rain stops and the silence becomes deafening." The system rewrites the remaining chapter plan to stay coherent with your intervention.

Then you download the whole thing as a typeset PDF with embedded fonts, cover art, synopsis page, and numbered table of contents.

No server. No account. No database. Your Gemini API key lives in sessionStorage and dies when you close the tab. There's a full demo book you can browse without any key.

The stack

Zero backend. Zero dependencies beyond the browser and a Gemini key.

Getting AI to generate images without text.

I needed painterly cover illustrations with zero typography. Image models desperately want to put words on images. The prompt has to be adversarial — "ABSOLUTELY NO TEXT, NO LETTERS, NO WORDS" — and it still fails maybe 20% of the time. This single problem took more iterations than the rest of the app combined.

Multi-chapter coherence with human interventions. When you inject a Director's Note that contradicts the planned story arc, every downstream chapter summary needs to adapt. The system sends the generated chapter text + the user's note back to the AI and asks it to rewrite the remaining chapter metadata. It works surprisingly well. When it doesn't, the prose still adapts through context because each chapter prompt includes the tail end of the previous chapter.

Two-pass PDF rendering. The table of contents needs page numbers, but you don't know the page numbers until you've rendered all the chapters. So: first pass renders everything and tracks where each chapter lands, second pass goes back to the TOC page and fills in the numbers. Justified text is done via manual word-spacing calculation — split each line into words, measure the leftover space, distribute it evenly.

Persistence without a backend. Cover images are multi-megabyte base64 strings that blow up localStorage. Solution: metadata goes to localStorage, covers go to IndexedDB, and the library view stitches them back together on load. Delete a book and both stores get cleaned up.

What it's NOT

It's not a publishing pipeline. It's not meant to flood Amazon with AI novels. It's a creative toy — closer to AI Dungeon for long-form fiction than a KDP tool.

The question I was chasing: can a human and an AI co-direct a narrative across multiple chapters, with the human's choices propagating forward coherently?

The answer is "sometimes, and it's genuinely fascinating when it works."

Try it `ebookforge.app`

You can browse the full demo book (English or French) without entering any API key. Bring your own Gemini key to forge one from scratch.
Bilingual EN/FR.

The whole thing is a solo side project that started as a formatting script and turned into whatever this is. If you've ever fought with PDF generation in the browser, or tried to make AI-generated text stay coherent across 10+ chapters — I'd love to hear how you approached it.

I built a JSON to PDF Ebook engine because formatting ebooks was driving me insane

EbookForge — Sun, 07 Dec 2025 00:40:23 +0000

Hey everyone 👋

I’m Sam — a solo builder who spends way too much time writing long-form content: guides, frameworks, SOPs, ebooks…
And weirdly, the writing was never the hard part.

The hard part was turning that content into something clean, structured, and publishable without spending hours in Google Docs, Notion, or—worse—InDesign.

So I built EbookForge:
👉 a fast, deterministic JSON → PDF Ebook engine for developers and creators. Website: EbookForge

The Problem

If you write long-form content, you probably know the pain:

Fighting with margins and spacing
Random line breaks
Tables that jump around
PDFs that look different every time you export
Manual formatting that kills your flow
Templates that solve nothing

I always thought “why isn’t there a simple, deterministic way to generate a clean ebook from structured content?”

There wasn’t. So I built one.

What EbookForge does

EbookForge takes a strict JSON schema and turns it into a clean, professional PDF ebook.

It supports:

Titles / subtitles
Headings
Paragraphs
Lists
Page layout rules
Consistent typography
Automatic spacing

*No WYSIWYG. No template hell. Just structure → output. *

Why JSON?

Because:

t’s predictable
It’s scriptable
It’s versionable
It works with LLMs
It integrates with any backend
Developers already understand it

If you’ve ever built internal docs, tutorials, online courses, ebooks, or technical PDFs… JSON is the perfect middle layer.

Who this is for

Developers generating PDFs programmatically
SaaS founders shipping guides or documentation
Indie hackers building content products
Writers who want full control over structure
Anyone automating content workflows

I built EbookForge for myself first, but I realized others might find it useful too.

Try it

It’s live here EbookForge

You paste a JSON example, hit “Generate”, and get a clean PDF instantly.

Still early, still improving — feedback is super welcome.

Feedback appreciated

If you’ve ever struggled with PDF/ebook generation, I’d love to know:

What formats do you use?
What pain points do you hit the most?
What features would make this 10× more useful?

Happy to share code snippets or JSON examples too.

Thanks for reading! 🙌
Sam