Artikel für den Blog: Werkzeugkiste für Self-Publisher und jedermann

      Artikel für den Blog: Werkzeugkiste für Self-Publisher und jedermann

      Diesen Text als EPUB lesen oder via PDF ausdrucken. Veröffentlicht unter der GNU Affero General Public License 3 or any later version, auf self-publisher-forum.de mit besonderer Genehmigung. Quelldateien siehe hier, automatische Aufbereitung möglich mit Commit 107 + Patch der Werkzeuge für digitales Publizieren.

      Werkzeugkiste für Self-Publisher und jedermann

      Für Autoren, die einmal ein einzelnes Buch veröffentlichen wollen, ist die Sache relativ einfach: Programme wie Sigil oder LibreOffice können dazu verwendet werden, um die üblichen Zielformate EPUB und PDF zu erzeugen. Doch schnell werden die Grenzen deutlich, die sich aus einer allzu manuellen Herangehensweise ergeben, denn nachträgliche Korrekturen können umfangreiche Anpassungen erforderlich machen. Erst recht der Umgang mit größeren Textbeständen oder besondere Aufbereitungs-Anforderungen verlangen Software-Lösungen, die wiederkehrende Arbeitsschritte automatisieren und gleichzeitig nicht statisch auf einen einzigen Anwendungsfall festgelegt sind, sondern flexibel im Rahmen unterschiedlicher Projekte eingesetzt werden können – mit anderen Worten: es braucht eine Werkzeugkiste für Self-Publisher, Verlage neuen Typs, Verlage alten Typs und auch sonst jedermann.

      Günstigerweise hat die Technik im Bereich der Medienproduktion in den letzten Jahrzehnten große Fortschritte gemacht, was nicht zuletzt auch Standardisierungsprozessen und der Verfügbarkeit von frei lizenzierten Implementierungen zu verdanken ist. Während nun die alte Verlagswelt langsam umsteigt auf „Digital First“-Workflows, darf die Self-Publisher-Szene dahinter nicht zurückbleiben, zumal das Veröffentlichungsmonopol ja gerade infolge der zunehmenden Digitalisierung weggefallen ist und es gilt, das entstandene Vakuum mit einem neuartigen Literaturbetrieb zu besetzen, anstatt un- und antidigitalen Angeboten Vorschub zu leisten. Die Akteure in diesem digitalen Literaturbetrieb benötigen jedoch alle geeignete Werkzeuge und haben teils schon angefangen, sich jeweils eigene Lösungen zu schaffen. Weil man aber niemals um die Technik, sondern um die Bedeutsamkeit von Inhalten konkurrieren sollte, ist es an der Zeit, eine gemeinsame technische Basis zu schaffen, die das unabhängige Publizieren insgesamt fördert, anstatt wieder und wieder in die Lösung bereits gelöster Aufgabenstellungen zu investieren. Natürlich gibt es bereits diverse Projekte, die an einer solchen gemeinsamen Basis oder auch an einzelnen Komponenten dafür arbeiten. Mit publishing-systems.org sollen diese Bemühungen verzeichnet, bewertet, unterstützt, miteinander verknüpft und ergänzt werden. Es folgt nun eine Beschreibung der Design-Kriterien für unsere eigene Software als auch unseres Projekts an sich.



      Der wichtigste Grundsatz lautet freie Lizenzierung. Seit der allgemeinen Verfügbarkeit von Digitaltechnologie und der darin inherenten Entkoppelung der Information von ihrem physischen Träger bei gleichzeitig immenser Skalierbarkeit durch den Computer als Universalrechenmaschine (Interoperabilität) steht fest, dass das prä-digitale Urheberrecht in seiner gegenwärtigen Form dringend reformbedürftig ist, weil es mittlerweile infolge technischer, rechtlicher, sozialer und ethischer Effekte das genaue Gegenteil von dem erreicht, wofür es eigentlich gedacht war. Seit den 80er-Jahren tobt der Kampf um digitale Grundrechte in den Bereichen Software, Musik, Video und jetzt auch bei den Büchern, wo aber die Öffentlichkeit wenig organisierte Interessensvertretung hervorgebracht hat und der Gesetzgeber tendenziell eher den Vorschlägen restriktiver Rechteverwerter folgt.

      Bei Software und manchen Formaten ist eine Form von DRM schon allein aus technischen Gründen gegeben, sodass die unabhängige, eigenständige Datenverarbeitung effektiv unmöglich gemacht werden kann. Die Anwendung des Urheberrechts auf Software trotz ihres Charakters als Werke von praktischem Nutzen tut ihr Übriges, um Nutzer und andere Entwickler in Abhängigkeit zu bringen. Die einzigste Chance besteht im Moment darin, dass die Urheber ihre Software frei lizenzieren, indem Nutzern umfangreiche Nutzungsrechte eingeräumt werden und anderen Entwicklern die kollaborative Zusammenarbeit ermöglicht wird. Darum ist unsere Software unter der GNU Affero General Public License 3 or any later version lizenziert, um die Verfügbarkeit, Veränderbarkeit, Weiterverbreitbarkeit und unabhängige Verwendbarkeit langfristig sicherzustellen.

      Wenn es um Medienwerke wie Bücher geht, ist freie Lizenzierung genauso wie bei der zugrundeliegenden verarbeitenden Software eine elementare Voraussetzung für einen ganzheitlich digitalverträglichen Literaturbetrieb. Vielfältig muss das digitale Potential im Hinblick auf den Umgang mit Texten unausgeschöpft werden, weil immer noch das Urheberrecht dazu missbraucht wird, das Geschäftsmodell des Verkaufs einzelner Dateikopien als Nachbildung der Knappheit aus der physischen Welt einzuführen, obwohl der digitalen Welt der Überfluss zugrundeliegt und die künstliche Verknappung dem Anliegen und Zweck einer Veröffentlichung direkt entgegensteht („Veröffentlichung“ hat etwas mit Öffentlichkeit zu tun). Ziel muss es deshalb sein, die Arbeit an und mit frei lizenzierten sowie gemeinfreien Texten aktiv voranzutreiben, die dafür vorhandenen Geschäftsmodelle weiter zu etablieren und so etwas wie eine freie digitale Bibliothek in welcher Form auch immer entstehen zu lassen, die in den Genuss umfangreicher als auch vielfältiger Community- und Softwareunterstützung kommen wird.

      Mehr zum Thema von Richard Stallman (über Software, über andere Medienwerke), Cory Doctorow (über die Implikationen von Digitaltechnologie für das Konzept „Buch“, über DRM) und The League Of Noble Peers (Steal This Film 2).

      Die nächste wesentliche Eigenschaft der Software in der Werkzeugkiste betrifft die Automatisierung. Es gibt einen ständig wachsenden Bestand an Texten und jeder dieser Texte bedarf umfangreicher Pflege, Anreicherung und Aufbereitung. Anstatt viel Zeit mit manueller Bearbeitung zu verschwenden, die bei der nächsten Gelegenheit schon wieder hinfällig werden kann, sollen wiederkehrende Arbeitsschritte möglichst automatisiert werden, damit mehr Zeit für automatisierungskompatible Anreicherungen bleibt. Die Automatisierung geht keineswegs zulasten der Qualität oder der Gestaltungsfreiheit, sondern kann im Rahmen der Verarbeitung durchaus Konfigurationseinstellungen oder die Einbindung externer Module zwecks Sonderbehandlung vorsehen, sodass der Workflow ein durchgängig datengetriebener ist und die Automatisierungssoftware lediglich die Methodik zur Verfügung stellt, um von einer definierten Eingabe zur gewünschten Ausgabe zu gelangen, womit der Prozess beliebig oft auf dieselben oder kompatible Eingabedaten neu angewendet werden kann.

      Die technische Grundlage dafür stellt XML als universaler Standard zur Auszeichnung von textorientierten Daten dar, womit zahlreiche auf bestimmte Anwendungsbereiche spezialisierte Formate wie z.B. HTML, DocBook, ODT oder TEI definiert wurden, wofür in quasi allen Programmiersprachen Zugriffs- und Verarbeitungsbibliotheken zur Verfügung stehen, worauf mächtige Werkzeuge wie XML-Schema-Validierer, XSLT- und XSL-FO-Prozessoren operieren. XML sichert dabei die Interoperabilität, indem zwischen unterschiedlichen Formaten hin- und herkonvertiert werden kann, Nicht-XML-Quelldateien über Parser nach XML und XML-Daten über entsprechende darauf zugeschnittene Generatoren (evtl. irreversibel) in die gewünschten Zielformate überführt werden. Freilich sind Konzepte wie Single Source Publishing oder gar „Multi Source Publishing“ (Erzeugen mehrerer Zielformate unter der Zusammenfügung mehrerer Datenquellen, die womöglich ihrerseits jeweils mehrfach konvertiert werden müssen) ganz im Sinne der Automatisierung. Allerdings soll die technische Komplexität der Formate, der Verarbeitung und der Abstimmung der Werkzeuge vor dem Benutzer durch grafische Oberflächen komplett verborgen werden (siehe Robert Cailliau zu den Grundlagen des Webs), weil einerseits manuelle Eingriffe beim nächsten Durchlauf hinfällig wären und andererseits die Erstellung qualitativer Quelldokumente und die Definition von Workflows mithilfe von sinnvollen Standardvorgaben stark vereinfacht werden können.

      Dieser Beitrag wurde bereits 39 mal editiert, zuletzt von „skreutzer“ ()

      Die Automatisierung profitiert ganz erheblich von der Modularität der Software in der Werkzeugkiste. Die meiste Software für Self-Publisher folgt einer monolithischen Architektur, d.h. ein einziges großes Programm vereint sämtliche angebotene Funktionalität in sich selbst mit dem Ziel, eine integrierte Arbeitsumgebung bereitzustellen. Der Nachteil davon ist, dass einzelne Funktionen oft nicht separat aufgerufen werden können, sondern stattdessen immer die komplette Arbeitsumgebung gestartet werden muss. Dann ist die Arbeitsumgebung in der Regel eine grafische, sodass die Bedienung des Programms primär mit der Maus erfolgt. Bei der Automatisierung macht es aber nur wenig Sinn, Klicks auf Buttons und Menüs auszulösen, denn die Eingabe von Daten soll ja schließlich von außen parametrisiert angesteuert werden, um einen rein datengetriebenen Ablauf zu erreichen.

      Dementsprechend soll die Software, die im Rahmen des Projekts entwickelt wird, aus einer Reihe von kleinen Einzelprogrammen bestehen, die zu größeren automatisierten Workflows zusammengeschaltet werden können. Einerseits entsteht dadurch eine hohe Flexibilität, weil die Programme auch in anderen Kombinationen eingesetzt werden können, andererseits können zwischen den einzelnen Verarbeitungsschritten externe Komponenten aufgerufen werden. Dass die Programme auch abseits automatischer Workflows zur Bewältigung begrenzter Aufgaben in einem ansonsten manuellen Aufbereitungsworkflow genutzt werden können, versteht sich von selbst. Dieser Ansatz schließt übrigens keineswegs aus, dass vor oder während der Verarbeitung umfangreiche benutzerspezifische Einstellungen hinterlegt werden können, die dann von den jeweiligen Einzelschritten berücksichtigt werden. Eine optionale grafische Oberfläche ist dabei behilflich, die überdies auch zur Steuerung und Bedienung der Einzelprogramme, der Workflows und des Gesamtsystems dient. Um die Einzelprogramme möglichst unabhängig von den sie aufrufenden Workflows zu halten, erfolgt die Kommunikation über wohldefinierte Schnittstellen, über welche die Workflows die in „Jobs“ zusammengefassten Einstellungen einspeisen können. Ein Nachteil dieses Ansatzes ist, dass die Komplexität der Abhängigkeiten bei Änderungen an den Schnittstellen oder in den Einzelprogrammen umso mehr steigt, je mehr Workflows sich der betroffenen Programme bedienen – dem soll nach Möglichkeit mit zusätzlichen Abstraktionsebenen begegnet werden, welche Schnittstellendetails nach oben hin verbergen (kapseln).

      Die entwickelte Software besteht sowohl aus Online- als auch Offline-Teilen. Die Ausführbarkeit der Programme auf dem lokalen Rechner ist wichtig, um die Hoheit über die eigene Datenverarbeitung (siehe das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme, dessen Verletzung ja nicht fahrlässigerweise begünstigt zu werden braucht) aufrecht erhalten zu können. Ausgenommen davon sind logischerweise Funktionen, die nur in einem Vernetzungs-Kontext Sinn machen, wie z.B. eine Benutzerverwaltung, mithilfe welcher die Aufteilung von Aufgaben für kollaboratives Arbeiten an einem Projekt organisiert werden kann. Allerdings können externe Online-Komponenten wie das MediaWiki oder WordPress von Online- und/oder Offline-Varianten unserer Programme angesteuert werden, wobei die Unterstützung von dezentralen Peer-to-Peer-Protokollen zwecks Bereitstellung derselben Funktionalität zu bevorzugen wäre. Ob die Einzelprogramme und Workflows mit einem Web-GUI versehen und online ausführbar gemacht werden sollen, hängt vom jeweiligen Nutzungsszenario ab, denn die Verwendung der Online-Version statt der Offline-Version muss im Gegensatz zur Bereitstellung von Diensten für kollaboratives Arbeiten oder für integrierte Plattformen nicht gerade herausgefordert werden.

      Ein weiteres wichtiges Anliegen ist die Plattform-Integration. Statt Werke, Werkzeuge, Dienste, Veröffentlichungskanäle und Geschäftsmodelle für sich isoliert zu betrachten, können diese Einzelbausteine miteinander kombiniert werden zu ganzheitlich digitalverträglichen Ökosystemen, in welchen die Produzenten höher entlohnt werden bei gleichzeitig für den Konsumenten günstigeren, quantitativ mehr und qualitativ besseren Ergebnissen. Freilich gibt es keine feste Rollenverteilung in solchen Ökosystemen, jedermann kann gleichberechtigt jede beliebige Funktion den eigenen Fähigkeiten und Fertigkeiten entsprechend ausüben, auch in Kooperation und Kollaboration. Interoperabilität und Vernetzung sind probate Mittel, um die verschiedenen Teilnehmer näher zusammenzubringen. Digitalverträgliche Plattformen fördern die Produktion, Distribution und Rezeption von Werken und erschweren sie nicht künstlich, um Interessen einzelner Parteien zu schützen auf Kosten der ebenso berechtigten Interessen anderer Parteien. Größte Aufmerksamkeit gebührt der Vermeidung von Abhängigkeiten, welche durch Einseitigkeit ein bestehendes Ökosystem ins Ungleichgewicht, in die Instabilität stürzen können. Daher sollten besagte Plattformen flexibel genug konzipiert sein, um einzelne Komponenten austauschen oder den Benutzer vor die Wahl stellen zu können, welche davon eingesetzt werden sollen.

      Eine Diskriminierung findet nicht statt. Inhaltliche, personelle, qualitative (nutzungsrechtliche und technische Anforderungen ausgenommen), quantitative, gestalterische, strategische und kommerzielle Präferenzen werden nicht besonders berücksichtigt, sondern sind den handelnden Personen eigenverantwortlich anheim gestellt.

      Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „skreutzer“ ()

      Installationsanweisungen

      Neben der Möglichkeit, die Programme der Werkzeugkiste aus dem Quellcode zu kompilieren, werden unter publishing-systems.org/downloads.php vorbereitete Download-Packages angeboten. Da für die Ausführung eine Java-VM benötigt wird, sollte mittels des Befehls

      java -version

      ermittelt werden, ob eine oder welche Java-VM auf dem System bereits installiert ist. Unterstützt wird Java 1.6 und höher. Weil die Verwendbarkeit der Werkzeugkiste für die 100% freien Distributionen des GNU-Betriebssystems stets gewährleistet werden soll, insbesondere aber gNewSense als Referenzsystem gelten kann, wäre, sofern noch nicht vorhanden, die Java Runtime Environment des OpenJDKs mittels

      apt-get install openjdk-6-jre

      zu installieren. Nachdem das Download-Package mit der höchsten Versionsnummer heruntergeladen und entpackt wurde, ist das Shell-Script

      $/workflows/run_setup1.sh

      auszuführen, woraufhin anschließend die einzelnen Tools und Workflows direkt oder über das dazugehörige Shell-Script aufgerufen werden können.

      Sobald PDFs erzeugt werden sollen, ist auch ein installiertes LaTeX-Satzsystem erforderlich, dessen pdflatex-Programm aufgerufen wird. Mit

      apt-get install texlive-latex-base
      apt-get install texlive-latex-memoir
      apt-get install texlive-lang-german

      können die benötigten Pakete eingerichtet werden.

      Die Werkzeugsammlung kann grundsätzlich auch in anderen Betriebssystem-Umgebungen als GNU eingesetzt werden. Die dafür notwendigen, oben beschriebenen Software-Komponenten sind infolge ihrer freien Lizenzierung auf beispielsweise Microsoft Windows oder Apple Mac OS X portiert worden, jedoch wird dringend von der Verwendung proprietärer Betriebssysteme als Grundlage für die Ausführung von portierten und an sich frei lizenzierten Programmen abgeraten, weil sonst von einer Hoheit über die eigene Datenverarbeitung und der Achtung digitaler Grundrechte ebenfalls keine Rede sein kann.

      Dieser Beitrag wurde bereits 11 mal editiert, zuletzt von „skreutzer“ ()

      Beschreibung der Tools

      Stand: Commit 107.

      csv2xml1 unter $/csv2xml/csv2xml1 ist ein Programm, welches eine CSV-Datei nach XML konvertiert. Das Trennzeichen zwischen den Werten kann über einen Parameter mitgegeben werden, außerdem werden mehrzeilige Felder über die Einklammerung in Anführungszeichen unterstützt. Die Namen der Tags in der resultierenden XML-Datei werden der ersten Zeile entnommen, welche von manchen Benutzern für Spaltenüberschriften bei der Bearbeitung in z.B. LibreOffice verwendet wird. Auch zu sehen in Workshop csv2all: Beschreibung Ausgangssituation.

      csv2xml2 unter $/csv2xml/csv2xml2 ist nahezu identisch mit csv2xml1 mit dem Unterschied, dass die Konvertierungs-Vorgaben über eine Konfigurationsdatei gesteuert werden. In selbiger wird das CSV-Trennzeichen festgelegt als auch, welche CSV-Spalte welchen XML-Tagnamen erhalten soll. Auf diese Weise kann auch eine Filterung der CSV-Daten erreicht werden, wenn nicht alle Spalten mit einer XML-Tagnamen-Zuordnung versehen werden.

      epub2html1 unter $/epub2html/epub2html1/ leistet wenig mehr, als eine EPUB2-Datei zu entpacken. Obwohl eigentlich ein Zip-Programm für die Bewältigung dieser Aufgabe völlig ausreichen würde, hat epub2html1 den Effekt, dass die internen Dateien zur Organisation des EPUB-Containers nicht in den Ausgabe-Ordner übernommen werden und überdies eine flache Dateistruktur entsteht, wie sie für statische Webseiten typisch ist. Die zu entpackende EPUB-Datei sowie das Ausgabe-Verzeichnis werden in einer Konfigurationsdatei festgelegt. Im Ausgabe-Verzeichnis erstellt epub2html1 zwar keine index.html, jedoch wird eine index.xml generiert, welche die extrahierten XHTML-Dateien aufzählt, sodass aufrufende Software das Ergebnis weiterverarbeiten oder mittels XSLT eine index.html daraus abgeleitet werden kann. Das Programm unterstützt die automatische Ermittlung des DOCTYPEs noch nicht, sodass im Unterverzeichnis $/epub2html/epub2html1/entities/ die Datei config_xhtml1_1.xml nach config.xml kopiert werden muss, damit der Aufruf erfolgreich ist. Das Extraktions-Verzeichnis $/epub2html/epub2html1/temp/epub_extraction/ wird nicht automatisch aufgeräumt.

      epub2html1_config_create_new1 unter $/epub2html/epub2html1/workflows/ ist ein Programm zur Workflow-Unterstützung, welches eine Konfigurationsdatei für epub2html1 mit Standardvorgaben generiert, welche von aufrufender Software anschließend mit den tatsächlichen Pfaden überschrieben werden können.

      file_picker1 unter $/gui/file_picker/file_picker1/ dient der Workflow-Unterstützung, indem ein Dateiauswahl-Dialog bereitgestellt wird, dessen anzuzeigende Dateitypen über eine Konfigurationsdatei festgelegt werden können. Ist eine Auswahl erfolgt, wird der absolute Pfad der ausgewählten Datei auf stdout ausgegeben. Abseits der Aufrufe durch andere Tools und Workflows gibt es keinen Verwendungszweck für file_picker1.

      html2epub1 unter $/html2epub/html2epub1/ packt XHTML-1.0-Strict-Dateien zu EPUB2 zusammen. Die internen Dateien zur Organisation des EPUB-Containers werden dabei automatisch generiert. Über eine Konfigurationsdatei können die Eingabe-XHTML-Dateien mit dem Titel, unter welchem sie in der EPUB-Navigation (Inhaltsverzeichnis) aufgeführt werden sollen, spezifiziert werden ebenso wie das Ausgabe-Verzeichnis, in welchem bei Erfolg eine out.epub abgestellt wird. Das Ausgabe-Verzeichnis muss bereits existieren, außerdem werden dort die Bestandteile des EPUBs ebenfalls abgelegt. Ferner können in der Konfigurationsdatei die Metadaten des EPUBs angegeben sowie eine Validierung der Eingabedateien deaktiviert oder wieder aktiviert werden, letzteres ist dringend zu empfehlen.

      html2epub1_config_create_new unter $/html2epub/html2epub1/gui/html2epub1_config_create_new/ ist ein Programm zur Workflow-Unterstützung, welches eine Konfigurationsdatei für html2epub1 generiert. Zwingend erforderliche Angaben wie die Eingabe-XHTML-Dateien, das Ausgabe-Verzeichnis oder die Metadaten-Felder bleiben leer, sodass aufrufende Software die entsprechenden Werte vor Verwendung erst noch hinterlegen muss. Der Pfad für die Konfigurationsdatei kann, sofern der Auswahldialog nicht aufgerufen werden soll, auch per Parameter mitgeteilt werden.

      html2epub1_config_file_setup unter $/html2epub/html2epub1/gui/html2epub1_config_file_setup/ stellt einen Dialog bereit, mithilfe welchem eine per Parameter oder per Dateiauswahldialog angegebene html2epub1-Konfigurationsdatei hinsichtlich der beteiligten Datei- und Verzeichnispfade bearbeitet werden kann. So können XHTML-Dateien hinzugefügt, entfernt oder in ihrer Reihenfolge anders angeordnet werden. Deren Titel, welche für die EPUB-Navigation (Inhaltsverzeichnis) herangezogen werden, können editiert werden. Das Ausgabeverzeichnis kann hinterlegt und geändert werden. Ein Button „Check“ dient der Überprüfung der Angaben, deren Korrektheit mittels kleiner Icons signalisiert wird. Wenn alle Icons grün sind, kann mit „Save“ gespeichert werden. Ein Verlassen mit „Exit“ speichert die Änderungen nicht!

      html2epub1_config_metadata_editor unter $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ stellt einen Dialog bereit, mithilfe welchem die Metadaten einer per Parameter oder per Dateiauswahldialog angegebene html2epub1-Konfigurationsdatei hinterlegt und bearbeitet werden können. Ein Button „Check“ dient der Überprüfung der Angaben, deren Korrektheit mittels kleiner Icons signalisiert wird. Wenn alle Icons grün sind, kann mit „Save“ gespeichert werden. Ein Verlassen mit „Exit“ speichert die Änderungen nicht!

      html2epub1_config_merge1 unter $/html2epub/html2epub1/workflows/ führt zwei html2epub1-Konfigurationsdateien zusammen, wobei von der ersten per Parameter angegebenen Konfigurationsdatei die Dateihinterlegungen der XHTML-Eingabedateien sowie das Ausgabeverzeichnis und von der zweiten per Parameter angegebenen Konfigurationsdatei die Metadaten übernommen werden, um sie in die mit dem dritten Parameter angegebene Datei rauszuschreiben.

      html_prepare4latex1 unter $/html2latex/html_prepare4latex1/ dient dem Escapen von LaTeX-Sonderzeichen in einer XHTML-1.0-Strict-Datei. Ausgenommen davon sind die Zeichen <, > und &, weil diese zwecks XML-Wohlgeformtheit in der XHTML-Datei weiterhin als Entity erhalten bleiben müssen, sodass sich nach einer Transformation von XHTML nach LaTeX ein anschließendes Suchen-und-Ersetzen anbietet, wo & durch \& ersetzt werden sollte. Bei < und > kann davon ausgegangen werden, dass die Transformation nach LaTeX als Nicht-XML-Ausgabeformat ein Deescaping der XML-Entities vornimmt. $/html2latex/html2latex1/layout/txtreplace1_replacement_dictionary_post_preparation.xml stellt eine entsprechende Ersetzungs-Konfigurationsdatei für txtreplace1 bereit. Das Programm unterstützt die automatische Auflösung der XHTML-DTDs noch nicht, sodass im Unterverzeichnis $/html2latex/html_prepare4latex1/entities/ die Datei config_xhtml1-strict.xml nach config.xml kopiert werden muss, damit der Aufruf erfolgreich sein kann.

      html2wordpress1 unter $/html2wordpress/html2wordpress1/ übermittelt eine XHTML-Datei an eine WordPress-Installation. Eine Internet-Verbindung ist erforderlich, ebenso muss seitens der WordPress-Installation die XML-RPC-Schnittstelle aktiviert sein, was aber standardmäßig der Fall ist seit WordPress 3.5. Um das Passwort des WordPress-Benutzers nicht im Klartext übermitteln zu müssen, muss serverseitig das „Secure XML-RPC“-Plugin von Eric Mann (Version 1.0.0, das ist Commit 31) installiert sein. Über eine Steuerungsdatei wird die zu übermittelnde XHTML-Datei und der URL der XML-RPC-Schnittstelle angegeben. Der Public- und Private-Key für die Benutzer-Authentifizierung kann im WordPress-Benutzerprofil für html2wordpress1 generiert werden und muss ebenfalls in die Steuerungsdatei eingetragen werden. Damit die neu generierten Keys auch abgespeichert werden, den Klick auf „Update Profile“ nicht vergessen. Der Private-Key sollte der Geheimhaltung unterliegen, weshalb darauf zu achten ist, dass dieser nicht in der Steuerungsdatei verbleibt, wenn auch andere Computerbenutzer lesenden Zugriff auf die Datei haben. Eine Möglichkeit besteht darin, nach der Übermittlung das Paar aus Public- und Private-Key im Benutzerprofil zu verwerfen. Der Text der XHTML-Datei wird im Klartext übermittelt. Ferner muss bzw. kann in der Steuerungsdatei die ID des entsprechenden Benutzers, welchen Post-Typ die übermittelte Ressource aufweisen soll (üblich sind „post“ und „page“, aber auch Custom Post Types können angewendet werden), mit welchem Status die Ressource versehen werden soll (diverse Stati wie z.B. „publish“, „pending“, „draft“, „future“ oder „private“ sind üblich), Titel und Kurzzusammenfassung, Datum und Uhrzeit (hiermit lässt sich auch eine automatische zukünftige Veröffentlichung realisieren), das Darstellungsformat, der Slug (leserlicher Namen für den URL), die Aktivierung oder Deaktivierung von Kommentaren und Pingbacks, das Sticky-Flag (angepinnte Ressource), eine Thumbnailbild-ID, die ID einer Parent-Ressource, Custom Fields (werden normalerweise für Metadaten genutzt), IDs der Einträge einer hierarchischen Taxonomie (müssen vorhanden sein) und die Namen einer Tag-Taxonomie (müssen nicht vorhanden sein, werden angelegt) festgelegt werden. Es findet eine Validierung der Eingabe-XHTML-Datei statt. html2wordpress1 beschränkt sich auf den Inhalt von <body> der Eingabe-XHTML-Datei, welcher unverändert übermittelt wird, dabei aber auch CSS-Angaben in <head> samt den dort enthaltenen Metadaten verloren gehen. Die Antwort des Servers wird direkt auf stdout ausgegeben.

      Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von „skreutzer“ ()

      html2wordpress1_jobfile_create_new1 unter $/html2wordpress/html2wordpress1/html2wordpress1_jobfile_create_new1/ dient der Workflow-Unterstützung, welches eine Steuerungsdatei für html2wordpress1 mit Standardvorgaben generiert, welche von aufrufender Software anschließend mit den tatsächlichen Angaben überschrieben werden können. Der Pfad für die Steuerungsdatei kann, sofern der Dateiauswahldialog nicht aufgerufen werden soll, auch per Parameter mitgegeben werden.

      html_attributeanalyzer1 unter $/html_attributeanalyzer/html_attributeanalyzer1/ liest aus einer XHTML-Eingabedatei alle enthaltenen Attribute, deren Wert, deren Element sowie das Eltern-Element aus und schreibt diese in eine Ausgabe-XML-Datei. Jede Kombination aus Attribut-Name, Attribut-Wert, Attribut-Element und Eltern-Element wird nur einmalig ausgewiesen. Das Programm wird bisher in keinem Workflow eingesetzt.

      html_attributereplace1 unter $/html_attributereplace/html_attributereplace1/ ersetzt Werte von Attributen in einer XHTML-Datei aufgrund einer Mapping-Konfigurationsdatei, wo die zu ersetzenden Attributwerte über den Element- und Attributnamen spezifiziert werden. Das Programm wird bisher in keinem Workflow eingesetzt.

      html_concatenate1 unter $/html_concatenate/html_concatenate1/ fügt mehrere XHTML-Dateien aneinander und schreibt das Ergebnis in eine XHTML-Ausgabedatei. Die Steuerung eines Aufrufs erfolgt über eine Konfigurationsdatei, in welcher auch festgelegt werden kann, aus welcher XHTML-Datei die HTML-Kopfdaten übernommen werden sollen, wobei sich die Aneinanderfügung der referenzierten Eingabedateien immer auf den Inhalt des <body>-Tags bezieht. Die Datei, aus welcher die HTML-Kopfdaten übernommen werden sollen (inklusive <body>), muss nicht Teil der Liste der aneinanderzufügenden XHTML-Dateien sein. Wenn keine HTML-Kopfdatendatei angegeben wird, werden die Kopfdaten der ersten angegebenen XHTML-Datei herangezogen.

      html_flat2hierarchical1 unter $/html_flat2hierarchical/html_flat2hierarchical1/ sorgt für sog. „Positional Grouping“. XML strukturiert Daten in aller Regel hierarchisch, wodurch ineinander verschachtelte Einheiten semantisch abgebildet werden. Es gibt jedoch auch die Möglichkeit, den Beginn (und theoretisch auch das Ende) logischer Einheiten über „Marker“ (manchmal auch „Milestones“ genannt) zu kennzeichnen, die auf derselben hierarchischen XML-Ebene stehen als ihre „Unterelemente“, für welche sie die umgebende Klammer darstellen sollen. Marker werden häufig verwendet, wenn sich überlappende Einheiten abgebildet werden sollen, was aber von html_flat2hierarchical1 nicht berücksichtigt wird. Ein anderer Verwendungsfall ist anzutreffen z.B. im ODT-Format, wo im Textverarbeitungsprogramm LibreOffice keine semantische Verschachtelung von Dokumentelementen hinterlegt werden kann, sodass intern nur eine „flache“ Struktur, sprich. eine Aufzählung der enthaltenen Elemente in der Reihenfolge ihres Auftretens, vorzufinden ist. Über eine Konfigurationsdatei kann html_flat2hierarchical1 angewiesen werden, solche Marker, die per Elementname und optional zusätzlich gemäß bestimmtem Attribut-Name und -Wert, versehen mit einer Angabe über deren hierarchische Wertigkeit, zu Parent-Elementen der darauffolgenden Elemente umstrukturiert werden, was sämtliche Unterelemente einschließt, bis der nächste Marker gleicher oder höherer hierarchischer Wertigkeit vorgefunden wird, woraufhin sämtliche vorhergehenden, noch geöffneten Marker-Verschachtelungsebenen geschlossen werden. Das Programm unterstützt die automatische Ermittlung des DOCTYPEs noch nicht, sodass im Unterverzeichnis $/html_flat2hierarchical/html_flat2hierarchical1/entities/ die Datei config_xhtml1-strict.xml nach config.xml kopiert werden muss, damit der Aufruf für XHTML 1.0 Strict erfolgreich ist.

      html_split1 unter $/html_split/html_split1/ teilt eine XHTML-Eingabedatei in mehrere Ausgabedateien auf, wobei die Aufteilungskriterien in einer Konfigurationsdatei spezifiziert werden. Als Kriterium wird ein Elementname und optional zusätzlich Attribut-Name und -Wert herangezogen. html_split1 berücksichtigt immer nur das zuerst gefundene Element, welches einem Kriterium entspricht, bis zu dessen Ende. Darin enthaltene Unterelemente, auf welche ebenfalls Kriterien zutreffen, werden nicht weiter unterteilt, wobei html_split1 zu diesem Zweck erneugt und evtl. rekursiv auf die Ergebnis-Dateien aufgerufen werden könnte. Die Ergebnis-Dateien werden in einem Ordner als XML-Dateien abgelegt, da der ausgeschnittene Bereich nicht mit HTML-Kopfdaten versehen wird, welche aber per XSLT nachträglich wieder ergänzt werden können. Das Ausgabe-Verzeichnis wird mit einer Datei info.xml versehen, welche die erzeugten Aufteilungs-Dateien auflistet.

      odt2html1 unter $/odt2html/odt2html1/ konvertiert eine ODT-Datei (Textverarbeitungs-Dokumentenformat des OpenDocument-Standards, welcher u.a. OpenOffice/LibreOffice zugrundeliegt) nach XHTML 1.0 Strict. Neben der Eingabedatei muss ein Ausgabeverzeichnis per Parameter mitgegeben werden. Entweder wird im angegebenen Verzeichnis eine XHTML-Datei mit demselben Namen wie die Eingabedatei, aber mit der Dateiendung *.html angelegt, oder optional kann über einen dritten Parameter ein abweichender Dateiname gewählt werden. Im Ausgabeverzeichnis werden neben der XHTML-Datei auch die enthaltenen Bilder abgelegt, welche überdies dort in einer info.xml verzeichnet werden. Außer Bildern werden auch Links und Stil-Hinterlegungen zwecks semantischer Weiterverarbeitung in die Ausgabe übernommen. Das temporäre Extraktions-Verzeichnis $/odt2html/odt2html1/temp/ wird möglichst aufgeräumt, was jedoch nicht immer gelingt und dann mit einer nicht weiter relevanten Warnung gemeldet wird.

      schemavalidator1 unter $/schemavalidator/schemavalidator1/ ist ein Wrapper, um mithilfe der Java-Standardlibrary eine XML-Schema-Validierung durchführen zu können, ohne ein externes Programm dafür aufrufen zu müssen. Neben der XML-Eingabedatei und dem Schema muss eine Konfigurationsdatei mitgeteilt werden, in welcher die DTDs der verwendeten XML-Entities hinterlegt sind, sowie eine weitere Konfigurationsdatei, in welcher Imports in den Schemen aufgelöst werden. Sofern die XML-Eingabedatei oder das Schema keine externen Entities oder Schemen heranzieht, brauchen die Konfigurationsdateien auch keine Einträge aufweisen.

      txtreplace1 unter $/txtreplace/txtreplace1/ nimmt eine einfache Textersetzung vor, wo die zu ersetzenden und ersetzenden Zeichen über eine Konfigurationsdatei festgelegt werden. Da die Konfigurationsdatei in XML verfasst ist, können XML-Tags in XML-Dateien damit nicht ersetzt werden, weil die Hinterlegung derselben mit dem Aufbau der Konfigurationsdatei konfligieren würde. Textinhalt von XML-Elementen kann aber in Eingabe-XML-Dateien wie in jeder anderen Dateiform auch ersetzt werden. Es wäre darauf zu achten, dass nicht versehentlich auch Tag-Namen mitersetzt werden, wo txtreplace1 natürlich keine Unterscheidung trifft zu gewöhnlichem Textinhalt innerhalb von XML-Tags.

      unzip1 unter $/unzip/unzip1/ ist ein primitiver Wrapper, um mithilfe der Java-Standardlibrary ein Zip-Archiv entpacken zu können, ohne ein externes Programm dafür aufrufen zu müssen.

      html2epub1-Workflow unter $/workflows/ ist für odt2epub1-Workflow fest auf eine Eingabe-XHTML-1.0-Strict-Datei abgestimmt, die auf $/odt2html/templates/template1/template1.ott basiert, um daraus ein EPUB2 zu erzeugen. Die Verwendung mit einer XHTML-Datei, die aus einem reinen odt2html-Aufruf stammt, ist nicht möglich, da odt2html1-Workflow gewisse Vorarbeiten vornimmt. Mittels html_split1 wird gemäß html_split1_config_part.xml und html_split1_config_chapter.xml aus $/odt2html/templates/template1/ in die einzelnen Bestandteile zerlegt, welche dann von xsltransformator1 entsprechend html2epub1_html_part.xsl bzw. html2epub1_html_chapter.xsl aus $/odt2html/templates/template1/ zum Ergebnis-Layout aufbereitet werden. Außerdem wird xsltransformator via $/odt2html/templates/template1/html2epub1_html_title.xsl eine zusätzliche XHTML-Titelseite („Cover“) für das EPUB generieren. Mit $/odt2html/templates/template1/html2epub1_config.xsl wird xsltransformator1 eine html2epub1-Konfigurationsdatei anlegen, in welcher die Metadaten für das EPUB aus der html2epub1-Konfigurationsdatei, die per Parameter mitgeteilt wurde, per html2epub1_config_merge1 eingefügt werden. html2epub1 besorgt dann die Erstellung der EPUB2-Datei, die unter $/workflows/temp/epub/ als out.epub zu finden sein wird. Es wird versucht, den Inhalt des Verzeichnisses vorher rekursiv zu löschen. Die Dateien der Zwischenschritte unter $/workflows/temp/ werden nicht aufgeräumt.

      html2pdf1-Workflow unter $/workflows/ erzeugt aus einer Eingabe-XHTML-Datei, die auf $/odt2html/templates/template1/template1.ott basiert und durch odt2html1-Workflow vorbehandelt wurde, eine Ausgabe-PDF-Datei. Die XHTML-Datei kann entweder als Kommandozeilenargument mitgeteilt oder in einem Dialog ausgewählt werden. Der Workflow bereitet die Eingabedatei erst mit html_prepare4latex1 aus $/html2latex/html_prepare4latex1/ samt einem Aufruf von txtreplace1 aus $/txtreplace/txtreplace1/ mit $/html2latex/html2latex1/layout/txtreplace1_replacement_dictionary_post_preparation.xml für die Aufbereitung durch LaTeX vor, um dann xsltransformator1 aus $/xsltransformator/xsltransformator1/ mit $/html2latex/html2latex1/layout/layout1.xsl die semantischen Stilkennzeichnungen gemäß der template1.ott an das LaTeX-Layout zu koppeln. Das Erebnis wird unter $/workflows/temp/pdf/ als out.tex abgelegt. Wenn pdflatex aufgerufen werden kann, findet sich dort dann auch eine entsprechende out.pdf. Es wird versucht, den Inhalt des Verzeichnisses vorher rekursiv zu löschen.

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „skreutzer“ ()

      odt2all1-Workflow unter $/workflows/ erzeugt aus einer Eingabe-ODT-Datei, die auf $/odt2html/templates/template1/template1.ott basiert, HTML-, EPUB2- und PDF-Dateien, die in dem Verzeichnis abgelegt werden, welches per Kommandozeilenargument mitgeteilt wurde. Eine Steuerungsdatei, die ebenfalls per Kommandozeile referenziert wird, listet eine oder mehrere Eingabe-ODT-Dateien auf ebenso wie eine Konfigurationsdatei für html2epub1, aus welcher die Metadaten für das EPUB entnommen werden. Intern wird zuerst odt2epub3-Workflow und dann odt2pdf2-Workflow aufgerufen.

      odt2all2-Workflow unter $/workflows/ ergänzt odt2all1-Workflow um grafische Dialoge zur Bedienung des Workflows, wo zuerst die odt2all1-Konfigurationsdatei ausgewählt oder neu angelegt wird, um dann mit odt2all1_config_edit2 aus $/workflows/gui/odt2all1_config_edit2/ die Eingabe-ODT-Dateien zu hinterlegen oder zu verändern. Daraufhin muss eine html2epub1-Konfigurationsdatei ausgewählt oder neu angelegt werden, welche anschließend mit html2epub1_config_metadata_editor aus $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ bearbeitet werden kann. Zuletzt muss noch ein Ausgabe-Verzeichnis ausgewählt werden, sodass odt2all1-Workflow unter Verwendung der hinterlegten Angaben aufgerufen werden kann.

      odt2epub1-Workflow unter $/workflows/ ruft erst odt2html1-Workflow auf, erlaubt über html2epub1_config_metadata_editor aus $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ die Hinterlegung von Metadaten, um dann mit html2epub1-Workflow eine EPUB2-Datei unter $/workflows/temp/epub/out.epub zu erstellen. Es wird versucht, den Inhalt von $/workflows/temp/epub/ vorher rekursiv zu löschen.

      odt2epub2-Workflow unter $/workflows/ unterscheidet sich von odt2epub1-Workflow nur dahingehend, dass statt der Eingabe der Metadaten des EPUBs per Dialog auf der Kommandozeile eine entsprechende html2epub1-Konfigurationsdatei und auch ein Pfad für das EPUB-Ergebnis mitgegeben werden kann.

      odt2epub3-Workflow unter $/workflows/ nimmt aus einer Konfigurationsdatei mehrere hinterlegte Pfade zu ODT-Dateien und zu einer html2epub1-Konfigurationsdatei mit Metadaten entgegen, um daraus eine EPUB2-Datei zu generieren, die unter einem per Parameter angegebenen Pfad abgelegt wird. Hierzu wird odt2html1-Workflow auf jede Eingabedatei aufgerufen, welche dann mit html_concatenate1 zusammengefügt werden, html2epub1-Workflow packt dann zu EPUB2 zusammen.

      odt2html1-Workflow unter $/workflows/ erzeugt aus einer ODT-Datei, die auf $/odt2html/templates/template1/template1.ott basiert (die hinterlegten benutzerspezifischen Stilvorlagen müssen auf den Text angewendet werden), eine Ausgabe-XHTML-Datei. Die Eingabedatei kann per Parameter mitgeteilt oder per Dialog ausgewählt werden. Nach odt2html1 werden aus $/odt2html/templates/template1/ prepare4hierarchical.xsl mit xsltransformator1, html_flat2hierarchical1_config.xml mit html_flat2hierarchical1 und html_clean.xsl mit xsltransformator nacheinander aufgerufen. Das Ergebnis wird unter $/workflows/temp/output_1/output_4.html (samt den dazugehörigen Bildern, die auch in besagtem Verzeichnis in einer info.xml aufgelistet sind) abgestellt, auch werden die Zwischenergebnisse output_1.html, output_2.html und output_3.html dort nicht aufgeräumt.

      odt2html2-Workflow unter $/workflows/ ruft odt2html1 auf eine Reihe von Eingabe-ODT-Dateien auf, die in einer Steuerungsdatei hinterlegt sind, und fügt diese mit html_concatenate1 zusammen. Anschließend werden aus $/odt2html/templates/template1/ prepare4hierarchical.xsl mit xsltransformator1, html_flat2hierarchical1_config.xml mit html_flat2hierarchical1 und html_clean.xsl mit xsltransformator auf die zusammengesetzte XHTML-Datei aufgerufen. Die Steuerungsdatei kann per Parameter mitgeteilt oder per Dialog ausgewählt werden, ferner ist der Pfad anzugeben, unter welchem die Ausgabedatei abgelegt werden soll. Das Ergebnis wird unter $/workflows/temp/output_1/output_4.html (im Moment noch ohne den dazugehörigen Bildern und ohne info.xml) abgestellt, auch werden die Zwischenergebnisse output_1.html, output_2.html und output_3.html sowie die output_1_*-Verzeichnisse dort nicht aufgeräumt.

      odt2pdf1-Workflow unter $/workflows/ erzeugt aus einer ODT-Datei, die per Kommandozeilenargument oder per Dialog mitgeteilt werden kann, ein PDF, indem zuerst mit xsltransformator1 und /odt2html/templates/template1/prepare4html2latex1_layout1.xsl transformiert wird, um html2pdf1-Workflow aufrufen zu können.

      odt2pdf2-Workflow unter $/workflows/ unterscheidet sich von odt2pdf1-Workflow nur dahingehend, dass per Kommandozeilenargument eine Steuerungsdatei entgegengenommen wird, die mehrere Eingabe-ODT-Dateien referenziert, welche dann mit odt2html2-Workflow für die weitere Verarbeitung vorbereitet werden. Ferner muss der Pfad angegeben werden, unter welchem die Ergebnis-PDF-Datei abgelegt werden soll.

      setup1-Workflow unter $/workflows richtet die Tool-Sammlung für die Verwendung ein, indem die Dateien aus $/w3c/ in die Verzeichnisse der Tools kopiert werden, damit diese jeweils eigenständig darauf zugreifen können.

      epub2wordpress1-Workflow unter $/workflows/epub2wordpress/epub2wordpress1/ entpackt ein EPUB2 mittels epub2html1 aus $/html2epub/html2epub1/, wendet das Stylesheet $/workflows/epub2wordpress/epub2wordpress1/html2wordpress1.xsl mittels xsltransformator1 aus $/xsltransformator/xsltransformator1/ darauf an und übermittelt das Ergebnis an eine WordPress-Installation mithilfe von html2wordpress1 aus $/html2wordpress/html2wordpress1/, wobei die html2wordpress1-Steuerungsdatei, die per Kommandozeilenargument mitgegeben wird, als Quelldatei $/html2wordpress/html2wordpress1/input.html eingetragen haben muss. Die in der EPUB2-Datei enthaltenen XHTML-Dateien werden jeweils einzeln transformiert und übermittelt.

      odt2all1_config_edit1 unter $/workflows/gui/odt2all1_config_edit1/ dient der Workflow-Unterstützung und erlaubt das Auswählen oder Neuanlegen einer odt2all1-Workflow-Konfigurationsdatei, wobei sowohl die Eingabe-ODT-Dateien als auch die html2epub1-Konfigurationsdatei hinterlegt werden können.

      odt2all1_config_edit2 unter $/workflows/gui/odt2all1_config_edit2/ unterscheidet sich von odt2all1_config_edit1 nur dahingehend, dass die html2epub1-Konfigurationsdatei nicht hinterlegt werden kann (weil z.B. ein Workflow sich darum kümmert).

      xsltransformator1 unter $/xsltransformator/xsltransformator1/ ist ein primitiver Wrapper, um mithilfe der Java-Standardlibrary eine XSLT-Transformation durchführen zu können, ohne ein externes Programm dafür aufrufen zu müssen. xsltransformator1 unterstützt die automatische Auflösung von DTDs noch nicht, sodass im Unterverzeichnis $/xsltransformator/xsltransformator1/entities/ die Datei config_xhtml1-strict.xml für XHTML 1.0 Strict oder config_xhtml1_1.xml für XHTML 1.0 nach config.xml kopiert werden muss, damit der Aufruf erfolgreich sein kann.

      multitransform1 unter $/xsltransformator/xsltransformator1/workflows/multitransform1/ kann ein XSLT-Stylesheet zwecks XSLT-Transformation auf eine Reihe von XML-Eingabedateien anwenden, welche dem Programm per Steuerungsdatei mitgeteilt werden zusammen mit dem jeweilig gewünschten Pfad der Ausgabe-Datei. Intern wird xsltransformator1 aufgerufen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „skreutzer“ ()

      Den Quellcode kompilieren

      Weil die Tools unter der GNU Affero General Public License 3 or any later version lizenziert sind, hat jeder Nutzer der Software ein Recht darauf, den Quellcode der Programme erhalten zu dürfen und zu können, welcher verändert oder unverändert eingesetzt als auch beliebig weitergegeben werden darf, solange dies unter der gleichen Lizenz geschieht. Wenn die Tools lediglich als ausführbare Dateien (Java Bytecode) ohne Quelltext überlassen wurden oder auf einem Server ausgeführt werden, der über ein Netzwerk zugänglich ist, muss entweder kenntlich gemacht sein, wo der korrespondierende Quelltext heruntergeladen werden kann oder eine Anschrift genannt werden, die auf Anfrage den Quelltext postalisch zusendet (bis zu drei Jahre nach erfolgter binärer Distribution). Wenn es sich um die offiziellen Bezugsquellen wie das öffentliche Online-Repository github.com/publishing-systems/automated_digital_publishing oder die Download-Packages unter publishing-systems.org/downloads.php handelt, ist sichergestellt, dass der Quellcode mit Java 1.6 und höher sowie mit OpenJDK kompatibel ist. Die Kompilierbarkeit soll für die 100% freien Distributionen des GNU-Betriebssystems gewährleistet werden, wobei insbesondere gNewSense als Referenzsystem gelten kann. Auf debianbasierten Distributionen kann mit

      apt-get install openjdk-6-jdk

      ein JDK installiert werden. Weil GNU make üblicherweise vorinstalliert ist, genügt der Befehl

      make

      im Wurzelverzeichnis $/.

      Da das offizielle öffentliche Repository auf GitHub gehostet wird, ist kollaboratives Arbeiten an der Software besonders einfach. Mit einem GitHub-Account kann zunächst ein „Fork“, eine eigene Kopie des Repositorys angelegt werden. Sofern git mittels

      apt-get install git

      installiert wurde, kann mit dem Befehl

      git clone <HTTPS clone URL des Repositorys auf github.com>

      eine lokale Kopie heruntergeladen werden, in welcher die Entwicklung stattfindet. Ist die Programmierung abgeschlossen, können die Änderungen mit dem Dreisatz

      git add *
      git commit -m "Beschreibung der Änderungen"
      git push origin <Branch, erst mal master>

      in den eigenen Fork hochgeladen und damit veröffentlicht werden. Zu berücksichtigen ist dabei, dass alle Änderungen ebenfalls unter GNU Affero General Public License 3 or any later version lizenziert werden müssen. Auf github.com kann dann in der Verwaltung des Fork-Repositorys ein „Pull Request“ zwecks potentieller Übernahme in das offizielle Repository angelegt werden, welcher nach Prüfung angenommen oder abgelehnt wird. Auf diese Weise können Patches zur Korrektur von Fehlern, neue Features, neue Tools usw. eingereicht werden, oder aber die Werkzeugkiste auch in eine ganz andere Richtung weiterentwickelt werden.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „skreutzer“ ()

      So, neben einem noch fehlenden „User Guide“-Abschnitt nach „Installationsanweisungen“ und vor „Beschreibung der Tools“ kommen jetzt nur noch kleinere Ergänzungen, Präzisierungen und Vereinfachungen. Für den Blog dürfte wahrscheinlich höchstens die Einleitung und der User Guide in Frage kommen, der Rest ist eher „technische Dokumentation“. Darauf aufbauend könnten zukünftige Funktionen, Features, (Plattform-)Integration und ganzheitlich digitalverträgliche Ökosysteme weiterdiskutiert werden. Eine Wunschliste mit Voting wäre ganz hübsch, im Forum können jetzt schon Fehler gemeldet und Vorschläge eingereicht werden. Auch gibt es ein paar ähnliche Software-Pakete, die ebenfalls begutachtet werden könnten. Feedback erwünscht.