Markdown / Word

Der Tag einer LaTeX-Nutzerin endet in dem Moment, in dem eine Mitautorin sagt: „Schick es einfach als Word-Datei.“ Die übliche Brücke heißt pandoc, ein Konverter zwischen Markdown, LaTeX und .docx – doch die beiden Richtungen verhalten sich völlig verschieden. Word → LaTeX baut Struktur auf, die es vorher nicht gab, es geht also nichts verloren. LaTeX → Word tut das Gegenteil: Es planiert die mühsam aufgebaute Struktur – die Verbindung zwischen \label und \ref, die Bedeutung eines \newcommand, den Aufbau einer Formel. LaTeX ist ein Programm, ein .docx die Aufzeichnung eines fertigen Ergebnisses. Ein Programm lässt sich ausführen und sein Ergebnis aufheben, aber aus dem Ergebnis lässt sich das Programm nicht zurückgewinnen. Diese Asymmetrie ist das Rückgrat dieser Seite.

Warum LaTeX → Word mehr verliert als die Gegenrichtung

Die Antwort ist einfach: Am Ziel gibt es nichts, was es aufnehmen könnte. Ein .docx ist im Kern ein Behälter für Absätze, Zeichenformatierung und Formatvorlagennamen. Es kennt kein Gegenstück zu \newcommand und keine Mechanik, die die Nummer neu berechnet, auf die ein \ref zeigt. Also übersetzt pandoc die Absicht so weit, wie Words Vokabular reicht, und lässt den Rest fallen. Nummern frieren auf dem Stand ein, den sie gerade hatten, und Querverweise werden zu bloßen Zeichen statt zu lebendigen Verknüpfungen. Die Gegenrichtung ist viel leichter. Ein Word-Dokument hat kaum Struktur jenseits von Überschriftsebenen, Listen und Fettdruck; pandoc bildet das schlicht auf \section und itemize ab: Information kann nur hinzukommen, nie verschwinden. Die Asymmetrie ist auch der Geschichte von pandoc eingeschrieben – die docx-Ausgabe kam mit pandoc 1.9 im Jahr 2012, der docx-Leser samt Verständnis für Änderungsverfolgung stammt von Jesse Rosenthal aus dem Jahr 2014: sechs beziehungsweise acht Jahre nach Projektbeginn.

pandoc-Grundlagen: -f, -t und --pdf-engine

pandoc bedient man, indem man das Eingabeformat mit -f (--from) und das Ausgabeformat mit -t (--to) benennt. In der Mitte steht ein einziger abstrakter Syntaxbaum: Reader bauen den AST auf, Writer geben daraus aus – deshalb vervielfacht sich der Aufwand nicht, wenn Formate hinzukommen. Der Autor John MacFarlane ist Professor für Philosophie an der University of California, Berkeley, und begann das Projekt, um Haskell zu lernen. Die erste, am 3. August 2006 veröffentlichte Fassung umfasste rund 3.000 Zeilen – und konnte bereits zwischen Markdown, reStructuredText, HTML und LaTeX umwandeln. Heute sind es mehr als fünfzig Eingabe- und mehr als siebzig Ausgabeformate. Mit --pdf-engine=lualatex geht es über eine LaTeX-Engine in einem Zug bis zum PDF; zu beachten ist aber: pandoc gehört nicht zu TeX Live. Es ist ein eigenständiges, in Haskell geschriebenes Programm und muss separat installiert werden.

pandoc -f markdown -t latex in.md  -o out.tex    # Markdown to LaTeX
pandoc in.md  -o out.pdf --pdf-engine=lualatex  # Markdown straight to PDF
pandoc in.tex -o out.docx                       # LaTeX to Word
pandoc in.docx -o out.tex                       # Word to LaTeX

