Hallo Herr Will, vornweg: Nach meinem letzten eher zufälligen Test vermute ich gar nichts mehr -- ich fürchte nur noch, dass eine Erfahrung, die ich vom PDFMaker kenne, auch hier zutreffen könnte: Für die Produktmanager und Softwerker, die für PDFMaker, AdobePDF-Druckertreiber etc. zuständig sind, sind Geschwindigkeitsoptimierungen kein vordringliches Thema.
Doch zunächst zu Ihren Antworten: > Sie schrieben (siehe Zitat oben), daß Ihrer > Meinung nach der Treiber EPS-Daten ungeprüft > weiterreichen würde, wenn als Ziel der Distiller > feststeht und nur zeitraubend prüft, wenn ein > anderer Drucker als Ziel angegeben wird. > Da aber gerade dann der Zeitaufwand größer wird, > wenn der Distiller als Ziel angegeben wird, kann > Ihre Vermutung nicht stimmern, oder? Zeitraubend wird geprüft, wenn der Druckertreiber "Adobe PDF" (alias "Acrobat Distiller") einfach nur eine PS-Datei schreiben soll. (Weil in diesem Moment, so war mein Verdacht, als Endziel der Arbeit die Ausgabe auf einem realen PS-Drucker angenommen wird.) Konnte der Druckertreiber jedoch wissen, dass das Endziel PDF ist (weil der Prozess über die Routine "Speichern als PDF" angestoßen wurde), bleiben die EPS-Daten ungeprüft (und entsteht die TPS-Datei entsprechend schneller). > Ich wiederhole mich zwar, aber das kann der > Treiber garnicht, da beim Druckertreiber keine > Infos zu Live-Transparenzen mehr ankommen bzw. in > Form von pdfmarks (die der Treiber nicht > verarbeitet) oder von programm-spezifischen > Kommentaren (wie bei AI-EPSen), die der Treiber nicht > verarbeiten kann. Genau diese Intelligenz aber hatte ich dem "Adobe PDF"-Druckertreiber unterstellt. Schließlich ist der "Adobe PDF"-Druckertreiber kein "gewöhnlicher" Druckertreiber, der (ausschließlich) auf die Standard-Engine im Betriebssystem für das Erstellen von PostScript-Druckerdaten zurückgreift (dass da mehr passiert belegen die unterschiedlichen Zeiten für die Generierung der (T)PS-Datei). > >Das muss ich überlesen haben. Welche Sonderheiten könnte es in TIF > >geben, die besonderer Beachtung bedürfen? > Das ist eben die Frage. > Evtl. werden vom Treiber in der TIF-Datei > vorhandene Komprimierungen aufgehoben und dann erst das Bild > verarbeitet? Das könnte man vermuten -- aber ich vermute ja nichts mehr. > Ein weiterer Punkt, weshalb auch TIF-Dateien > (Alphakanal) zu einer Verlangsamung des Prozesses führen können. Das zu testen, überlasse ich anderen. Allerdings müssten die Alphakanal-Informationen letztlich auch beim RIP ankommen: Der Druckertreiber kann ja nicht einfach die unter Alphakanal-Transparenzen liegenden Vektorgrafiken in Pixel konvertieren. > > > >4 ++ Der Distiller-Druckertreiber verursacht beim > "Drucken" eine > > > >deutlich höhere Prozessorlast als beim "Speichern als PDF" > > > > > > Spielt das eine Rolle für die Dauer des Druckens? > > > >Es deutet darauf hin, dass der Prozessor tatsächlich etwas macht -- > >"und nicht nur Däumchen dreht". > > Solange die CPU unter 100% Last bleibt, sollte > das aber keine derartige Verlangsamung des Druckprozesses zur > Folge haben. Das wollte ich auch nicht damit sagen. > >Da außerdem zu vermuten ist, dass der Leerlauf > >durch langsame RAM-Zugriffe entsteht (im Gegensatz zu schnellen > >Cache-Treffern), werden während des "Druckens" "dicht beieinander > >liegende" Daten intensiv bearbeitet. > > Beim "Sichern als PDF" wird vom System _deutlich_ > mehr Speicher angefordert als beim "Drucken in Datei" (ca. > doppelt soviel RAM). Das widerspricht meiner Aussage nicht. Mit Cache meinte ich jenen auf dem Prozessorchip (nicht den Festplatten-Cache). Da sicher auch Sie für die Tests keine extragroßen Projekte gewählt haben, hat sich vermutlich außer dem einmaligen Lesen der Quellen und dem einmaligen Schreiben der (T)PS-Datei alles im RAM abgespielt. > Meine Vermutung ist, daß beim Weg über den > Druckertreiber erst die jeweilge Seite in das > PS-File geschrieben wird und anschließend die > benötigten PDFmark-Befehle generiert werden. > Beim "Sichern als PDF" scheinen deutlich > effizientere Mechanismen zum Tragen zu kommen > (ist ja auch später programmiert worden und kann > direkt auf die FM-Objekte zugreifen). Da in beiden Fällen (Drucken in PS-Datei und Speichern als PDF) eine PostScript-Datei (mit Dateinamenerweiterung PS bzw. TPS) erstellt wird, die völlig identisch sind, gehe ich davon aus, dass auch beim "Speichern als PDF" der Druckertreiber "Adobe PDF" (alias "Acrobat Distiller") die PS-Datei schreibt. Es ist ausgesprochen unwahrscheinlich, dass unterschiedlicher Code, der auch noch unterschiedliche Mechanismen nutzen soll, absolut dieselbe Ergebnisdatei produzieren. > Für mich der Hinweis, daß das Zusammenspiel von > FM und Druckertreiber entscheidend ist. > Das kann aber abschließend nur von den > Adobe-Programmierern (FM und/oder Treiber) beantwortet werden. Das war mein Ausgangspunkt: Abhängig vom Endziel des Prozesses werden an den Druckertreiber "Adobe PDF" unterschiedliche Parameter übergeben, die dafür sorgen, dass beim Drucken in eine PostScript-Datei zusätzliche Prüfungen ausgeführt werden. Wobei ich auch daran erinnern möchte, dass das Drucken in Datei mit einem anderen PS-Druckertreiber zu ähnlichen Zeiten für die Erstellung der PS-Datei führt, wie beim "Speichern als PDF" für die Erstellung der TPS-Datei benötigt werden. Das Zusammenspiel dürfte beim Druckertreiber für einen Dritthersteller-Drucker von Seiten FM kaum besser optimierbar sein, als für den Druckertreiber "Adobe PDF". Aber: Nachdem ich versehentlich im Drucken-Dialog die Option "Ausgabe in Datei" deaktiviert hatte, der Druckertreiber "Acrobat Distiller" daraufhin mir als Ergebnis gleich eine PDF-Datei präsentierte, in diesem Fall für Druck und PDF-Generierung aber noch viel länger brauchte, als für alle anderen Szenarios, kann ich nicht mehr glauben, dass hier absichtsvolle Prüfungen und Optimierungen abhängig vom Zielmedium (PDF-Datei, RIP in einem realen Drucker) ausgeführt werden. Das erklärt zwar nicht die zeitlichen Unterschiede, aber ich vermute als Ursache nicht mehr systematische Optimierungen der Ergebnisdatei. PS: Es gibt Leute, die haben die Acrobat-Vollversion und setzen dennoch den von mir gepflegten PDF-T-Maker ein -- weil er das, was er macht, erheblich schneller als der PDFMaker erledigt. Viele Grüße Johannes Graubner mailto:[EMAIL PROTECTED] Tel. 0179-66 55 215 (O2) / 03641-620 540 http://www.transcom.de Fax 0941-5992 95552 -- --------------------- [ SECURITY NOTICE ] --------------------- To: [EMAIL PROTECTED] For your security, [EMAIL PROTECTED] digitally signed this message on 29 November 2007 at 22:52:59 UTC. Verify this digital signature at http://www.ciphire.com/verify. ---------------- [ CIPHIRE DIGITAL SIGNATURE ] ---------------- Q2lwaGlyZSBTaWcuAjh0YWxrQGZyYW1lbWFrZXIuZGUAZ3JhdWJuZXJAdHJhbnNj b20uZGUAZW1haWwgYm9keQB8FQAAfAB8AAAAAQAAAMtCT0d8FQAAsQIAAgACAAIA IOgusu0P2naCWjmEVZYRBWBXco5V1pxY0W0/kHDvji5AAQCmM6EfbaCHZT8VLiD/ btdrC0b6IZsT1dYMXp0UXd8zeJsXpsR2hr5eAldqtzNPQQf+71wHs9chPEpjAeFc 9LAD1QcAU2lnRW5k ------------------ [ END DIGITAL SIGNATURE ] ------------------ _______________________________________________ Talk mailing list [email protected] http://lists.framemaker.de/mailman/listinfo/talk
