Re: [de-users] Writer hängt ein paar Sekunden nach dem Speichern - 5.2.6.2 Win7 64bit

Hallo Matthias,

bitte meine vorherige Mail ( OoOHWHOoO, Sat Jun 03 20:24:47 GMT 2017 ) 
ignorieren, da ist mir leider bei den Punkten [3] und [4] zu abendlicher 
Stunde "bissel was" durcheinandergeraten - SORRY :-o ...

Hier die KORRIGIERTE Version:

Der "Verarbeitungsaufwand" für LO (LibreOffice) beim Speichern eines 
WRITER-Dokuments (~.odt) ist weitestgehend identisch, egal, ob die 
Bilder DIREKT oder via VERKNÜPFUNG eingefügt wurden. Damit diese Aussage 
nachvollziehbar und verstehbar ist - und auch meine Antworten auf Deine 
Fragen (s.u. [5]) - muss ich (leider) etwas weiter ausholen:

1. Ein WRITER-Dokument (= WRITER-Datei) ist ein ZIP-Archiv, welches man 
entpacken kann. Dieses Archiv enthält Dateien und Verzeichnisse.

1.1 Verzeichnisse ( Configurations2 | META-INF | (Pictures) | Thumbnails 
)
1.2 Dateien ( content.xml | layout-cache | manifest.rdf | meta.xml | 
mimetype | settings.xml | styles.xml )

2 Für die weiteren Erläuterungen sind nur 2 Verzeichnisse und eine Datei 
interessant.

2.1 Pictures
2.1.1 Enthält die Bilder, wenn diese in das WRITER-Dokument DIREKT 
eingefügt wurden. Und nur dann wird dieses Verzeichnis auch angelegt.

2.2 Thumbnails
2.2.1 Enthält nur die erste Seite des WRITER-Dokuments als Bild. Wenn 
man im EXPLORER eine WRITER-Datei anklickt, sieht man links unten dieses 
Bild der ersten Seite.

2.3 content.xml
2.3.1 Hier ist mit XML-Anweisungen das WRITER-Dokument abgebildet. LO 
interpretiert diese XML-Anweisungen und erstellt daraus das, was der 
Benutzer auf dem Bildschirm sieht.
2.3.2 xml-Zeile
2.3.2.1 Beginnt mit "<" und endet mit "/>".
2.3.2.1 Beispiel: <text:p text:style-name="P1"/>
2.3.3 xml-Abschnitt
2.3.3.1 Beginnt mit <schlüsselwort> und endet mit </schlüsselwort>
2.3.3.2 Beispiel: <office:body> und </office:body>

3 Zwei Leerzeilen und "zwei Bilder DIREKT" in das WRITER-Dokument 
eingefügt.

3.1 Pictures
3.1.1 Dieses Verzeichnis wird (neu) angelegt und enthält die DIREKT 
eingefügten Bilder.

3.2 Thumbnails
3.2.1 In diesem Verzeichnis ist genau ein Bild - das Bild der ersten 
Seite.

3.3 content.xml

3.3.1 Hinweise
3.3.1.1 "~~~" - Von mir eingefügt mit der Bedeutung, dass das da noch 
etwas steht, ich es aber weggelassen habe, da sonst das Ganze zu 
unübersichtlich würde.
3.3.1.2 "|" - Von mir eingefügt zur besseren Darstellung der einzelnen 
XML-Abschnitte.

3.3.2 Auf das Wesentliche reduzierte "content.xml"

~~~
<office:document-content ~~~ >
| ~~~
| <office:body>
| | <office:text>
| | | <text:sequence-decls>
| | | ~~~
| | | </text:sequence-decls>
| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild1" ~~~ >
| | | | | <draw:image ~~~ 
xlink:href="Pictures/10000000000002C5000002C5887E723DABCCD504.jpg"/>
| | | | </draw:frame>
| | | </text:p>
| | | <text:p text:style-name="P1"/>
| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild2" ~~~ >
| | | | | <draw:image ~~~ 
xlink:href="Pictures/10000000000002C5000002C5D5C8CF25151250C9.jpg"/>
| | | | </draw:frame>
| | | </text:p>
| | | <text:p text:style-name="P1"/>
| | </office:text>
| </office:body>
</office:document-content>

3.3.2.1 XML-Anweisung für eine Leerzeile

| | | <text:p text:style-name="P1"/>

3.3.2.2 XML-Anweisungen für ein DIREKT eingefügtes Bild

| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild1" ~~~ >
| | | | | <draw:image ~~~ 
xlink:href="Pictures/10000000000002C5000002C5887E723DABCCD504.jpg"/>
| | | | </draw:frame>
| | | </text:p>

Das Bild "10000000000002C5000002C5887E723DABCCD504.jpg" befindet sich im 
Verzeichnis "Pictures" des ZIP-Archivs der WRITER-Datei.

4 Zwei Leerzeilen und "zwei Bilder via VERKNÜPFUNG" in das 
WRITER-Dokument eingefügt

4.1 Pictures
4.1.1 Dieses Verzeichnis wird NICHT angelegt.

4.2 Thumbnails
4.2.1 In diesem Verzeichnis ist genau ein Bild - das Bild der ersten 
Seite.

4.3 content.xml

4.3.1 Hinweise
4.3.1.1 "~~~" - Von mir eingefügt mit der Bedeutung, dass das da noch 
etwas steht, ich es aber weggelassen habe, da sonst das Ganze zu 
unübersichtlich würde.
4.3.1.2 "|" - Von mir eingefügt zur besseren Darstellung der einzelnen 
XML-Abschnitte.

4.3.2 Auf das Wesentliche reduzierte "content.xml"

~~~
<office:document-content ~~~ >
| ~~~
| <office:body>
| | <office:text>
| | | <text:sequence-decls>
| | | | ~~~
| | | </text:sequence-decls>
| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild1" ~~~ >
| | | | | <draw:image ~~~ xlink:href="file:///D:/BILDER/BILD_1.jpg"/>
| | | | </draw:frame>
| | | </text:p>
| | | <text:p text:style-name="P1"/>
| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild2" ~~~ >
| | | | | <draw:image ~~~ xlink:href="file:///D:/BILDER/BILD_2.jpg"/>
| | | | </draw:frame>
| | | </text:p>
| | | <text:p text:style-name="P1"/>
| | </office:text>
| </office:body>
</office:document-content>

4.3.2.1 XML-Anweisung für eine Leerzeile

| | | <text:p text:style-name="P1"/>

4.3.2.2 XML-Anweisungen für ein via VERKNÜPFUNG eingefügtes Bild

| | | <text:p text:style-name="P1">
| | | | <draw:frame draw:name="Bild1" ~~~ >
| | | | | <draw:image ~~~ xlink:href="file:///D:/BILDER/BILD_1.jpg"/>
| | | | </draw:frame>
| | | </text:p>

Das Bild "BILD_1.jpg" befindet sich im Verzeichnis "BILDER" auf der 
Partition "D:".

5 Zu Deinen Fragen

"[...] Eigentlich sollte es dann keinerlei bemerkbare Verzögerung nach 
dem Speichern-Fortschrittsbalken geben - so wie ich Dich verstand. Nur 
woher kommt dann bei meinem
Text diese Verzögerung ? [..]"

Da hatte ich mich wohl missverständlich ausgedrückt oder Du hast hattest 
mich vielleicht falsch verstanden - oder eben beides. Siehe oben [1] bis 
[4]. Es ist egal, ob die Bilder via VERKNÜPFUNG oder DIREKT eingefügt 
werden, der "Verarbeitungsaufwand" für LO beim Speichern eines 
WRITER-Dokuments ist weitestgehend identisch: jeweils 5 XML-Zeilen !

"[...] Werden jedesmal Thumbnails noch erzeugt und dies dauert halt? 
Falls es so sein sollte - warum nur ? An den Bildern selbst hat sich ja 
nichts verändert. [...]"

Nein, in dem Verzeichnis "Thumbnails" ist nur 1 Bild - das Bild der 
ersten Seite des WRITER-Dokuments. Siehe oben [2.2]. Das ist für LO 
sicherlich kein erhöhter Verarbeitungsaufwand.

