ZFX + Developia

Hallihallo,

Ich hätte gern ein Problem :)

Die Kurzform für Eilige: Ich habe 400 Open Office Dokumente. Und möchte nun in allen Dokumenten die Kopfzeile ändern. Per Batch. Wie mache ich das denn?

Ausführlicher:

Ich habe die Online Blender Manual nach ODT umgewandelt, das LibreOffice / OpenOffice Format. Damit ich was editierbares habe um dann nach PDF zu exportieren. Dabei herausgekommen sind um die 400 einzelne Dokumente. Weil schon dabei habe ich nach der ganzen Konvertiererei noch überall eine Kopfzeile reingemacht. Damit man spätestens beim Ausdrucken auch sieht von welcher Manual das ist.

Und da fängt das Drama an. Denn nun müsste ich diese Kopfzeile ändern. In allen 400 Dokumenten. Und ich will nicht schon wieder alle 400 Dokumente einzeln aufmachen. Zumal das ein Task ist der mich vermutlich mit jeder neuen Version erwartet. Also ist spätestens jetzt Zeit für Automatisierung.

Gefunden habe ich bisher einen Konverter. Kostet mal eben 20 Dollar. Ohne die Möglichkeit das wirklich auszuprobieren. Die Demo funktioniert nur mit einem Dokument. Und ich bin eh geizig. Also weitersuchen. Auf die Frage wie ich denn das ganze automatisieren könnte bekam ich auf einem Libre Office Forum als Antwort: mittels scripten. <- Das war schon die Antwort :lol:

Also weitergestöbert. Dabei rausgekommen ist bisher dass das odt Format eigentlich nix anderes als ein Zipfile ist. Das kann man tatsächlich mit einem Zipprogramm wie 7Z entpacken, schon ausprobiert. Und der eigentliche Text ist dann in der content.xml. Was mir erst mal nicht viel weiterhilft. Ob ich das nun direkt in Libre Office bearbeite oder einzeln entpacke und die xml Datei bearbeite bleibt sich ja gleich. Aber das bietet nen Ansatz für scripten. Entpacken, xml Datei bearbeiten, wieder packen.

Und damit wären wir wieder beim scripten angekommen :)

Der Beitrag den ich aufgestöbert habe, und aus dem ich die Infos ist allerdings schon etwas angegraut. Der stammt von 2009. https://forum.openoffice.org/en/forum/v ... 30&t=17703

Da ist was von einem Linux Script zu lesen. Ich bin grade dabei Ubuntu auf VMWare zu installieren. Wie müsste ich denn da vorgehen? Noch lieber wäre mir natürlich eine Lösung unter Windows :)

Oder vielleicht kenn ja jemand von euch noch eine leichtere Möglichkeit? Vielleicht einen Freeware Batch Converter?

Wenn du unter Windows Bash-Skripte schreiben willst empfehle ich MSYS2. Bei deinem eigentlichen Problem kann ich dir allerdings wenig weiterhelfen. Eventuell funktioniert es mit einer regular expression in Bash.

Danke für die Idee. Aber wenn es auf der Bash geht dafür habe ich mir ja nun Ubuntu installiert. VMWare ist schon praktisch ab und zu ^^

Ich kenne mich halt mit den ganzen Bash Geschichten oder dem Windows Scripting Host wenig aus. Und genau diese konkrete Hilfe ist ja das Problem. Jeder sagt sollte über scripten gehn, aber keiner sagt wie :)

Ok, ich versuch mal dir nen Ansatzpunkt zu geben, VORSICHT! UNGETESTET und nimmt an, dass nur content.xml in der ZIP-Datei ist:
Z.b. als "script.sh" speichern und im Ordner mit deinen Dateien als "./script.sh *" ausführen ("*" wird durch alle Dateien in dem Ordner ersetzt und dem Skript als Argumente übergeben, wo es als "$@" verwendbar ist).

Danke :)

Ist das für Linux oder Windows? Hm, der Punkt deutet auf Linux. Ich probier mal ^^

Ah, aber da ist noch viel mehr im Zipfile. Eben die ganzen anderen Bestandteile des Dokuments auch :/

Ich würde dringend davon abraten, das Manual in ODT zu pflegen. Irgendwann wirst Du eine Online-Hilfe haben wollen und von ODT wieder dahin zurück ist sicher kein Zuckerschlecken. Auch Modifikationen an der Doku sind dann viel schwieriger zu verwalten. Wenn Du die Doku im PDF-Format bereitstellen willst, würde ich mir eher Sachen wie http://rst2pdf.ralsina.me/stories/index.html anschauen.

Chromanoid hat geschrieben:Ich würde dringend davon abraten, das Manual in ODT zu pflegen. Irgendwann wirst Du eine Online-Hilfe haben wollen und von ODT wieder dahin zurück ist sicher kein Zuckerschlecken. Auch Modifikationen an der Doku sind dann viel schwieriger zu verwalten. Wenn Du die Doku im PDF-Format bereitstellen willst, würde ich mir eher Sachen wie http://rst2pdf.ralsina.me/stories/index.html anschauen.

Wie, es gibt eine Welt außerhalb von LaTex? :)

Too late. Nun habe ich schon zwei Monate investiert um das Ding endlich umzuwandeln :D

Ich weiss natürlich wo du hinwillst. Der Trend geht zur Online Manual mit Stichwortsuche und allen Schikanen. Aber die Entscheidung odt zu nehmen war eine einfache Lösung zu haben die auch Normalsterbliche pflegen und ändern können. Ohne dass sie ausgebildete Programmierer sind. Das geht super mit OpenOffice und LibreOffice. Das funktioniert aber weder mit Sphinx, welches bei der Blender Manual verwendet wird, noch mit deiner Lösung. Und von da nach PDF geht auch unglaublich schwer. Deswegen gibts auch keine PDF Manual für Blender mehr. Sphinx verkackts. Das waren die zwei Monate Arbeit. Die ganzen zerballerten Tabellen und andere Unannehmlichkeiten reparieren ...

Klar, ich kann so keine Seiten und Stichworte gegenlinken. Aber das empfinde ich eh als Pest. Wenn ich mir eine Manualseite anschaue, dann will ich da kein Inhaltsverzeichnis für andere Teile der Manual lesen, und mich dann im Kreis linken lassen. Sondern die Sachen da erklärt haben wo sie gebraucht werden.

Ich hätte zwar auch ein Wiki, aber da wäre die Pflege unglaublich aufwendig. Und schon da zuckt so manch Normalsterblicher zurück. Und dann müsste ich zwei Sachen pflegen.

Letztenendes kann ich schon allein aus Manpower Gründen nur eins haben und pflegen. Entweder eine Offline Manual, die ich dann auch online anbiete. Oder eine Online Manual wie Blender. Ich habe mich eben für ersteres entschieden. Weil, sobald mal konvertiert, viel bequemer und schneller zu bearbeiten. Mit einer WYSIWYG Umgebung. Und mit funktionierendem sauberen PDF Export :)

Okay, ich gebe auf. Selbst mit Hilfe eines Informatikers war da nix zu machen. Er vermutet dass das odt Format wohl doch nicht ganz zip kompatibel ist. Jedenfalls kommt einfach nichts im Dokument an.

Muss ich anders rangehen. Ich wollte die Manual eh umstrukturieren. Also gibts jetzt doch pro Kapitel ein Dokument. Und nicht wie jetzt so zersiedelt. Dann brauche ich auch nicht so viel ersetzen ^^

Falls jemand doch noch eine Lösung findet, die ist natürlich immer willkommen :)

Mir ging es darum, dass die Doku von Blender ja auch immer wieder aktualisiert wird und die scheinen ja reStructuredText zu benutzen, um zu dokumentieren. Es wird ein Heidenspaß, wenn Du mal wieder die Doku für ein paar neue Features aus Blender in Dein Projekt mergen willst, insbesondere wenn Du die gleichen Stellen überarbeitet hast. Wenn mehrere Leute an Deiner Dokumentation arbeiten sollten, wird es auch nicht gerade einfach. Zumindest finde ich die Änderungsvergleiche in Word immer ziemlich ätzend.

@ODT: Evt. bekommst Du das mit Makros hin.

Alexander Kornrumpf hat geschrieben:

Chromanoid hat geschrieben:Ich würde dringend davon abraten, das Manual in ODT zu pflegen. Irgendwann wirst Du eine Online-Hilfe haben wollen und von ODT wieder dahin zurück ist sicher kein Zuckerschlecken. Auch Modifikationen an der Doku sind dann viel schwieriger zu verwalten. Wenn Du die Doku im PDF-Format bereitstellen willst, würde ich mir eher Sachen wie http://rst2pdf.ralsina.me/stories/index.html anschauen.

Wie, es gibt eine Welt außerhalb von LaTex? :)

Die Anzahl an leichtgewichtigen Formatierungssprachen geht echt rasant in die Höhe. Markdown hat sicher die Nase vorn, aber auch da gibt es ja mittlerweile sehr viele Dialekte... https://en.wikipedia.org/wiki/Lightweig ... p_language ist in diesem Zusammenhang auch interessant.

Ich hatte http://rst2pdf.ralsina.me/stories/index.html natürlich nur erwähnt weil das ein Konverter für reStructuredText nach PDF ist. reStructuredText ist das Format mit dem die Blender Doku erzeugt wird.

Ja klar. Wie gesagt weiss ich genau auf was du rauswillst. Aber das ist eben eine andere Richtung. Das ist die Programmiererlösung. Da brauchts Programmierer und Spezialwissen. Meine ist eine Userlösung. Das können auch User machen. Finde ich einfach sinniger.

Im Moment arbeitet einer an der Manual. Ich. Also schaue ich dass ich es mir selber so einfach wie möglich mache. Mit den Pferdefüssen kann ich da dann gut leben. Und über die anderen Brücken gehe ich sobald ich sie erreiche :)

Bei Blender arbeitet im Grunde auch nur noch ein Mann an der Manual. Campbell. Weil allen anderen die Sphinx Schose viel zu kompliziert ist. Da hat sich auch schon Ton sehr unglücklich drüber geäussert. Der ist damit gar nicht zufrieden. Aber nun ist es schon mal da, also bleibts.

Und bezüglich einpflegen, Bforartists ist kein einfacher Blender Branch in den man Blender Teil einpflegt. Das ist ein Fork aus gutem Grund. Schon jetzt ist es eigentlich fast unmöglich Teile aus Blender einfach so nach Bforartists zu transferieren. Da hat sich schon viel zu viel verändert. Ich hatte vor Kurzem jemanden der wollte zumindest mal die neuen Libraries in Bforartists reinbringen. Blender hat ja nun Python 3.5 und vieles neues an Libraries mehr. Das Ziel war dass er beides auf einem Rechner kompilieren kann, Blender und Bforartists. Dann hätte es ein Linux Build gegeben. Er hat dann aufgegeben. Und mir fehlt die Zeit und das Wissen für sowas. Mein Ziel ist die UI. Und dann schaun mer mal.

Back to topic und bezüglich Makros, hmm, interessante Idee. Danke dafür. Damit habe ich mich noch gar nicht beschäftigt. Das Problem ist allerdings das gleiche. Auch da bräuchte ich immer noch was das mir das Dokument aufmacht, das Makro startet, das Dokument wieder zumacht, das neue Dokument aufmacht und die Prozedur wiederholt.

Tiles hat geschrieben:Back to topic und bezüglich Makros, hmm, interessante Idee. Danke dafür. Damit habe ich mich noch gar nicht beschäftigt. Das Problem ist allerdings das gleiche. Auch da bräuchte ich immer noch was das mir das Dokument aufmacht, das Makro startet, das Dokument wieder zumacht, das neue Dokument aufmacht und die Prozedur wiederholt.

Das sollte eigentlich alles mit Makros möglich sein. Das hab ich eben über Google dazu gefunden: https://wiki.openoffice.org/wiki/DE/Mak ... C3.B6ffnen

Chromanoid hat geschrieben:Die Anzahl an leichtgewichtigen Formatierungssprachen geht echt rasant in die Höhe. Markdown hat sicher die Nase vorn, aber auch da gibt es ja mittlerweile sehr viele Dialekte... https://en.wikipedia.org/wiki/Lightweig ... p_language ist in diesem Zusammenhang auch interessant.

Ist wahrscheinlich wieder so eine "Tool für den Zweck" Sache. Grundsätzlich würde ich dazu tendieren, direkt LaTeX oder HTML zu schreiben (andere Outputs brauche ich nicht regelmäßig, YMMV). Etwas drittes scheint sinnvoll, wenn man

- Kein rohes HTML vom User annehmen will. Obwohl es etwas enttäuschend ist, dass das Problem in den letzten 15 Jahren nicht gelöst wurde.
- Man ein gemeinsames Subset von LaTeX und HTML braucht um daraus beides erzeugen zu können.
- [Related: Man ein gemeinsames Subset von Quellcodecomentaren, LaTeX und HTML braucht, vulgo Doxygen und Nachfolger]
- Es aus irgendeinem Grund leichter scheint das dritte zu lernen als das was man eigentlich will.

Der letzte Punkt wird natürlich dadurch ad absurdum geführt dass man schlimmstenfalls nicht einen dritten Dialekt lernt sondern rasant steigend viele.

Ich hatte http://rst2pdf.ralsina.me/stories/index.html natürlich nur erwähnt weil das ein Konverter für reStructuredText nach PDF ist. reStructuredText ist das Format mit dem die Blender Doku erzeugt wird.

Erschreckend plausibel. Wenn ich Quellen in einer Auszeichnungssprache hätte würde ich sicher nicht freiwillig mit einer bereits umgewandelten Form arbeiten.

Tiles hat geschrieben:Okay, ich gebe auf. Selbst mit Hilfe eines Informatikers war da nix zu machen. Er vermutet dass das odt Format wohl doch nicht ganz zip kompatibel ist. Jedenfalls kommt einfach nichts im Dokument an.

Ich hatte das vor ein paar Monaten auch mal gemacht. Es ist ein zip Format, hat aber extra Ansprüche.

Siehe http://stackoverflow.com/questions/4957 ... -its-files

If a MIME type for a document that makes use of packages is existing, then the package SHOULD contain a stream called "mimetype". This stream SHOULD be first stream of the package's zip file, it MUST NOT be compressed, and it MUST NOT use an 'extra field' in its header (see [ZIP])..

The purpose is to allow packaged files to be identified through 'magic number' mechanisms, such as Unix's file/magic utility. If a ZIP file contains a stream at the beginning of the file that is uncompressed, and has no extra data in the header, then the stream name and the stream content can be found at fixed positions. More specifically, one will find:

a string 'PK' at position 0 of all zip files
a string 'mimetype' at position 30 of all such package files
the mimetype itself at position 38 of such a package.

Um sicher zu gehen: Die erste Datei in der zip MUSS "mimetype" heißen und UNKOMPRIMIERT den mimetype enthalten.
Damit hat dass dann bei mir damals auch geklappt.

Alexander Kornrumpf hat geschrieben:Grundsätzlich würde ich dazu tendieren, direkt LaTeX oder HTML zu schreiben (andere Outputs brauche ich nicht regelmäßig, YMMV).

Also ich finde Markdown schon ziemlich gut. HTML ist keine gute Sprache, um auch den Dokument-Quelltext gut lesen zu können. LaTeX ist hier ebenfalls problematisch und außerdem noch höllisch kompliziert und nicht sehr leichtgewichtig, wenn man daraus mal schnell als Build-Schritt in der Build-Pipeline eine Doku generieren will. Ich finde insgesamt das Textverarbeitung jedweder Form noch ziemlich rudimentär ist, dafür dass das Problem schon so lange angegangen wird. Darüber könnte ich mich stundenlang aufregen, von Word bis LaTeX alles Grütze.
Wenn wir das noch länger thematisieren wollen, sollten wir ein neues Thema aufmachen ;)

Ich hatte das vor ein paar Monaten auch mal gemacht. Es ist ein zip Format, hat aber extra Ansprüche.

Ah super, da gibts also doch eine Lösung. Danke Artifical Mind. Und ja, das war eben die Vermutung dass das nicht ganz konform ist :)

Leider habe ich nun schon angefangen das doch in grössere Brocken zu vereinen. Und brauche das Batchrenaming deswegen doch nicht mehr. Die zwanzig mal kann ich auch von Hand machen. Aber interessant zu wissen bleibt es allemal :)