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
[email protected] 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 [email protected]:
> 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: [email protected]
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: [email protected]
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
