Hello all !

Im Rahmen einer Neustrukturierung unseres PDF-Workflows teste ich gerade die Performance der pdfToolbox 5 bei der X3-Konvertierung. Als Testdatei sollte ein PDF 1.6 dienen, ca. 250x370 cm (ja, Zentimeter!) mit einigen Bildchen und einem großen, 2fach platzierten Hintergrundmotiv (660 MB), so dass die PDF-Endgröße mit ZIP-Kompression bei ca. 600 MB lag.

Um die Tests zu beschleunigen, habe ich die beiden Hintergrundmotive erstmal entfernt ( => PDF 1.6 mit ca. 120 MB) und damit folgende Verarbeitungszeiten erreicht:

– Das Acrobat 9-Standard Korrekturprofil "Nach PDF/X-3 konvertieren (Coated FOGRA 39)" in Acrobat 9 ausgeführt -> ca. 3 Min.
Um gleiche Verhältnisse zu schaffen, habe ich dieses Setting aus Acrobat exportiert und in die pdfToolbox importiert:
– Das Acrobat 9-Standard Korrekturprofil "Nach PDF/X-3 konvertieren (Coated FOGRA 39)" in Acrobat 9 ausgeführt -> ca. 6 Min.

Dies ist grob gesagt eine Verdoppelung der Verarbeitungszeit, wofür sicherlich vor allem die in der pdfToolbox hinterlegten Bildoptimierungen verantwortlich sind (welche z.B. 300 dpi-ZIP zu 600dpi-JPG-Kompression wandeln). Teste ich die Verarbeitungszeiten des Original-PDFs (mit 2x Hintergrundmotiv), so erhalte ich folgende Zeiten:
– Acrobat: ca. 35 Min.
– pdfToolbox: > 90 Min.

Mit derart langen Verarbeitungszeiten kann und möchte ich mich nicht widerstandslos abfinden, zumal diese PDF-Größen bei Großformaten keine Seltenheit sind.

Hierzu sei noch ergänzt, dass hierbei absichtlich der Weg "INDD -> PDF 1.6 -> Konvertierung zu X3 via pdfToolbox" gewählt wurde und ein Direktexport aus INDD als X3 ausscheidet. Ferner ist die Transparenzreduzierungs-Einstellung des besagten Settings mit "schnellste Verarbeitung" definiert und soll – als beste Wahl zwischen Qualität und Quantität – auch so stehen bleiben. Sämtliche Bilder wurden bereits beim Export auf Bildrahmen beschnitten.

Welche anderen Möglichkeiten gibt es, die Verarbeitungszeiten der pdfToolbox bei der PDF/X3-Konvertierung zu beschleunigen?


MfG
Thomas Kittel

Hallo,

ich selbst habe mich auch schon öfter darüber geärgert, dass sowohl Acrobat als auch Toolbox jeweils nur einen Prozessorkern nutzen. In Zeiten von 8-Kern-Maschinen und mehr ist das ein Witz und zeigt mal wieder sehr schön den Unterschied zwischen Marketing-bla-bla und der Praxis. Auf einem aktuellen Mac und PC habe ich ständig 88% Prozessorleistung ungenutzt weil 7 Kerne einfach brach liegen und das regt mich tierisch auf.

In dem Fall wäre wahrscheinlich der Toolbox-Server eine Alternative mit einer intelligenten Hardware-Wahl. Müsste man mal bei Callas fragen, ob der in der CLI-Version die Hardware besser nutzt.

Gruß

Hallo "rohrfrei",

die "reine" Serverversion ohne CLI (heißt das so?) kann das nach meinem jetzigen Kenntnisstand ebenfalls nicht, denn auch dort erhält jeder Vorgang max. 1 Kern. Ein einziges Mal sah ich zwar kurz die Prozentzahl 100,2% aufblinken, was ich mir aber nicht wirklich erklären kann. Ansonsten lässt meine "große" Testdatei auch die Serverversion gute 94 Min. (auf 2x 2,3 GHz QuadCore mit 12 GB RAM und SSD-Platten) rund um die 100% Auslastungsmarke tanzen.

