Re: [de-users] Re: A: [de-users] Ladezeiten – "Update all", "content.xml"

html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial, helvetica, 
sans-serif;;}
Hallo IB, wer bist Du? oder auch Hallo an die Community, den Nutzerkreis


Frage 1) "Update all" ist in der englischen Version unter "Tools-Update", in der deutschen finde 
ich das unter "Extras - Aktualisieren" dann "Alles", was eigentlich fast gut übersetzt ist. Habe 
extra für die Beantwortung dieser Frage mein LO mal auf deutsch umgestellt.


Frage2) Die Antwort ist nicht kurz, vielleicht interessant:


Das content.xml ist nicht sooo kompliziert das man es nicht mit irgendeinem Programm selbst 
generieren kann, und es sogar funktioniert. Ich habe mit solchen Dingen in 2004..5 mit Winword.docx 
angefangen, habe gesehen, ah geht, ohne eine lange Doku durchstudieren zu müssen, einfach Struktur 
anschauen, probieren, überlegen warum und die funktionalen Dinge dahinter erkennen. Natürlich kann 
man auf diese Weise nicht sofort alles was möglich ist. Aber für normale Texte, Formatvorlagen 
(indirekt ist besser), spezielle Dinge wie Seiten und Spaltenumbrüche, Bilder und links, das ist 
eigentlich (für mich) ziemlich schlüssig im XML. Ich programmiere das in Java (sehr zuverlässige 
Programmiersprache) und habe mittlerweile meine eigenen Treiber dafür. Die haben sich auch schon 
für komplexe Dinge wie XML im TIA-Portal bewährt (das ist die Simatic-Entwicklungsumgebung).


Bei LibreOffice habe ich mich rangesetzt weil ich 5 min Bearbeitungszeit bei "update all" hatte, 
und ich schauen wollte was da innen drinnen los ist. Ergebnis 
isthttps://vishia.org/LibreOffc/html/Videos_LOffcZmL.htmlauf meiner Webseite. Der dort gespeicherte 
Stand ist nicht der letzte den ich selbst verwende, habe aber derzeit keine Zeit das dort zu 
pflegen.


Ganz so einfach ist das alles aber nicht. Habe da schon Wochen drangesetzt.


Interessant ist es ggf. allgemein, LibreOffice Files von außen zu erzeugen und zu lesen, ohne LO 
selbst. Wichtig dafür ist, dass das XML-Format standardisiert ist, und das ist es.


LibreOffice draw Files lesen und Grafiken in C-Code umsetzen mache ich 
mit:https://vishia.org/fbg/html/Videos_OFB_VishiaDiagrams.htmlDas ist das eigentlich wichtigere 
Hobby derzeit bei mir.


Grüße von Hartmut




Rest@MB-MC.ch schrieb am 18.06.2025 16:56 (GMT +02:00):
Guten Tag,


> Ich habe noch eine andere Erfahrung: Ein Dokument.odt mit ca. nur 100 Seiten
> hat immer länger 
> gebraucht bei "Update all" Minuten! Das lag an einer komplex in der Zeit
> gewachsenen Struktur 
> von (unnötigen) direkten Styles im content.xml. Ich habe im XML-File
> aufgeräumt, generiere den 
> immer mal neu. Seit dem dauert das bei nunmehr 135 Seiten nur wenige sekunden,
> wie es sein soll. 
> Manchmal gibt es da komplexe Ursachen, denen wir aber nachgehen müssen.
Es führt jetzt zwar vom eigentlichen Thema weg, aber ich habe dazu trotzdem zwei
kurze Fragen:
1. Wo gibt es dieses "Update all"?
2. Wie kann man diese "content.xml" einfach neu generieren?
Danke im Voeaus für die Antworten.


Gruß IB
-------
Am 17.06.25 um 22:52 schrieb 9876@vishia.de:
> html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial,
> helvetica, sans-serif;;}
> Hallo Michael
>
>
> Mit den vielen Dateien in der komplexen Ordnerstruktur, das möchte ich nur
> bestätigen. Ich vermute allerdings, dass nicht die wirkliche Prozessorarbeit
> die Zeit benötigt, sondern hier auch das Response im Filesystem, das geht halt
> durch mehrere Ebenen. Wenn ich meine Javadoc-Dokumentation auf meinen Webserver
> per Einzelfile übertrage, katastrophal lange. Daher zippe ich die files,
> schicke den zipfile rüber und rufe beim Server Unzip auf. Letzteres geht
> rasend schnell (Auspacken dieser vielen Files). D.h. auch hier ist Request und
> Response bei jedem File übers Internet der Zeitfresser, und nicht die
> Datenmenge an sich (das Zippen ist ca. die Hälfte der MByte, das ist es
> nicht). Und: viele Files schreiben auf dem Server selbst geht sehr schnell,
> Files schreiben über Netzwerkschnittstelle (dürfte auch bei lokaler
> Kommunikation, Samba, so sein) dauert oft viel länger.
>
>
> Also mein Hinweis ist: Das ist nicht die Datenmenge, sondern die Kommunikation
> die zum Hängen führt. Und das war auch die Hauptaussage im Thread, der hier
> fehlt, mit dem Kollegen mit dem Arabischen Zeichensatz. 
>
>
> Mein Wissen ist freilich auch nicht universal, aber wenn ich in den odt-zip
> reinschaue, dann ist das eine recht flache Struktur. Sind viele Bilder drin,
> dann sind das zwar viele Bilddateien, aber so viele nun auch nicht. Ich
> müsste, um genaue Aussagen zu treffen, Rechenzeitmessungen mit Beispielen
> machen. Habe aber dafür nicht die Zeit.
>
>
> Ich habe noch eine andere Erfahrung: Ein Dokument.odt mit ca. nur 100 Seiten
> hat immer länger gebraucht bei "Update all" Minuten! Das lag an einer komplex
> in der Zeit gewachsenen Struktur von (unnötigen) direkten Styles im
> content.xml. Ich habe im XML-File aufgeräumt, generiere den immer mal neu.
> Seit dem dauert das bei nunmehr 135 Seiten nur wenige sekunden, wie es sein
> soll. Manchmal gibt es da komplexe Ursachen, denen wir aber nachgehen müssen.


-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme?https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/Tipps zu 
Listenmails:https://wiki.documentfoundation.org/Netiquette/deListenarchiv:https://listarchives.libreoffice.org/de/users/Datenschutzerklärung:https://www.documentfoundation.org/privacy
-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy