writer 5.1 unter win 7 pro, 64 bit, Fehlermeldung: bad allocation

de-users
#1

Moin, moin,

ich möchte ein Global-Dokument drucken; insgesamt ca. 430 Seiten Text mit
eingestreuten Bildern. Einmal bei ca. 250, einmal bei ca. 320 Seiten steigt
das Programm mit der o.a. Fehlermeldung aus.

Ich habe dann einen hardware check laufen lassen, einmal unter windows,
einmal auf bios-Ebene - ohne Befund; ich habe den Windows-Update-Status
geprüft - ebenfalls ohne Befund.

Die CPU-Auslastung schwankt zwischen 30 und 50%, der Arbeitsspeicher wird zu
einem Drittel genutzt...

Hat jemand eine Idee, welche Parameter verstellt werden sollten/könnten?

Vielen Dank im Voraus & viele Grüße aus Hannover, Klaus

#2

Hallo Klaus,

noch weiss ich nicht, ob ich Dir helfen kann. Ich versuche mal ein paar Ideen bezusteuern.

Zunächst wäre es schön, wenn Du noch mitteilst, wieviele Unterdokumente Du im Globaldokument verwendest.
Ein Knackpunkt sind meist die Bilder. Wieviele Bilder verwendest Du und welche Größe (kB) haben diese?
Wenn die Bilder in den Unterdokumenten eingefügt sind (eingefügt / OLE-Objekt?), kann man mit der rechten Maustaste auf das jeweilige Bild klicken und Eigenschaften auswählen. Dort den Punkt "Komprimieren auswählen und komprimieren/(verkleinern). Im Dokument müssen die Bilder meist gar nicht so groß (in kB) sein.

Ich hoffe Du hast ein paar Anregungen gefunden.

Gruß
Harald (B.)

-----Original-Nachricht-----

#3

Hallo Klaus,

ich möchte ein Global-Dokument drucken; insgesamt ca. 430 Seiten
Text mit eingestreuten Bildern. Einmal bei ca. 250, einmal bei ca.
320 Seiten steigt das Programm mit der o.a. Fehlermeldung aus.

Lässt sich vielleicht zuerst das Ganze in eine *.pdf-Datei exportieren?
Wie hoch steht bei Dir
Extras > Optionen > LibreOffice > Arbeitsspeicher > Grafikspeicher ?
Ich habe den bei mir standardmäßig bei 100 MB, weil ich auch öfter mit
Globaldokumenten (Base-Handbuch) arbeite.

Gruß

Robert

#4

Hallo Harald, hallo Robert,

vielen Dank für Eure Hinweise!

Ich habe folgendes probiert:
a) "Autoruns" aus den sysinternals genutzt, um einige Prozesse nicht zu
automatisch starten zu lassen;
b) die Wiederherstellung solange laufen lassen, bis sich die CPU-Nutzung
beruhigt hat;
c) der LO-interne pdf-Export brach mit der o.a. Fehlermeldung ab;
d) der pdf-Druck (acrobat, Version 10) lief problemlos durch...

Ad Harald) Es sind knapp 20 Kapitel, die Bilder [es sind viele!] sind nicht
eingebettet, mit dem Parameter "Kompression" habe ich bisher nicht
gearbeitet;

Ad Robert) Der Grafik-Speicher steht bei 500 MB;

Ich bin "unruhig", werde mit den genannten Parametern probieren und mich
dann wieder melden.

Viele Grüße aus Hannover, Klaus

#5

Hallo Klaus,

wie groß sind den die einzelnen Dateien (incl. der Bilder), die Du zu
einem Globaldokument zusammen fasst? Bei mir ergibt das, wenn ich aus
dem Globaldokument ein *.odt-Dokument mache, nicht ganz 12 MB bei 549
Seiten und einer sehr großen Anzahl von Screenshots. Ich habe dabei
keine Probleme, die Datei nach *.pdf zu exportieren und auch keine
Probleme, aus dem Globaldokument eben eine *.odt-Datei zu erstellen.

Allerdings: Bei mir sind alle Bilder eingebunden, nicht verlinkt. Und
bei mir sind fast alle Bilder "Als Zeichen" verankert.

Unterschied ist bei uns sicher noch das Betriebssystem (ich habe
OpenSUSE 42.1 64bit rpm Linux) sowie eventuell Arbeitsspeicher und
Prozessor - aber da liege ich mit 4 GB und einer i3-3220-CPU wohl für
heutige Verhältnisse eher unter dem Durchschnitt.

Gruß

Robert

#6

Hallo Klaus,

d) der pdf-Druck (acrobat, Version 10) lief problemlos durch...

wenn du das Pdf erzeugt bekommst, probier mal, das Dokument nicht als Pdf,
sondern als postscript zu drucken:

Datei -> Drucken -> Allgemein -> Eigenschaften -> Gerät -> Druckersprache

Bei Druckersprache wählst du nun nicht pdf, sondern eine der angebotenen
Postscriptsprachen.

Gruß

Peter Mulller

#7

Moin, moin & ganz kurz:

Nachdem ich heute wieder die Fehlermeldung "bad allocation" erhielt, habe
ich folgendes erledigt:
- mit den sysinternals den Startup des Rechners bereinigt und
- upgrade auf 5.1.5.2 (x64) durchgeführt.

Aufruf des Global-Dokumentes, Aktualisierungen usw. usf. konnten normal
durchgeführt werden, der Druck als pdf (acrobat X) ergab ein Dokument mit 32
MB, der Export als pdf ergab ein Dokument mit 118 MB.

Merkwürdig war, das der Parameter "Automatisch eingefügte Leerseiten
drucken" vom pdf-Export ignoriert wurde - warum auch immer.

Den Parameter für den Grafik-Speicher habe ich auf 1 GB eingestellt - ein
größerer Wert führte (vor dem update, s.o.) zum Abbruch.

So, jetzt bin ich einen Schritt weiter!

Viele Grüße aus Hannover, Klaus

PS ad Robert:

- Umwandeln des Global-Dokumentes in eine odt-Datei: Habe ich noch nicht
ausprobiert, aus meiner Sicht bietet die Aufteilung Global- und
Unterdokumente viele Vorteile;
- Bilder und Grafiken: Sind per Verweis eingebunden, so konnte ich sie
teilweise nachbearbeiten, Verankerung: Ich weiß nicht genau, was Du meinst,
die meisten hängen an einem Absatz dran, einige, mit oder ohne Beschriftung,
auch auf einer Seite;

PPS ad Harald:

Um eine Komprimierung der Bilder habe ich mich nicht gekümmert, das hat das
Programm für mich erledigt - dabei habe ich den Wert des Parameters
"Speicher pro Objekt" auf 1 MB belassen, auch wenn fast alle Bilder deutlich
größer sind...

#8

Hallo Klaus,

PS ad Robert:

- Umwandeln des Global-Dokumentes in eine odt-Datei: Habe ich noch
nicht ausprobiert, aus meiner Sicht bietet die Aufteilung Global-
und Unterdokumente viele Vorteile; - Bilder und Grafiken: Sind per
Verweis eingebunden, so konnte ich sie teilweise nachbearbeiten,
Verankerung: Ich weiß nicht genau, was Du meinst, die meisten
hängen an einem Absatz dran, einige, mit oder ohne Beschriftung,
auch auf einer Seite;

Wenn Du tatsächlich Bilder an einer Seite verankerst und dann aus
Einzeldokumenten ein Globaldokument machst, dann rutschen diese
Bilder, so weit ich das in Erinnerung habe, auch im Globaldokument auf
die entsprechende Seite. Angenommen Du hast ein Bild auf Seite 2 eines
Unterdokuments verankert, so wird dort in Globaldokument ebenfalls S.
2 - vom Start des Globaldokumentes aus gerechnet.

Ich speichere das Globaldokument zum Schluss auch als *.odt-Dokument
ab. Da mache ich kein *.odt-Dokument draus, um es weiter zu
bearbeiten, sondern nur, um das jeweilige Handbuch sowohl als *.pdf
als auch als *.odt im Netz stehen haben zu können. Das Globaldokument
bleibt natürlich erhalten und auch die Einzeldokument bestehen weiter
und sind die Datenquelle für alles.

Gruß

Robert

#9

Hallo Harald,

seit ich auf die 64 bit-Version von LO umgestellt habe, habe ich die o.a. Fehlermeldung nicht mehr erhalten!

Weiter habe ich mit Hilfe der batch-Funktion von irfanview viele der eingebundenen Graphiken, die größer als 5 MB waren, verkleinert (size jeweils 50%); Auswirkungen auf den pdf-Druck: nicht feststellbar, Auswirkungen auf den LO-eigenen pdf-Export: Reduktion der Größe des pdf von 130 auf 100 MB.

Ich habe den Parameter für den Graphik-Speicher auf 2 GB erhöht, die Nutzung des Arbeitsspeichers bei Aufruf des Global-Dokumentes erhöhte sich um ca. 3 GB.

Mein Vertrauen in die Stabilität von LO ist deutlich gestiegen!

Viele Grüße aus Hannover, Klaus

#10

Hallo Klaus,

danke für's Feedback. Na also, geht doch.

Bei den Bildern hättest Du wahrscheinlich die Größe noch verringern können. Für die Anzeige/Ausdruck innerhalb von DIN-A4-Seiten sind >=2,5 MB bis <5MB nicht erforderlich. Wenn Du mal viel Zeit hast kannst Du ja mal mit einer Testdatei probieren, z.B. <=500 KB.

Schade, dass wir jetzt nicht wissen woran es genau lag, 32/64Bit-Version oder Bilder verkleinern.

Viele Grüße
Harald (B.)

-----Original-Nachricht-----

#11

... meine Vermutung: Ursache war der Wechsel zur 64-Bit-Version, denn Drucken und Bearbeiten war schon VOR der Reduktion ohne Fehlermeldung möglich.

Gruß, Klaus