OpenOffice.info

Für ein verlustfreies Arbeiten mit OpenOffice ist eine Vorkenntnis aller bekannten Absturzmechanismen und deren Vorbeugung vorteilhaft. Folgende Übersicht dokumentiert die möglichen Methoden zur Optimierung der Zuverlässigkeit im OOo-Bereich.

------------------------------------------------------------------------------------------------------------------------
Titel: Überschreitung der 64 kCharakter (nicht kByte) Obergrenze für Absätze (Engl.: Paragraph)

Fehlerbeschreibung:
Datenverluste und Abstürze in OOo-Writer (alle Versionen)
Ursache:
65534 Zeichen (nachtr. Korrektur: nicht 65534 Byte) Obergrenze für Absätze in OOo-Writer
Vorwarnung:
keine Vorwarnung, ggf. mit einem Macro möglich.
Reparatur:
keine Reparaturmöglichkeiten bekannt.
Risikobereich:
Kopieren und Einfügen aus Webseiten, die keine Absatzmarken enthalten, auch bei der Importfunktion aus Quellen, die keine Absatzmarken enthalten. Das Problem tritt aber auch auf, falls Sie z.B. in einem Macro beim Editieren Absatzmarken löschen und dabei die Obergenze vorübergehend überschreiten.
Absturzszenario:
viewtopic.php?p=47510#47510 (deutsch)
http://qa.openoffice.org/issues/show_bug.cgi?id=69580 (englisch)
Bugreport:
http://qa.openoffice.org/issues/show_bug.cgi?id=17171 (englisch)
Vorbeugung:
Dokument vor dem Kopieren und Einfügen aus Webseiten in Kopie sichern
Maximale Absatzlänge im Dokument optisch oder mit einem Macro überprüfen.
Behebung:
Umfangreiche und kostspielige Änderung (-> nicht im nächsten Release)
------------------------------------------------------------------------------------------------------------------------
Titel: Fehler beim Speichern ("Write Error")

Fehlerbeschreibung:
Fehlermeldung und ggf. Abstürze in OOo-tools (alle Versionen)
Ursache:
OOo schließt vorübergehend temporäre Dateien, die dann beim Einsatz sog. "Diskcleaners" vorzeitig gelöscht werden.
Vorwarnung:
Meldung "Fehler beim Speichern", "Write Error"
Abhilfe:
Vorübergehend Speichern in Microsoft-Format, z.B. als ".doc" oder Kopieren und Einfügen in ein anderes Dokument (mit Formatverlust).
Risikobereich:
Einsatz unterschiedlicher Diskcleaner-Software, z.B.: IE Privacy Keeper, CCleaner, McAfee Security centre
Erfahrungsberichte:
http://www.oooforum.org/forum/viewtopic ... highlight= (englisch)
Bugreport:
http://www.openoffice.org/issues/show_bug.cgi?id=63875 (englisch)
Vorbeugung:
Abschaltung der Diskcleaner-Software (zumindest während den OOo-Arbeiten).
Behebung:
Im Bugreport wird eine Behebung im nächsten Release 2.4 angekündigt.
------------------------------------------------------------------------------------------------------------------------

Für ein verlustfreies Arbeiten mit OpenOffice ist eine Vorkenntnis aller bekannten Absturzmechanismen und deren Vorbeugung vorteilhaft.

Ja, aber wieviele wären das?

Folgende Übersicht dokumentiert die möglichen Methoden zur Optimierung der Zuverlässigkeit im OOo-Bereich.

Naja, wie wäre es denn mit "zwei mögliche" statt "die möglichen"?



Also ich mußte über diesen Post wirklich schmunzeln, so mir nicht ganz einleuchtet was er bezweckt. Klar was da steht ist wohl so, aber es gibt doch weitaus mehr bekannte Fehler, so das ich nicht so recht sehe wo der Vorteil liegt zwei davon in dieser Form zu dokumentieren.

Falls Du aber Weitere dokumentieren willst, mit dem Anspruch auf einigermaßen Vollständigkeit und Aktualität, würde ich Dir das Wiki (http://www.ooowiki.de) empfehlen, denn dort stehen sie den Interessierten langfristig zur Verfügung. Hier im Forum stehen sie höchstens einige Tage im Interesse.

Du kannst mich auch bei Bedarf hier über das Forum anschreiben, ich stelle gerne einen Kontakt zum Wikibetreiber her falls Du die Absicht hättest so vorzugehen. Sicherlich wäre Martin (der Wiki-Betreiber) erfreut wenn Du eine solche Übersicht ins Wiki stellst und sie langfristig pflegst, denn ohne Frage wäre das für die englischunkundigen Nutzer von OOo eine Hilfe.


Aber ich habe so oder so nichts einzuwenden, ich wollte nur darauf aufmerksam machen das das Forum hier für solche Dinge, die eher langfristig verfügbar sein sollen, rein vom Technischen her nicht unbedingt der geeigneste Ort ist.



Gruß
Stephan

Stephan hat geschrieben:

Also ich mußte über diesen Post wirklich schmunzeln, so mir nicht ganz einleuchtet was er bezweckt.

Hallo Stephan,

Die Übersicht soll der OOo-Gemeinde die Mechanismen der Abstürzen erklären. Abstürze mit Datenverlust sind Hauptgründe für die Verzweiflung, die Anwender in den Foren immer wieder beschreiben. Dabei kann man diese Datenverluste und Abstürze durch Schulung und vernünftiger Rechnerkonfiguration mit wenigen Handgriffen abstellen.

Selbstverständlich ist eine solche Übersicht erst ein Anfang. Mir ist auch klar dass es noch weitere Fehler mit Datenverlust gibt, aber es gibt nicht allzuviele Abstürze oder Datenverluste, die wirklich reproduzierbar sind. Falls Du weitere Beispiele kennst, dann gehören die selbstverständlich dazu.

Viele Leute suchen Hinweise nicht in den Wikis, aber sehr wohl in den Foren.

Einige Fehler werden bereits nach kurzer Zeit behoben und deren Dokumentation ist daher genau so kurzlebig wie die Releases. Im Forum kann man genau so schnell oder gar schneller etwas finden, wenn man einen Suchbegriff eingibt. Bei den Wikis ist man darauf angewiesen, dass jemand sich zuvor schon um einen Eintrag gekümmert hat.

Ich greife aber Deinen Vorschlag auf und werde mal sehen, ob ich die Info in die Wiki-Pages übernehmen kann.

Grüsse -Hans-

Hallo Hans,

vielen Dank für Deine Hinweise. Hätten sie nicht im Forum gestanden, sondern im Wiki, hätte ich sie nie gesehen. Ich bin seit April 2006 komplett auf OO umgestiegen (vorher RagTime).

Eigentlich habe ich seitdem überwiegend (ziemlich lange) Texte aus dem Internet in OO-Writer Dokumente überführt ("copy" und "Einfügen>unformatierter Text"). Ich gehöre also zur "Risikogruppe". Nach Deinem Post komme ich mir vor wie der Patient, der seit über einem Jahr ein Medikament nimmt, das ihm gut hilft, dem aber nun der Beipackzettel in die Hände fällt. Schlimme Nebenwirkungen mit hoher Auftretenswahrschienlichkeit!

Bislang hatte ich nie das Problem. Das Ärgernis an aus HTML-Dateien kopiertem Text sind auch eher die viel zu vielen Absatzumbrüche, die ich aber dank "AutoFormat" gut in den Griff kriege. Allerdings gibts mitunter herunterladbare Txt-Dateien (vor allem im usenet), die schon mal 50 Seiten ohne "Punkt und Komma", also auch ohne Absätze enthalten.

Dazu habe ich zwei Fragen an den Fachmann (bin nämlich keiner):
1. Gibt es in OO-Writer auch eine Dokument-Obergrenze? RagTime hatte nämlich eine, die nicht dokumentiert war (nach ca 1000 Seiten formatierten Textes war endgültig Schluss). Mein bisher größtes .odt-Dokument hat inzwischen über 1700 Seiten formatierten Textes und speichert immer noch, wenn auch langsam, neue Kapitel.
2. Gibt es irgend eine DAU (dümmester anzunehmender User)-geeignete Möglichkeit, die Größe eines Absatzes einzuschätzen? Du hast da was angeregt, das aber mein intellektuelles Umsetzungsvermögen deutlich übersteigt. Ich gehe mal davon aus, dass die 64K Obergrenze sich auf das offene Dokument bezieht und nicht auf das als .odt gespeicherte. Wie kriege ich mit wie viel Speicher im unkomprimierten Zusand verbraucht werden?
Grüße
Peter

Ich bin seit April 2006 komplett auf OO umgestiegen (vorher RagTime).

Dir ist aber schon klar das OOo (Textverarbeitung) kein Ersatz für Ragtime (DTP) ist.

Gibt es in OO-Writer auch eine Dokument-Obergrenze?

Mir ist nichts Wirkliches bekannt, ich glaube auch nicht das eine solche Angabe, die ja rein theoretisch wäre, sinnvoll ist, weil ja bei entsprechend großen Dokumenten zusätzliche Faktoren Einfluß gewinnen dürften, so das ich selbst wenn es eine solche Angabe gäbe das Ganze mit einem Bildtext (der in etwa die benötigten Inhalte enthält) austesten würde. Das ist allenfalls eine halbe Stunde Arbeit und lohnt sich sicher.
In jedem Falle 'kann' OOo mehr Seiten als jemals sinnvoll benötigt werden, denn man wird ja wohl kaum auf die Idee verfallen mehrere tausend Seiten in einem Dokument zu verwalten, da das ja in jedem Fall Geschwindigkeitsnachteile bringt, für deren Tragen es keinerlei Grund gibt.

Gibt es irgend eine DAU (dümmester anzunehmender User)-geeignete Möglichkeit, die Größe eines Absatzes einzuschätzen? Du hast da was angeregt, das aber mein intellektuelles Umsetzungsvermögen deutlich übersteigt. Ich gehe mal davon aus, dass die 64K Obergrenze sich auf das offene Dokument bezieht und nicht auf das als .odt gespeicherte. Wie kriege ich mit wie viel Speicher im unkomprimierten Zusand verbraucht werden?

Du verstehst das scheinbar falsch. Die Obergrenze von 64K bezieht sich ganz einfach auf die Anzahl der möglichen Zeichen eines Absatzes, der darf also etwa 65500 Zeichen (inklusiv Leerzeichen etc.) maximal enthalten, was ja leicht abzuschätzen sein dürfte, oder auch (in den neueren OOo-Versionen) zu zählen indem Du den Absatz markierst und Extras-Wörter zählen verwendest. Sehr grob sind das bei 'üblichen' Seiten- und Schrifteinstellungen etwa 13-15 Din A4 Seiten.



Gruß
Stephan

Dir ist aber schon klar das OOo (Textverarbeitung) kein Ersatz für Ragtime (DTP) ist.

Schon klar, nur habe ich in 13 Jahren Rag Time diese Funktionen und Fähigkeiten ganz selten genutzt, seit die gebeamte Präsentation die liebevoll gestaltete Tischvorlage komplett abgelöst hat, eigentlich gar nicht mehr. Und für den unwahrscheinlichen Fall, dass es doch noch mal nötig wird, habe ich Rag Time natürlich nicht von der Platte geputzt.

Rag Time ist in der Gestaltung absolut flexibel aber dafür auch arbeitsaufwändig und extrem teuer - für das update auf die neue Version 6 sollte ich knapp 300 € bezahlen - Gott sei Dank hatte ich vorher OO kennen gelernt.

Was ich wirklich vermisse und schon oft beschrieben habe (zum Leidwesen der Fachleute hier im Forum) ist der gelungene PDF-Export. Hier ist Rag Time, ich glaube durch seinen Verzicht auf eine eigene PDF-Engine und durch clevere Integration des Adobe Destillers (oder in der neuesten Version auch von Ghostscript), haushoch überlegen. In Rag Time habe ich immer alle langen Werke (abgeschlossene Fortsetzungsgeschichten aus dem Internet) nach PDF konvertiert, vor allem um Speicherplatz zu sparen. Das ist bei OO nicht nötig, da die .odt-Dateien noch viel kleiner sind. Ansonsten hatte ich noch keine Anforderung, die OO nicht blendend gemeistert hätte. Zwei Funktionen liebe ich besonders: "AutoFormat" und "Unformatierten Text einfügen". Ich kann zwar nicht sagen, dass ich die in Rag Time vermisst habe; möglicher weise gab's die ja dort sogar in den Teifen der Menues und Funktionen, nur in OO sind sie mir sofort aufgefallen.

So, das hatte jetzt nicht mehr wirklich mit dem Thema des Threads zu tun, ich bitte um Nachsicht.

Grüße
Peter

nur habe ich in 13 Jahren Rag Time diese Funktionen und Fähigkeiten ganz selten genutzt

weiß ich nicht wie das geht, wenn Du Ragtime nutzt nutzt Du DTP , ich habe zwar zugegeben seit 3 Jahren nichts mehr mit Ragtime gemacht, kann mir aber nicht denken das es zur Textverarbeitung mutiert wäre. Naja, ein bißchen 'halb und halb' war Ragtime ja zugegeben immer.

Was ich wirklich vermisse und schon oft beschrieben habe (zum Leidwesen der Fachleute hier im Forum) ist der gelungene PDF-Export.

Du meinst in OOo?

Hier ist Rag Time, ich glaube durch seinen Verzicht auf eine eigene PDF-Engine und durch clevere Integration des Adobe Destillers (oder in der neuesten Version auch von Ghostscript), haushoch überlegen.

Ich weiß garnicht mehr was Ragtime verwendet, aber haushoch kann im Vergleich zu OOo so nicht ganz stimmen. Du sprichst ja selbst von Ghostscript und ich weiß das Ghostscript bei den Tests der C't im Vergleich mit dem Acrobat Distiller ziemlich gut abgeschnitten hat. "Ziemlich gut abgeschnitten" ist natürlich nicht gleichgut, aber in jedem Fall recht nahe dran und einer großen Anzahl kommerzieller Produkte überlegen.

Die Fähigkeiten von Ghostscript stehen in OOo aber schon seit langer Zeit mittels der Extension "ExtendedPDF" perfekt integrierbar zur Verfügung.
siehe:
http://www.3bview.com/epdf-home.html

Den Acrobat Distiller zu integrieren, dürfte wohl einzig daran scheitern das niemand so recht Interesse hat ein Makro dafür zu schreiben, meines Erachtens deshalb weil die dafür interessierte Anwenderschaft als eher gering eingeschätzt wird. Abgesehen davon das mich das Thema persönlich nicht so sehr interessiert, habe ich auch keinen modernen Acrobat so das ich mich mal dran versuchen könnte. Ich habe hier einen Acrobat 5 der mir für alles was ich brauche bisher ausreicht und mir eine neue Version zu kaufen lohnt sich so nicht wirklich.



Gruß
Stephan

Peter Funken hat geschrieben:
Dazu habe ich zwei Fragen an den Fachmann (bin nämlich keiner):
1. Gibt es in OO-Writer auch eine Dokument-Obergrenze? RagTime hatte nämlich eine, die nicht dokumentiert war (nach ca 1000 Seiten formatierten Textes war endgültig Schluss). Mein bisher größtes .odt-Dokument hat inzwischen über 1700 Seiten formatierten Textes und speichert immer noch, wenn auch langsam, neue Kapitel.
2. Gibt es irgend eine DAU (dümmester anzunehmender User)-geeignete Möglichkeit, die Größe eines Absatzes einzuschätzen? Du hast da was angeregt, das aber mein intellektuelles Umsetzungsvermögen deutlich übersteigt. Ich gehe mal davon aus, dass die 64K Obergrenze sich auf das offene Dokument bezieht und nicht auf das als .odt gespeicherte. Wie kriege ich mit wie viel Speicher im unkomprimierten Zusand verbraucht werden?
Grüße
Peter

Hallo Peter,

1. Ich glaube, dass eine Obergrenze eher von der Hardware begrenzt wird, z.B. weil der PC zu langsam wird. OOo kann theoretisch in einem Masterdokument sehr grosse Teildokumente verwalten.

2. Leider ist die Abschätzung der 64K Obergrenze nicht einfach.
Ich wollte ein Macro schreiben, habe aber zur Zeit "keine Zeit".
Es handelt sich dabei immer auf die Situation des ungespeicherten Dokuments, denn OOo schneidet den Anteil oberhalb 65534 Zeichen (nachtr. Korrektur: nicht Bytes) einfach ab. Dummerweise ist ein Character nicht einfach 1 Byte. Unicode erlaubt auch die Speicherung von 2 bis sogar 3 Bytes / Charakter. Das Macro sollte auch Unicode berücksichtigen. Falls Du nur die Buchstabenzahl zur Verfügung hast, dann für die Schätzung sicherheitshalber 2 Bytes / Charakter ansetzen.
Eigentlich sollte das Prüfverfahen bereits vor dem Einfügen feststellen, ob der Text an der Einfügungsstelle Probleme bereitet. Man kann aber ein Macro schlecht auf den Copy/Paste-Puffer anwenden.

Natürlich sollte der 64 kZeichen-Fehler (bzw. der "Mangel") behoben werden,
aber das dauert m.E. bestimmt noch 2 Jahre.
Ich habe deshalb eine empfohlene sichere Arbeitsweise entworfen und im englischsprachigen Forum dokumentiert.
http://www.oooforum.org/forum/viewtopic ... highlight=

Zusammenfassung:
Oberstes Gebot ist: Absätze mit mehr als 64 kByte Umfang zu jeder Zeit vermeiden.

1. Unterhalb 65534 Zeichen (nachtr. Korrektur: nicht Bytes) Text gibt es keine Probleme (d.h. 4-5 Seiten Text)
2. In größeren Texten sollte man regelmäßig die maximale Absatzlänge (mit einem noch zu erstellenden Macro) überprüfen. Diese sollte 20-24 kZeichen nicht überschreiten, da beim Editieren zwei Paragraphen (ggf. auch vorübergehend) verschmolzen werden könnten.
3. Bei Copy/Paste aus dem Internet o.ä. empfehle ich diese zuerst in ein neues OOo-Dokument zu importieren (nicht mit Copy/Paste, aber mit "Import"). Dann wird das Importmodul in OOo bei Bedarf Absatzmarken nach jeweils 65534 Zeichen (nicht Bytes) einfügen. Das ist aber gefährlich, da beim nachfolgenden Editieren zwei Paragraphen (ggf. auch vorübergehend) verschmolzen werden könnten. Dieses neue Dokument muss nun mit Absatzmarken so ausgestattet werden, dass die maximale Absatzlänge deutlich unterhalb 20-24 kZeichen bleibt. Dabei zunächst nur Absatzmarken hinzufügen, d.h. keine Absatzmarken entfernen oder Text hinzufügen.
4. Falls man nur einzelne Seiten aus dem Web kopiert, ist die Gefahr geringer. Auch dann sollte man mit dem Macro immer wieder die maximale Absatzlänge überwachen und sofort Absatzmarken einfügen.

Grüsse -Hans-

Leider ist die Abschätzung der 64K Obergrenze nicht einfach. [...]

Dann stelle doch bitte ein einfaches HTML-Dokument zur Verfügung, was einen Absatz mit weniger als 65536 Zeichen enthält, welcher sich beim Kopieren in OOo so verhält wie beschrieben.

Alle Beispieldokumente in den issues und deren 'Umfeld' habe ich durchgesehen, alle Dokumente welche ich finden konnte zeigen das Problem nur anhand der Grenze von 65535 Zeichen auf, welche ich momentan beim Kopieren (und darum ging es wenn ich Deine Ausführungen richtig verstehe) für die relevante Grenze halte.



Gruß
Stephan

Stephan hat geschrieben:

Leider ist die Abschätzung der 64K Obergrenze nicht einfach. [...]

Dann stelle doch bitte ein einfaches HTML-Dokument zur Verfügung, was einen Absatz mit weniger als 65536 Zeichen enthält, welcher sich beim Kopieren in OOo so verhält wie beschrieben.

Alle Beispieldokumente in den issues und deren 'Umfeld' habe ich durchgesehen, alle Dokumente welche ich finden konnte zeigen das Problem nur anhand der Grenze von 65535 Zeichen auf, welche ich momentan beim Kopieren (und darum ging es wenn ich Deine Ausführungen richtig verstehe) für die relevante Grenze halte.

Gruß
Stephan

Hallo Stephan,

Vielen Dank für Deinen Hinweis. Dieser bringt neue Details ans Tageslicht.

Habe mal mit dem Writer experimentiert und zum Testen einen Text gebastelt mit genau 65535 Zeichen.
Der Text enthält einen verketteten String 1234567890, der ständig wiederholt wird. Das ergibt in OOo ein Einzelwort mit exakt 65535 Zeichen.

Dann habe ich im gesamten Dokument die Ziffer 1 ersetzt durch einen russischen Buchstaben (Д) und 13 andere Ziffern durch einen arabischen Buchstaben ersetzt (ﮠ). Am Ende des Textes schreibe ich das Wort "ENDE", so dass die Zahl der Zeichen genau 65535 Zeichen bleibt.

Obwohl es sich um Unicode handelt, treten keine Probleme auf.
Das arabische Zeichen fügt jedoch aufomatisch ein Wortende ein.
Fügt man am Anfang Text ein, wird es am Ende abgeschnitten. Die Zahl der Buchstaben bleibt konstant 65535. Editiert man am Ende unvorsichtig, stürzt Writer ab, aber das Dokument läßt sich wieder herstellen.

Fazit: Obwohl Unicode verwendet wird, verwaltet Writer immer genau 65535 Zeichen. Dein Hinweis auf die relevante Grenze ist korrekt.
Das OOo-Problem sollte deshalb nicht "65535 Bytes Obergrenze", sondern eher "65535 Zeichen Obergrenze" genannt werden.

-> Die Abschätzung der 64K Obergrenze ist einfacher möglich. Man muss nur noch die Zeichenzahl ermitteln.

Trotzdem bleibe ich bei meinen Empfehlungen, die Absätzlänge immer weit unterhalb dieser Grenze zu belassen, denn wenn man zwei aufeinander folgenden 64k-Absätze editiert, kann es leicht zum Datenverlust oder Absturz kommen.

Schöne Grüsse -Hans-