Und wenn, wie in meinem Fall, hierbei auch noch ein PowerSwitch-Workflow zum Zuge kommen soll, der exakt an dieser Stelle mit weiteren "Abformaten" darauf warten muss, ob die X3-Konvertierung erfolgreich sein wird oder nicht, so sehe ich mich in genau diesem Punkt vor einem gaaanz großen Problem! :o(

Zur Not würde ich von meinen verlustfrei ZIP-komprimierten Bildern im PDF1.6 Abstand nehmen, fürchte jedoch, dass beim Wechsel auf JPG max. die Qualität leiden wird!? Da die Bildoptimierung der pdfToolbox auf jeden Fall eingreifen wird, können bei der Konvertierung von PDF1.6 JPGmax nach PDF/X3 JPGmax die Bilder ja auch nicht einfach "durchgereicht" werden, was vielleicht den ersehnten Geschwindigkeitsschub bringen würde!?

Dass verlustfreies JPG2000 (welches ja auch erst dekomprimiert werden müsste, um anschl. im X3 zu JPGmax. zu werden) einen Geschwindigkeitsvorteil bieten könnte, halte ich eher für unwahrscheinlich – habe es aber noch nicht ausprobiert.

Irgendwelche Ideen oder weitere "Kritik" hierzu?

Gruß Thomas

Hallo Ihr zwei,

auf unserem Server mit Switch und callas ToolBox Server wird bei mehreren Aktivitäten die ToolBox mehrfach gestartet.

Während die ToolBox also noch mit Deinem X3 beschäftigt ist, wird auf dem zweiten Kern eine zweite ToolBox gestartet, welche dann mal eben eine Optimeirung für eine Visitenkarte macht und auf dem dritten Kern eine Vorschau erzeugt.

Oder interpretiere ich das falsch, wenn ich bei Switch im Fortschritt mehrere ToolBox-Aktionen sehe und in der Aktivitätsanzeige von OS-X-Server auch mehrfach die ToolBox auftaucht.

Grüße aus Berlin

Nein, das siehst du richtig. Wenn die Aktivitätsanzeige mehrere Prozesse gleichen Namens mit unterschiedlichen PIDs siehst, laufen da auch mehrere Prozesse parallel.

@ T-Kittel:

Was die Frage nach JPEG angeht: Das wird sicherlich schneller, da das reine File I/O abnimmt, und die JPEG Kompression/Dekompression nicht so viel Last erzeugt. Bei JPEG2000 sieht das wieder ganz anders aus, das erzeugt hier immer Unmengen an Last (Lässt sich schon beim Sichern und Öffnen in Photoshop beobachten.)

Warum glaubst du, dass die JPEG Komprimierung von Toolbox bei gleicher Qualitätsstufe erneut absolviert wird?

Wie groß ist denn die 'große'?

@Polylux,
nein, ich denke Du interpretierst das schon richtig. Auch bei mir werden mehrere Prozesse gleichzeitig gestartet, je nach Switch-Voreinstellung (0 = "Alle verfügbaren") . Des Users Wunschtraum wäre wohl, dass selbst eine einzelne Aufgabe auf mehrere Prozessoren gleichzeitig verteilt werden könnte – Wunschtraum eben ;o)

In meinem Falle (auf Dein Beispiel übertragen) verhält es sich so, dass die Optimierung der Visitenkarte (2. Kern) und die Vorschau (3. Kern) wirklich erst dann gestartet werden soll, wenn die X3-Konvertierung (1. Kern) auch wirklich erfolgreich war (Stichwort "Syncronisationspunkte"). Denn wofür die Kerne 2+3 schon (umsonst) arbeiten lassen, wenn Kern 1 kurze Zeit später feststellt, dass die X3-Kriterien nicht erfüllt werden? Klar könnte man die unnötig-erzeugten "Abformate" vor Übergabe an den Ausgabeordner wieder einsammeln und vernichten - fände ich aber suboptimal.

Mich stört ja in der Hauptsache die – in Relation zum X3-Direktexport aus Indesign – bedeutend längere Verarbeitungszeit (PDF 1.6 -> X3 via pdfToolbox = ca. 90 Min. vs. X3-Direktexport aus INDD = 7 Min.)! Im Grunde erledigen doch beide (rein technisch gesehen) die gleichen Aufgaben und Prozesse (Farbkonvertierung, Downsampling, Transparenzreduzierung, etc.) und in beiden Fällen mit Original-Adobe-Technologie. Dass Callas on-the-fly auch noch eine Bildoptimierung vornimmt finde ich zwar sehr lobenswert, aber der Preis (in Form einer solch verlängerten Bearbeitungszeit) empfinde ich persönlich als zu hoch.

Und genau hier suche ich einen Ansatzpunkt:
Am liebsten würde ich der pdfToolbox gerne die Daten schon "mundgerecht" vorbereiten, indem ich Auflösung und Kompression bereits im Vorfeld auf die Ausgabe der Toolbox anpasse.
Aber dies wird sicher nicht möglich sein, da die Toolbox mit ihrer (nicht deaktivierbaren?) Bildoptimierung die JPGs sowieso dekomprimieren, transparenzreduzieren, hochrechnen und optimieren und neu-komprimieren muss.

Antwort auf [ Thomas Richard ]

Warum glaubst du, dass die JPEG Komprimierung von Toolbox bei gleicher Qualitätsstufe erneut absolviert wird?

Weil ja hier noch die Transparenzreduzierung durchgeführt werden muss und somit das (bereits im Quell-PDF) verlustbehaftete Bild dekomprimiert und erneut mit Verlusten neu-komprimiert werden muss, oder?

Die Qualität bzw. Auflösung hatte ich übrigens hier ( http://www.hilfdirselbst.ch/...medium__P473433.html ) schon bemängelt, wobei mir neben den Schärfeverlusten auch die Logik (300 dpi ZIP wird zu 300-1200 dpi JPG) nicht ganz einleuchtete und einleuchtet.

Antwort auf [ Thomas Richard ]

Wie groß ist denn die 'große'?

Wie oben erwähnt: ca. 600 MB (bei ZIP-Kompression)

Antwort auf [ Thomas Richard ]

Was die Frage nach JPEG angeht: Das wird sicherlich schneller, da das reine File I/O abnimmt, und die JPEG Kompression/Dekompression nicht so viel Last erzeugt.

Wenn Du mir so viel Mut machst, werde ich möglichst bald mal einen JPG-Test fahren und sowohl auf die Zeiten als auch auf die Qualität ein besonderes Augenmerk werfen.

MfG

Nachtrag:
Die pdfToolbox lässt mir ja auch nicht wirklich die Wahl bzgl. meiner Wunsch-Kompressionsmethode im Ziel-PDF/X3. Durch die Bildoptimierungen – im Zusammenspiel mit den 4 möglichen Einstellungen (ebenfalls hier http://www.hilfdirselbst.ch/...medium__P473433.html behandelt) – wird offenbar von Kachel zu Kachel entschieden, ob eine bestehende ZIP-Kompression beibehalten oder in JPG umkomprimiert wird. Das resultiert z.T. in hunderten, wild zwischen ZIP- und JPG-Kompression wechselnden Bildkacheln - zum Glück ohne optische Auswirkungen.

Antwort auf [ t-kittel ]

Hierzu sei noch ergänzt, dass hierbei absichtlich der Weg "INDD -> PDF 1.6 -> Konvertierung zu X3 via pdfToolbox" gewählt wurde und ein Direktexport aus INDD als X3 ausscheidet.

Willst Du uns vielleicht verraten, wieso das so ist?
Ich persönlich erstelle am Liebsten einmal ein PDF und mache daran so wenig wie nötig.
• Warum nicht gleich aus InDesign ein PDF/X3?
• Warum nicht vielleicht sogar ein PDF/X-4?

Habe heute erst wieder so eine Murks-Datei aus Pages mit Quartz bekommen, wo die Transparenzreduzierung die Schriften in Hieroglyphen gewandelt hat.
Beim Parallel-Flow ohne Reduzierung ist alles schön.

Tja, hier kommt die (alles andere als einfach zu verwirklichende) Philosophie der Dienstleistung ins Spiel, die versucht es allen recht zu machen:
In den meisten Fällen besteht leider keinerlei Kontakt zu den PDF-Empfängern (große und kleine Druckereien rund um den Globus) und somit herrscht totale Unkenntnis über das gewünschte PDF-Format. Gefühlt halten sich wohl momentan PDF/X3 und PDF 1.6 die Waage. Bis es soweit ist, dass alle Empfänger mit 1.6 und Transparenz umgehen können, sollen beide Formate stets vorrätig gehalten werden. Schicke ich 1.6 ins Land und bekomme es moniert, greife ich auf das bereitliegende X3 zurück – und umgekehrt. Das nachgelieferte X3 entstand definitiv aus dem zuvor versandten PDF 1.6 (quasi seiner "Mutter"), wodurch maximale Sicherheit gewährleistet werden soll. Ein manueller oder nochmaliger autom. Abgleich (zwischen 1.6 und X3) soll ebenso vermieden werden, wie ein zweiter Exportvorgang (und die hierdurch ebenfalls erforderliche, erneute Prüfung).
Exportiere ich zuerst nur X3, komme ich natürlich nie mehr zu meinem 1.6 oder X4. Hinzu kommen noch die gewaltigen Unterschiede der techn. Ausstattung; sowohl der Druckereien untereinander, als auch auf Seiten des Kunden, der z.T. noch in Acrobat Reader 5-ähnlichen Tools ohne Überdruckenvorschau unterwegs ist.

Sicherlich: ein hochgestecktes Ziel, wie die Tücke im Detail hier anhand meiner vielen Foreneinträge beweist.

Gruß Th.

Ich bin mir nicht sicher ob ich alles in diesem Diskussionstrang richtig verstand habe und frage daher einfach mal drauf los:

- wieso ist man mit der pdfToolbox dazu verdonnert, die Bilddaten zu rekomprimieren?

- wieso will man von 300ppi ZIP auf 600ppi JPEG hoch-sampeln / komprimieren?

Zur Performance: ich habe hier ein wenig den Eindruck, dass der pdfToolbox etwas "angelastet" wird, was die anderen Werkzeuge gar nicht "können", nämlich das Hochsampeln - das allerdings in der Tat ein kleiner Zeitfresser ist, schließlich wird die (ausgepackte) Datenmenge vervierfacht, und muss dann anschließend wieder mit JPEG eingepackt werden.

- zu JPEG2000: JPEG2000-Kompression ist auf dem HIntergrund der verwendeten Algorithmen recht aufwändig, mit PDF/X-3 ist sie obendrein eh' nicht erlaubt.

Grundsätzlich glaube ich, dass man in der Tat ein möglichst gutes und möglichst gut passendes Ausgangsmaterial erstellen sollte, um mit der pdfToolbox dann gezielt das anzupassen/zu konvertieren, was man evtl. nur mit einem nachgelagerten pdfToolbox-Prozess erreichen kann.


Olaf

Guten Morgen Olaf,

auch wenn ich nicht der Original-Poster bin, möchte ich trotzdem einmal antworten, so wie ich es verstanden habe und nachvollziehen konnte:

Antwort auf [ olaflist ]

- wieso ist man mit der pdfToolbox dazu verdonnert, die Bilddaten zu rekomprimieren?

Weil diese mit Transparenzen in Verbindung kommen und beim Verflachen macht die ToolBox sowas halt.

Antwort auf [ olaflist ]

- wieso will man von 300ppi ZIP auf 600ppi JPEG hoch-sampeln / komprimieren?

Das wollen wir ja gar nicht unbedingt, dass macht die ToolBox von sich aus ganz alleine (Bildoptimierung).
siehe auch hier: http://www.hilfdirselbst.ch/..._P474168.html#474168

Mich stört das schon etwas. Wo ich eben noch einen Fehler hatte mit 83 ppi bei ZIP sind nach der Transparenzreduzierung plötzlich 3200 ppi bei JPEG mit Kachelung des Bildes.

Viele Grüße

 
@Polylux
Da warst Du mal wieder schneller als ich ;o)
Trotzdem: Vielen Dank für das Vorwegnehmen der Antworten auf Olaf's Fragen. Betonen möchte ich allerdings, dass Deine Antworten und der Querverweis zu meinem "JPGmedium"-Thread allesamt auf meinen Aussagen beruhen, welche ich auf Grund meiner Praxistests gesammelt und hier publiziert habe. Möglicherweise befinde ich mich auch total auf dem Holzweg ... hatte es aber bisher immer so verstanden, dass zur Transparenzreduzierung mit Kachelung die Bilddaten zwangsläufig ent- und neukomprimiert werden müssen. Sollte dies nicht der Fall sein, bitte ich um Aufklärung.

Auch interessiert mich weiterhin die Frage, ob sich die autom. Bildoptimierung – wichtiger aber noch das daraus resultierende Hochrechnen durch die pdfToolbox – nicht doch durch bestimmte Einstellungen oder Einstellungskombinationen deaktivieren lässt?
...was nicht unbedingt heißen muss, dass ich dies im Wokflow auch tun würde ;o)
Denn wie Du mir unterstützend beigepflichtet hast, ist ein Sprung von 83 ppi auf 3200 ppi für den "normalen" Anwender so erstmal nicht nachzuvollziehen. Meine Befürchtungen hierbei gehen vor allem in Richtung beliebter, mehrfach freihändig-skalierter Transparenzeffekte, welche meiner Praxiserfahrung nach bei unglücklicher Konstellation bzw. Verzerrung beim Reduzieren zu fälschlicherweise zu niedrigen Auflösungen führen können. Hier bringt es ja nichts, die zuvor fälschlicherweise auf 83 ppi downgesampelten und somit "kaputtgerechneten" Bilder nur in der Auflösung wieder "aufzupumpen", denn die eigentlich vorhandene Qualität ging ja bereits zuvor verloren.


@Olaf
Ich möchte hier keinesfalls der pdfToolbox etwas "anlasten", vor allem nicht zu Unrecht! ...doch leider gibt es noch so ettliche Dinge, welche ich – sowohl in Sachen PDF als auch in der Funktionsweise der pdfToolbox – noch nicht verstehe. Die pdfToolbox selbst, hat mich persönlich in Sachen Funktionsumfang und Benutzerfreundlichkeit, vor allem aber auf Grund ihrer immensen Möglichkeiten mit dynamischen Prüfungen UND im Zusammenspiel mit PowerSwitch längst überzeugt! Ich denke momentan sogar daran, sämtliche im Workflow platzierten PitStop-Profile mit der pdfToolbox nachzubauen, weil mir der installierte PitStop 10-Server bisher alles andere als gierig nach verfügbarer Performance greift. Über weite Strecken nutzt er nichtmal 1 Prozent der CPU, obwohl reichlich Leistung frei ist und die zu erledigenden Aufgaben oftmals Sache von wenigen Sekunden wären, aber minutenlang ohne Fortschritt bleiben.

Auch deshalb bin ich mir heute morgen nicht mehr sicher, ob entweder mein Testrechner (bzw. seine derzeitige Installation) oder das bisher verwendete Test-PDF Ursache für die vielen Ungereimtheiten und überdurchschnittlich langen Verarbeitungszeiten sein könnten!?

