Lyndis: Live aus Westwoodforest

Schon seit ich wieder regelmäßig schreibe, geht es mir ständig richtig auf die Nerven, dass ich meine Texte einzeln für animexx und ff.de umformatieren muss.

Ich weiß, dass FF.de auch odf Dateien annimmt, aber dann muss ich jedes Mal das aktuelle Kapitel aus dem eigentlichen Dokument heraus kopieren und in ein neues Speichern und dieses Dokument dann hochladen. 

Animexx ist da schon komfortabler, aber beim copy&pasten geht trotzdem das ein oder andere verloren. Wie zum Beispiel Textzentrierungen, die ich brauche, um Textabschnitte voneinander abzutrennen und die POV anzugeben.

Es geht leider auch nicht, dass ich einfach einmal das Kapitel formatiere, weil mexx und ff.de unterschiedliche Syntax verwenden (etwas in italic zu schreiben geht auf ff.de mit [style type = "italic" ][ / style ] und auf mexx mit [ i ][ / i ]).

Zusätzlich dazu, werde ich demnächst irgendwann (ist schon länger geplant aber bisher noch nicht umgesetzt) beginnen auf ff.net und ao3 (archive of our own) zu veröffentlichen und ich glaube, die beiden haben auch ihre ganz eigene Syntax.

Muss ich dann also einen Text 4 Mal editieren? Pfft... nein, ganz sicher nicht.

Es nervt mich teilweise so sehr, dass ich das veröffentlichen auf einer Plattform aufgeschoben haben. Jüngst hat das dazu geführt, dass ich hier auf mexx vollkommen vergessen habe, 2 Kapitel hochzuladen.

Warum erzähle ich euch das jetzt? Nun, ich bin Informatikerin und so ein Problem lässt sich netterweise mit Informatik lösen. Euch erzähle ich das, weil ich das folgende Projekt mit euch teilen will:

Ich will einen Parser schreiben.

Was ist ein Parser? Um es einfach zu machen: In meinem Fall ist ein Parser ein Programm, in das ich eine ODF (Open Office oder Libre Office) Datei gebe und die mir den Inhalt davon in den jeweiligen Formatierungen ausgibt, die ich für die Seiten brauche, auf denen ich veröffentliche.

Achtung, ab hier wird es technisch. Ich merkiere die Stelle, an der es wieder weniger technisch wird. Aber für alle, die sich für sowas interessieren, kann ich empfehlen weiter zu lesen. Ich halte die Sprache so einfach wie möglich.

Ich habe sowas ähnliches schonmal mit reinen .txt Dateien gemacht, die ich zur hübscheren Darstellung in eine .html Datei umgewandelt habe. Das ging wesentlich einfacher wie das, was ich jetzt vorhabe.

Warum war das einfacher? .txt Dateien sind Plain-Text Dateien. Das heißt, es läuft kein Programm, das diesen Text in irgendeiner anderen Weise darstellt, als das, was da wirklich steht. Anders sind z.B. HTML Dateien, die Befehle beinhalten, die dem Browser sagen, wie er Textteile darstellen soll. Will ich also eine .txt Datei Parsen, gehe ich Zeile für Zeile durch, vielleicht auch Wort für Wort und übertrage die in ein HTML Format. Will ich HTML Parsen, wird das schon schwieriger, weil ich dann vielleicht nicht nur den reinen Text haben will, sondern die Formatierungen berücksichtigen muss. Wenn ich zum Beispiel eine Tabelle, weiterhin als Tabelle haben will, muss ich die ganzen < table >< / table > Befehle berücksichtigen und einen Parser schreibt man eben so, dass es für möglichst ALLE Arten eines Dateiformats funktioniert. Das heißt, ich weiß, dass in dem Dokument irgendwo eine Tabelle auftaucht, aber ich habe keine Ahnung wo bzw. in welcher Zeile genau. Das heißt, statt dem Programm zu sagen 'Hey du, in Zeile so und so fängt eine Tabelle an und in Zeile so und so hört sie wieder auf' muss ich ihm sagen 'Du, achte mal darauf, ob du irgendwo ein < table > findest und wandle alles was danach kommt um, bis du auf ein < / table > triffst.' Und das müsste ich für jede Formatierung machen, auf die ich stoße. Das ist aber auch noch vergleichsweise einfach.

Denn dann gibt es ODF Dateien... Das ODF Format ist ein Sammelsurium von verschiedenen Dateien, die (meiner Meinung nach) auf ziemlich übertriebene Art und Weise ziemlich unlogisch zusammenhängen. Ihr wollt wissen, wie das aussieht? Macht mal einen Rechtsklick auf eine ODF Datei und wählt dann unter 'Öffnen mit' irgendein ZIP Programm aus (7zip oder WinRaR oder so). Dann seht ihr alle Dateien, die so eine simple ODF Datei eigentlich enthält.

In der content.xml steht der Inhalt der Datei inkl. einem Haufen unnötiger Formatierungsbefehle. Warum unnötig? Wenn ihr an 4 verschiedenen Stellen im Dokument irgendwas italic macht, hat diese Datei 4 verschiedene Befehle dafür, obwohl in jedem Befehl exakt das gleiche drin steht. Sowas sieht zum Beispiel so aus:

-<style:style style:name="P12" style:parent-style-name="Standard" style:family="paragraph">

<style:paragraph-properties style:justify-single-word="false" fo:text-align="justify"/>

<style:text-properties officeooo:paragraph-rsid="00e2d7e6" officeooo:rsid="01da2dd7" style:font-style-complex="italic" style:font-style-asian="italic" fo:font-style="italic"/>

</style:style>

Lasst euch nicht zu sehr verwirren, alles was wir brauchen ist das, wo 'italic' steht.

