[2013 R2] Riesige PDF-Drucks im Report

Hallo zusammen,

wie so häufig stoße ich zu euch um nach einer Lösung oder einem Ansatz für ein RDLC-Problem zu fragen.

Das aktuelle Problem ist, dass ein Kunde einen Belegdruck mit 5 Bilder pro Seite hat und nicht damit einverstanden ist, dass ein 11-seitiger Ausdruck dann auch 11 MB als PDF belegt (gedruckt über die Standard-PDF-Funktion).
Wenn der Beleg aber über einen klassischen PDF-Drucker gedruckt wird belegt die Datei lächerliche 109 KB.

Meine Fragen also:
- Kann ich etwas an dem Druckverhalten des Clients bei PDFs drehen?
- Woran kann dieser große Unterschied liegen?
- Wie kann ich ein ähnliches Ergebnis über den Standard erzielen?

Ich bedanke mich im vorhinein für jeden hilfreichen Kommentar.

Mit freundlichen Grüßen
Sipa

Interessant, das Problem war mir so noch nicht bekannt.
Für mich hört sich das so an, als würde der "echte PDF-Drucker" die Bilder komprimieren, was der eingebaute Generator nicht tut.
Mich würde zum Vergleich interessieren, wie sich Word verhält, wenn du dieselben Bilder einfügst und das Dokument als PDF speicherst. Ist ja der gleiche Mechanismus wie in NAV. Ich würde daher erwarten, dass auch dieses PDF groß wird.

Alternativ könntest du Bilder von vorneherein in komprimierter Version in NAV speichern.

Hallo Natalie,

hier wird es besonders: Das Word-Dokument ist nur 1,5 MB groß, das aus Word erstellte PDF nur 0,5 MB.

Hast du eine Vermutung wo hier der Unterschied liegen könnte?

Gruß
Sipa

Hallo,

sind das 5 variable Bilder oder konstante?

Falls konstant, gibt es einen Unterschied zwischen einer vom NAV übergebenen Grafik oder einer im Report enthaltenen Grafik?

Gruß, Fiddi

Hast du eine Vermutung wo hier der Unterschied liegen könnte?

Da kann ich nur raten.
Könnte es z.B. sein, dass das NAV-PDF die Größe des DataSets annimmt?
Probier mal aus, ob die Größe durch CLEARen der Blobfelder im C/AL-Report-Code positiv beeinfluss wird: http://dynamicsuser.net/blogs/waldo/arc ... asets.aspx
Ich finde die Beschreibung z.T. irreführend. Es geht darum, dass wenn du in DataItem1 ein Bild druckst, und dieses DataItem1 hat als "Kind" DataItem2, dann solltest beim zweiten Datensatz des DataItems2 CLEAR(Blobfeld) ausführen.

Hallo,

@Fiddi:
Die Bilder stammen zwar aus dem DataSet, ergo nicht fest eingebunden, werden aber während der Laufzeit immer gleich bleiben.
Hier legt der Kunde aber auch Wert drauf, dass die Bilder Datenbankübergreifend schnell ausgewechselt werden können. Deswegen beziehe ich diese aus der Firmendatentabelle (mit Extra-Blob-Feldern).

@Natalie:
Grundsätzlich hatte ich bereits Probleme gehabt durch zu viel Platzverschwendung im DataSet durch die Bilder - hierfür hatte ich eigentlich bereits eine Optimierung vorgenommen.
Die Idee aus deinem Link es per vorgeschobenes Interger-DataItem zu regeln, dass die Bilder nur einmal ins DataSet kommen finde ich aber sehr gut und werde sofort mal überprüfen ob das einen Unterschied macht.

Gruß

Sipa

Hier legt der Kunde aber auch Wert drauf, dass die Bilder Datenbankübergreifend schnell ausgewechselt werden können. Deswegen beziehe ich diese aus der Firmendatentabelle (mit Extra-Blob-Feldern)

Druckst du häufig größere Belegberichte (>100 Seiten pro Druckjob)? Dann solltest du dich von den übergebenen Bilder verabschieden, weil dir sonst der Bericht wg. des zu großen Datenvolumens platzen könnte (Die Bilder werden mit jedem Datensatz übergeben, es sei denn man kann es im Programm abfangen)

Gruß, Fiddi

Hallo Fiddi,

die Größe des DataSets bei solchen Summen ist mir bewusst, doch handelt es sich hier um Belegdrücke, da werden wir solche Zahlen hoffentlich nie erreichen

Gruß
Sipa

doch handelt es sich hier um Belegdrücke, da werden wir solche Zahlen hoffentlich nie erreichen

Das habe ich auch gedacht, bis mich der erste Kunde fragte, warum er seine 150 Seiten große Sammelrechnung nicht drucken kann. Ein anderer Kunden druckt alle noch nicht gedruckten Rechnungen mit dem Filter "Anzahl gedruckt <> 0' aus und kommt damit auch auf eine ähnliche Anzahl Seiten pro Druckjob.

Gruß, Fiddi

Das ist aber mit dem Kunden abgeklärt - die machen nie Stapeldrucke und haben das auch nicht vor ;)

//UPDATE:
@Natalie: Habe das DataSet nun verbessert - der Druck ist schonmal zumindest auf 8,6 MB runtergegangen, somit danke schonmal für den Tipp - aber trotzdem ist das noch zu viel.

Gruß
Sipa

Hallo,

würde ein "Clear(Company.Picture)" in dem Line Trigger vom Dataset nicht ausreichen?

Ungetestet!

Weil für die erste Zeile im Dataset, dann das Bild drin wäre und für die Zeilen dann nicht mehr, oder?


Gruß
Aydin

Hallo aydina81,

Die Idee aus deinem Link es per vorgeschobenes Interger-DataItem zu regeln, dass die Bilder nur einmal ins DataSet kommen finde ich aber sehr gut und werde sofort mal überprüfen ob das einen Unterschied macht.

Genau das meinte ich damit und bin wie folgt vorgegangen:
- Oberste Ebene ein Integer-DataItem (Filter: Number = 1)
- Alle Bilder in der DataSet-Zeile übergeben
- Clear aller Bilder im OnPostDataItem

Alle Bilder waren somit nur in der ersten DataSet-Zeile vorhanden, danach leer.

Gruß
Sipa

würde ein "Clear(Company.Picture)" in dem Line Trigger vom Dataset nicht ausreichen?

Nicht, wenn du pro Beleg nur eine Zeile hast, bzw. wenn mehrere Belege auf einmal gedruckt werden, und mit unterschiedlichen Bildern arbeiten.

Ein weiterer Vorteil des nicht Übergebens von Bildern, ist die wesentlich höhere Geschwindigkeit beim Drucken .

Gruß, Fiddi

Hallo,

wie gesagt sind das die (dank der Masse an Berichten begründete) Limitierungen durch den Kunden:
- Die Bilder müssen aus der DB kommen
- Es wird IMMER ein Beleg auf einmal gedruckt
- Pro Druck bleiben die Bilder aber statisch

Ich würde auch am liebsten fest eingebundene Bilder verwenden, aber geht leider Gottes nicht

Gruß
Sipa