Während gestern abend meine Vergleichstests zwischen JPG und ZIP noch immense Unterschiede (94 min. bei ZIP vs. 2 min. bei JPG) bei den Konvertierungszeiten zu X3 aufwiesen, scheint sich in allen heutigen Tests die Differenz eher im Rahmen zu halten (59 min. ZIP vs. 41 min. JPG).

Auch eine zweite, 64seitige Testdatei (mit knapp 285 MB als PDF 1.6 bei ZIP-Kompression) verhält sich bei der X3-Konvertierung eher analog den heutigen Ergebnissen: (6:10 min. ZIP vs. 6:00 ZIP).

Hiernach scheint es also doch nicht soo eine große Rolle zu spielen, ob die Bilddaten im Ausgangs-PDF als ZIP oder JPG vorliegen!?

Ich fürchte fast erst dann weitere Auskünfte geben zu können, wenn der Testrechner komplett neu aufgesetzt wurde.

Soweit für den Moment von mir...
Gruß Thomas

Hallo Thomas,

versuchen Sie doch einmal, bei der Korrektur "Transparenz reduzieren" die Optimierung auf "Keine" zu setzen. Dies müsste die Verarbeitungszeit deutlich reduzieren. Allerdings kann es je nach Inhalt der Dateien unter Umständen zu leichen Fragmentbildungen in den Grafiken und Bildern kommen.

Gerne würden wir Ihre 600MB-Datei auch selber einmal durchtesten, sollten Sie uns diese auf einem FTP-Server zur Verfügung stellen können wäre dies toll (wir können Ihnen auf Wunsch natürlich auch einen FTP-Zugang mailen).

Mit besten Grüßen,
Marc Heusmann.

Ich mal wieder ;o)

Zu fortgeschrittener Stunde und von zuhause aus, will ich mal versuchen die Ergebnisse meiner weiteren Performance-Tests im Telegrammstil zusammenzufassen:
Max. Verhältnis der Verarbeitungszeiten von JPG- vs. ZIP-Kompression im Ausgangs-PDF lag in meinen Tests nun bei 2:3 +++STOP+++ X3 aus PDF1.6/JPG = 60 Min., X3 aus PDF1.6/JPGmax = 40 Min. +++STOP+++ bei kleineren Ausgangs-PDFs 1.6 (ca. 285 MB) sind die Unterschiede eher marginal +++ STOP+++ X3 aus PDF1.6/JPG = 6:10 Min., X3 aus PDF1.6/JPGmax = 6:00 Min. (siehe auch Beitrag #7) +++STOP+++ Größte Zeitersparnis erziele ich momentan mit der fixen Idee, im Ausgangs-PDF keinerlei Kompression für Bilder anzuwenden +++STOP+++ d.h. Exportdauer aus ID zeitlich genau zwischen ZIP- und JPG-Kompression +++STOP+++ PDF1.6-Größe mit 1,9 GB (anstelle von 591 MB/ZIP oder 76 MB/JPGmax) jenseits von gut und böse +++STOP+++ aber die pdfToolbox freut sich, dass für die X3-Konvertierung vorab keinerlei Bilder dekomprimiert werden müssen +++STOP+++ und dankt es mir mit 600% Leistungssteigerung (10 min. anstatt 60 min. Verarbeitungszeit) bei der X3-Erstellung +++STOP+++ Der Schritt zurück (vom 1,9 GB-PDF) zum "kompakten" PDF1.6 mit gezippten Bildern, erledigt die Toolbox in nur 6 Minuten +++STOP+++ wobei die PDF1.6-Endgröße mit 716 MB unerwartet deutlich über den 519 MB liegt, welche beim Export aus ID mit gleicher Einstellung entstehen. +++STOP+++ und ich dachte bisher immer ZIP ist gleich ZIP +++STOP und ENDE des Telegramms+++

Aufgrund der letztgenannten PDF-Größenunterschiede (716 vs. 519 MB) müsste ich fast mutmaßen, dass die pdfToolbox selbst bei Durchführung eines eigens angefertigten Korrekturprofils, welches nichts anderes tun soll, als unkomprimierte Farb- und Graustufenbildern mit ZIP-Kompression zu versehen, ebenfalls Bildoptimierungen durchführt? Doch dies kann ich mir 1. nicht vorstellen und 2. kann ich im resultierenden PDF auch keinerlei Spuren in Form von veränderten Auflösungen oder Kompressionsmethoden davon finden. Auch die Bildrahmen muten in der PitStop-Konturenansicht identisch an. Doch wie lassen sich die Unterschiede in der Endgröße sonst erklären? Nutzt Indesign beim Export ein anderes ZIP-Verfahren als die pdfToolbox???
Für genauere Analysen dieser beiden PDFs reichte mir heute abend weder Zeit noch Nerven, aber ich werde morgen früh wieder am Ball sein.

Zu guter Letzt möchte ich auch Ihnen Herr Heusmann heute keinerlei Antworten schuldig bleiben:

Antwort auf [ hmh ]

versuchen Sie doch einmal, bei der Korrektur "Transparenz reduzieren" die Optimierung auf "Keine" zu setzen. Dies müsste die Verarbeitungszeit deutlich reduzieren. Allerdings kann es je nach Inhalt der Dateien unter Umständen zu leichen Fragmentbildungen in den Grafiken und Bildern kommen.

Wenn ich mich recht erinnere, hatte ich dies vor einigen Wochen schon einmal getan, bin aber aufgrund sehr augenscheinlicher Fragmentbildungen gleich wieder davon abgekommen. Müsste aber nochmal gezielt nach diesen Ergebnissen fahnden, sofern ich sie überhaupt noch auf dem Rechner habe.

Antwort auf [ hmh ]

Gerne würden wir Ihre 600MB-Datei auch selber einmal durchtesten, sollten Sie uns diese auf einem FTP-Server zur Verfügung stellen können wäre dies toll

Gerne würde ich dies tun, fürchte aber die Genehmigung seitens des Kunden nicht zu erhalten. Falls ich morgen doch etwas erreichen sollte, erhalten Sie eine Mail mit Downloadlink von mir.

Doch nun mache ich erstmal die Augen zu und wünsche allen, die dieses "Telegramm mit Überlange" noch heute lesen eine "Gute Nacht"!

Gruß Thomas

Hallo,

sind doch ein paar interessante Erkenntnisse dabei.

Zitat

Doch wie lassen sich die Unterschiede in der Endgröße sonst erklären? Nutzt Indesign beim Export ein anderes ZIP-Verfahren als die pdfToolbox???

Kennst du die Speicherprüfung in Acrobat? Da könnte man mal schauen, wie sich der Speicherbedarf der PDFs aufteilt. Zu finden im Menü Erweitert/PDF-Optimierung und dann oben rechts der Button "Speicherprüfung".

Ich weiß gar nicht, ob man die ZIP-Komprimierung unterschiedlich ausführen kann. Im Prinzip ist das doch immer ein Balanceakt zwischen max. Komprimierung und min. Rechenaufwand. Kann mich momentan beim besten Willen nicht erinnern, ob das spezielle ZIP-Packer einstellen können seit dem ich nur noch die OS-eigenen Mittel dafür verwende.

Gruß