Reference

PDF generation by stack and document type

Each page has the code for one stack and the CSS for one document type. The stack decides how you return the bytes and what turns your template into a string; the document decides what has to be on it and how it has to page.

When one of these is already built and the output is wrong, start from what goes wrong when HTML becomes a PDF instead. It is organised by symptom rather than by stack. For the CSS itself, and which parts of the paged media specification are actually implemented, see CSS for paged documents. If the question is how big the page should be, that is page sizes, with real dimensions and margins. And if what you need is the markup for the document itself rather than the code that renders it, start from the document templates, which carry a complete file each. For what the API itself can be asked to do, and the real limit on each of those things, see everything the API does.

Three narrower references sit alongside those: barcodes that still scan on paper, what each writing system needs beyond a font, and what an automation platform does with the file.

JavaScript

Python

PHP

Ruby

Go

Go

net/http, no dependency to add, from an http.HandlerFunc that copies the body through.

Gin

Templates in html/template, rendered from a Gin handler using DataFromReader.

Java

Rust

Rust

reqwest, the usual client here, from an axum handler returning a streaming Body.

JVM

Kotlin

OkHttp, the usual client here, from a Spring controller returning an InputStreamResource.

TypeScript

NestJS

Templates in Handlebars via the built-in view layer, or none, rendered from a controller returning StreamableFile.

SvelteKit

Templates in Svelte components, rendered server side, rendered from a +server.ts endpoint returning a Response.

Nuxt

Templates in Vue components, rendered with the server renderer, rendered from a defineEventHandler in server/api.

.NET

Elixir

Phoenix

Templates in HEEx, rendered from a controller action using send_download.