Eine in LaTeX gezeichnete Abbildung ist schon vor jedem Export eine Vektorgrafik – die Achsen liegen als Kurven vor, die Beschriftungen als Glyphen einer Schrift. Sobald sie jedoch als Bild exportiert wird, geht diese Information erstaunlich leicht verloren. Und die Entscheidung darüber fällt viel früher, als die meisten annehmen: bei der einen Frage, ob der Weg über DVI oder über PDF führt. Das Handbuch von dvisvgm sagt es unumwunden: Text in PDF- und PostScript-Dateien wird immer in Pfadelemente umgewandelt. Führt der Weg über ein PDF, hören die Buchstaben in der Abbildung auf, Buchstaben zu sein. Diese Seite ordnet standalone, pdfcrop, dvisvgm und das Rastern genau um diesen Angelpunkt.
Nur die Abbildung auf eine Seite: die Klasse standalone
Der erste Schritt beim Exportieren besteht darin, das Papier auf die Größe der Abbildung zu bringen. Martin Scharrers Klasse standalone (in TeX Live 2024 als v1.3b enthalten) setzt die Seitenmaße auf die Maße des Inhalts. Steckt man hier nichts als $\displaystyle \int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}$ in \documentclass[border=2pt,preview]{standalone} und lässt pdflatex laufen, hat das entstehende PDF die Seitengröße 85.779 × 27.993 pt – genau die Kontur der Formel. Ohne Angabe von border gilt an allen Seiten 0pt. Die Klasse selbst schreibt den seltsam genauen Wert 0.50001bp fest – er soll verhindern, dass Rundung die Kante einer Glyphe abschneidet –, doch die mitgelieferte standalone.cfg überschreibt ihn kurz vor der Optionsverarbeitung mit \standaloneconfig{border=0pt}. Für eine TikZ-Zeichnung nimmt man \documentclass[tikz,border=2pt]{standalone} und setzt die tikzpicture direkt hinter \begin{document}. Soll ein Textstück mit Zeilenumbruch herausgeschnitten werden, gibt man ihm mit etwa varwidth=10cm eine Breite. Das Paket preview, das standalone darunter verwendet, entstand ursprünglich für preview-latex in AUCTeX unter Emacs – von dort stammt der Gedanke, nur einen Ausschnitt eines Dokuments zu setzen.
% fig.tex — a figure that is its own page
\documentclass[tikz,border=2pt]{standalone}
\begin{document}
\begin{tikzpicture}
\draw[thick,->] (0,0) -- (3,0) node[right] {$x$};
\draw[thick,->] (0,0) -- (0,2) node[above] {$y$};
\draw[blue,thick] (0,0) .. controls (1,2) .. (3,1);
\end{tikzpicture}
\end{document}Die Ränder eines fertigen PDF beschneiden: pdfcrop
Steckt die Abbildung in einem gewöhnlichen Dokument und lässt sich nicht neu erzeugen, hilft pdfcrop. Es ist ein Perl-Skript von Heiko Oberdiek (v1.42 in TeX Live 2024), das die umschließende Box des Seiteninhalts berechnet und die Trimbox darauf verkleinert. Hier gemessen: Ein einseitiges Dokument im Letter-Format von 612 × 792 pt kam aus pdfcrop doc.pdf doc-crop.pdf mit 345 × 539 pt heraus. Soll der Rand nicht null sein, gibt --margins 10 an jeder Seite 10 pt zurück und ergibt 365 × 559 pt. Ein Vorbehalt: pdfcrop ruft Ghostscript auf – gleich am Kopf des Skripts steht „Requirements: Perl5, Ghostscript“. Ohne installiertes gs läuft es nicht. Und wenn sich die Abbildung ohnehin mit standalone erzeugen lässt, braucht man pdfcrop gar nicht: den Rand nicht entstehen zu lassen, ist schneller und genauer, als ihn abzuschneiden.
pdfcrop doc.pdf doc-crop.pdf # 612x792 pt becomes 345x539 pt
pdfcrop --margins 10 doc.pdf doc-crop.pdf # keep 10 pt on every side
pdfcrop --hires doc.pdf doc-crop.pdf # use the high-resolution bounding boxSVG erzeugen: dvisvgm – und warum der DVI-Weg gewinnt
Für eine Abbildung, die ins Web soll, ist SVG die erste Wahl. Martin Giesekings dvisvgm (3.2.2 in TeX Live 2024) wandelt DVI, EPS und PDF nach SVG – doch was herauskommt, hängt davon ab, durch welche Tür man hereingekommen ist. Setzt man \def\pgfsysdriver{pgfsys-dvisvgm.def} vor \documentclass, erzeugt mit latex ein DVI und ruft dvisvgm fig.dvi auf, enthielt das entstandene SVG Achsen und Kurve als <path>-Elemente und die Beschriftungen $x$, $y$ und $y=f(x)$ als <text>-Elemente – Buchstaben blieben Buchstaben und verweisen auf Vektorschriften in <defs>. Über ein PDF geschieht das nicht. Das Handbuch von dvisvgm sagt ausdrücklich, dass Text in PDF- und PostScript-Dateien stets in Pfadelemente umgewandelt wird. Tatsächlich lieferte poppler mit pdftocairo -svg aus dem PDF derselben Abbildung ein SVG mit null <text>-Elementen.
% figdvi.tex — the DVI route, which keeps the labels as real text
\def\pgfsysdriver{pgfsys-dvisvgm.def}
\documentclass[tikz,border=2pt]{standalone}
\begin{document}
\begin{tikzpicture}
\draw[thick,->] (0,0) -- (3,0) node[right] {$x$};
\draw[blue,thick] (0,0) .. controls (1,2) .. (3,1);
\end{tikzpicture}
\end{document}latex figdvi.tex # produce a DVI, not a PDF
dvisvgm figdvi.dvi # SVG with <text> elements and vector paths
# the PDF route needs a helper and outlines all text:
dvisvgm --pdf fig.pdf # requires mutool with Ghostscript 10.01 or newerFür den Weg von PDF nach SVG kommt ein weiteres, praktisches Hindernis hinzu. dvisvgm --pdf reichte das PDF früher an Ghostscript weiter, doch laut Handbuch hat der mit Ghostscript 10.01.0 eingeführte neue PDF-Interpreter diesen Weg unbrauchbar gemacht; dvisvgm sucht nun stattdessen nach mutool aus MuPDF. Auf dem Rechner für diesen Artikel (Ghostscript 10.03.0, kein mutool) bricht dvisvgm --pdf fig.pdf mit ERROR: can't retrieve number of pages from file fig.pdf ab. Der PDF-Weg verlangt also eine zusätzliche Abhängigkeit; und sobald Ghostscript die Datei verarbeitet, gilt die Regel des Handbuchs und der Text wird ohnehin in Konturen umgewandelt – zwei Gründe, den DVI-Weg vorzuziehen. Eine weitere lohnende Option ist -e (--exact-bbox): Standardmäßig wird die umschließende Box aus den TFM-Maßen abgeleitet, sodass eine Glyphe, die darüber hinausragt, beschnitten werden kann. Fehlen am Rand einer Abbildung Teile von Buchstaben, greift man zuerst hierzu.
Was mit den Schriften im SVG geschieht: --font-format und --no-fonts
<text> zu behalten ist gut, verlangt aber noch eine Entscheidung. Voreingestellt sind in dvisvgm SVG-Schriften – <font> und <glyph> eingebettet in <defs>. Die gibt es zwar in der Spezifikation, unterstützt werden sie längst nicht überall; das Handbuch von dvisvgm schreibt unter --no-fonts, die Pfadausgabe sei „mit den meisten Anwendungen, die keine SVG-Schriften unterstützen, besser verträglich“. Der Vergleich aller drei Varianten an derselben TikZ-Abbildung: Standard-SVG-Schriften ergaben 5.790 Byte, --font-format=woff2 ergab 4.815 Byte (ein WOFF2 als Daten-URI im src einer @font-face-Regel), und --no-fonts ergab 8.290 Byte mit null <text>-Elementen und jeder Glyphe als <path>. Die Praxisregel ist schlicht. Fürs Web: --font-format=woff2 – der Text bleibt markierbar und jeder Browser stellt ihn dar. Für die Weitergabe an Illustrator, Inkscape oder PowerPoint: --no-fonts – größer, aber es bleibt nichts übrig, das falsch dargestellt werden könnte.
| Option | Text im SVG | Größe bei derselben Abbildung | Wofür geeignet |
|---|---|---|---|
--font-format=svg | <text> plus SVG-Schriften (Voreinstellung) | 5.790 Byte | Unterstützung lückenhaft; selten die richtige Wahl |
--font-format=woff2 | <text> plus WOFF2 in einer @font-face-Regel | 4.815 Byte | Veröffentlichung im Web; markierbarer Text, kleinste Datei |
--no-fonts | kein <text>; jede Glyphe ist ein <path> | 8.290 Byte | Weitergabe an andere Grafikprogramme; nichts kann falsch erscheinen |
Nach PNG rastern – für Folien und ältere Werkzeuge
Viele Ziele nehmen noch kein SVG an; dann weicht man auf PNG aus. Die Auflösung stellt -r ein; 300 dpi gelten als Untergrenze, 600 dpi als Zielwert für Druck oder hochauflösende Bildschirme. Das oben erzeugte Formel-PDF von 85.779 × 27.993 pt bei 600 dpi zu rastern ergab ein transparentes PNG von rund 715 × 233 Pixeln – sowohl mit Ghostscript (gs -sDEVICE=pngalpha -r600) als auch mit pdftocairo -png -r 600 -transp aus poppler. Da 72 pt ein Zoll sind, gilt 85.779 ÷ 72 × 600 ≈ 715; ob die Rechnung aufgeht, ist die Probe darauf, dass die Auflösungsangabe tatsächlich gewirkt hat. Ohne Transparenz liefert -sDEVICE=png16m (beziehungsweise pdftocairo ohne -transp) einen weißen Hintergrund. Viele Anleitungen empfehlen ImageMagick mit magick -density 300 in.pdf out.png, doch ImageMagick reicht das Rendern von PDF an Ghostscript weiter. Es gehört nicht zu TeX Live und war auf dem hier verwendeten Rechner nicht installiert, sein Verhalten wurde also nicht geprüft. Wenn ohnehin Ghostscript zeichnet, spart der direkte Aufruf eine Abhängigkeit.
# Ghostscript, transparent background, 600 dpi
gs -q -dNOPAUSE -dBATCH -sDEVICE=pngalpha -r600 \
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 \
-sOutputFile=eq.png eq.pdf
# poppler, same result, shorter to type
pdftocairo -png -r 600 -transp -singlefile eq.pdf eqIn einem Befehl bis zum PNG: convert= von standalone und --shell-escape
Wem drei Befehle jedes Mal zu viel sind, übergibt die Arbeit der Klassenoption convert= von standalone. Sobald der Satz fertig ist, wirft die Klasse selbst einen Umwandlungsbefehl an die Shell. Als Backend stehen imagemagick (Voreinstellung), ghostscript und pdf2svg zur Wahl, die voreingestellte Auflösung ist density=300. Auch ohne ImageMagick funktioniert es, wenn man ghostscript angibt: Mit \documentclass[border=2pt,convert={ghostscript,density=600,outext=.png}]{standalone} und pdflatex --shell-escape eqc.tex stand im Protokoll gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r600 -sOutputFile=eqc.png eqc.pdf, und ein PNG von 715 × 233 entstand aus diesem einen Befehl. Da ein externes Programm gestartet wird, genügt eingeschränktes Shell-Escape nicht – --shell-escape ist nötig. In einem Projekt mit vielen Abbildungen ist es sicherer, die Umwandlung im Build-Skript zu belassen, damit --shell-escape nicht zur Gewohnheit wird.
% eqc.tex — build the PNG in the same run
\documentclass[border=2pt,convert={ghostscript,density=600,outext=.png}]{standalone}
\usepackage{amsmath}
\begin{document}
$\displaystyle \int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}$
\end{document}
% then: pdflatex --shell-escape eqc.texAlles bisher Beschriebene – nur den Ausschnitt setzen, ihn beschneiden, dann nach Vektor oder Raster überführen – fasst TeX2img in einer grafischen Oberfläche zusammen. Man fügt eine Formel ein, wählt Format und Auflösung, und Transparenz wie Kantenglättung erledigt das Programm. Für einen einmaligen Export ist das unschlagbar schnell; bei einem Dokument mit Dutzenden Abbildungen, das viele Fassungen durchläuft, ist es am Ende bequemer, die Befehle der vorigen Abschnitte in den Build aufzunehmen. TeX2img ist eine eigenständige Anwendung, gehört nicht zu TeX Live und war auf dem hier verwendeten Rechner nicht installiert; sein Verhalten wurde daher nicht überprüft.
In welches Format exportieren?
- Eine Abbildung fürs Web → SVG. Mit
latexein DVI erzeugen unddvisvgm --font-format=woff2laufen lassen. Der Text bleibt in<text>, und beim Zoomen verliert nichts an Qualität. - Eine Abbildung, die zurück in ein LaTeX-Dokument soll → als PDF belassen. Mit
standaloneerzeugt, hat sie keinen Rand und geht direkt in\includegraphics. - Folien, Word, soziale Netzwerke → PNG, über
gs -sDEVICE=pngalpha -r600oderpdftocairo -png -r 600 -transp. Die Transparenz nur weglassen, wenn ein weißer Hintergrund gewünscht ist. - Eine Abbildung, die in Illustrator oder Inkscape nachbearbeitet wird → SVG mit
--no-fonts. Die Formen halten auch dort, wo die Schrift fehlt. - Eine Abbildung mit Fotografie → JPEG nur für das Foto; Strichgrafik und Beschriftung als SVG oder PNG. Das Ganze als JPEG verschmutzt die Ränder der Buchstaben.
- Wenn
dvisvgm --pdfden Dienst verweigert → zuerst auf den DVI-Weg wechseln. Muss es unbedingt aus einem PDF kommen,mutoolaus MuPDF installieren.