Zwei weitere Ansatzpunkte formen die Ausgabe. --template ersetzt das äußere Gerüst textbasierter Ausgabeformate (latex, html und Verwandte), sodass sich eine eigene Präambel oder ein eigenes \documentclass einsetzen lässt. Für Binärformate wie .docx bewirkt es nichts – dafür ist das oben beschriebene --reference-doc zuständig. Der zweite Ansatzpunkt ist ein Lua-Filter (--lua-filter), der den AST unmittelbar nach dem Einlesen und vor dem Schreiben umbaut. Aufgaben wie „diese Umgebung in eine andere Überschrift verwandeln“ oder „jedes \todo{...} entfernen“ sind an dieser Stelle weit sicherer aufgehoben als in regulären Ausdrücken über der LaTeX-Quelle.

Was pandoc von LaTeX versteht – und ob es warnt

pandoc versteht nur einen Teil von LaTeX, schweigt dazu aber nicht völlig. Trifft es bei Formeln auf etwas, das es nicht analysieren kann, gibt es die Warnung Could not convert TeX math aus und belässt diese Formel als LaTeX in der Ausgabe – sie wird durchgereicht, nicht verworfen. Eigene Makros überstehen mehr, als man erwarten würde: Ist die Erweiterung latex_macros aktiv, analysiert pandoc laut offiziellem Handbuch LaTeX-Makrodefinitionen und wendet die entstehenden Makros auf alle LaTeX-Mathematik und allen rohen LaTeX-Code an. Ein \newcommand{\R}{\mathbb{R}} kommt also durch. Wirklich lautlos verschwindet erst, was darüber hinausgeht. Ein Block, den pandoc als rohes LaTeX einstuft – etwa eine tikzpicture-Umgebung – bleibt im AST als raw erhalten, doch die docx- und HTML-Writer geben ihn nicht aus. Eine Warnung wie bei Formeln erscheint dabei nicht, und so fällt der Verlust erst auf, wenn die Datei in Word geöffnet wird und die Abbildung schlicht fehlt.

Das Aussehen der Word-Datei mit --reference-doc steuern

Stimmt das Aussehen des erzeugten .docx nicht, dreht man nicht an einer Vorlage, sondern an --reference-doc. Das offizielle Handbuch erklärt den Mechanismus unmissverständlich: Der Inhalt des Referenz-docx wird ignoriert; nur seine Formatvorlagen und Dokumenteigenschaften – einschließlich Rändern, Seitengröße, Kopf- und Fußzeile – werden im neuen docx verwendet. Die Referenzdatei ist also ein leeres Formatmuster, kein Textgerüst. Der richtige Weg lautet daher: die Standard-Referenzdatei aus pandoc herausholen, in Word oder LibreOffice öffnen, die Formatvorlagen (Heading 1, Body Text, Table Caption und so weiter) nach den Einreichungsrichtlinien anpassen, speichern und wiederverwenden. Das Handbuch ergänzt, dass das Referenz-docx am besten eine abgewandelte Fassung eines von pandoc erzeugten docx ist. Beim Herausholen muss -o vor --print-default-data-file stehen.

# 1. extract the default reference file (-o must come first)
pandoc -o custom-reference.docx --print-default-data-file reference.docx

# 2. edit the STYLES in Word or LibreOffice, then save

# 3. reuse it for every export
pandoc in.tex -o out.docx --reference-doc=custom-reference.docx

Die Optionen, auf die es bei Word → LaTeX wirklich ankommt

Ein .docx ist im Grunde ein ZIP-Archiv voller XML, pandoc kann es also direkt lesen. Der erste Schalter beim Import ist --extract-media=media; er tut genau das, was das offizielle Handbuch beschreibt: Bilder und andere Medien, die im Quelldokument enthalten oder verlinkt sind, in dieses Verzeichnis zu entpacken und die Bildverweise auf die entpackten Dateien umzuschreiben. Wer ihn vergisst, findet die Abbildungen nirgends. Dateien, die von Mitautoren zurückkommen, enthalten meist Änderungsverfolgung; --track-changes=accept / reject / all bestimmt, was damit geschieht – all behält alles in Spans verpackt. Die Option wirkt nur auf den docx-Leser. Literatur lässt sich mit --citeproc und einer .bib-Datei auflösen, den CSL-Stil wählt --csl. Stören die hart umbrochenen Absätze in der Ausgabe, hilft --wrap=none. Words Absatzformate überleben als custom-style – ein Ansatzpunkt, um die Hausformate einer Autorin auf LaTeX-Umgebungen abzubilden.

