Ich suche alle Informationen, um den Import und Export von HTML zu steuern!
Ich habe dazu weder in der Papyrus-Hilfe, noch hier im Forum etwas finden können.
Ich habe ein Dokument mit Tabelle im Papyrus erzeugt und als HTML exportiert.
Von dort ausgehend wird es im HTML bearbeitet und durch ein Programm Teile der Tabelle automatisch ergänzt. Es müssen für die effektive Programmierung optimalerweise auch die TAG-Ergänzungen (die Klassenbezeichnungen für die Spaltenzuordnungen) gesetzt werden.
Papyrus wirft diese allerdings wieder raus - entweder schon beim Importieren oder erst beim Exportieren?
Und ich finde keine Möglichkeit das zu steuern, wie HTML-Im- oder -Exporte gesteuert werden können.
Also im Papyrus-Handbuch taucht die Abkürzung »HTML« schon recht häufig auf.
In den Papyrus-Einstellungen > Import/Export > HTML kann man eine Checkbox einschalten, dass unbekannte HTML-Tags erhalten bleiben sollen. Ich würde zunächst mal davon ausgehen, dass dass auch für unbekannte Attribute (class, lang, style, etc.) gilt.
Ich antworte dir nur wegen diesem Satz und weil ich selbst mal ne Bibelseite hatte, wenn auch für die böse Seite. Den Rest versteh ich nämlich nicht.
Meine Erfahrungen mit HTML: Du kriegst dinge exportiert, aber nicht mit allem, was Papyrus da an Attributen oder Bereichen anbietet. Ein Dokument in HTML zu bearbeiten und wieder zu importieren, hat bei mir nie das gewünschte Ergebnis gebracht. Ist aber zu lange her, um dazu eine Aussage zu treffen.
Interessanter fand ich die Datenbank, die ja nur aus Textdateien besteht. Export geht hier einigermaßen, Import ist nahezu unmöglich, wenn man Unicode verwendet. Die Tests gingen mir so auf die Nerven, dass ich dazu Klassen in PHP geschrieben habe. Ich kann nun eine Papyrus-Datenbank über PHP auslesen. Ich habe zwar ein paar Bearbeitungs- und Suchmöglichkeiten eingebaut, aber auch das war mir zu umständlich. Ich erzeuge also eine CSV, die ich in MySql einlesen kann. Und von dort aus kann ich dieses Ergebnis wieder zu einer neuen Papyrus-Datenbank machen.
Achtung: Weil das Ding kein SQL spricht, kann ich dort nichts hinzufügen! Es gibt eine komplett neue Datenbank-Datei. Das Projekt ruht momentan, weil ich wieder mal mehr an meinem Roman arbeite. Ich kann dir nicht versprechen, dass alles erschöpfend gut dokumentiert ist. Wenn du es aber brauchen kannst, versuche ich gern zu helfen.
Nein, die Attribute werden leider einfach entfernt.
Ich werde mir also etwas anders ausdenken müssen und den Parser zum Verarbeiten etwas stärker auf die Struktur anpassen müssen, anstatt die Attribute mit in die Auswahl mit einbeziehen zu können.
Grundidee das Problem anders anzugehen habe ich schon im Kopf.
Das PHP / SQL-Gespann interessiert mich immer.
Auch wenn ich das momentan nicht direkt benötige.
Ja es ist schade, dass die PapyrusDB keinen SQL-Kern hat. Wäre genial, denn dann würde ich alles mögliche damit aufmotzen und zur Verfügung stellen.
Das Grundlegende Problem ist halt das PAP halt ein reines Schreibprogramm ist und kein HTML Editor, und so reagiert es auch, es wird das was es verstehen kann von HTML in PAP wandeln das es bearbeitet wird und es wird das ausgaben was es dann noch hat der Rest geht da halt verloren.
HTML zu Schreiben und Editieren da muss ein HTML Editor her denn nur der kann auch (eventuell) mit alle Tags umgehen auch wenn es es selbst nicht versteht.
Wenn ich ein Schreibprogramm programmieren würde, dann würde ich die Daten in XML verwalten und die Formate mit Klassen und CSS. Ich hatte darauf spekuliert, dass das hier mit HTML Im- und Export entsprechend funktioniert.
An anderer Stelle kann man für die EPubs oder Ähnliches ja auch CSS-Formatierungen zusätzlich angeben.
Es ist schade, dass ich da keine Möglichkeit habe den Im- und Export zu steuern.
Aber ich sollte mich evtl. einmal darum kümmern was das mit dem CSS so auf sich hat und ob ich das da nicht evtl. über das Extrahieren aus dem EPub hinbekommen könnte
Ich blicke bei dir nicht durch, was du machen willst. Ich wollte auch den PAP-Text parsen. Aber im Gegensatz zu DOC sind die Zip-Files innerhalb des PAP-Formates wohl verschlüsselt.
Nach vielen schlaflosen Nächsten und viel Herumprobieren, bin ich von HTML abgekommen. Aber es gibt ein anderes Format, das viel mehr mitbringt als HTML: ODT. Und da dies ein Schreibformat ist, gibt sich Papyrus dort auch viel mehr Mühe damit, alles, was möglich ist, dorthin zu übertragen.
Und auch dazu hab ich bereits nen Parser geschrieben. Hab allerdings alles selbst rausgelesen und keine Dokus durchgearbeitet. Darum taucht immer mal was auf, was das Ding noch nicht kennt. Mein Ziel beim Parsen war es, an die Kommentare von Papyrus zu kommen, weil ich über die Daten in eine Datenbank spielen wollte.
Bleibt nur dein Problem, Daten wieder zurück in ein Papyrus-Dokument zu spielen. Das wird wahrscheinlich nur gehen, wenn Ulli das Format irgendwie freigibt. Das erwarte ich offen gestanden nicht, obwohl es ungeahnte Möglichkeiten bieten würde.
Da hast Du etwas missverstanden.
Ich parse das HTML und lese das dann wieder in Papyrus ein.
Ist dann halt nacktes HTML, aber das macht die Sache auch sehr viel übersichtlicher.
Im Übrigen geht mit der HTML/CSS-Kombination so gut wie ALLES!
Und da Papyrus bei ePub-Format auch anbietet, dass man eine CSS-Datei mit einbinden kann, dachte ich, dass HTML das evtl. irgendwo auch anbieten könnte, denn da kommt das ja her und außerdem beherrsche ich das brauchbar.
CSS beherrscht übrigens auch Formatvorlagen. Damit arbeite ich seit etwa 20 Jahren.
Der Vorteil von HTML ist für mich (und den Parser) auch, dass es sehr simpel und übersichtlich gestrickt ist.
Mein Plan ist, transkribierte Interviews automatisch in die einzelnen Sätze zu zerlegen.
Das wird die dritte Spalte eine Din A 4 -quer-Tabelle.
Spalte: Interview-Timestamp.
Spalte: Satznummer (automatisch)
Spalte: Originaltext des Interviews
Spalte: Keywords aus dem Text (automatisch)
Spalte: Synonyme zu 4. (halbautomatisch, Thesaurus)
Spalte: wissenschaftstauglichen Formulierung von 3.
ps - an den Parsern in PHP habe ich durchaus Interesse.
Als kleine Gegenleistung: ich erstelle gerade ein BackUp-System, das unter Windows 10 (DOS-Konsole) läuft und nach Verzeichnissen oder Kategorien differenziert täglich sukzessive seine BackUps mit Winrar (alternativ ginge natürlich auch WinZip) erzeugt.
Das System benötigt nur eine separate Festplatte, keinen Server.
Papyrus exportiert doch die CSS-Stile mit. Ich hab mir da meine eigene CSS-Vorlage gebaut, bei der ich jeder Formatvorlage einen CSS-Klasse zugewiesen habe. Ist leider etwas umständlich damit zu hantieren, weil Papyrus immer wieder Stile rauswirft und man bei jedem Export neu schauen muss, ob alles korrekt verknuddelt ist.
Du meinst Klassen?
Die Tabelle stelle ich mir sonderbar vor.
Ich hänge die Dateien mal mit einem etwas schlechten Gefühl an. Ich hab seit etwa einem Jahr sehr aktive Testleser und komm nicht dazu, das Projekt rund zu machen. Hab einen fiesen Fehler bei meinem Synchonisationsmechanismus, den ich nicht finde. Davon dürften aber diese drei Dateien nicht betroffen sein.
Mit der Funktion liest du die Inhalte einer ODT-Datei aus. Mit diesem String fütterst du dann die odt-Klasse. Wundere dich nicht, wenn ich mal in Deutsch und mal in Englisch dokumentiert habe. Ich switche in meinem Leben immer mal wieder hin und her und recycle Code aus dem jeweils anderen Lebensabschnitt.
Was macht die Klasse? Sie nimmt das XML des ODT-Dokuments und sucht sich alle Kommentare raus. Die Daten dieser Kommentare (Text, Autor, Zeit) werden wie ein Query-String aufbereitet und urlencoded und in geschweifte Klammern eingeschlossen. So kann ich sie weiterverarbeiten und du kannst sie mit einem einfachen Regex rauswerfen. Überschriften werden – und jetzt wirds interessant für dich – zu HTML-Tags umgewandelt. Dann wird alles andere XML entfernt, sodass nur noch der Text stehenbleibt.
Leider für dich habe ich niemals mit Tabellen herumprobiert. Wahrscheinlich wird das im ODT-XML keine Freude sein, sich das rauszusuchen. Wenn du die Methode ->umwandeln_ueberschriften() abwandelst, könntest du damit aus dem Tabellen-XML des ODTs wieder HTML machen. Letzten Endes ist es nur ein wenig Herumprobieren.
Und ganz wichtig: Jedes Programm spricht einen anderen ODT-Dialekt. Papyrus, LibreOffice und Word geben alles jeweils anders aus. Und wie kann es anders sein, hält sich Word nicht an alle Vorgaben.
Jein!
Auch ohne Klassen kann ich für jedes TAG spezifische Eigenschaften festlegen.
Die Klassen sind dann schon eine sehr flexible Erweiterung.
Der Grund-Aufbau der Tabelle ist in dem wissenschaftlichen Auswertungsverfahren vorgeschrieben. Ich habe ihn für die halbautomatische Analyse nur etwas erweitert. Und selbstverständlich ist das passende Format DIN A 4 quer.
Für einen klassischen wissenschaftlichen Text ohne Besonderheiten dürfte es auch genügen.
Da sind nur hierarchische Überschriften und einfache Text-Formatierungen erforderlich.
Wenn aber Chat-Dokus u. Ä. dazu kommt, dann genügt das natürlich kaum noch.
Aber ich hätte da ein paar Tricks auf Lager … falls Papyrus die div-, section-, main- und article-Tags kennen sollte.