Das ist ein abgeschlossener style Befehl, der einem Textabschnitt sagt, wie er auszusehen hat. Wer ein bisschen was damit anfangen kann, wird sich jetzt vielleicht fragen 'Hä? Wie jetzt? Aber da ist doch gar kein Text!'. Richtig!

Der dazu passende Text kommt nämlich viiiiel weiter unten:

<text:p text:style-name="P12">Ich habe dir vertraut.</text:p>

<text:p text:style-name="P12"/>

Der Textschnippsel 'Ich habe dir vertraut', wäre jetzt italic, also schräg geschrieben. Der Name 'P12' verweist auf den oben angegebenen Style Befehl.

Jetzt ist ODF leider nicht sonderlich intelligent in der Erstellung dieser Befehle. Gefühlt jede Zeile hat einen anderen Stylebefehl, obwohl ich außer 'center', 'Überschrift 1', 'Überschrift 2' (ganz selten auch 'Überschrift 3') und 'italic' oder 'bold' keinerlei Stylebefehle verwende. Man sollte jetzt also eigentlich annehmen können, dass ODF auch nur maximal 6 Stylebefehle erstellt. Falsch. Die Befehle gehen von P1 bis P37 in diesem Dokument und ich habe nochmal Befehle die mit T beginnen und von T1 bis T14 gehen. Und gefühlt in 90% aller Fäller steht in den Befehlen das gleiche! In weiteren 9% (hauptsächlich in den T Befehlen) steht Zeug drin, die ich zum Parsen gar nicht benötige. Das zumindest ist gut, den Kram kann ich dann nämlich ignorieren.

Jetzt hat tatsächlich jede Zeile andere Befehle. Das ist schon allein deshalb bescheuert, weil ich dann zum Parsen immer den Text suchen muss. Ich muss dem Programm also beibringen, wie es den PlainText findet (müsste ich bei HTML auch). Das Programm muss also Zeile für Zeile durchgehen und das als Text interpretieren, was zwischen > < steht. Warum? Weil der anfang eines Befehls mit > endet und das ende eines Befehls mit < Anfängt. Jedes Mal, wenn das Programm also auf ein > trifft, müsste es testen, ob danach noch ein Buchstabe kommt, weil es sonst viel zu viele Leerzeilen mit rein nehmen würde. Das ist aufwendig und unschön, wäre aber nicht zu vermeiden.

Achtung, ab hier wird es NOCH technischer

Zusätzlich dazu müsste ich die Formatierungen irgendwie rausfinden. Dazu gibt es mehrere Möglichkeiten, aber ich finde die hier am einfachsten umzusetzen:

Die Formatierungsbefehle der Datei stehen am Anfang. Ich müsste also durch die anfänglichen Zeilen gehen (ich weiß nicht wie viele es sind, deshalb müsste ich mir noch einen Stopp-Befehl ausdenken. In dem Fall von ODF muss das Programm aufhören wenn es auf den Befehl < office:body > trifft) und dem Programm sagen, dass es sich die Namen der Befehle merken soll (wie z.B. P12) die Formatierungen enthalten. Das ist nicht so trivial, wie es sich anhört. Warum? Ein Programm kann in dem Sinn nichts 'sehen'. Wenn wir auf so einen Programm Schnippsel schauen und ein wenig geübt darin sind, sowas zu lesen, sehen wir schnell 'ok, da steht italic, ein bisschen weiter oben steht style:Name=P12, das wird der Name des Befehls sein'. Einem Programm muss man das erst beibringen. Ich könnte natürlich hingehen und jeden der über 40 Befehle speichern lassen und dann bei jeder Zeile mit dem Namen überprüfen lassen, ob das ein Befehl ist, der eine relevante Formatierung enthält, aber das ist ultra aufwendig und unschön. Was ich also machen muss, ist dem Programm zu sagen, dass es sich merken soll, wenn es auf ein Element stößt, dass 'style:Name' beinhaltet, den Namen erstmal speichern soll und dann bis zum nächsten </style:style> schauen soll, ob es eine relevante formatierung findet. Wenn ja, soll es sich den Namen merken und zusätzlich die entsprechende Formatierung dafür speichern. Jetzt kann so ein Befehl aber mehrere Formatierungen enthalten. Deshalb muss das Programm diesem Namen auch ja jede Formatierung zuordnen können. Das ist meiner Meinung nach der einfachste Weg. 

Das ist alles machbar aber nervig. Das könnte einfacher gehen! Aber das ist eben das Problem, mit einem WYSIWYG Editor. Die bauen alle so einen Murks.

Ab hier wird es wieder untechnischer

Wenn ich mich jetzt so darüber aufrege, was das ODF Format macht, warum benutze ich nicht was sinnvolleres? Markdown würde sich unglaublich anbieten. Dafür wäre es super simpel einen Parser zu schreiben. Warum mache ich es nicht einfach so?

Abreitsumgebungen sind wichtig. Und ich stehe auf schnörkel und fancy Schriftarten wenn ich schreibe, weil mir das mehr Spaß macht. Für Sachtexte (wie diesen hier gerade) würde ich immer zu markdown oder LaTeX greifen, aber nicht für kreatives Schreiben. Ich habe Stunden damit verbracht mir eine Vorlage in LibreOffice zu basteln, die mir gefällt und mir Spaß macht. Markdown Editoren kann man auch bis zu einem gewissen Grad anpassen, aber einfach nicht so sehr. Das heißt, um mir ein bis zweimal die Woche zu ersparen, meine Texte umzuformatieren, müsste ich einen großen Teil meines Wohlbefindens mit meiner Arbeitsumgebung einbüßen. Das will ich nicht.

Deshalb will ich diesen Parser schreiben. Es gibt aber noch mehr Probleme, die ich mit dem Parser habe, als das oben beschriebene. Das ist einfach nur umständlich und aufwendig, aber an sich kein Problem. 

Ich will den Parser in Javascript schreiben und das ganze in einer HTML Datei ausführen lassen. Warum? Weil das die einfachste Möglichkeit ist, das Programm nachher zu bedienen und vor allem weiter zu geben. Denn ich will euch dieses Programm auch zugänglich machen.

Ich will, dass ihr das ohne Probleme bedienen könnt, ohne irgendwas zusätzlich installieren zu müssen. Ich will euch eine ZIP Datei zukommen lassen können, die ihr einfach nur entpacken müsst. Dann könnt ihr die HTML Datei öffnen und direkt loslegen. 

Es ist kein Problem eine ODF Datei in Javascript einzulesen. Es ist aber ein Problem, das Teil dann in ein ZIP umzuwandeln, damit ich an die content.xml komme. (Ich will den Zwischenschritt nicht machen müssen, das ODF als ZIP zu speichern. Das ist aufwendig)

Ich habe einen Workaround gefunden, mit dem ich aber noch nicht ganz zufrieden bin. Es ist aber ein Anfang. Man kann eine ODF Datei als HTML abspeichern. Wenn man das macht, bekommt man sogar einigermaßen sauberes HTML raus. Aber das ist ein Zwischenschritt, der mich momentan noch sehr nervt. Ich denke aber, ich werde den Parser erst einmal dafür schreiben.

Sollte irgendwer, der hier drüber stolpert, wissen, wie man mit Javascript (oder einer JS Library) an die content.xml kommt, bitte ich darum, mir Bescheid zu geben. Vielleicht ist es ja gar nicht so schwer und ich denke einfach verkehrt.     - Problem ist vorläufig gelöst. Danke an  Galileo 

Wer es bis hierher geschafft hat, dem gratuliere ich. 

In jedem Fall werde ich euch mit dem Projekt auf dem Laufenden halten. Ich hoffe, der Artikel war nicht zu verwirrend geschrieben. Ich hab das gerade einfach so runter getippt, weil ich mal meine Gedanken dazu niederschreiben wollte.

Auf bald! 

Lyn

Schon seit ich wieder regelmäßig schreibe, geht es mir ständig richtig auf die Nerven, dass ich meine Texte einzeln für animexx und ff.de umformatieren muss.

Ich weiß, dass FF.de auch odf Dateien annimmt, aber dann muss ich jedes Mal das aktuelle Kapitel aus dem eigentlichen Dokument heraus kopieren und in ein neues Speichern und dieses Dokument dann hochladen. 

Animexx ist da schon komfortabler, aber beim copy&pasten geht trotzdem das ein oder andere verloren. Wie zum Beispiel Textzentrierungen, die ich brauche, um Textabschnitte voneinander abzutrennen und die POV anzugeben.

Es geht leider auch nicht, dass ich einfach einmal das Kapitel formatiere, weil mexx und ff.de unterschiedliche Syntax verwenden (etwas in italic zu schreiben geht auf ff.de mit [style type = "italic" ][ / style ] und auf mexx mit [ i ][ / i ]).

Zusätzlich dazu, werde ich demnächst irgendwann (ist schon länger geplant aber bisher noch nicht umgesetzt) beginnen auf ff.net und ao3 (archive of our own) zu veröffentlichen und ich glaube, die beiden haben auch ihre ganz eigene Syntax.

Muss ich dann also einen Text 4 Mal editieren? Pfft... nein, ganz sicher nicht.

Es nervt mich teilweise so sehr, dass ich das veröffentlichen auf einer Plattform aufgeschoben haben. Jüngst hat das dazu geführt, dass ich hier auf mexx vollkommen vergessen habe, 2 Kapitel hochzuladen.

Warum erzähle ich euch das jetzt? Nun, ich bin Informatikerin und so ein Problem lässt sich netterweise mit Informatik lösen. Euch erzähle ich das, weil ich das folgende Projekt mit euch teilen will:

Ich will einen Parser schreiben.

Was ist ein Parser? Um es einfach zu machen: In meinem Fall ist ein Parser ein Programm, in das ich eine ODF (Open Office oder Libre Office) Datei gebe und die mir den Inhalt davon in den jeweiligen Formatierungen ausgibt, die ich für die Seiten brauche, auf denen ich veröffentliche.

Achtung, ab hier wird es technisch. Ich merkiere die Stelle, an der es wieder weniger technisch wird. Aber für alle, die sich für sowas interessieren, kann ich empfehlen weiter zu lesen. Ich halte die Sprache so einfach wie möglich.

Ich habe sowas ähnliches schonmal mit reinen .txt Dateien gemacht, die ich zur hübscheren Darstellung in eine .html Datei umgewandelt habe. Das ging wesentlich einfacher wie das, was ich jetzt vorhabe.

Warum war das einfacher? .txt Dateien sind Plain-Text Dateien. Das heißt, es läuft kein Programm, das diesen Text in irgendeiner anderen Weise darstellt, als das, was da wirklich steht. Anders sind z.B. HTML Dateien, die Befehle beinhalten, die dem Browser sagen, wie er Textteile darstellen soll. Will ich also eine .txt Datei Parsen, gehe ich Zeile für Zeile durch, vielleicht auch Wort für Wort und übertrage die in ein HTML Format. Will ich HTML Parsen, wird das schon schwieriger, weil ich dann vielleicht nicht nur den reinen Text haben will, sondern die Formatierungen berücksichtigen muss. Wenn ich zum Beispiel eine Tabelle, weiterhin als Tabelle haben will, muss ich die ganzen < table >< / table > Befehle berücksichtigen und einen Parser schreibt man eben so, dass es für möglichst ALLE Arten eines Dateiformats funktioniert. Das heißt, ich weiß, dass in dem Dokument irgendwo eine Tabelle auftaucht, aber ich habe keine Ahnung wo bzw. in welcher Zeile genau. Das heißt, statt dem Programm zu sagen 'Hey du, in Zeile so und so fängt eine Tabelle an und in Zeile so und so hört sie wieder auf' muss ich ihm sagen 'Du, achte mal darauf, ob du irgendwo ein < table > findest und wandle alles was danach kommt um, bis du auf ein < / table > triffst.' Und das müsste ich für jede Formatierung machen, auf die ich stoße. Das ist aber auch noch vergleichsweise einfach.

Denn dann gibt es ODF Dateien... Das ODF Format ist ein Sammelsurium von verschiedenen Dateien, die (meiner Meinung nach) auf ziemlich übertriebene Art und Weise ziemlich unlogisch zusammenhängen. Ihr wollt wissen, wie das aussieht? Macht mal einen Rechtsklick auf eine ODF Datei und wählt dann unter 'Öffnen mit' irgendein ZIP Programm aus (7zip oder WinRaR oder so). Dann seht ihr alle Dateien, die so eine simple ODF Datei eigentlich enthält.

In der content.xml steht der Inhalt der Datei inkl. einem Haufen unnötiger Formatierungsbefehle. Warum unnötig? Wenn ihr an 4 verschiedenen Stellen im Dokument irgendwas italic macht, hat diese Datei 4 verschiedene Befehle dafür, obwohl in jedem Befehl exakt das gleiche drin steht. Sowas sieht zum Beispiel so aus:

-<style:style style:name="P12" style:parent-style-name="Standard" style:family="paragraph">

<style:paragraph-properties style:justify-single-word="false" fo:text-align="justify"/>

<style:text-properties officeooo:paragraph-rsid="00e2d7e6" officeooo:rsid="01da2dd7" style:font-style-complex="italic" style:font-style-asian="italic" fo:font-style="italic"/>

</style:style>

Lasst euch nicht zu sehr verwirren, alles was wir brauchen ist das, wo 'italic' steht.

Das ist ein abgeschlossener style Befehl, der einem Textabschnitt sagt, wie er auszusehen hat. Wer ein bisschen was damit anfangen kann, wird sich jetzt vielleicht fragen 'Hä? Wie jetzt? Aber da ist doch gar kein Text!'. Richtig!

Der dazu passende Text kommt nämlich viiiiel weiter unten:

<text:p text:style-name="P12">Ich habe dir vertraut.</text:p>

<text:p text:style-name="P12"/>

Der Textschnippsel 'Ich habe dir vertraut', wäre jetzt italic, also schräg geschrieben. Der Name 'P12' verweist auf den oben angegebenen Style Befehl.

Jetzt ist ODF leider nicht sonderlich intelligent in der Erstellung dieser Befehle. Gefühlt jede Zeile hat einen anderen Stylebefehl, obwohl ich außer 'center', 'Überschrift 1', 'Überschrift 2' (ganz selten auch 'Überschrift 3') und 'italic' oder 'bold' keinerlei Stylebefehle verwende. Man sollte jetzt also eigentlich annehmen können, dass ODF auch nur maximal 6 Stylebefehle erstellt. Falsch. Die Befehle gehen von P1 bis P37 in diesem Dokument und ich habe nochmal Befehle die mit T beginnen und von T1 bis T14 gehen. Und gefühlt in 90% aller Fäller steht in den Befehlen das gleiche! In weiteren 9% (hauptsächlich in den T Befehlen) steht Zeug drin, die ich zum Parsen gar nicht benötige. Das zumindest ist gut, den Kram kann ich dann nämlich ignorieren.

Jetzt hat tatsächlich jede Zeile andere Befehle. Das ist schon allein deshalb bescheuert, weil ich dann zum Parsen immer den Text suchen muss. Ich muss dem Programm also beibringen, wie es den PlainText findet (müsste ich bei HTML auch). Das Programm muss also Zeile für Zeile durchgehen und das als Text interpretieren, was zwischen > < steht. Warum? Weil der anfang eines Befehls mit > endet und das ende eines Befehls mit < Anfängt. Jedes Mal, wenn das Programm also auf ein > trifft, müsste es testen, ob danach noch ein Buchstabe kommt, weil es sonst viel zu viele Leerzeilen mit rein nehmen würde. Das ist aufwendig und unschön, wäre aber nicht zu vermeiden.

Achtung, ab hier wird es NOCH technischer

Zusätzlich dazu müsste ich die Formatierungen irgendwie rausfinden. Dazu gibt es mehrere Möglichkeiten, aber ich finde die hier am einfachsten umzusetzen:

Die Formatierungsbefehle der Datei stehen am Anfang. Ich müsste also durch die anfänglichen Zeilen gehen (ich weiß nicht wie viele es sind, deshalb müsste ich mir noch einen Stopp-Befehl ausdenken. In dem Fall von ODF muss das Programm aufhören wenn es auf den Befehl < office:body > trifft) und dem Programm sagen, dass es sich die Namen der Befehle merken soll (wie z.B. P12) die Formatierungen enthalten. Das ist nicht so trivial, wie es sich anhört. Warum? Ein Programm kann in dem Sinn nichts 'sehen'. Wenn wir auf so einen Programm Schnippsel schauen und ein wenig geübt darin sind, sowas zu lesen, sehen wir schnell 'ok, da steht italic, ein bisschen weiter oben steht style:Name=P12, das wird der Name des Befehls sein'. Einem Programm muss man das erst beibringen. Ich könnte natürlich hingehen und jeden der über 40 Befehle speichern lassen und dann bei jeder Zeile mit dem Namen überprüfen lassen, ob das ein Befehl ist, der eine relevante Formatierung enthält, aber das ist ultra aufwendig und unschön. Was ich also machen muss, ist dem Programm zu sagen, dass es sich merken soll, wenn es auf ein Element stößt, dass 'style:Name' beinhaltet, den Namen erstmal speichern soll und dann bis zum nächsten </style:style> schauen soll, ob es eine relevante formatierung findet. Wenn ja, soll es sich den Namen merken und zusätzlich die entsprechende Formatierung dafür speichern. Jetzt kann so ein Befehl aber mehrere Formatierungen enthalten. Deshalb muss das Programm diesem Namen auch ja jede Formatierung zuordnen können. Das ist meiner Meinung nach der einfachste Weg. 

Das ist alles machbar aber nervig. Das könnte einfacher gehen! Aber das ist eben das Problem, mit einem WYSIWYG Editor. Die bauen alle so einen Murks.

Ab hier wird es wieder untechnischer

Wenn ich mich jetzt so darüber aufrege, was das ODF Format macht, warum benutze ich nicht was sinnvolleres? Markdown würde sich unglaublich anbieten. Dafür wäre es super simpel einen Parser zu schreiben. Warum mache ich es nicht einfach so?

Abreitsumgebungen sind wichtig. Und ich stehe auf schnörkel und fancy Schriftarten wenn ich schreibe, weil mir das mehr Spaß macht. Für Sachtexte (wie diesen hier gerade) würde ich immer zu markdown oder LaTeX greifen, aber nicht für kreatives Schreiben. Ich habe Stunden damit verbracht mir eine Vorlage in LibreOffice zu basteln, die mir gefällt und mir Spaß macht. Markdown Editoren kann man auch bis zu einem gewissen Grad anpassen, aber einfach nicht so sehr. Das heißt, um mir ein bis zweimal die Woche zu ersparen, meine Texte umzuformatieren, müsste ich einen großen Teil meines Wohlbefindens mit meiner Arbeitsumgebung einbüßen. Das will ich nicht.

Deshalb will ich diesen Parser schreiben. Es gibt aber noch mehr Probleme, die ich mit dem Parser habe, als das oben beschriebene. Das ist einfach nur umständlich und aufwendig, aber an sich kein Problem. 

Ich will den Parser in Javascript schreiben und das ganze in einer HTML Datei ausführen lassen. Warum? Weil das die einfachste Möglichkeit ist, das Programm nachher zu bedienen und vor allem weiter zu geben. Denn ich will euch dieses Programm auch zugänglich machen.

Ich will, dass ihr das ohne Probleme bedienen könnt, ohne irgendwas zusätzlich installieren zu müssen. Ich will euch eine ZIP Datei zukommen lassen können, die ihr einfach nur entpacken müsst. Dann könnt ihr die HTML Datei öffnen und direkt loslegen. 

Es ist kein Problem eine ODF Datei in Javascript einzulesen. Es ist aber ein Problem, das Teil dann in ein ZIP umzuwandeln, damit ich an die content.xml komme. (Ich will den Zwischenschritt nicht machen müssen, das ODF als ZIP zu speichern. Das ist aufwendig)

Ich habe einen Workaround gefunden, mit dem ich aber noch nicht ganz zufrieden bin. Es ist aber ein Anfang. Man kann eine ODF Datei als HTML abspeichern. Wenn man das macht, bekommt man sogar einigermaßen sauberes HTML raus. Aber das ist ein Zwischenschritt, der mich momentan noch sehr nervt. Ich denke aber, ich werde den Parser erst einmal dafür schreiben.

Sollte irgendwer, der hier drüber stolpert, wissen, wie man mit Javascript (oder einer JS Library) an die content.xml kommt, bitte ich darum, mir Bescheid zu geben. Vielleicht ist es ja gar nicht so schwer und ich denke einfach verkehrt.     - Problem ist vorläufig gelöst. Danke an  Galileo 

Wer es bis hierher geschafft hat, dem gratuliere ich. 

In jedem Fall werde ich euch mit dem Projekt auf dem Laufenden halten. Ich hoffe, der Artikel war nicht zu verwirrend geschrieben. Ich hab das gerade einfach so runter getippt, weil ich mal meine Gedanken dazu niederschreiben wollte.

Auf bald! 

Lyn

Schon seit ich wieder regelmäßig schreibe, geht es mir ständig richtig auf die Nerven, dass ich meine Texte einzeln für animexx und ff.de umformatieren muss.

Ich weiß, dass FF.de auch odf Dateien annimmt, aber dann muss ich jedes Mal das aktuelle Kapitel aus dem eigentlichen Dokument heraus kopieren und in ein neues Speichern und dieses Dokument dann hochladen. 

Animexx ist da schon komfortabler, aber beim copy&pasten geht trotzdem das ein oder andere verloren. Wie zum Beispiel Textzentrierungen, die ich brauche, um Textabschnitte voneinander abzutrennen und die POV anzugeben.

Es geht leider auch nicht, dass ich einfach einmal das Kapitel formatiere, weil mexx und ff.de unterschiedliche Syntax verwenden (etwas in italic zu schreiben geht auf ff.de mit [style type = "italic" ][ / style ] und auf mexx mit [ i ][ / i ]).

Zusätzlich dazu, werde ich demnächst irgendwann (ist schon länger geplant aber bisher noch nicht umgesetzt) beginnen auf ff.net und ao3 (archive of our own) zu veröffentlichen und ich glaube, die beiden haben auch ihre ganz eigene Syntax.

Muss ich dann also einen Text 4 Mal editieren? Pfft... nein, ganz sicher nicht.

Es nervt mich teilweise so sehr, dass ich das veröffentlichen auf einer Plattform aufgeschoben haben. Jüngst hat das dazu geführt, dass ich hier auf mexx vollkommen vergessen habe, 2 Kapitel hochzuladen.

Warum erzähle ich euch das jetzt? Nun, ich bin Informatikerin und so ein Problem lässt sich netterweise mit Informatik lösen. Euch erzähle ich das, weil ich das folgende Projekt mit euch teilen will:

Ich will einen Parser schreiben.

Was ist ein Parser? Um es einfach zu machen: In meinem Fall ist ein Parser ein Programm, in das ich eine ODF (Open Office oder Libre Office) Datei gebe und die mir den Inhalt davon in den jeweiligen Formatierungen ausgibt, die ich für die Seiten brauche, auf denen ich veröffentliche.

Achtung, ab hier wird es technisch. Ich merkiere die Stelle, an der es wieder weniger technisch wird. Aber für alle, die sich für sowas interessieren, kann ich empfehlen weiter zu lesen. Ich halte die Sprache so einfach wie möglich.

Ich habe sowas ähnliches schonmal mit reinen .txt Dateien gemacht, die ich zur hübscheren Darstellung in eine .html Datei umgewandelt habe. Das ging wesentlich einfacher wie das, was ich jetzt vorhabe.

Warum war das einfacher? .txt Dateien sind Plain-Text Dateien. Das heißt, es läuft kein Programm, das diesen Text in irgendeiner anderen Weise darstellt, als das, was da wirklich steht. Anders sind z.B. HTML Dateien, die Befehle beinhalten, die dem Browser sagen, wie er Textteile darstellen soll. Will ich also eine .txt Datei Parsen, gehe ich Zeile für Zeile durch, vielleicht auch Wort für Wort und übertrage die in ein HTML Format. Will ich HTML Parsen, wird das schon schwieriger, weil ich dann vielleicht nicht nur den reinen Text haben will, sondern die Formatierungen berücksichtigen muss. Wenn ich zum Beispiel eine Tabelle, weiterhin als Tabelle haben will, muss ich die ganzen < table >< / table > Befehle berücksichtigen und einen Parser schreibt man eben so, dass es für möglichst ALLE Arten eines Dateiformats funktioniert. Das heißt, ich weiß, dass in dem Dokument irgendwo eine Tabelle auftaucht, aber ich habe keine Ahnung wo bzw. in welcher Zeile genau. Das heißt, statt dem Programm zu sagen 'Hey du, in Zeile so und so fängt eine Tabelle an und in Zeile so und so hört sie wieder auf' muss ich ihm sagen 'Du, achte mal darauf, ob du irgendwo ein < table > findest und wandle alles was danach kommt um, bis du auf ein < / table > triffst.' Und das müsste ich für jede Formatierung machen, auf die ich stoße. Das ist aber auch noch vergleichsweise einfach.

Denn dann gibt es ODF Dateien... Das ODF Format ist ein Sammelsurium von verschiedenen Dateien, die (meiner Meinung nach) auf ziemlich übertriebene Art und Weise ziemlich unlogisch zusammenhängen. Ihr wollt wissen, wie das aussieht? Macht mal einen Rechtsklick auf eine ODF Datei und wählt dann unter 'Öffnen mit' irgendein ZIP Programm aus (7zip oder WinRaR oder so). Dann seht ihr alle Dateien, die so eine simple ODF Datei eigentlich enthält.

In der content.xml steht der Inhalt der Datei inkl. einem Haufen unnötiger Formatierungsbefehle. Warum unnötig? Wenn ihr an 4 verschiedenen Stellen im Dokument irgendwas italic macht, hat diese Datei 4 verschiedene Befehle dafür, obwohl in jedem Befehl exakt das gleiche drin steht. Sowas sieht zum Beispiel so aus:

-<style:style style:name="P12" style:parent-style-name="Standard" style:family="paragraph">

<style:paragraph-properties style:justify-single-word="false" fo:text-align="justify"/>

<style:text-properties officeooo:paragraph-rsid="00e2d7e6" officeooo:rsid="01da2dd7" style:font-style-complex="italic" style:font-style-asian="italic" fo:font-style="italic"/>

</style:style>

Lasst euch nicht zu sehr verwirren, alles was wir brauchen ist das, wo 'italic' steht.

Das ist ein abgeschlossener style Befehl, der einem Textabschnitt sagt, wie er auszusehen hat. Wer ein bisschen was damit anfangen kann, wird sich jetzt vielleicht fragen 'Hä? Wie jetzt? Aber da ist doch gar kein Text!'. Richtig!

Der dazu passende Text kommt nämlich viiiiel weiter unten:

<text:p text:style-name="P12">Ich habe dir vertraut.</text:p>

<text:p text:style-name="P12"/>

Der Textschnippsel 'Ich habe dir vertraut', wäre jetzt italic, also schräg geschrieben. Der Name 'P12' verweist auf den oben angegebenen Style Befehl.

Jetzt ist ODF leider nicht sonderlich intelligent in der Erstellung dieser Befehle. Gefühlt jede Zeile hat einen anderen Stylebefehl, obwohl ich außer 'center', 'Überschrift 1', 'Überschrift 2' (ganz selten auch 'Überschrift 3') und 'italic' oder 'bold' keinerlei Stylebefehle verwende. Man sollte jetzt also eigentlich annehmen können, dass ODF auch nur maximal 6 Stylebefehle erstellt. Falsch. Die Befehle gehen von P1 bis P37 in diesem Dokument und ich habe nochmal Befehle die mit T beginnen und von T1 bis T14 gehen. Und gefühlt in 90% aller Fäller steht in den Befehlen das gleiche! In weiteren 9% (hauptsächlich in den T Befehlen) steht Zeug drin, die ich zum Parsen gar nicht benötige. Das zumindest ist gut, den Kram kann ich dann nämlich ignorieren.

Jetzt hat tatsächlich jede Zeile andere Befehle. Das ist schon allein deshalb bescheuert, weil ich dann zum Parsen immer den Text suchen muss. Ich muss dem Programm also beibringen, wie es den PlainText findet (müsste ich bei HTML auch). Das Programm muss also Zeile für Zeile durchgehen und das als Text interpretieren, was zwischen > < steht. Warum? Weil der anfang eines Befehls mit > endet und das ende eines Befehls mit < Anfängt. Jedes Mal, wenn das Programm also auf ein > trifft, müsste es testen, ob danach noch ein Buchstabe kommt, weil es sonst viel zu viele Leerzeilen mit rein nehmen würde. Das ist aufwendig und unschön, wäre aber nicht zu vermeiden.

Achtung, ab hier wird es NOCH technischer

Zusätzlich dazu müsste ich die Formatierungen irgendwie rausfinden. Dazu gibt es mehrere Möglichkeiten, aber ich finde die hier am einfachsten umzusetzen:

Die Formatierungsbefehle der Datei stehen am Anfang. Ich müsste also durch die anfänglichen Zeilen gehen (ich weiß nicht wie viele es sind, deshalb müsste ich mir noch einen Stopp-Befehl ausdenken. In dem Fall von ODF muss das Programm aufhören wenn es auf den Befehl < office:body > trifft) und dem Programm sagen, dass es sich die Namen der Befehle merken soll (wie z.B. P12) die Formatierungen enthalten. Das ist nicht so trivial, wie es sich anhört. Warum? Ein Programm kann in dem Sinn nichts 'sehen'. Wenn wir auf so einen Programm Schnippsel schauen und ein wenig geübt darin sind, sowas zu lesen, sehen wir schnell 'ok, da steht italic, ein bisschen weiter oben steht style:Name=P12, das wird der Name des Befehls sein'. Einem Programm muss man das erst beibringen. Ich könnte natürlich hingehen und jeden der über 40 Befehle speichern lassen und dann bei jeder Zeile mit dem Namen überprüfen lassen, ob das ein Befehl ist, der eine relevante Formatierung enthält, aber das ist ultra aufwendig und unschön. Was ich also machen muss, ist dem Programm zu sagen, dass es sich merken soll, wenn es auf ein Element stößt, dass 'style:Name' beinhaltet, den Namen erstmal speichern soll und dann bis zum nächsten </style:style> schauen soll, ob es eine relevante formatierung findet. Wenn ja, soll es sich den Namen merken und zusätzlich die entsprechende Formatierung dafür speichern. Jetzt kann so ein Befehl aber mehrere Formatierungen enthalten. Deshalb muss das Programm diesem Namen auch ja jede Formatierung zuordnen können. Das ist meiner Meinung nach der einfachste Weg. 

Das ist alles machbar aber nervig. Das könnte einfacher gehen! Aber das ist eben das Problem, mit einem WYSIWYG Editor. Die bauen alle so einen Murks.

Ab hier wird es wieder untechnischer

Wenn ich mich jetzt so darüber aufrege, was das ODF Format macht, warum benutze ich nicht was sinnvolleres? Markdown würde sich unglaublich anbieten. Dafür wäre es super simpel einen Parser zu schreiben. Warum mache ich es nicht einfach so?

Abreitsumgebungen sind wichtig. Und ich stehe auf schnörkel und fancy Schriftarten wenn ich schreibe, weil mir das mehr Spaß macht. Für Sachtexte (wie diesen hier gerade) würde ich immer zu markdown oder LaTeX greifen, aber nicht für kreatives Schreiben. Ich habe Stunden damit verbracht mir eine Vorlage in LibreOffice zu basteln, die mir gefällt und mir Spaß macht. Markdown Editoren kann man auch bis zu einem gewissen Grad anpassen, aber einfach nicht so sehr. Das heißt, um mir ein bis zweimal die Woche zu ersparen, meine Texte umzuformatieren, müsste ich einen großen Teil meines Wohlbefindens mit meiner Arbeitsumgebung einbüßen. Das will ich nicht.

Deshalb will ich diesen Parser schreiben. Es gibt aber noch mehr Probleme, die ich mit dem Parser habe, als das oben beschriebene. Das ist einfach nur umständlich und aufwendig, aber an sich kein Problem. 

Ich will den Parser in Javascript schreiben und das ganze in einer HTML Datei ausführen lassen. Warum? Weil das die einfachste Möglichkeit ist, das Programm nachher zu bedienen und vor allem weiter zu geben. Denn ich will euch dieses Programm auch zugänglich machen.

Ich will, dass ihr das ohne Probleme bedienen könnt, ohne irgendwas zusätzlich installieren zu müssen. Ich will euch eine ZIP Datei zukommen lassen können, die ihr einfach nur entpacken müsst. Dann könnt ihr die HTML Datei öffnen und direkt loslegen. 

Es ist kein Problem eine ODF Datei in Javascript einzulesen. Es ist aber ein Problem, das Teil dann in ein ZIP umzuwandeln, damit ich an die content.xml komme. (Ich will den Zwischenschritt nicht machen müssen, das ODF als ZIP zu speichern. Das ist aufwendig)

