Mein Eindruck, wonach es bereits zu einem Bedeutungsverlust des Formats LaTeX bei wissenschaftlichen Publikationen gekommen sein könnte, wird durch einen Blogbeitrag von Martin Fenner zu dem unlängst veranstalteten Workshop für Bibliothekare „Beyond the PDF“ verstärkt. Die Überschrift dieses Beitrags erhält deshalb einen anderen Sinn – weg vom Konverter, hin zum Wechsel des Formats. Fenner äußert darin die Vermutung, EPUB (oder sollte man doch besser „ePub“ schreiben?) solle PDF als Format für wissenschaftliche Veröffentlichungen ablösen, weil es gegenüber diesem eine Reihe von Vorteilen aufweise:
„The ePub format uses a collection of files held together in a zip archive. Content is displayed using a combination of XHTML and CSS – not different from web pages – and the ePub can also contain other files. Journal publishers use XML internally, and it is therefore easy to distribute journal articles in ePub format – some of them are already doing this routinely. ePub has several advantages over PDF, including:
- ePub can be used for all steps in the creation of a scholarly document, including data collection, authoring, annotating and peer review. There is no need for time-consuming and expensive format conversions. Currently most manuscripts are submitted in Microsoft Word or LaTeX formats, and then converted first to XML and then to HTML and PDF. Metadata such as author identifiers, digital object identifiers and semantic information can be added early on and don’t get lost in a format conversion.
- ePub makes it easy to include supplementary material, e.g. video and other multimedia content, the datasets used in the publication (particularly the data used for tables and figures), all cited references in BibTeX format, etc.
- ePub is much better suited for reading on mobile devices, as the format allows reflowing of content. Most articles today are printed from the PDF and then read, but this behavior is rapidly changing.“
Ich kann das gut nachvollziehen. Es gibt immer wieder Anwender, die gerade bei wissenschaftlichen Publikationen von den LaTeX-zu-XML-Konvertern, die es derzeit gibt, enttäuscht sind. Es wäre konsequent, die Daten gleich in einem XML-Format zu erfassen und dann für verschiedene Ausgabegeräte jeweils weiter zu verarbeiten (zum Drucken nach LaTeX; zur Darstellung im Web nach (X)HTML; für mobile Geräte nach EPUB, falls die Quelle nicht von vornherein schon in EPUB vorliegen sollte). Sebastian Rahtz hat das schon vor Jahren vorgeschlagen (ders., The TEI-TeX Interface, in: Proceedings EuroTeX 2005, DTK 2/2006, S. 38 ff., 49: „Forget trying to teach people \{} … Forget trying to make TeX the centre of the universe …“).
Ich würde sofort damit beginnen, meine Daten in einem XML-Format zu erfassen, wenn es dazu akzeptable Editoren gäbe. ODT böte sich hierfür sicherlich an, aber man wird einem Autor, der es gewöhnt ist, in einem Editor zu schreiben, der so leistungsfähig ist wie Emacs mit AUCTeX, nicht ernsthaft vorschlagen wollen, auf LibreOffice umzusteigen. Insbesondere bei langen und komplexen Texten, wie sie im wissenschaftlichen Bereich üblich sind, kann dessen Oberfläche ganz sicherlich nicht mit einem „richtigen“ Texteditor mithalten. Andererseits sind die XML-Modes für den Emacs für die meisten Autoren wohl wenig geeignet. LaTeX ist auch deshalb immer noch bei Autoren beliebt, weil es sehr viel leichter einzugeben ist als die Tag-Suppe aus irgendwelchen, womöglich mehrfach geschachtelten XML-Tags. Davon abgesehen sind die XML-Kommandozeilenwerkzeuge schlicht zu kompliziert in der Handhabung. Wer sich über die steile Lernkurve beim Erlernen von LaTeX beschwert, wird hier erst recht frustriert das Handtuch werfen. Solange die Programme so funktionieren wie derzeit, werde wahrscheinlich nicht nur ich weiter beim Emacs bleiben und wie gewohnt pdflatex aufrufen.
Es ist trotzdem immer wieder interessant, Bibliothekaren beim Nachdenken über wissenschaftliches Arbeiten zuzusehen.
Via Matti Stöhr, der übrigens auch auf den ebenso lesenswerten Bericht von Lambert Heller über dieselbe Tagung verweist.
TeX & Friends 
In XML verfassen? XML ist eine einzige Pest und das ist eine Meinung, die viele in FOSS-Gefilden mit mir teilen. Wie kann man sich dort schnellstens unbeliebt machen? Configdatei statt plain text XML.
Vielen Dank für die Kommentare. Ich finde auch, dass es keine guten XML-Editoren gibt. Das andere große Problem ist dass XML well-formed sein möchte, und den Autor manchmal in eine bestimmte Struktur zwängt.
Bibliothekare waren übrigens bei den Beyond the PDF workshop in der deutlichen Minderheit. Teilnehmer waren hauptsächlich Wissenschaftler (bin ich selbst auch) und Mitarbeiter von Verlagen.
Also meine letzte Publikation musste ich als Word-Dokument einreichen. War bei vier in Betracht kommenden Journals der Fall, zwei davon AMA, einmal BMJ Group. Ich erkenne da in absehbarer Zukunft keinen Paradigmen-Wechsel.
XML eignet sich vielleicht als Austauschformat, aber kaum als Eingabeformat, dazu ist der Signal-Rausch-Abstand einfach deutlich zu klein. Ein typisches XML-Dokument besteht zu einem großen Teil aus Tags (also Syntax), die teilweise auch noch redundant sind, und nicht aus Inhalt. Das hat auch wenig mit der Editorunterstützung zu tun. Wesentlich besser geeignet wären leichtgewichtige Markup-Sprachen wie reStructuredText oder Markdown. Zum Einreichen könnten diese Eingabedateien dann ohne größeren Aufwand ins EPUB-Format konvertiert werden.
Hast Du das mal ausprobiert? Ich habe im letzten Jahr im Selbstversuch beides ausprobiert, XML und reST – bei XML kam ich mit selbsterstelltem doctype mit viel Aufwand ungefähr auf die Flexibilität von TeX, aber am Ende war dann doch nur die Syntax XML, die Strukturen von Beginn an nur Mappings für ConTeXt. Zumindest war es ausreichend mächtig dafür.
reST habe ich danach in Angriff genommen, und im Prinzip kommt man über directives und text roles an alles heran, was auch TeX kann. Dafür sieht auch der Code entsprechend markupdurchsetzt aus. Um Sourcecode zu dokumentieren und für Readme-Dateien ist reST ausgezeichnet. Aber um einen längeren Text zu schreiben, ist XML das absolute Minimum. Nur ein Beispiel: Fußnoten in reST sind der absolute Horror, je mehr man davon hat, desto unlesbarer der Code. (Außerdem ist der PDF-Output von Docutils der letzte Dreck, und die meisten reST-Konverter für TeX implementieren nur ein Subset der Spec.)
Aber, um dem Artikel grundsätzlich recht zu geben: Im Editor ist XML ein Graus, die Balance zwisch Maschinen- und Menschenlesbarkeit gerät mit zunehmender Komplexität ins Wanken.