"[...] Einen zweiten Fortschrittsbalken habe ich bisher nicht bewusst 
wahrgenommen. Gibt es denn einen solchen ? [...]"

Beim Öffnen eines (sehr) großen WRITER-Dokuments sieht man nacheinander 
2 Fortschrittsbalken. Der erste "läuft" über die gesamte Breite des 
LO-Fensters, der zweite nur zirka über 1/5 der LO-Fensterbreite. Das ist 
nur eine spekulative Annahme meinerseits gewesen, dass es beim Speichern 
eines WRITER-Dokuments auch zwei solche Fortschrittsbalken (in der 
4er-Version) gegeben haben könnte. Der "Fortschrittsbalken" ist 
lediglich ein Hinweis für den Benutzer "Bitte warten, bin beschäftigt !" 
und hat die Funktion, dass der Benutzer nicht verunsichert wird, weil er 
(eine Zeit lang) nicht mit LO interagieren kann. Bei meiner 600 MB 
TEST-Datei mit 1401 Tabellen, 2732 Bildern und 102146 Zeichen hat die 
"content.xml" eine Größe von ≈ 4.2 MB und beinhaltet 83728 XML-Zeilen, 
die LO beim Speichern ver-/abarbeiten muss - das benötigt nun mal eine 
gewisse Zeit.

"[...] Solange ich nicht weiß was LO da macht in dieser Zeit - so lange 
ist da ein ungutes Gefühl im Vergleich zur 4er Version wo ich das so 
nicht erlebte. [...] Falls es so sein sollte so wäre wichtig zu wissen 
warum es langsamer wurde und was der Nutzen dieser Wartezeit für den 
Anwender ist. [...]"

Ich glaube nicht wirklich, dass LO ab der 5er-Version ein 
Verarbeitungsproblem hat oder bei dieser Verarbeitung langsamer wurde. 
Ich meine, der Fortschrittsbalken wird ab der 5er-Version einfach zu 
früh ausgeblendet (oder ein zweiter nicht eingeblendet) und deshalb 
entsteht bei dem Benutzer diese Irritation. Würde der Fortschrittsbalken 
die ganze Zeit über, so wie bei der 4er-Version, angezeigt, gäbe es 
diese Irritation und Vermutung, dass LO ab der 5er-Version langsamer 
wurde, wohl eher nicht.

In https://bugs.documentfoundation.org/show_bug.cgi?id=98731 geht es 
auch nicht um ein Verarbeitungs-/Zeitproblem, sondern vielmehr darum, 
warum die "progress bar" (Fortschrittsbalken) zu früh verschwindet 
und/oder nicht wieder erscheint "... just wait until the period when 
there is no progress bar updating ...":

Michael Meeks 2017-05-26 21:26:27 UTC
Oh - sure =) it's pretty easy I think; just wait until the period when 
there is no progress bar updating, stop the app in the debugger and see 
what the stack frames look like =) it is exactly those stack frames that 
are not doing the right thing. Resume execution for a second, pause and 
take another stack trace etc. Thanks!
https://bugs.documentfoundation.org/show_bug.cgi?id=98731

Ich denke, Du kannst ganz beruhigt weiter mit LO der 5er-Version 
arbeiten. Ich arbeite mit "5.2.7.2 (x64)" und habe bisher keinerlei 
besorgniserregende Auffälligkeiten feststellen können, zumal ja auch das 
"progress bar"-Problem in Bearbeitung ist (s.o.).

Da kann man sich wirklich auf den Versions-Hinweis ( 
https://de.libreoffice.org/download/release-notes/ ) verlassen: 
"Zielgruppen: Die Version 5.2.7 ist prinzipiell für alle 
LibreOffice-Anwender gut geeignet. Insbesondere wenn Sie einen hohen 
Wert auf die Stabilität von LibreOffice legen und die neuen Funktionen 
der Entwicklungsreihe 5.3 nicht unbedingt benötigen, ist dies die 
richtige Wahl."

Gruß
Hans-Werner
--
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: http://listarchives.libreoffice.org/de/users/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert