Agon S. Buchholz wrote:

> Mathias Bauer wrote:
> 
>> Das hat sich als ein altbekanntes Problem entpuppt, das an anderer 
>> Stelle schon erkannt und gefixt wurde (in der 2.3). Dein Dokument 
>> scheint ja nun zu zeigen, dass es in der 2.3 noch immer Fälle gibt,
>> wo es auftritt. Mit dem von dir eingesandten Dokument sollten wir dem
>> auf die Spur kommen. Ich könnte auch eine Reparatur anbieten, sofern 
>> gewünscht. Sozusagen als Service für das Einsenden. :-)
> 
> Vielen Dank, aber wie halt meistens in solchen Fällen ist auch dieses
> Dokument zeitkritisch, daher habe ich den heutigen Tag über versucht,
> die veränderten Stellen aus content.xml mit Diff-Tools und nach
> Gedächtnis herauszufischen, diese in letzte funktionierende Version
> wieder einzubauen und dann an der Arbeit weitergeschrieben. Mit einer
> reparierten Fassung könnte ich jetzt noch prüfen, was ich dabei
> übersehen habe (was natürlich auch nicht schlecht wäre ;)

Es könnte allerdings sein, dass das reparierte Dokument später
irgendwann wieder Ausfallerscheinungen zeigt, wenn du nicht alles
"erwischt" hast.

> Etwas wichtiger wäre mir grundsätzlich, eine Handreichungzu bekommen,
> wie ich den Fehler ggf. selbst reparieren kann; beim Googeln habe ich da
> einige haarsträubende Fälle gefunden, beispielsweise solche, wo das
> Dokument kurz vor Abgabe einer Examensarbeit zerschrotet wurde, und das
> würde ich natürlich sehr gerne vermeiden. Alle Reparaturanleitungen, die
> ich bisher gefunden habe, beziehen sich jedoch auf einen leicht
> nachvollziehbaren Fall (wie die Ersetzung von "office" durch "of&ice" in
> [1]), oder versackten eben ergebnislos. Vielleicht gibt es eine solche
> generische Anleitung ja auch schon irgendwo, oder kann der Laie den
> Unicode-Krams in den XML-Dateien eher sowieso nicht reparieren?

Dein Problem ist ein sehr spezielles. Es entsteht dadurch, dass OOo beim
Kodieren von "_"-Zeichen gelegentlich auch Kodierungszeichen kodiert und
das dann natürlich kumulativ, bei jedem Speichern. Problematisch wird
das, weil irgendwann der String zu lang wird...

> Noch grundsätzlicher wäre mir *viel* wichtiger, dass das Laden und
> Speichern von OOo so stabil wie das von Microsoft Word wird, dass also
> beispielsweise ein Dokument mit kleinen Fehlern von OOo repariert werden
> kann, oder dass der Parser "intelligent" genug wird, das Format zu
> validieren und ggf. zu korrigieren oder wenigstens irgendwie
> "fehlertoleranter" zu handhaben. Ich finde es jedenfalls nicht besonders
> prickelnd, wenn das Laden eines OOo-Dokuments anscheinend wegen eines
> gekippten Bits oder Bytes komplett scheitern kann - denn das kann,
> selbst wenn OOo das Dokument nicht selbst beschädigt, immer mal
> passieren (fehlerhafter Datenträger, Bitkipper bei der Übertragung über
> Mail/Web/Internet etc.).

Fehlertolerantes Parsen von XML ist nun mal etwas, was eigentlich nicht
"vorgesehen" ist. Was man vielleicht erreichen könnte, ist, dass man
versucht, nach einem Fehler wieder aufzusetzen. Das ist aber nicht so
einfach.

Deshalb muss man eben schon beim Speichern aufpassen, dass nix falsches
geschrieben wird. Immerhin kann man mit einem vernünftigen Editor das
Dokument retten, wenn der Fehler "nur" im XML-Code liegt. Ein ähnlicher
Fehler in einer Binärdatei schrottet jedenfalls in der Regel die Datei
komplett und für den Anwender irreparabel.

Das Problem wird MSOffice mit seinen neuen Formaten auch haben. Und
gerade das Laden und Speichern von Word ist nun wirklich nicht für seine
Stabilität bekannt.

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Antwort per Email an