OpenOffice.info

Hallo
das erklär ich nochmal ausführlicher - am Anfang der xml-Datei befindet sich ein mapping von `kurzen_namen` auf vollständige "bezeichner" hier mal etwas formatiert:
elem.get(...) benötigt als Argument diesen vollen Bezeichner zum Namen `Text` eingefasst in {}geschweiften klammern und gefolgt von Variablen-namen selbst.

Hallo Stephan,

Stephan hat geschrieben:@Dreh-Gel

Deine Aussagen öffnen mir die Augen das es mit Reg-Ex ganicht bzw. nur sehr sehr kompliziert geht (bisher war ich der Meinung es ginge relativ leicht, meine Gründe Reg-Ex eher nicht zu wollen waren Andere)

Ganz generell: RegEx sind dann gut, wenn es sich um eine "Reguläre Grammatik" handelt, das ist der am wenigsten komplexe Fall der Chomsky Hierarchie. Das ist bei XML-Dateien generell nicht der Fall. Genau so eignen sich RegExe nicht zum Parsen von HTML. Jedenfalls nicht den gesamten Sprachumfang. Allerdings gelegentlich will man gar nicht XML oder HTML parsen, sondern nur ein paar Informationen rausholen. So wie bei Dir. Dann kanns durchaus gehen.

Kurz gesagt, wenn du geschachtelte Regeln hast, zb. Draw-Frame im Draw-Frame, dh man muss das Ende-Tag dem Anfangs-Tag zuordnen, (also Schachtelung oder Sequenz unterscheiden) dann geht das über einen RegEx hinaus und man muss tricksen, bzw den Rest des Parsers um den RegEx drumherum schreiben. Geht es nur ein bisschen über die Reguläre Grammatik hinaus, dann kanns noch gehen, aber es wird schnell kompliziert. Es gibt ja XML-Parser, sei es der aus Open Office oder SAX. Leider habe ich mit denen keine Erfahrungen.

Hat man jedoch einen Sprachteil, der nicht geschachtelt ist oder es gibt sonstige Vereinfachungen, dann können RegExe doch in Betracht kommen. Das hängt davon ab, welcher Grammatik der erzeugte Text entspricht. Der OpenOffice Generator wird nicht den gesamten Sprachumfang von XML erzeugen, dh dass auch der Parser einfacher ist. Allerdings muss man dazu wissen, was der Generator nun genau erzeugt und ggf überprüfen, ob das in der nächsten Version auch noch so ist.

Stephan hat geschrieben: nochmals zur Erklärung, das RegEx müsste (im ersten Schritt) folgenden (hier allgemein codiert/beschrieben) Abschnitt finden (rot markiert):

<draw:frame [...] </draw:frame> [...] <draw:frame [...] </draw:frame> [...] <text:p> [...] </text:p>

dürfte aber NICHT Folgenden finden (die Rotmarkierung betrifft hier nur das was man wohl FÄLSCHLICH als zu finden ansieht):

<draw:frame [...] <draw:frame [...] </draw:frame><text:p> [...] </text:p> [...] </draw:frame>

Gruß
Stephan

Hier sind geschachtelte Draws möglich. Das geht über einen RegEx hinaus. In deinem Beispiel ganz oben hast du geschrieben:

<!-- Abschnitt B -->

Das hätte man sehr gut mit RegEx erkennen können. Aber sowas ist nicht im Text drinnen. Man könnte über RegExe nachdenken, wenn man sowas reinkriegen könnte. Zb wenn man wüsste, in welcher Reihenfolge er alle Draws nacheinander in die Datei schreibt und man wüsste, was man tun muss, um danach ein Element mit einem bestimmten Namen zu erzeugen. Ich würde schon erwarten, dass das möglich sein sollte. Wie das mit dem Aufwand ist, ist aber eine andere Frage.

Aber das hängt alles davon ab, was du vor hast, wo die Dokumente herkommen und wie langlebig und stabil die Lösung sein soll.

In Summe scheint mir, dass Axels und Karolus' Vorschlag der bessere und langlebigere ist. Wenn die Schachtelung so ist und eventuell noch andere Unwägbarkeiten im Generator sind, dann ist es sicherer über das Objektmodell zu gehen.

Gruss
DG

Gerade erst gelesen:

Stephan hat geschrieben:Oder die faktische Gesamtaufgabe (nicht alles aber 99% davon):
wie mache ich aus den content.xml mehrerer odt-Dokumente eine content.xml die zu einer Darstellung des Gesamtdokumentes führt als würden die aneinandergereihten Teildokumente am Bildschirm so aussehen als verhielten sie sich als DTP-Dokumente, d.h. absolut verankerte Elemente werden an den nun quasi neuen, richtigen Positionen dargestellt.

Du willst nicht nur Informationen extrahieren, sondern auch noch ein neues Dokument generieren, syntaktisch und semantisch richtig zusammenbauen und es geht um ziemlich viel Text. Karolus hat recht; das geht definitiv deutlich über RegEx hinaus.

Ja das steht doch im node:... text:anchor-type="page"

oh je bin ich unaufmerksam. Ja, stimmt das steht dort und dessen war ich mir eigentlich auch bewusst.

Du hast somit völlig recht, zumal dieses Herangehen ja schon im Grundsatz besser ist, denn damit werden automatisch wirklich nur die richtigen draw-frame erfasst.

im Beispielscode oben frage ich diese Eigenschaft ab mit der Zeile

Hast Du eine Antwort in Basic? Probieren brauchst Du nicht das kann ich auch selbst, also nur wenn Du es direkt weist. (Das quasi Rahmenmakro für den Zugriff auf die Nodes steht oben im Thread)



Gruß
Stephan

Hallo

Hast Du eine Antwort in Basic?

Nee, `lxml.etree` ist ja eine python-lib, und da hab ich gestern schon einige Haare verloren bis ich diesen verflixten xml-Kram ein wenig kapiert hab, das tue ich mir jetzt nicht nochmal mit den kruden api-methoden an.

Wenn ich in der Richtung mehr machen müsste würde ich einen Blick auf odfpy werfen.