Nachgelegt: Der Workflow beim Schreiben

Nachdem ich bereits heute Morgen auf Facebook ein paar Worte zu meinem aktuellen kreativ Projekt habe fallen lassen und bereits vor einiger Zeit etwas grundsätzliches zu meinem Workflow in Bezug auf abfassen von Texten geschrieben habe, dachte ich mir, dass ich eigentlich auch mal ein, zwei Worte darüber schreiben könnte, wie sich mein Workflow bei Keativarbeiten unterscheidet.

Ich werde (jedenfalls in diesem Post) nichts dazu schreiben, wie man eine Idee für Texte findet oder wie man diese aufbereiten kann um daraus letztendlich wirklich einen Text zu stricken, denn dies würde sicherlich den Umfang dieses kleinen Artikels um längen Sprengen und kann sicherlich auch nicht so trivial beantwortet werden.

Wie viele sicherlich schon mitbekommen haben dürften verwende ich oftmals und eigentlich fast immer den kleinen minimalistischen Editor vim. Schon alleine aus dem Grund, dass dieser Editor hübsch schlank ist und mich von den meisten Distraktion fern hält. Ich kann mich einfach auf den Inhalt konzentrieren kann. Generell bevorzuge ich eher eine Konzentration auf den Inhalt anstatt auf das Äußere eines Textes. sicherlich gibt es einigermaßen vernünftige Richtext Editoren, die (vermeintlich) ihre Arbeit zufriedenstellend verrichten.
Um eine weitere angenehmes Arbeiten mit den Inhalten zu ermöglichen verwende ich Markdown zum schreiben des Textes (im besonderen hier pandoc flavored Markdown), welches die Grundlage bildet um ansprechende Ausgabeformate zu kreieren: pandoc als Markdown Prozessor ermöglicht es mir die einzelnen Markdownfiles in verschiedene Ausgabeformate zu transformieren. Derzeit verwende ich per se zwei bis drei verschiedene Ausgabefilter: odt, (La)TeX und DocBook. Das erste der drei Formate ist vielleicht das bekanntestete der Dreien. Da allerdings nicht ganz offensichtlich ist, warum ich diese drei Formate nutze, soll dies natürlich erklärt werde:

  • ODT: ganz einfacher Anwendungsfall, denn *.odt Files kann ich bequem verwenden um entweder eine schnelles (optisch nicht ganz so schickes) PDF zu exportieren und/oder einfach Ausschnitte der Arbeit an meine Testleser aus zu liefern. (Ja, ich bin so ein Mensch, der ein gewisses Maß an echtem Feedback benötigt). Auch ein Export nach MS Office wäre hier denkbar, sofern man dies denn wirklich benötigt.
  • (La)TeX: Meine Wahl, wenn es um PDFs geht, die für den Print vorgesehen sind und aus diesem Grund verschiedene Anforderungen erfüllen müssen. Nicht zu Letzt soll eine Printausgabe ja auch ansprechende ausschauen, sonst bekommen wir ja alle Augenkrebs. LaTeX erzeugt übrigens eine äußerst akurate und angenehme Typographie. (In den meisten Fällen wesentlich bessere als InDesign oder Quarkxpress).
  • DocBook: genauso wie LaTeX ist dieses Format eher nicht für Einsteiger geeignet, da es zwar hochgradig flexibel ist, aber an vielen Stellen eben nicht sonderlich gut in Bezug auf Usability. Bei DocBook handelt es sich um einen Ableger aus der Familie der Auszeichungs und Struktursprachen, die ihre Eigenschaften von SGML erben (HTML oder XML gehören ebenfalls in diese Familie). Aus DocBook heraus ist es vergleichsweise einfach ePublikationen wie eBooks in den gängigen Formaten zu erstellen. Da DocBook wie XML durch XSLT modifiziert werden kann, sind hier so gut wie keine Grenzen zur Weiterverarbeitung gesetzt.

So viel erstmal zum Erzeugen des Inhaltes aus rein technischer Sicht. Nun gut, ich habe wohl noch nicht erwähnt, was mein Kleber zum steuern und produzieren ist. pandoc als Prozessor kann zwar alle drei aufgeführte Formate ohne weiteres erzeugen, doch spielt pandoc seine Stärken erst aus, sofern man ein wenig auf Automation setzt. Da ich eh innerhalb von Shells arbeite und oft Software baue, bietet es sich an auch hier auf ein entsprechendes Tool zu setzen. Für mich ergaben sich nach Überlegungen nur zwei wirkliche Methoden: entweder der Einsatz eines Makefiles, welches GNU make steuert oder der Einsatzes einen python build-scribtes mit optionaler yaml Konfigurationsdatei. – Derzeit setze ich auf die erste der beiden Lösungen, ich nutze also ein Makefile.

Da nun geklärt ist noch ein abschließendes Wort zur Speicherung der Daten: per se ist im Falle von „Akaya“ vorgesehen, dass jedes Kapitel in einer eigenen Markdown-Datei abgelegt wird, sowie der jeweilige Output von pandoc in verschiedenen Unterverzeichnissen, welche relativ zum Arbeitsverzeichnis existieren. In den beiden Verzeichnissen für LaTeX und DocBook existiert jeweils ein git Repository um die erzeugten Dateien zu verwalten. Bei den eigentlichen Markdown Dateien ist dies nicht von Nöten. An sich wird im übrigen das ganze Arbeitsverzeichnis via rsync auf mehrere Maschinen gesnced um die Möglichkeit zu bieten von mehreren Maschinen aus arbeiten zu könne.

Advertisements
Veröffentlicht in Suppentopf

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: