2.13. OpenDocument-Vorlagen

kivitendo unterstützt die Verwendung von Vorlagen im OpenDocument-Format, wie es OpenOffice.org ab Version 2 erzeugt. kivitendo kann dabei sowohl neue OpenDocument-Dokumente als auch aus diesen direkt PDF-Dateien erzeugen. Um die Unterstützung von OpenDocument-Vorlagen zu aktivieren muss in der Datei config/kivitendo.conf die Variable opendocument im Abschnitt print_templates auf ‘1’ stehen. Dieses ist die Standardeinstellung.

Während die Erzeugung von reinen OpenDocument-Dateien keinerlei weitere Software benötigt, wird zur Umwandlung dieser Dateien in PDF OpenOffice.org benötigt. Soll dieses Feature genutzt werden, so muss neben OpenOffice.org ab Version 2 auch der “X virtual frame buffer” (xvfb) installiert werden. Bei Debian ist er im Paket “xvfb” enthalten. Andere Distributionen enthalten ihn in anderen Paketen.

Nach der Installation müssen in der Datei config/kivitendo.conf zwei weitere Variablen angepasst werden: openofficeorg_writer muss den vollständigen Pfad zur OpenOffice.org Writer-Anwendung enthalten. xvfb muss den Pfad zum “X virtual frame buffer” enthalten. Beide stehen im Abschnitt applications.

Zusätzlich gibt es zwei verschiedene Arten, wie kivitendo mit OpenOffice kommuniziert. Die erste Variante, die benutzt wird, wenn die Variable $openofficeorg_daemon gesetzt ist, startet ein OpenOffice, das auch nach der Umwandlung des Dokumentes gestartet bleibt. Bei weiteren Umwandlungen wird dann diese laufende Instanz benutzt. Der Vorteil ist, dass die Zeit zur Umwandlung deutlich reduziert wird, weil nicht für jedes Dokument ein OpenOffice gestartet werden muss. Der Nachteil ist, dass diese Methode Python und die Python-UNO-Bindings benötigt, die Bestandteil von OpenOffice 2 sind.

[Anmerkung]Anmerkung

Für die Verbindung zu OpenOffice wird normalerweise der Python-Interpreter /usr/bin/python benutzt. Sollte dies nicht der richtige sein, so kann man mit zwei Konfigurationsvariablen entscheiden, welcher Python-Interpreter genutzt wird. Mit der Option python_uno aus dem Abschnitt applications wird der Interpreter selber festgelegt; sie steht standardmäßig auf dem eben erwähnten Wert /usr/bin/python.

Zusätzlich ist es möglich, Pfade anzugeben, in denen Python neben seinen normalen Suchpfaden ebenfalls nach Modulen gesucht wird, z.B. falls sich diese in einem gesonderten OpenOffice-Verzeichnis befinden. Diese zweite Variable heißt python_uno_path und befindet sich im Abschnitt environment. Sie ist standardmäßig leer. Werden hier mehrere Pfade angegeben, so müssen diese durch Doppelpunkte voneinander getrennt werden. Der Inhalt wird an den Python-Interpreter über die Umgebungsvariable PYTHONPATH übergeben.

Ist $openofficeorg_daemon nicht gesetzt, so wird für jedes Dokument OpenOffice neu gestartet und die Konvertierung mit Hilfe eines Makros durchgeführt. Dieses Makro muss in der Dokumentenvorlage enthalten sein und “Standard.Conversion.ConvertSelfToPDF()” heißen. Die Beispielvorlage ‘templates/mastertemplates/German/invoice.odt’ enthält ein solches Makro, das in jeder anderen Dokumentenvorlage ebenfalls enthalten sein muss.

Als letztes muss herausgefunden werden, welchen Namen OpenOffice.org Writer dem Verzeichnis mit den Benutzereinstellungen gibt. Unter Debian ist dies momentan ~/.openoffice.org2. Sollte der Name bei Ihrer OpenOffice.org-Installation anders sein, so muss das Verzeichnis users/.openoffice.org2 entsprechend umbenannt werden. Ist der Name z.B. einfach nur .openoffice, so wäre folgender Befehl auszuführen:

mv users/.openoffice.org2 users/.openoffice

Dieses Verzeichnis, wie auch das komplette users-Verzeichnis, muss vom Webserver beschreibbar sein. Dieses wurde bereits erledigt (siehe Manuelle Installation des Programmpaketes), kann aber erneut überprüft werden, wenn die Konvertierung nach PDF fehlschlägt.