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+unsubscr...@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
