Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03522.jsonl.gz/2286

Hallo Joe,
eine Gegenfrage: Denken Sie, dass die Tatsache, dass Sie unter Mac OS 9.x im Druckertreiber einen PostScript Level anwählen konnten, Ihnen tatsächlich die Möglichkeit gab, im großen maßstab Einfluß darauf zu nehmen, welcher PostScript Code von einem Layoutprogramm egneriert wurde?
Unsere heutigen, professionellen Layoutprogramme generieren ihren PostScript-Code überwiegend oder ausschließlich selbst und überlassen dies nicht dem Druckertreiber. So war es z.B. in allen QuarkXPress Versionen vor 6.0 reine Augenwischerei im Treiber auf PostScript 3 umzuschalten zu können, weil diese Programmversionen einfach noch keine Zeile PostScript 3 Code beherrschten und dem Treiber nur die Schrifteinbettung überliesen.
Ein weiterer Grund dafür, dass die Wahl des PostScript-Levels eigentlich unnötig bzw. nutzlos ist, ist die Tatsache, dass jedes im Layout platzierte EPS oder PDF einen "eigenen" PostScript Level einschleppt der ebenfalls völlig unbeeinflußt von der Wahl des Levels im Druckertreiber bleibt.
Der korrekte Ansatz ist, den PostScript Level aus der verwendeten PPD-Datei auszulesen und sich als Applikation daran zu orientieren (soweit das aus oben genannten Gründen überhaupt möglich ist).
Zusätzlich kann man den Code noch so aufbereiten, dass dynamisch während der Verarbeitung entscheiden wird, ob ein PostScript 3 oder Lvel 2 Codeteil abgearbeitet wird. Dies macht z.B. Adobe InDesign über die Abfrage des PostScript Levels im PostScript-Code während der Interpretation.
Die Wahl der Ausgabekodierung (binär oder ASCII) ist so eine Sache. Hersteller wie Adobe behaupten, dass aus technischen Gründen unter Mac OS X bei der Ansteuerung eines Ausgabegeräts nur ASCII85 möglich ist (daher ist dies Wahlmöglichkeit bei Ansteuerung eines Ausgabegeräts ausgegraut und nur beim Drucken in eine Datei aktiv). Ob es tatsächlich so ist kann ich nicht beurteilen.
Das ist aber auch kein Beinbruch, weil Mac OS X kein ASCIIHex, sondern eben ein ASCII85 erzeugt. Ersteres führt bei Bilddaten zu einer Verdoppelung des Datenvolumens gegenüber Binärdaten. Das wäre zugegebenermassen schlecht. ASCII85 füht im ungünstigen Fall aber höchstens zu einem Anwachs um den Faktor 1,25. In der Praxis ist es oftmals aber sogar kompakter als Binär, weil Vorkommen von Nulldatgen (also viele Datennullen hintereinander) sehr kompakt kodiert werden können.
Somit besteht als kein Anlaß zur Panik.
Mit freundlichen Grüßen
Robert Zacherl
************************
IMPRESSED GmbH http://www.impressed.de
als Antwort auf: [#88999]