Liebe Liste!
Ich begrüße den Trend, dass WYSIWYG-Editoren im Web-Bereich sterben. Die waren schon immer scheiße, aber erst mit den Page-Buildern verschwanden sie aus den Admin-Bereichen. Bei Django CMS, Django Wagtail und vielen Wordpress Themes werden die Seiten in einer langen Liste aus aus Komponenten zusammengeklickt und nicht mehr in ein Textfeld eingegeben.
Meine Frage ist: Gibt es das auch für Print? Hat schonmal ein Verlag ein Programm an seine Autoren geschickt, mit dem sie Textbereiche, Infoboxen und Bilder zusammenklicken? Es gibt bunte XML-Editoren, die genau das mit DocBooks können. Aber die sind schon sehr generisch. Da muss man für eine neue Tabellenzeile eingeben, dass man jetzt das Zeilen-Element haben möchte.
Die Grundvoraussetzung für diese Art Bücher zu schreiben wäre wohl eine Editor-Beschreibungs-Sprache. Darin wird festgelegt, welche Layout-Vorlagen es gibt und welche Eigenschaften sich daran einstellen lassen.
Das Wordpress-Plugin Advanced Custom Fields liest so eine json-Datei ein, die genau festlegt, was in welchem Zusammenhang eigegeben werden kann und muss. Wie das später auf der Seite aussieht, ist dem Plugin egal. Eigentlich wäre dieses Plugin als Stand-Alone-Anwendung schon das, was ich meine.
Als netter Nebeneffekt lassen sich Bücher mit Page-Builder gut im Team bearbeiten und beliebig skalieren. Man könnte jedes Layout (Text, Tabelle, Galerie, Infobox) als eigene Datei ablegen und mit Git verwalten. In den Dateien stehen Vorgänger und Nachfolger. Auf diese Weise fallen Inkonsistenzen automatisch auf. Kollisionen gibt es nur, wenn wirklich das selbe Layout von mehreren bearbeitet wurde.
Mediawiki hat seit ewigen Jahren einen Markdown-Editor. So etwas geht eigentlich nur für Fließtext. Links und Bilder erfordern Konzentration. Galerien, Infoboxen und Tabellen gehen mit normalem Aufwand gar nicht. LaTeX ist am gleichen Problem gestorben. Und gleichzeitig der Beweis, dass automatischer Textsatz ganz OK funktioniert, wenn die Quelle da ist.
Viele Grüße Thomas