Problem beim manuellen generieren von .odt-Dateien

[TNG]

Hallo liebe OpenOffice-Gemeinde,

wir als Consulting-Unternehmen generieren für den automatisierten Export unserer Mitarbeiterprofile, welche von den Mitarbeitern selbst im firmeneigenen Wiki gepflegt werden, mithilfe von Freemarker manuell .odt-Dateien. Diese sind ja auch (im Wesentlichen) nichts anderes als gezippte und anschließend umbenannte XML-Dateien.

Nach einem Upgrade der OOo-Version auf unseren internen Servern von 3.0 auf 3.2 funktioniert das leider nicht mehr problemlos. Öffnet man die generierten Dateien, so erhält man eine Fehlermeldung dass die Datei beschädigt sei und man sie nun automatisch reparieren lassen könnte. Nach der Reparatur sieht alles wunderbar aus, die Profile sind nicht zu unterscheiden von den bis vor dem Update validen Dokumenten. Nun ist es leider nicht nur nervig diese Fehlermeldung wegzuklicken, zudem verwenden wir die generierten Dateien in Verbindung mit einem OpenOffice-Prozess im Headless-Modus, um daraus automatisiert PDF-Profile zu erzeugen. Dieser Schritt wird leider nicht so problemlos durchgeführt, da das Command Line Interface von OpenOffice keine Option für automatische Reparaturen eventuell beschädigter Dateien vorsieht.

Unsere erste Herangehensweise war, das alte Template mit der Version 3.2 zu öffnen und die Freemarker-Kommandos zu übertragen bzw. sich über diff/xmldiff die Unterschiede der kaputten und der autoreparierten Versionen von exportierten Profilen anzusehen, wobei ersteres leider keinen Erfolg und letzteres leider zu viele Resultate brachte, da OpenOffice bzw. LibreOffice oder AbiWord beim automatischen Reparieren von Dateien anscheinend nicht versuchen, die Dateien weitestgehend unverändert zu lassen, sondern über standardisierte Ersetzungen die gängigsten Fehler bereinigen.

Die Hoffnung wäre hier auf Experten zu treffen, die eventuell mehr zu Änderungen am akzeptierten Dateiformat zwischen OpenOffice-3.0 und OpenOffice-3.2 sagen können oder ob euch sonst noch etwas einfällt. Wir sind für alle Vorschläge offen und für jede Hilfe dankbar.

Zur Zeit steht auch die Neuerstellung des Templates als weiteres Vorgehen zur Auswahl, falls jemand bessere bzw. weniger aufwändige und genauso langfristig sinnvolle Vorschläge hat, bitte immer her damit! Vielen Dank schon mal an euch alle.

Viele Grüße,
Roland Schmid
(TNG Technology Consulting GmbH)

[Stephan]

Unsere erste Herangehensweise war, das alte Template mit der Version 3.2 zu öffnen und die Freemarker-Kommandos zu übertragen bzw. sich über diff/xmldiff die Unterschiede der kaputten und der autoreparierten Versionen von exportierten Profilen anzusehen, wobei ersteres leider keinen Erfolg und letzteres leider zu viele Resultate brachte, da OpenOffice bzw. LibreOffice oder AbiWord beim automatischen Reparieren von Dateien anscheinend nicht versuchen, die Dateien weitestgehend unverändert zu lassen, sondern über standardisierte Ersetzungen die gängigsten Fehler bereinigen.

Ich verstehe nicht so recht was hier "erstens" und "zweitens" ist bzw. meint.
Außerdem würde ich ganz grundsätzlich empfehlen die Dateien nicht nur automatisch sondern auch händisch zu prüfen und dabei auf menschliche Intuition zu vertrauen, denn ich weiß durchaus was ihr bezüglich der Problememe eines formalen 1:1-Vergleichs meint.

Hilfreich wäre es wenn ihr 2 Dateien hier ins forum stellt dann kann jeder der Mitleser sich selbst ein Bild machen.

Die Hoffnung wäre hier auf Experten zu treffen, die eventuell mehr zu Änderungen am akzeptierten Dateiformat zwischen OpenOffice-3.0 und OpenOffice-3.2 sagen können

Es kann nur um Geringfügigkeiten gehen, denn Formatänderungen sind mir nicht bekannt [1], mithin wären UNterschiede nur bei der Formatauslegung zu erwarten.
Hilfe werdet ihr zu dieser Art Detailfragen der (internen) Formatverwendung/Unterstützung hier wohl eher nicht finden (siehe auch: viewtopic.php?f=3&t=12975). Besser ist es sich beispielsweise an das Apache/OOo-Projekt zu wenden und zwar über deren Mailinglisten, siehe:
http://mail-archives.apache.org/mod_mbo ... r-ooo-dev/
denn dort lesen auch Entwickler mit, ebenso auch Leute die in ISO-Ausschüssen sitzen wo es um die Standardisierung von ODF geht.