Ich habe einen Workaround gefunden, mit dem ich aber noch nicht ganz zufrieden bin. Es ist aber ein Anfang. Man kann eine ODF Datei als HTML abspeichern. Wenn man das macht, bekommt man sogar einigermaßen sauberes HTML raus. Aber das ist ein Zwischenschritt, der mich momentan noch sehr nervt. Ich denke aber, ich werde den Parser erst einmal dafür schreiben.

Sollte irgendwer, der hier drüber stolpert, wissen, wie man mit Javascript (oder einer JS Library) an die content.xml kommt, bitte ich darum, mir Bescheid zu geben. Vielleicht ist es ja gar nicht so schwer und ich denke einfach verkehrt.     - Problem ist vorläufig gelöst. Danke an  Galileo 

Wer es bis hierher geschafft hat, dem gratuliere ich. 

In jedem Fall werde ich euch mit dem Projekt auf dem Laufenden halten. Ich hoffe, der Artikel war nicht zu verwirrend geschrieben. Ich hab das gerade einfach so runter getippt, weil ich mal meine Gedanken dazu niederschreiben wollte.

Auf bald! 

Lyn

Es ist ja nicht so, dass ich mir von meinen Charas komplett auf der Nase rumtanzen lasse, aber ich habe ein Problem, wenn einem meiner Charas plötzlich einfällt, dass ich was nicht bedacht habe -.-

Bei JaL geht es mir derzeit so. Das Gespräch verläuf nicht gaaaaaanz so wie geplant XD Aber gut, ich habe mal meinen Mitbewohner und ne Freundin aus meinem Schreibzirkel um Rat gefragt und habe jetzt ne richtig coole Lösung für mein Problem gefunden. Zumindest vorerst.

Ein anderer Ansatz wäre, dass ich Mai nicht dazu kommen lassen das zu denken, was sie in dem Gespräch gerade denkt, aber das würde ihr irgendwann trotzdem auffallen und ich kann sie ja nicht immer ablenken (obwohl wahrscheinlich schon, aber das ist so anstrengend XD). Irgendwann käme ich dann in eine noch prekärere Situation und hier kann ich mich momentan echt adäquat wieder rauswinden, zumindest fürs Erste :)

Bin gespannt was ihr von dem Allen haltet. Das nächste Kapitel kommte denke ich in 1-2 Wochen, wenn es so weiter geht^^

Endlich habe ich es geschafft! Ich habe endlich das zweite Kapitel zu meiner Fanfiction Bruder angefangen!!! Ich bin so stolz auf mich.

Ich würde gerne auch bei Just another Lovestory weiter schreiben, aber da muss ich erst mal von meinen eigenen Ansprüchen an die Story wieder runter kommen. Ich hab immer die Angewohnheit was großes daraus machen zu wollen, was erfahrungsgemäß aber einfach nicht funktioniert.

Ich bin am überlegen, ob ich nicht mit der Einstellung von Mai bei Sesshoumaru erstmal nen Break mache und das ganze dann in einer Fortsetzung weiter ausführe. Eigentlich würde das ganze als Prolog super fungieren, dann könnte ich die Abenteuer, die die beiden bei der 'Schatzsuche' erleben, in einzelne Stories aufteilen.

Ja, vielleicht mache ich das so, ich muss mal schauen. Mir tut es da natürlich auch um die Leser tierisch leid, die jetzt so lange warten müssen und dann eventuell doch erstmal nicht kriegen, was sie eigentlich wollen. Immerhin ist die Story meine bisher erfolgreichste, sowohl bei den Klickzahlen, als auch den Favoeinträgen (zumindest auf Fanfiction.de). Ich muss mal schauen ob ich eine gute Lösung für alle Beteiligten finde. Im Mai werde ich relativ viel Zeit haben (endlich mal wieder).

Sollte das hier jemand lesen, kann er mir ja mal seine Meinung dazu hinterlassen. (Ich würde mich freuen ;))

P.S.: Wenn ich rausgefunden habe, wie das neue Webog Format funktioniert, werde ich die Links zu den erwähnten Stories noch ergänzen.

Endlich habe ich es geschafft! Ich habe endlich das zweite Kapitel zu meiner Fanfiction Bruder angefangen!!! Ich bin so stolz auf mich.

Ich würde gerne auch bei Just another Lovestory weiter schreiben, aber da muss ich erst mal von meinen eigenen Ansprüchen an die Story wieder runter kommen. Ich hab immer die Angewohnheit was großes daraus machen zu wollen, was erfahrungsgemäß aber einfach nicht funktioniert.

Ich bin am überlegen, ob ich nicht mit der Einstellung von Mai bei Sesshoumaru erstmal nen Break mache und das ganze dann in einer Fortsetzung weiter ausführe. Eigentlich würde das ganze als Prolog super fungieren, dann könnte ich die Abenteuer, die die beiden bei der 'Schatzsuche' erleben, in einzelne Stories aufteilen.

Ja, vielleicht mache ich das so, ich muss mal schauen. Mir tut es da natürlich auch um die Leser tierisch leid, die jetzt so lange warten müssen und dann eventuell doch erstmal nicht kriegen, was sie eigentlich wollen. Immerhin ist die Story meine bisher erfolgreichste, sowohl bei den Klickzahlen, als auch den Favoeinträgen (zumindest auf Fanfiction.de). Ich muss mal schauen ob ich eine gute Lösung für alle Beteiligten finde. Im Mai werde ich relativ viel Zeit haben (endlich mal wieder).

Sollte das hier jemand lesen, kann er mir ja mal seine Meinung dazu hinterlassen. (Ich würde mich freuen ;))

P.S.: Wenn ich rausgefunden habe, wie das neue Webog Format funktioniert, werde ich die Links zu den erwähnten Stories noch ergänzen.