megorei / banan.io
Satzsysteme.
15+ Systeme. 4 Paradigmen. Laser-Drucker, Browser, LaTeX, Typst, Prawn, Chrome, Gotenberg. Die Technologie ist nicht die Frage. Die Frage ist: wer gestaltet die Vorlage?
Zu viele Systeme.
Falsche Frage.
Wer heute ein PDF braucht, wird von Optionen erschlagen. LaTeX. Typst. Chrome headless. WeasyPrint. wkhtmltopdf. Prawn. iText. HexaPDF. Gotenberg. Puppeteer. Pandoc. LibreOffice. PdfLib. Crystal Reports.
Alle können PDFs erzeugen. Die Frage ist nicht welches System technisch am besten ist. Die Frage ist: welches System passt zu deiner Organisation, deinen Skills, deinen Anforderungen?
Wer die Systeme nach Feature-Listen vergleicht, stellt die falsche Frage. Die richtige Frage ist strukturell: wer in deiner Organisation gestaltet die Vorlage?
Die Kernfrage ist nicht technisch.
Sie ist organisatorisch.
Wie man PDF denkt.
| Paradigma | Prinzip | Vertreter | Designerin ist… |
|---|---|---|---|
| Programmatisch | PDF-Primitives direkt im Code beschreiben | Prawn, iText, HexaPDF, PdfLib | Developer |
| Markup / Satz | Deklarative Sprache beschreibt Layout | LaTeX, Typst, Troff | Developer (technisch) |
| Browser-Rendering | HTML+CSS → Headless Browser → PDF | Chrome, wkhtmltopdf, WeasyPrint, Puppeteer, Gotenberg | Webdesigner |
| Template / GUI | Visuelle Vorlagen, Merge-Felder | LibreOffice, Crystal Reports, Word → PDF | Fachbenutzer |
Hervorgehoben: Browser-Rendering hat den besten Kompromiss aus Gestaltungsfreiheit und Zugänglichkeit für die meisten Teams.
15+ Systeme in vier Spalten.
Wer gestaltet die Vorlage?
Das ist die Entscheidungs-Achse. Nicht Performance. Nicht Lizenzkosten. Nicht Ökosystem. Alles andere folgt daraus: wer kann diese Vorlage pflegen, wenn sich die Anforderungen ändern?
Richtiges System für richtige Aufgabe.
Die Reise durch
alle Paradigmen.
Wer länger als fünf Jahre PDFs in Produktion erzeugt, kennt mehr als ein System. Nicht weil er unentschlossen ist — weil jede Anforderung ein anderes System optimal macht. Die Reise ist der Lernprozess.
LaTeX — die erste Wahl wenn Qualität über allem steht. Perfekte Typografie, mathematische Präzision, KOMA-Script für Deutsche Dokumente. Die Kosten: TeX-Distribution auf jedem Server, Build-Zeiten, Debugging in LaTeX-Fehlermeldungen die kein Mensch versteht. "Overfull \hbox (3.45pt too wide)" ist kein Stack-Trace den man googeln kann.
Prawn — Ruby-nativ, keine externe Abhängigkeit. Aber: jede Rechnung ist ein Malprogramm. 200 Zeilen Ruby für Logo + Adresse + Tabelle + Summe + Footer. Jede Design-Änderung ist eine Code-Änderung. Kein Designer greift an ohne Dev-Begleitung.
wkhtmltopdf — pragmatischer Mittelweg: HTML/CSS → PDF ohne Chrom-Overhead. Funktioniert. Bis man moderne CSS-Features braucht. Seit 2022 nicht mehr aktiv gepflegt. Mit jedem Jahr steigt der Abstand zur Browser-Realität.
CSS Print —
Chrome lügt.
Die W3C CSS Print Specification definiert wie PDFs aus HTML/CSS erzeugt werden sollen: Seitenumbrüche (page-break-*), Kopf- und Fußzeilen (@page), Fußnoten (float: footnote), Orphans und Widows, Seitengrößen und -ränder.
Chrome implementiert davon ungefähr 60%. Bugs bei komplexen Tabellen-Seitenumbrüchen, Float-Clearance in Print-Kontext, @page-Margin-Boxen, Fußnoten-Support (de facto: null).
Das ist kein Chrome-Problem. Browser sind für Bildschirme optimiert. Print ist ein Nebenprodukt. Für echte Print-Qualität gibt es zwei Systeme die ernst genommen werden:
Prince XML — seit 2004, CSS Print vollständig implementiert. Kommerziell (€3,800 Einmallizenz). Weil Print ihr Kernprodukt ist, nicht ein Browser-Feature. Die Typographie-Qualität ist sichtbar besser bei komplexen Dokumenten.
DocRaptor — Prince als SaaS-API. Per-Document-Pricing. Kein Server, kein Setup, einfach POST mit HTML → PDF zurück.
Chrome für schnelle Geschäftsdokumente: ja.
Chrome für Jahresberichte oder Bücher: nein.
Eine Rechnung.
Fünf Systeme.
Standard-Rechnung: Logo, Absenderblock, Empfänger, Rechnungstabelle (Position, Menge, Einzelpreis, Gesamt), Steuerangaben, Footer. Wie viel Code ist das?
width: 515, height: 60) do
pdf.image logo_path,
width: 120
end
# Jede Box, jede Linie,
# jeder Abstand: Code.
#set text(font: "Helvetica")
= Rechnung #invoice.number
#table(columns:(auto,1fr,auto),
[Pos],[Beschreibung],[€],
..items.map(i => ...)
)
@page { margin: 2cm; }
table { width: 100%; }
</style>
<table><tr>...</tr></table>
# POST /forms/chromium/convert/html
# Felder: {d.name}, {d.total}
curl -X POST \
https://api.carbone.io/render \
-d '{"data": {...}}'
Carbone.io —
Word als Template-Engine.
Das Konzept klingt simpel bis man versteht was es ermöglicht: DOCX-Vorlage mit {{d.variable}}-Platzhaltern + JSON-Daten rein + PDF raus.
Was das bedeutet in der Praxis: Die Fachabteilung baut das Template in Microsoft Word — mit dem Werkzeug das sie kennt. Keine Syntax, kein CSS, keine Deployment-Zyklen. Developer liefert nur die Daten-API. Trennung perfekt.
Wo es nicht funktioniert: wenn das Layout komplex wird, stoßen DOCX-Templates schnell an Grenzen. Bedingte Seiten, dynamische Tabellen mit Verschachtelung, Print-Optionen — da beginnt die Frustration.
Aber für Standard-Rechnungen, Zertifikate, Lieferscheine mit stabiler Struktur: Carbone.io ist die schnellste Lösung für Teams die keinen Entwickler im Layout-Loop haben wollen.
Wenn Mensch das Template baut. GUI-First.
Enterprise-Standard für Reporting: GUI-Designer mit Drag-and-Drop, direkte Datenbankanbindung, Reporting-Server der tausende PDFs pro Stunde rendert.
Sachbearbeiter öffnet JasperStudio oder Crystal Reports Designer, zieht Felder auf die Canvas, definiert Aggregationen, speichert Template. Kein Code. Developer liefert nur die Query.
Das ist das Paradigma der Enterprise-Welt: nicht Code als Vorlage, sondern GUI-Template als Vorlage. BIRT, Cognos Report Studio, SAP Crystal Reports — alle dasselbe Paradigma, verschiedene Ökosysteme.
Wo der Preis liegt: die Werkzeuge sind alt, die UX ist komplex, und wer aus dem JasperReports-Ökosystem heraus will, migriert manuell.
Agents und Satzsysteme —
wer generiert dann?
Wenn Agenten Compliance-Reports, COA-PDFs, Audit-Protokolle, Behördendokumente generieren: wer gestaltet dann die Vorlage? Und welches System kann ein Agent zuverlässig befüllen?
Prawn: Agent schreibt Ruby-Code der PDFs generiert. Technisch möglich. Aber fragil: kleiner Syntaxfehler → Exception → kein PDF. Agent muss Ruby, Prawn-API und das Layout-Konzept verstehen. Zu viel Kontext.
Chrome/HTML: Agent schreibt HTML. Das kann jedes Modell — HTML ist im Pre-Training. Aber CSS-Print-Bugs können Behördendokumente unbrauchbar machen.
Carbone.io: Agent befüllt DOCX-Template via JSON. Funktioniert wenn Template stabil ist. Für variable Layouts (z.B. unterschiedlich viele Seiten je nach Daten) schnell an Grenzen.
Typst gewinnt im Agentic Context. Warum:
Kein TeX-Distribution-Overhead, kein Browser, kein Server. Eine Binary, deterministischer Output. Agent ruft typst compile invoice.typ — fertig.
Modelle kennen CSS aus dem Pre-Training. Typst-Syntax ist nah genug, dass ein Agent Typst-Markup zuverlässig schreiben kann — ohne Prawn-API oder LaTeX-Makros zu kennen.
Gleicher Input → gleicher Output. Immer. Template kann gecheckt werden: typst compile --check template.typ. Fehler sind klare Compile-Errors, kein Runtime-Chaos.
§26-Compliance-Report als Typst-Template. Daten kommen vom Compliance-Agent (357 CSCs, Mitgliedslisten, Dokument-Fristen). Wöchentlich, automatisch, behörden-konform. Das ist der agentic Satzsystem-Loop.
HexaPDF, Prince und
die Spezialisten.
Das modernste Low-Level PDF-Framework in Ruby. Wenn Prawn nicht reicht: komplexe Formulare, PDF/A-Validierung, digitale Signaturen, Verschlüsselung. Volle PDF-Spezifikation in Ruby. Nicht für Layout-Arbeit — für PDF-Manipulation und -Validierung.
€3,800 Einmallizenz. Kommerziell. Lohnt sich wenn: Bücher, Jahresberichte, Dokumente mit Fußnoten und laufenden Kopfzeilen. CSS Print vollständig implementiert weil das das einzige Produkt ist. Typografische Qualität auf LaTeX-Niveau — aber über CSS gesteuert.
Universeller Konverter: Markdown → PDF (über LaTeX/Typst), DOCX → PDF, HTML → PDF. Wenn das Quelldokument wechselt — Autorin schreibt Markdown, Devops schreibt DOCX, Daten kommen als HTML — aber das Zielformat immer PDF ist. Pandoc mit Typst-Backend ist die modernste Variante.
Python-Ökosystem-Vertreter. WeasyPrint implementiert mehr CSS Print als Chrome — weil es sich darauf fokussiert hat. Für Python-lastige Teams oder wenn Chrome-Bugs stören aber kein Prince-Budget vorhanden ist.
Wer gestaltet, entscheidet.
Die Technologiewahl folgt aus der Organisationsfrage. Nicht umgekehrt. Identifiziere wer die Vorlage heute pflegt und wer sie morgen pflegen soll — dann wird klar welches System passt.