Geheimtipp wäre evtl. bei http://teamopenoffice.org/de/ anzufragen denn dort sitzen Programmierer die über Jahre beruflich, im Auftrage von Sun und Oracle, OOo programmiert haben.
Problem ist dabei evtl. das man dort derzeitig etwas abweisend reagieren könnte da man dort momentan in gewissen Dissenz zur 'normalen' Weiterentwicklung von OOo steht, die ja unter Regie von Apache erfolgt (http://incubator.apache.org/openofficeorg/). Viele der Mitglieder von http://teamopenoffice.org/de/ dürften auch über XING zu erreichen sein, z.B. ist der derzeitige Moderator der OpenOffice.org-Gruppe bei XING ein Mitglied bei http://teamopenoffice.org/de/.


{1]
Beide OOo-Versionen sollten das (nicht ISO-konforme) ODF 1.2 als Default verwenden, es kann sein das Dieses inzwischen auch gültiger OASIS-Standard ist, der ISO-Standard steht jedoch weiterhin bei ODF 1.0.



Gruß
Stephan

[TNG]

Hallo Stephan,

vielen Dank schonmal für die schnelle Antwort!

Ich verstehe nicht so recht was hier "erstens" und "zweitens" ist bzw. meint.

Es ist lediglich gemeint, was wir zuerst und was wir danach versucht haben, leider kein tieferer Sinn dahinter

Außerdem würde ich ganz grundsätzlich empfehlen die Dateien nicht nur automatisch sondern auch händisch zu prüfen und dabei auf menschliche Intuition zu vertrauen, denn ich weiß durchaus was ihr bezüglich der Problememe eines formalen 1:1-Vergleichs meint.

Hilfreich wäre es wenn ihr 2 Dateien hier ins forum stellt dann kann jeder der Mitleser sich selbst ein Bild machen.

Grundsätzlich haben wir das natürlich auch getan, die diffs sind ja dazu da um einem einfach alle Unterschiede zu zeigen und wir haben hin und wieder mal eine Kleinigkeit entdeckt, die allerdings leider bisher wohl noch nicht die entscheidenden waren. Dateien kann ich euch leider nicht so ohne weiteres zur Verfügung stellen, dazu müsste ich mir erst die Genehmigung besorgen, zwei Dateien mit "Dummy-Daten" überarbeiten und sie dann hochladen...

Besser ist es sich beispielsweise an das Apache/OOo-Projekt zu wenden und zwar über deren Mailinglisten, siehe:
http://mail-archives.apache.org/mod_mbo ... r-ooo-dev/
denn dort lesen auch Entwickler mit, ebenso auch Leute die in ISO-Ausschüssen sitzen wo es um die Standardisierung von ODF geht.

Vielen Dank für den Tipp, werden wir definitiv mal versuchen.

Geheimtipp wäre evtl. bei http://teamopenoffice.org/de/ anzufragen denn dort sitzen Programmierer die über Jahre beruflich, im Auftrage von Sun und Oracle, OOo programmiert haben.

Auch diese Idee hört sich sehr vielversprechend an, danke.

Viele Grüße,
Roland Schmid
(TNG Technology Consulting GmbH)

[Stephan]

Es ist lediglich gemeint, was wir zuerst und was wir danach versucht haben

und ich wiederhole meine Frage:
Was IST "erstens" was IST "zweitens"?

die allerdings leider bisher wohl noch nicht die entscheidenden waren

Wie begründet sich das im Konkreten? Um welche 'Kleinigkeiten' geht es dabei im Konkreten?


Gruß
Stephan

[TNG]

Hallo Stephan,

und ich wiederhole meine Frage:
Was IST "erstens" was IST "zweitens"?

Okay, ein zweitens gibt es in diesem Sinne hier nicht, da die verschiedenen Ansätze sich gegenseitig überschneiden:

Unsere erste Herangehensweise war, das alte Template mit der Version 3.2 zu öffnen und die Freemarker-Kommandos zu übertragen bzw. sich über diff/xmldiff die Unterschiede der kaputten und der autoreparierten Versionen von exportierten Profilen anzusehen, wobei ersteres leider keinen Erfolg und letzteres leider zu viele Resultate brachte, da OpenOffice bzw. LibreOffice oder AbiWord beim automatischen Reparieren von Dateien anscheinend nicht versuchen, die Dateien weitestgehend unverändert zu lassen, sondern über standardisierte Ersetzungen die gängigsten Fehler bereinigen.

Was ich damit gemeint habe ist, dass wir zunächst als das Problem erkannt wurde, mit der oben beschriebenen Vorgehensweise versucht haben den Fehler auszumachen.
Genauer heißt das, wir haben hier 2 verschiedene Ansätze gehabt:
(1) Öffnen der alten Template-Datei von v3.0 mit einem OpenOffice 3.2, speichern, übertragen der Freemarker-Kommandos in die neue Datei (diese werden ja von OpenOffice nicht erkannt und somit automatisch als "Fehlerquelle" beseitigt
(2) Unzip eines kaputten und eines (mit OpenOffice/LibreOffice/AbiWord) autoreparierten Profils, direkter Vergleich der zusammengehörenden XML-Dateien (manuell und mit den tools diff/vimdiff/xmldiff)

Wie begründet sich das im Konkreten? Um welche 'Kleinigkeiten' geht es dabei im Konkreten?

Dass es nicht die entscheidenden Kleinigkeiten waren mache ich daran fest, dass OpenOffice bei Verwendung eines hinsichtlich dieser Kleinigkeiten überarbeiteten Profils noch immer die identische Fehlermeldung zeigt.
Ich muss allerdings an dieser Stelle erwähnen, dass ich mich selbst nicht besonders gut mit dem OpenDocument-Format auskenne und eventuell nicht genau sagen kann was die Veränderung im speziellen bewirkt.
Bisher habe ich folgende Sachen bereinigt:

Code: Alles auswählen

content.xml:
* Anpassen des Headers (<office:document-content> - Tag): Update einiger angegebener xmlns:-Felder, office:document-content="1.2" -> office:version="1.2"
* Update der Style-Attribute rel-column-width: diese wurden von der Autoreparatur alle mit ~7.19 multipliziert
* Hinzufügen des style:display-name Attributs zu allen Styles (wie sie nach dem Speichern wie bei (1) hinzugefügt wurden)
* Renaming aller Styles (hatten teilweise Leerzeichen bzw. Unterstriche im Namen die nach der Autoreparatur mit _#hexcode#_ mit dem entsprechenden UTF-8-Hexcode für das entsprechende Zeichen ersetzt wurden; z.B. 20 für ein Leerzeichen, 5f für einen Unterstrich)

styles.xml
* Siehe Style-Refactoring in der content.xml

Das sind zumindest alle Refactorings die ich mir dokumentiert habe, sollten aber eigentlich alle sein die ich so im ersten Anlauf erkennen konnte.
Für eine tiefere Analyse fehlen mir dann wie gesagt die Kenntnisse zum OpenDocument-Dateiformat.

Ich hoffe ich konnte deine Fragen damit (ausreichend) beantworten?

Viele Grüße,
Roland Schmid
(TNG Technology Consulting GmbH)

[Stephan]

(1) Öffnen der alten Template-Datei von v3.0 mit einem OpenOffice 3.2, speichern

klar

übertragen der Freemarker-Kommandos in die neue Datei

ich kenne Freemarker nicht, diese Aussage meint dann aber das Freemarker eine DAtei erzeugt auf Grundlage der gerade angepassten Vorlage?
Bzw. was ist 'übertragen von KOmmandos', dass meint doch 'anwenden von Kommandos auf die Datei'?

(diese werden ja von OpenOffice nicht erkannt und somit automatisch als "Fehlerquelle" beseitigt

mmh, das klingt nun doch anders, falls es nun doch darum geht etwas nur 'freemarker-spezifisches' in die Datei zu schreiben wäre das doch schon einmal eion Ansatzpunkt, denn es geht hier um Etwas Anderes als was ich bisher dachte. Der Unterschied zwischen solchen Inhalten und 'normalen' Inhalten ist der das solche Inhalte optional sind aber nicht direkt Teil des ODF-Standards, es geht dann also mit gewisser Sicherheit nicht um einen Formatfehler im engeren Sinne, würde ich meinen.

Ich hoffe ich konnte deine Fragen damit (ausreichend) beantworten?

Zumindet weiß ich jetzt was mit "Kleinigkeiten" gemeint war.

Nichts jedoch weiß ich weiterhin über die manuelle Prüfung.
Im Grunde ginge diese doch über ein reines optisches Beurteilen des XML hinaus, denn man müßte doch vor allem bestrebt sein den Ort des Fehlers einzugrenzen.
Dazu würde ich zunächst einzelne XML-Dateien innerhalb des Dateiarchivs gegen deren ursprüngliche Versionen (die aus der 3.0er Datei) austauschen und kontrollieren welchge Auswirkung das hat. Dadurch kann man die konkrete XML-Datei identifizieren die die Probleme hervorruft und hier kann man dann genauso einzelne Abschnitte austauschen.
Durch dieses 'Eingabeln' der Fehlerquelle sollte man recht schnell das Problem eingrenzen können, weil erwartet werden kann das viele, eigentlich abweichende Stellen, als Fehlerursache eleminierbar sind.



Gruß
Stephan