Hallo Her Graubner, nach dem Lob und der Anregung durch Hr. Schulze müssen wir das ja weiterführen ... :-)
> > ich kenne keine Software, die Vermutungen anstellt. > >OCR-Software, Schach- und sonstige bislang nicht vollständig gelöste >Brettspielprogramme, es gibt einen ganzen Zweig der Computerwissenschaft, >der mit Wahrscheinlichkeiten (also Vermutungen) rechnet: KI und Fuzzy Logic. also für mich ist eine Vermutung etwas anderes als eine Wahrscheinlichkeit. Vermutungen können mehr oder weniger stark von Wahrscheinlichkeiten beeinflußt sein, gehen aber nach meinem Dafürhalten weit darüber hinaus. Daher sind KI und FuzzyLogic erest auf dem Weg hinzu Vermutungen, aber der ist noch weit. Allerdings wird dies eine philosophische und semantische Diskussion. >Im konkreten Fall allerdings hat die Vermutung der Programmierer angestellt >und seinem Programm fest mitgegeben. Eben. > > >Im ersten Fall übergibt er die in der Quelle > > >enthaltenen EPS-Dateien ungeprüft und unverändert an die > > >PostScript-Datei (und damit an den Distiller), im zweiten > > untersucht er > > >die EPS-Dateien in einem zeitraubenden Prozess -- um gegebenenfalls > > >Änderungen vorzunehmen. > > > > Da als Ziel-Drucker sowohl bei Hr. > > Müller-Hillebrand wie auch bei meinen Tests der > > "Adobe PDF"-Drucker - mithin also der Distiller - > > angegeben war, hätte es nach Ihrer Vermutung das > > Problem nicht geben dürfen. Oder? > >Ich gehe mal davon aus, dass "Acrobat Distiller" und "Adobe PDF", wenn sie >denn so im "Dokument drucken"-Dialog von FM im Feld "Drucken" ausgewiesen >sind, Synonyme sind. Ich habe keinen "Adobe PDF" in der Liste der >installierten Druckertreiber. Der "Distiller Drucker" heißt seit Acrobat v6 "Adobe PDF". >Es durfte also nicht nur das Problem geben, Sie hatten es. 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? > > "Adobe PDF"-Drucker - mithin also der Distiller - > >Ich gehe davon aus, dass Sie hier auch verkürzt schreiben und wohl wissen, >dass der Druckertreiber nicht der Distiller selbst ist. Dieser Ausriß alleine macht wenig Sinn als Zitat, da der Zusammenhang verloren geht. Ich hebe hier darauf ab, daß - nach Ihrer Ansicht - der Druckertreiber sich "ansieht", welcher Drucker angesteuert werden soll - hier der Distiller -, und danach der Druckertreiber sein weiteres Vorgehen festlegt. Deshalb mein Hinweis auf den Distiller als "Endgerät". > > Live-Transparenzen können bis heute - von ganz > > wenigen Ausnahmen abgesehen - von keinem Drucker/RIP > > verarbeitet werden. Erst jetzt fangen die Drucker-/RIP-Hersteller an, > > diese Funktionen zu unterstützen. Allerdings als > > PDF-Druckengine implementiert. > >Da widerspreche ich Ihnen doch gar nicht. Aber weil das so ist, dass Drucker >diese nicht unterstützen, wohl aber PDF. Gerade weil es in PDF und auf dem >Drucker unterschiedliche Funktionalitäten gibt, vermute ich, dass der >Druckertreiber "korrigierend" eingreift. 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. > > Deshalb gibt es keine Live-Transparenz in PS-Files, nicht > > einmal aus InDesign. > >Da haben Sie aber in einer früheren Mail etwas anderes geschrieben: In der >"verpackten" Variante (EPS-Dateien) würden die Transparenzinformationen in >PS-Kommentaren stehen. Ich schrieb, daß es möglich ist, aus Adobe Illustrator EPSe in besonderer Form abzuspeichern (als bearbeitbares EPS). Dort sind quasi zwei Dateien enthalten: einmal ein normales EPS mit flachgerechneten Transparenz-Effekten und als zweite "Datei" sind besondere AI-spezifische Kommentare enthalten, die es AI und tw. InD & PS erlauben auf die originalen Transparenz-Einstellungen von AI-Objekten Zugrif zu nehmen. AI kann daher eine solche EPS-Datei wieder als vollständig bearbeitbare Datei öffnen, aber eben auch nur AI. Einfacher Test: speichern Sie eine solche Datei aus AI einmal als bearbeitbar und einmal als normales EPS ab, Sie werden feststellen, daß die erste EPS-Datei deutlich größer ist als die zweite Version. > > >2 ++ Keine zeitlichen Unterschiede sind für Quelldateien > > feststellbar, > > >die keine EPS-Dateien verlinkt oder eingebettet haben > > > > Nicht richtig, da auch bei Verwendung von > > TIF-Bildern der Druckertreiber etwa doppelt solange braucht. > >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? > > >3 ++ Werden die FM-Dateien "gedruckt", dauert insbesondere das > > >"Drucken" jener Seiten besonders lange, auf denen EPS-Dateien > > >verlinkt/eingebettet sind. Dieses "Stottern" ist nicht > > erkennbar, wenn > > >die FM-Dateien "als PDF gespeichert" werden. > > > > Habe ich so noch nicht festgestellt, aber auch noch nicht > > darauf geachtet. > >Ist bei meinen Testdaten (EPS-Dateien unter anderem mit eingebetteten >Alphakanaltransparenz-TIFs) sehr auffällig. Ein weiterer Punkt, weshalb auch TIF-Dateien (Alphakanal) zu einer Verlangsamung des Prozesses führen können. > > >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. >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). Für mich ein Hinweis darauf, daß beim "Sichern als PDF" die Verarbeitung größtenteils im schnellen RAM stattfindet. > > Ergänzung: > > Ich habe nochmal getest und folgendes festgestellt: > > - Sichern als PDF: Dauer bis TPS = 30 Sek. > > - Drucken in Datei MIT aktiviertem "Acrobat-Daten generieren" > > = 50 Sek. > > - Drucken in Datei OHNE aktiviertes "Acrobat-Daten > > generieren" = 30 Sek. > > > > Das würde Sinn machen, da das Generieren der > > Acrobat-Daten (Lesezeichen, Hyperlinks, TaggedPDF > > etc.) zusätzliche Zeit in Anspruch nimmt. > >Nein. Nach meiner Meinung: Ja. 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). >1. Schalten Sie die Rich PDF-Merkmale auch für "Speichern als PDF" ab, >dürfte sich die Generierung der TPS-Datei um dieselbe absolute Dauer >verkürzen. Das Abschalten verkürzt die Zeit beim "Sichern als PDF" von 30 auf 26 Sek. >2. PS-Datei-Generierung dauert bei mir immer noch deutlich länger. Bei mir - wie geschrieben kaum - noch. >3. Bei FM-Dokumenten mit nur WMF-Bildern und Rich PDF-Erzeugung gab es bei >mir keine nennenswerten zeitlichen Differenzen zwischen "Drucken" und >"Speichern als PDF". 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. Alles weitere ist Spekulation. Grüße Stephan Will _______________________________________________ Talk mailing list [email protected] http://lists.framemaker.de/mailman/listinfo/talk
