OpenOffice.info

Irgendwie ist eben alles schiefgegangen. Die zwei vorhergehenden Beiträge können bei Bedarf gelöscht werden um doppelte Posts zu vermeiden.
Aber zur Sache.

Da ich von 7-zip und WinRAR weiß, daß 'solid archiving' die
Kompressionsdichte deutlich verbessert, habe ich dieses Konzept mal auf ODF
angewandt. ODF ist ja nichts anderes als ein ZIP-Archiv mit XML-Dateien als
Inhalt. Auf einer Webseite, die ich leider nicht mehr finde, wird dargelegt
warum ZIP zum Einsatz kommt. Aussage der Seite: Es ist nicht mit teuren
Patenten belastet, packt relativ gut und sehr schnell. Außerdem erwartet
man von Officeformaten, daß es eine einzelne Datei ist und gut. Dann will
man noch die Dateigröße möglichst kleinhalten und Text läßt sich recht gut
packen. Plattformübergreifend verfügbar soll es sein. ZIP ermöglicht all das.

Testablauf
Von jedem Format eine leere Datei speichern. Unter Anderem auch um die
Nachvollziehbarkeit zu ermöglichen.
mittels WinRAR 3.71, dessen ZIP-Kompression ist ähnlich stark, wie die von
OpenOffice (Durch Versuch gefunden).

ODF entpacken
ohne Kompression in erstes ZIP-Archiv kopieren (Store)
mit max Kompression das unkomprimierte ZIP-Archiv packen (Best)
dabei kommen folgende Ergebnisse heraus


Draw
ODS 7161 Bytes
Solid ODS 4387 Bytes
gespart ca 38%

Impress
ODS 9206 Bytes
Solid ODS 6391 Bytes
gespart ca 30%

Calc
ODS 6396 Bytes
Solid ODS 3712 Bytes
gespart ca 42%

Writer
ODS 6888 Bytes
Solid ODS 4152 Bytes
gespart ca 40%

Daß es >zusätzlich< was bringt sieht man an der Ersparnis von ca 30-42%.
Je nachdem wie es in einer Datei mit realistischen Inhalten aussieht, wird
die Ersparnis in etwa in dem Bereich liegen. Je nach Inhalt auch darüber
oder darunter. Wenn zB Graphiken eingebunden sind, hilfts weniger. Ohne
Graphik (Ja, solls geben) könnens viel mehr als die hier ermittelten 40%
sein.

Kleine Dateien sagst du. Größere Dateien sind oft kompressibler als kleine. Das untermauert höchstens meine Ausführungen. Das hängt zwar schon vom Inhalt ab, aber grundsätzlich triffts auf Text/XML zu (Die Graphik im ODF, d.h. GIF,PNG,JPG... ist schon gepackt). Das ist ja gerade der Vorteil von 'solid archiving'. Es faßt viele kleine Dateien zu einer großen zusammen. Das Wörterbuch des ZIP-Algorithmus wird noch besser genutzt, was die Kompression erhöht. Mehr dazu auf Wikipedia unter LZ77.

Hinweis
Alle Versionen von WinRAR seit 2.9 liefern untereinander identische
Ergebnisse für jeweils RAR oder ZIP

Wenn man nicht wollte, daß die Dateigröße kleingehalten wird, könnte man eine
Version von TAR benutzen. Kommt unter Linux für TAR/GZ zum Einsatz. Ist
nichts anderes als eine Form von 'solid archiving'. TAR faßt die Dateien/Verzeichnisse in einer Datei zusammen und GZIP komprimiert diese dann. Genau das habe ich hier einmal ausprobiert, nur daß ausschließlich ZIP zur Verwendung kommen sollte. Und siehe da, es funktioniert wie erwartet.

Es sollte jeder die Möglichkeit haben, sich für mehr Geschwindigkeit oder für
mehr Kompression zu entscheiden. Es würde keinesfalls doppelt so lang dauern.
Im ersten Schritt wird ja nur kopiert ohne viel Rechenzeit nötig zu haben.
Erst im zweiten Schritt wird wie bisher auch gewissenhaft komprimiert.
Die zusätzliche Zeit für den ersten Schritt ist daher wirklich nicht so viel.
Im Gegenzug erhält man kleinere Dateien.

Ich will hier nur aufzeigen, wie mit vorhandenen Mitteln noch mehr aus dem
Dateiformat zu holen ist.

Gut, und wer von den Anwendern von OOO, bzw. Forumsteilnehmern soll das umsetzen ??

Einsenden einer Fehlermeldung oder eines Verbesserungsvorschlags

Gruß
lorbass

Hallo wingleader,

Es sollte jeder die Möglichkeit haben, sich für mehr Geschwindigkeit oder für mehr Kompression zu entscheiden.

Selbst wenn man es sich auswählen könnte, so frag ich mich, wozu das ganze?

Dateigröße soll ja wohl in der heutigen Zeit kein Thema mehr sein, bei den geringen Preisen pro Megabyte für ne Festplatte. Selbst die mobilen Datenträger kosten ja auch nicht mehr die Welt.

Mit Geschwindigkeit meinst Du jetzt wohl nur den reinen Kompremierungsvorgang, oder?
Also das seh ich auch nicht so als frapierend an, da er ja nicht der Hauptfaktor beim Öffnen, beziehungsweise beim Speichern einer Datei ist. Es kommt meiner Meinung mehr darauf an, wie die Datei aufgebaut ist, und was für einen Inhalt und welche Funktion sie hat.
Wie es sich z.B. bei einer Writer Datei verhält, kann ich nicht sagen, aber zu einer Calc Datei kann ich mich äußern.

Eine aktuelle Calc Datei von mir hat momentan eine Größe von ca. 468 KB. Sie braucht auf meinem Rechenknecht ca. 105 Sekunden bis sie vollständig geladen (geöffnet) ist. Sie beinhaltet keine Grafiken, oder Bilder, also nur Formeln. Entpackt ist sie ca. 26.820 KB (ca.26 MB) groß. Das (de)komprimieren dauert ca. 2 Sekunden.
So nebenbei bemerkt ist das ein Komprimierungsfaktor von ca. 98%.

Selbst wenn die Komprimierungszeit noch schneller geht, so wird dadurch die Datei nicht bedeutend schneller geladen (was sind schon 2 Sekunden mehr oder weniger?). Denn dazu sind einfach zu viele Formeln vorhanden, die Calc ja erst mal aus einer reinen Textform in Maschinensprache übersetzen muss. Und das nennt man wohl Compilieren.
Falls ich falsch liege, so möge man mich korigieren, aber genau dieses Compilieren braucht ja wohl die meiste Zeit nicht nur beim öffnen, sondern auch beim speichern einer Datei.

Also warum an der Schraube "Komprimieren" etwas drehen wollen, wenn es doch keinen sehr großen Nutzen hat?
So sehe ich das.


Gruß
balu

Gut, und wer von den Anwendern von OOO, bzw. Forumsteilnehmern soll das umsetzen ??

naja, diejenigen unter uns die Programmieren können (StarBasic reicht prinzipiell) könnten das im Grundsatz wohl als Extension realisieren, der Zugriff über die API ist jedenfalls möglich:
C:\Programme\OOoSDK\sdk\docs\common\ref\com\sun\star\packages\zip\module-ix.html

wobei der Zugriff auf den Algorithmus als Solches problemlos funktioniert, was ich weiß da ich schon damit programmiert habe. Wie das mit der Veränderung der Kompression in OOo real auswirkt, Konstanten sind:

NO_COMPRESSION
BEST_SPEED
BEST_COMPRESSION
DEFAULT_COMPRESSION

siehe in:
C:\Programme\OOoSDK\sdk\docs\common\ref\com\sun\star\packages\zip\ZipConstants.html

damit habe ich bisher keine praktische Erfahrung.

Es sollte jeder die Möglichkeit haben, sich für mehr Geschwindigkeit oder für
mehr Kompression zu entscheiden. Es würde keinesfalls doppelt so lang dauern.
Im ersten Schritt wird ja nur kopiert ohne viel Rechenzeit nötig zu haben.
Erst im zweiten Schritt wird wie bisher auch gewissenhaft komprimiert.
Die zusätzliche Zeit für den ersten Schritt ist daher wirklich nicht so viel.
Im Gegenzug erhält man kleinere Dateien.

Ich will hier nur aufzeigen, wie mit vorhandenen Mitteln noch mehr aus dem
Dateiformat zu holen ist.

lorbass hat Dir den richtigen Link bereits hingeschrieben, denn das Ganze ist mehr ein Thema für OOo (OOo-Projekt) denn für das Dateiformat (OASIS bzw. ISO)

Falls ich falsch liege, so möge man mich korigieren

kompilieren hat mit Datei-öffnen nichts zu tun, sondern ist das 'Übersetzen einen Programm-Quelltextes in Maschinensprache', siehe z.B. http://de.wikipedia.org/wiki/Kompilierung

Also warum an der Schraube "Komprimieren" etwas drehen wollen, wenn es doch keinen sehr großen Nutzen hat?

Weil es für Anwender ggf. von Nutzen wäre und weil auch kleine Verbesserungen ein Programm verbessern.

Und bei "2 Sekunden" solltest Du Dir überlegen was das für Unternehmen bedeutet die hunderte Arbeitsplätze haben, da machen 2 Sekunden pro Datei sehr schnell hunderte Euro pro Woche aus, denn die Arbeitszeit in der Angestellte darauf warten das OOo eine Datei öffnet ist ja nun einmal nicht kostenfrei.
Hast du beispielsweise ein Unternehmen das auf 500 Arbeitsplätzen die gleiche Calc-Datei benutzt und diese muß pro Arbeitsplatz und Tag zehnmal geöffnet und geschlossen werden ergeben 2 Sekunden pro öffnen und schliessen:

500 x 10 x 2 x 2 Sekunden = 20.000 Sekunden = ca. 5,56 Stunden

überlege selbst wieviel 5,56 Stunden das Unternehmen an Lohnkosten kosten werden (5,56 Stunden pro Tag wohlgemerkt und nicht nur einmalig).



Gruß
Stephan

Hallo Stephan

kompilieren hat mit Datei-öffnen nichts zu tun, sondern ist das 'Übersetzen einen Programm-Quelltextes in Maschinensprache'

Ja und wie nennt man das verfahren denn dann, wenn Klartext in Maschinensprache umgewandelt wird? Denn um so etwas geht es doch, wenn das Programm z.B die Befehle aus der content.xml Computergerecht umwandelt.

Und bei "2 Sekunden" solltest Du Dir überlegen was das für Unternehmen bedeutet ...

Hast ja recht.


Gruß
balu

Hallo Sanne,

Interpreter, dat wars, was mir auf der Zunge lag. Alles klar, weiß wieder bescheid. Danke dir.


Gruß
balu

Ja und wie nennt man das verfahren denn dann, wenn Klartext in Maschinensprache umgewandelt wird?

es werden Inhalts- und Layoutanweisungen, die hier zufällig als 'Klar'text vorliegen (bei z.B. doc liegen sie binär vor) in Bildschirmanzeige umgesetzt.
Dazu werden die Dateien die sie enthalten vom Programm (das hierbei den Maschinencode darstellt) eingelesen, 'ausgewertet' und erkannte Inhalte als Werte von Variablen bzw. Parameter an weitere Teile des Programms übergeben das diese verarbeitet was letztlich zur Bildschirmdarstellung führt indem Ergebnisse von der CPU über die Grafikkarte auf den Monitor ausgegeben werden.

Umgangssprachlich würde man das vielleicht Rendern nennen, nur ist das wohl nicht korrekt, da es beim Rendern eher um Grafik geht und zum Anderen meine obige Erklärung schon zu weitgehend ist insofern die Bildschirmdarstellung ja nicht mehr mit dem eigentlichen öffnen der Datei zu tun hat.
Ich würde das Ganze somit als öffnen oder einlesen der Datei bezeichnen.

Denn um so etwas geht es doch, wenn das Programm z.B die Befehle aus der content.xml Computergerecht umwandelt.

In Maschinensprache umgewandelt werden kann nur Programmcode, da nun einmal Maschinensprache keine reine Binärdarstellung irgendwelcher 'Texte' ist, sondern als Maschinensprache nur eine Abfolge von (sinnvollen) Instruktionen/Anweisungen gilt die ein bestimmter Prozessor/Prozessortyp auch tatsächlich verarbeiten kann.

Maschinencode wird nur beim kompilieren oder assemblieren (oder zur Laufzeit durch interpretieren) erzeugt und das setzt Programmcode und nicht irgendwelchen Text oder Zahlen voraus.
Kannst Du Dich jederzeit in der Basic-IDE von überzeugen indem Du dort entweder den Inhalt einer XML-Datei einfügst oder anderen beliebigen Text und auf 'übersetzen' oder 'ausführen' klickst, dabei versucht OOo Deine Eingabe in Maschinencode umzuwandeln und da keine dafür sinnvolle Eingabe (=Programmcode) vorliegt, stoppt das Ganze mit einer Fehlermeldung.
(Um solche Fehlermeldungen für 'Nicht-Befehls-Code' zu vermeiden bedient man sich innerhalb von Programmcode der Markierung solcher Anteile als Kommentar, in Starbasic z.B. durch Markierung mittels Hochkomma oder dem Schlüsselwort REM (für remark). So markierte Teile werden dann bei der Umwandlung in Maschinencode übergangen.)


Ggf. suche Dir ein besser passendes Forum, denn diese Fragen maschinennaher Programmierung sind sicherlich nicht meine Spezialstrecke.


Sorry an die Mitleser, diese Dinge sind insgesamt alle ziemlich off topic und eigentlich sollte ich nicht so umfassend dazu schreiben, tut mir leid.


Gruß
Stephan

P.S.
Im Übrigen täusche Dich ggf. nicht 'Ursache und Wirkung', denn XML liegt auch erst als 'Klartext' vor nachdem es verarbeitet wurde, im Kern liegen alle Arten von Programmen/Dateien auf Deinem Rechner nur als Nullen und Einsen vor und können auch nur so verarbeitet werden.
Beispiel:
Eine Context.XML enthält am Anfang z.B. die Zeile:
was Du Dir sowohl im Speicher (wenn die datei geladen ist) wie auf der physischen Festplatte wie als Datei mittels Hexeditor anschauen kannst, welcher Dir dann die Hexwerte der Binärwerte zeigt, weil Binärwerte für den Menschen schwer zu lesen sind.
Obige Zeile in Hex wäre dann:
was der Rechner aber speichert und verarbeitet ist binär. Obige Zeile in Binär ist:
Und Letzteres ist auf Deinem Computer auf der Festplatte gespeichert und wird beim Öffnen der Datei in den Speicher geladen und dort weiter verarbeitet.
Eine Umwandlung des 'Klartextes' findet also korrekt betrachtet garnicht statt, weil dieser garnicht existiert, sondern erst erzeugt wird wenn Du ihn z.B betrachten willst also die XML-Datei direkt (z.B. mit Editor) öffnest.

Alles das sind auch keine soo großen Geheimnisse, Du kannst diese Dinge nachvollziehen wenn Du Dir einen Hexeditor (wie z.B. Winhex http://www.winhex.com/winhex/index-d.html) beschafftst.
Damit kannst Du dann letztlich sogar einzelne Bytes auf Deiner physikalischen Festplatte direkt ändern und auf diesem Weg auch direkt Dateien ändern.
(mache Letzteres aber nur wenn Du weist was Du tust denn damit kannst Du bei Fehlbedienung den Rechner lahm legen)

wo also direkt das "Text"file für die Befehlsausführung verwendet wird, spricht man von "interpreter" - jedenfalls war das in meiner Jugend so....

auch ein Interpreter wandelt m.E. nur Programmcode um, nicht beliebige Texte. Die XML-Files um die es hier geht sind jedoch kein Programmcode.


Gruß
Stephan

Hallo Stephan,

Sorry an die Mitleser, diese Dinge sind insgesamt alle ziemlich off topic und eigentlich sollte ich nicht so umfassend dazu schreiben, tut mir leid.

Zu sehr "Off-Topic" finde ich deine Antwort überhaupt nicht, denn man kann nicht immer eine exakte Linie ziehen die nicht überschritten werden darf.

Im Übrigen täusche Dich ggf. nicht 'Ursache und Wirkung', denn XML liegt auch erst als 'Klartext' vor nachdem es verarbeitet wurde, im Kern liegen alle Arten von Programmen/Dateien auf Deinem Rechner nur als Nullen und Einsen vor und können auch nur so verarbeitet werden.

Und da hat bei mir der Wecker extrem laut geklingelt, und ich bin wieder wach geworden. Natürlich liegen alle Daten nur in der Form von Nullen und Einsen vor, und erst die Programme "Dolmetschen" für uns diese informationen.

Also muss ich mich dafür entschuldigen, dass wir wohl vom eigentlichem Thema abgedriftet sind.
Jetzt habe ich aber doch noch eine Frage aus unsicherheit, die mich schon seit beginn dieses Threads beschäftigt.

Hat das Komprimieren eigentlich etwas mit dem Dateiformat zu tun, oder nicht?

Mir ist schon klar, dass die Spezifikationen von ODF recht umfangreich sind, und das da verdammt vieles geregelt wird, aber vielleicht weißt Du, oder jemand anderer, mehr darüber bescheid. Meine Englisch kenntnisse reichen nicht so weit um die veröffentlichten Dokumente über das ODF-Format zu verstehen. Würde mich über eine Antwort darüber sehr freuen.



Gruß
balu