[de-discuss] Re: [de-discuss] Bilder, die in Berichte eingelesen werden, vergrößern Datenbankdateien auf ein Vielfaches

Hallo Thomas,
> Noch mal mein Vorgehen:
> 1. Deine Datei aus Bug 80320 heruntergeladen
> (https://bugs.freedesktop.org/attachment.cgi?id=101477)
> 2. Sie entpackt
> 3. Entpacktes Verzeicnis nach $Verzeichnisname$Version (also z.B.
> reports_blow_up_odb_file416 zum Testen mit der 4.1.6 ... ;) )
> 4. LO Version: 4.1.6.2 Build-ID: 40ff705089295be5be0aae9b15123f687c05b0a
> gestartet
> 5. Datei pictures_in_reports_without_ObjectReplacements.odb geöffnet
> 6. Links auf „Bericht“, rechts Kontextmenü auf „report“ und „Bearbeiten“
> gewählt
> 7. Im Rport Builder kurz auf „Picture, connected by the path“
> angeklickt, bis der Rahmen erschien
> 8. <STRG>+<S>, <STRG>+<W>, um den Bericht zu speichern und zu schließen
> 9. „Datei – Speichern unter...“, „*_new“ als Dateinamen gewählt (also am
> vorherigen Dateinamen nur ein _new angehängt ... ;) )

Ist nicht notwendig, kannst Du auch direkt speichern.

> 10. Base geschlossen
> 11. Auf der Kommandozeile „cp -f /pfad/zum/jpg
> reports_blow_up_odb_file416/picture.jpg“, um das Bild zu tauschen
> 12. Schritte 4 bis 10 wiederholt, wobei ich nur bei 8 einen anderen
> Dateinamen gewählt habe (*_replaced_pic) ... ;)
>
> Das hab’ ich außer mit der 4.1.6.2 auch mit der LO Version: 4.2.5.2
> Build-ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 und Version: 4.3.0.1
> Build-ID: 9ed0c4329cf13f882dab0ee8b9ecd7b05e4aafbb (alles unter Debian
> Testing i686) probiert ... ;)
>
> Ergebnis:
> Dateigrößen bei allen drei Versionen:
> Originaldatei: 8,0 KB
> ..._new: 772 KB

Da ist doch der Bug bereits aufgetaucht: Die neue Datei ist ohne
jegliche Änderung 764 KB größer als erwartet. Das ist eine Zunahme um
das 96,5-fache. Ändere lediglich picture.jpg auf eine normal große
Digitalkameradatei (z.B. hier von einer älteren Spiegelreflex 2,8 MB),
dann wächst die Datenbankdatei beim gleichen Vorgehen natürlich deutlich
mehr an. Ich habe nur nicht so eine große Datei angehängt um nicht den
Rahmen für Attachments bei Bugzilla zu sprengen.

> ..._replaced_pic: 28 KB

Auch logisch. Da ist jetzt nicht der alte Bericht überschrieben worden
sondern ein neuer entstanden.

> (mit „du -hs pictures_in_reports_without_ObjectReplacements*“ im jeden
> Verzeichnis). Also nicht so ein enormer Dateigrößenzuwachs, wie du ihn
> beschrieben hast ... ;) 

Nein, der enorme Zuwachs kommt, wenn ich normal große Dateien oder
mehrere Dateien nehme. Ich hatte hier eine Beispieldatei zur Einbindung
von Bildern, bei dem ich etwas mit 3 Bildern experimentiert habe: 2
Icons und eine normal große *.ipg-Datei. Da waren dass dann schon 16MB
als Datenbankdatei.

Das Verhalten ist bei allen LO-Versionen gleich, stammt also wohl schon
aus der Zeit vor LO. Vermutlich haben viele Leute, die mit Bildern in
Base arbeiten, sich nie über die Größe ihrer Datei gewundert. Das kann
ja auch nur auffallen, wenn die Bilder extern liegen und eingelesen
werden. Mit internen Bildern wird die Datenbankdatei auch so schnell
recht groß.

Meine Version ist 64bit rpm Linux. Gleiches Ergebnis wie bei Dir. Fehlt
nur noch eine Bestätigung von Windows- und Mac-Seite. Aber auch da wird
sicher der Fehler auftreten, denn das Ganze liegt an einem Zusätzlichen
Verzeichnis, dass innerhalb der *.odb-Datei erstellt wird und in dem
diese unbrauchbare (je nach verbundenen Bildern unterschiedlich große)
Datei liegt.

Gruß

Robert


-- 
Liste abmelden mit E-Mail an: discuss+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/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert