Markdown zu PDF mit Code-Highlighting: Syntax-Farben erhalten
Wenn Markdown → PDF mit erhaltenem Code-Highlighting (Farben, Schrift, Zeilennummern) gewollt ist, sollte ein Headless-Chromium-Werkzeug zum Einsatz kommen. /markdown-to-pdf leistet das ohne Konfiguration — eingezäunte Codeblöcke werden mit voller Prism / highlight.js-Farbe, monospaced Schrift und richtigem Zeilenumbruch gerendert; die PDF entspricht exakt der Vorschau.
Der Rest erklärt, warum die meisten Markdown-→-PDF-Tools Code-Farben strippen, welche drei Dinge zusammenpassen müssen, und wie verbreitete Werkzeuge dabei abschneiden.
Drei typische Fehlermodi:
- Der Renderer hat nie gehighlightet. Ein nacktes
pandoc input.md -o output.pdfnutzt Listings/Skylighting; Farben sind veraltet und kontrastarm. Ohne--highlight-stylekann sogar Schwarz-Weiß herauskommen. - Highlighter lief, aber Print-CSS hat alles gekillt. Beim Browser-⌘+P setzen viele Seiten via Print-Stylesheet
color: black !important. Codeblöcke werden reines Schwarz auf Weiß — lesbar, aber strukturlos. - PDF-Engine entfernt Farben beim Konvertieren. Ältere PDF-Bibliotheken erzwingen Graustufen bei bestimmten Druckerprofilen. Ein Indiz: Links bleiben blau, Codeblöcke verlieren Grün/Orange.
Wenn beim Export Markdown plus monochromer Code statt eines Syntax-Themes herauskommt, ist es fast immer einer dieser drei.
Code-Highlighting im PDF zu erhalten, ist eine Kette. Bricht ein Glied, sind die Farben weg:
- Ein echter Syntax-Highlighter rendert die Quelle. Prism, highlight.js, Shiki oder Pandocs Skylighting. Ohne Highlighter ist Code nur monospaced Text.
- Das Theme überlebt den Print-Pfad. Entweder exportiert das Werkzeug die Bildschirmdarstellung direkt (Headless Chromium) oder es gibt ein Print-Stylesheet, das Farben nicht resettet.
- Schriften und Farben passen zur Theme-Idee. Dunkle Themes (Dracula, One Dark) auf weißem Papier sind unschön; helle Themes (GitHub Light, Solarized Light) drucken gut.
Der Browser-basierte Pfad liefert alle drei standardmäßig — Bildschirm und PDF sind derselbe Chromium-Snapshot.
Nutzt Headless Chromium und fängt die Vorschau exakt als PDF ab. Eingezäunte Codeblöcke verwenden Prism mit einem eingebauten, druckoptimierten Hell-Theme. Lange Zeilen brechen weich um. Inline-code behält Hintergrund und monospaced Schrift.
Urteil: funktioniert ohne Konfiguration.
Ebenfalls Headless Chromium darunter, das highlight.js-Theme lässt sich über YAML-Front-Matter steuern:
---
stylesheet:
- https://cdn.jsdelivr.net/npm/highlight.js/styles/github.css
---
Urteil: volle Farbe, aber Theme selbst mitbringen. Für Druck github.css, für dunkles PDF atom-one-dark.css.
Auch Chromium, aber das Default-Highlight-Theme hängt am Editor-Theme. Dunkler VSCode = dunkles PDF — am Bildschirm okay, beim Druck Toner-intensiv. Überschreiben in den User-Settings:
"markdown-pdf.highlightStyle": "github.css"
Urteil: funktioniert, aber Theme vor dem Druck prüfen.
Pandocs Default-Code-Rendering nutzt Skylighting (eigener Highlighter, nicht highlight.js / Prism). Farben wirken nach Web-Standards veraltet. --highlight-style=tango (oder pygments, kate, monochrome) wechselt die Palette — aber kein Set passt exakt zu modernen Web-Themes.
Für ein Web-Style-Theme via Pandoc: erst nach HTML, dann im Browser drucken.
pandoc input.md -o output.html --highlight-style=pygments --self-contained
# danach HTML im Browser zu PDF drucken
Urteil: funktioniert, aber indirekt. Pandoc wird selten für Web-Ästhetik gewählt.
Hängt komplett am Print-Stylesheet. github.com druckt Farben anständig, manche Doku-Seiten strippen aggressiv. Vor wichtigen Lieferungen testen.
Urteil: Glückssache.
Ein paar praktische Hinweise:
- Helle Themes drucken besser. Dunkle Hintergründe verbrauchen Toner und kontrastieren bei S/W-Druck schlecht. GitHub Light, Solarized Light, Atom One Light sind sicher.
- Vermeide stark gesättigte Farben. Pures Rot/Grün wirkt auf Papier hart. Entkräftete Paletten (Solarized Light, Tomorrow) lesen sich besser.
- Erst ohne Zeilennummern testen. Lange Codeblöcke mit Zeilennummern verschieben den rechten Rand und kollidieren mit Seitenrand.
- Monospaced-Schrift checken. Ist die Theme-Schrift nicht installiert, fällt das System auf Courier zurück (sieht alt aus). Inter, JetBrains Mono, Fira Code sind sichere Defaults.
- Lange Zeilen überlaufen. Mit eigenem CSS:
pre { white-space: pre-wrap; }. Sonst Zeilen vor dem Export manuell brechen. - Tabs vs. Spaces. PDFs interpretieren Tab-Breiten unterschiedlich; bei wichtiger Ausrichtung vorher zu Spaces normalisieren.
- Smart Quotes. Manche Markdown-Prozessoren wandeln Code-interne Anführungszeichen in typografische um — das bricht Syntax. Bei Pandoc:
--from=markdown-smartdeaktivieren. - Emojis in Kommentaren. Viele PDF-Schriften kennen keine Farb-Emojis. Sie werden zu Outline oder
?. Für druckperfekte Ausgaben Emojis aus Code-Kommentaren entfernen.
Unterstützt /markdown-to-pdf Prism-/highlight.js-Themes?
Default ist Prism mit einem druckoptimierten Theme. Wenn ein bestimmtes Theme nötig ist, ist die CLI-Route flexibler. Siehe unseren 5-Methoden-Vergleich.
Warum ist Code in der PDF farblos, aber in der Vorschau farbig?
Meistens Schuld: ein Print-Stylesheet auf der Quellseite. Browser-Druck respektiert @media print-Regeln, die Farben oft resetten. Das Web-/markdown-to-pdf hat das Problem nicht, weil es die Bildschirmdarstellung direkt einfängt.
Wie behalte ich Zeilennummern im PDF?
Das Web-Tool zeigt sie standardmäßig nicht — sie sind beim Debuggen nützlicher als beim Teilen. Wer sie braucht, nimmt md-to-pdf CLI mit einem highlight.js-Theme inklusive .hljs-ln-numbers.
Bestes Theme für ein gedrucktes PDF?
GitHub Light. Für Leser am vertrautesten, druckt in Farbe und in S/W gut, Kontrast passend ohne grell.
Bei Batch-Konvertierung Highlighting erhalten?
Ja — siehe Markdown stapelweise zu PDF. CLI-Methoden sind für Batch ideal.
Code-Highlighting in einer Markdown-→-PDF zu erhalten, ist mit echtem Chromium gradlinig. /markdown-to-pdf macht es ohne Konfiguration; die npm-CLI gibt Theme-Kontrolle pro Dokument; alles andere ist ein Trade-off zwischen Komfort und Farbtreue.