pandoc in.docx -o out.tex \
  --extract-media=media \
  --track-changes=accept \
  --wrap=none

# with a bibliography and a journal style
pandoc in.docx -o out.tex --citeproc --bibliography=refs.bib --csl=apa.csl

Ohne pandoc zu Word: die ODT-Ausgabe von tex4ht

Wenig bekannt, aber wahr: TeX Live allein reicht bis zu einem Textverarbeitungsformat. make4ht -f odt file.tex erzeugt eine .odt-Datei, also OpenDocument-Text. Öffnet man sie, zeigt sich: Es ist keine Bildmontage – die Mathematik steckt als ODF-Formelobjekt vom Medientyp application/vnd.oasis.opendocument.formula darin, und im Inneren steht MathML. Die Formeln bleiben auf der Textverarbeitungsseite also Formeln. mk4ht oolatex file.tex nimmt denselben Weg (ältere Artikel nennen ein eigenständiges Kommando oolatex; in TeX Live 2024 wird es als Auftragsname von mk4ht aufgerufen). Word kann OpenDocument-Text öffnen, und wer sichergehen will, öffnet die Datei in LibreOffice und speichert sie erneut als .docx. Geht es darum, editierbare Formeln zu übergeben, ist dieser Weg dem über pandoc mitunter überlegen.

# LaTeX to OpenDocument text, using only TeX Live
make4ht -f odt file.tex

# the same route under its historical name
mk4ht oolatex file.tex

Zwei weitere Werkzeuge seien wenigstens genannt. writer2latex ist ein quelloffenes Java-Programm, das LibreOffice-/OpenOffice-Dokumente nach LaTeX wandelt, und GrindEQ ein kommerzieller Word-↔-LaTeX-Konverter, der für den guten Umgang mit MathType-Formeln bekannt ist. Beide gehören nicht zu TeX Live und waren auf dem Rechner für diesen Artikel nicht installiert; ihr Verhalten wurde hier also nicht überprüft. Wer eines davon einsetzt, probiert es zuerst an einem kleinen Ausschnitt der echten Datei aus und sieht selbst nach, ob Formeln und Abbildungen überleben.

Zusammenarbeit mit Mitautoren, die auf Word bestehen

• LaTeX bleibt die maßgebliche Fassung. Ein .docx ist Ausgabe, keine Arbeitsdatei. Sobald eine direkt in Word bearbeitete Version zum Original wird, verschlechtert sich das Dokument mit jedem Hin und Her.
• Abschnittsweise weitergeben, nicht die ganze Arbeit. Nur den Abschnitt zu schicken, zu dem Kommentare erwünscht sind, lässt sich weit leichter zurückführen als ein riesiges .docx.
• Rückläufer zuerst mit --track-changes=all lesen. Erst sehen, was sich geändert hat, dann mit accept übernehmen oder nur die Änderungen von Hand in die Quelle übertragen.
• Abbildungen von Anfang an als Bilddateien führen. TikZ verschwindet durch pandoc; ein Aufbau, bei dem Abbildungen nach SVG oder PDF exportiert und mit \includegraphics eingebunden werden, übersteht jede Umwandlung.
• Sollen die Formeln editierbar bleiben, den ODT-Weg probieren. make4ht -f odt belässt sie als MathML-Formelobjekte.
• Die Formatvorgaben der Zeitschrift in ein --reference-doc sperren. Ränder und Formatvorlagen jedes Mal von Hand in Word zu korrigieren, vergisst man beim zweiten Mal garantiert.