Home Previous Zeitschrift 1999/11 Next Index
  Inhalt: 

    Seitenbeschreibung  

    Dateigröße  

    Schriften  

    Fontdescriptoren  

    Kontrollstrukturen  

    Editierbarkeit  

    graphische Objekte  

    Problem Druckertreiber  

    Autor  

 

Altlasten- von  Postscript zu PDF 

Teil2: Das Portable Document Format 

Im ersten Teil dieses Artikels wurde dargestellt, wie verschiedene Eigenschaften von Postscript, nämlich Dateigröße, fehlende Editierbarkeit und fehlende Seitenunabhängigkeit zu Verstimmung in der Druckvorstufe führen kann. Im folgenden zweiten Teil wird untersucht, inwiefern das Portable Document Format (PDF) diese Probleme löst. 

Seitenbeschreibung in PDF 

Die Grundidee von Postscript war die geräteunabhängige Seitenbeschreibung. Eine Seite wird beschrieben, indem die Bewegungen eines imaginären Zeichenstiftes auf der Seite aufgelistet werden. Diese Idee war so gut, daß sie in PDF beibehalten wurde. In PDF wird eine Seite auf die gleiche Weise beschrieben wie in Postscript. Adobe hat nur die Zeichenbefehle abgekürzt, um Platz zu sparen. Die Unterschiede zwischen PDF und Postscript (die, vom Seitenmodell einmal abgesehen, gewaltig sind) haben zwei Gründe: 

  • die bekannten Nachteile von Postscript sollten vermieden werden
  • PDF sollte für die Ausgabe von Dokumenten am Bildschirm optimiert werden. 
Die Frage ist, ob PDF hält, was es verspricht (oder was sich viele Leute davon versprechen). 

Größe von PDF-Dateien 

Sind PDF-Dateien kürzer als Postscriptdateien? Ein klares Ja ist die Antwort. Zu welchem Preis? PDF-Dateien sind mit genormten Kompressionsalgorithmen komprimiert. Das Dateiformat wird dadurch intransparent und kann zum Beispiel nicht mehr (wie Postscript) mit einem einfachen Texteditor beabeitet werden. Aber das will ja auch niemand. Die verwendeten Kompressionsalgorithmen sind für Texte und Zeichnungen reversibel. Für Bilder wird das nicht reversible Verfahren jpeg verwendet. Dies bedeutet in der Praxis hauptsächlich, daß ein Bild, das einmal den Zyklus Kompression - Dekompression durchlaufen hat, nicht ein zweites Mal komprimiert (gepackt) werden darf. Die Kompressions- und Dekompressionszeit ist im Vergleich zu der übrigen Verarbeitungszeit einer Datei minimal. Die Tatsache, daß PDF-Dateien komprimiert sind hat also in der Praxis keinen Nachteil. 

Umgang mit Schriften 

Anders ist dies mit dem anderen Sparkonzept von PDF: Dem Umgang mit Schriften. Wie im ersten Teil des Artikels beschrieben, verbrauchen Schriftbeschreibungen in Dateien viel Platz, da das Aussehen jedes einzelnen Zeichens beschrieben werden muß. Schon in Postscript wurde deswegen versucht, die Schriftbeschreibungen auf den Ausgabegeräten gespeichert zu halten und in den Dateien nur die Schriftnamen mitzuliefern. Wenn allerdings in der Datei eine Schrift verwendet wird, deren Beschreibung weder in der Datei selbst noch im Ausgabegerät zu finden ist, führt dies zu den in jedem Vorstufenbetrieb bekannten Schriftproblemen. 

Bei PDF tritt dieses Problem tendenziell verschäft auf: Das Datenformat ist ursprünglich für die Ausgabe auf Bildschirmen konzipiert (und auch heute noch werden für den Druck relevante Features des Formats eher stiefmütterlich behandelt, wie im PDF Whitepaper zu lesen ist ). Bei einfacher Bildschirmausgabe kommt es besonders häufig vor, daß ein Computer eine Schrift nicht auf Lager hat - schließlich installieren die meisten Benutzer nur die Standardschriften - und trotzdem soll das Dokument nie schlecht aussehen. PDF regelt dies durch das Konzept der Fontdescriptoren. 

Fontdescriptoren 

Im einzelnen funktioniert die Darstellung von Text in PDF folgendermaßen: 

Ein Text soll in einer bestimmten Schrift dargestellt werden. Ist die Schriftbeschreibung im Dokument enthalten (eine eingebettete Schrift, wie aus Postscript bekannt), sind alle glücklich: Die Schrift wird verwendet. Sollte dies nicht der Fall sein, ist noch lange nicht alles verloren: 

Das  Programm, das die PDF-Datei verarbeitet, schaut, ob die Schrift auf dem Ausgabegerät vorhanden ist und das Problem mit Bordmitteln gelöst werden kann. Sollte dies auch nicht der Fall sein, wird die Notbremse gezogen: Der Fontdescriptor kommt zum Zug. Es handelt sich hierbei um einen Datensatz, der den Schriftschnitt, die Dickten, die Schriftfamilie und die Strichstärken der gesuchten Schrift beschreibt. Dieser Datensatz ist für jede verwendete Schrift in einer PDF-Datei enthalten. Aus einem universellen Schriftsatz (einem sogenannten „Multiple Masters Font“) wird eine Schrift mit demselben Fontdescriptor wie die ursprüngliche Schrift errechnet. Dabei erhofft man sich, die Anmutung der Seite wenigstens annähernd wiederherzustellen. 

Bei ungewöhnlichen Sonderschriften kann es allerdings schon mal vorkommen, daß sich das Resultat vom Beabsichtigten erheblich unterscheidet. Typographen müssen bei diesem Vorgehen von ihren üblichen Qualitätsansprüchen natürlich ziemliche Abstriche machen, verglichen mit der gewohnten Qualität einer Bildschirmausgabe ist das Resultat jedoch sehr gut. 
 

 
 

Abbildung 1: Das Konzept der Fontdescriptoren 

 
Kontrollstrukturen und Seitenunabhängigkeit 

Das leidige Problem der Seitenunabhänigkeit wird bei PDF ein für alle Male gelöst. Die Kontrollstrukturen, die bei Postscript die Seitenunabhängikeit verhinderten, sind abgeschafft und das Format legt explizit Wert darauf, daß jede Seite einzeln in der selben Zeit gerippt werden kann. 

Editierbarkeit von PDF 

Ist PDF wirklich bis zum Ende editierbar? Wie schon im ersten Teil des Artikels müssen wir uns fragen, was das Wort „editierbar“ bedeutet. Betrachten wir einmal die Objekte, die wir editieren wollen: 

Zeichen: 
Einzelne Zeichen können, wie schon bei Postscript, ausgetauscht werden. 

Wort: 
Der Textfluß ist in Zeilen zusammengefaßt. Bei Flattersatz können einzelne Wörter verändert werden, wenn sich dadurch die Zeilenlänge nicht zu stark ändert. Bei Blocksatz hingegen ist das Editieren in der Praxis unmöglich. Da aber Information über Anfang und Ende der Zeile vorhanden ist, sind Werkzeuge zum Editieren von Zeilen im Blocksatz immerhin denkbar und werden auf dem Markt erhältlich sein. 

Schwieriger wird es bei der Veränderung von Absätzen oder anderen Manipulationen, die Auswirkungen über Seitengrenzen hinweg haben. Zwar kann bei PDF jede einzelne Seite getrennt und unabhängig von anderen Seiten belichtet werden, Informationen über die Bedeutung von Seitenzahlen, Querverweisen und Fußnoten sind jedoch in PDF-Dateien nicht vorhanden. 

Wenn also ein Autor zu einem Text einen langen Absatz hinzufügt, stimmt der Umbruch nicht mehr. Seitenzahlen, Inhaltsverzeichnis und Querverweise können fehlerhaft werden. Da ein universelles Dateiformat (eine digitale eierlegende Wollmilchsau) nicht sinnvoll machbar ist, werden solche Korrekturen immer in der (offenen) Quelldatei vorgenommen werden müssen. 

Editieren von graphischen Objekten 

Anders ist dies bei graphischen Objekten: Nehmen wir an, auf einem Bild sei ein Baum mit Blättern. Wenn ich das Bild nun editiere, indem ich den Baum verschiebe, will ich nicht, daß die Blätter stehenbleiben und nachher einzeln verschoben werden müssen. Der Computer benötigt hierfür die Information, daß Blätter und Stamm in ein und demselben Objekt „Baum“ vorkommen. Solches Zusammenfassen von Grundelementen zu einem Objekt ist in reinem Postscript nicht vorgesehen, in DSC immerhin erwähnt. In PDF ist es Grundlage des Dateiformats. 

Leider wird es beim derzeitigen Stand der Technik trotzdem nicht voll verwirklicht. Der Baum bleibt uneditierbar. Der Grund dafür liegt in der Art, wie wir PDF-Dateien erstellen: Die Informationen über das Objekt „Baum“, die im Zeichenprogramm vorhanden sind (denn dort kann der Baum ja editiert werden) gehen schon bei der Erzeugung von Postscript verloren. Warum? 
 
 

Abbildung2: Objekteditierbarkeit 

Das Problem sind die Druckertreiber 

Postscript wird normalerweise auf einem Rechner von dem Programm namens „Druckertreiber“ erstellt. Wie arbeitet solch ein Druckertreiber? 

Wenn in einem DTP-Programm ein Layout erstellt wird und gedruckt werden soll, muß das Datenformat des DTP-Programms in die Sprache des Druckers übersetzt werden. Der Hersteller des DTP-Programms weiß nicht, welcher Drucker nachher mit dem Programm  verwendet wird und der Hersteller des Druckers kennt das DTP-Programm nicht. Wer soll das Programm, das die notwendige Übersetzung vornimmt, entwickeln? Nach einigen weniger perfekten Lösungen (man erinnere sich noch an die DOS-Welt, in der jedem Programm eine Unmenge von Treibern mitgeliefert wurden) kennt man heute das Konzept der Druckertreiber: 

Der Hersteller des Betriebssystems entwirft und veröffentlicht eine Zwischensprache, die verwendet werden muß, wenn der Drucker angesprochen werden soll. Für die Windows-Welt heißt diese Zwischensprache beispielsweise GDI (graphics direct interface), für die Mac-Welt Quick Draw. Der Hersteller des DTP-Programms weiß jetzt, welche Sprache das Programm sprechen muß, wenn der Benutzer den Befehl zum drucken gibt. 

Der Hersteller des Druckers liefert den Druckertreiber. Dieser übersetzt die Befehle von der Zwischensprache in die Sprache des Druckers. Die Seitenbeschreibung wird also von der Sprache des DTP-Programms in die Zwischensprache und dann in die Sprache des Druckers übersetzt. Dieses Konzept ist für alle Seiten zufriedenstellend und bewirkt, daß heute auch nicht-postscript-fähige Drucker mit vielen Programmen zufriedenstellen zusammenarbeiten. 

 
 

Abbildung 3: Programme und Sprachen beim Desktop-Publishing

 
Der Grund, weswegen bei der Übersetzung via Druckertreiber notwendigerweise Objektinformationen verloren gehen, ist die Zwischensprache. Diese Sprachen kennen keine Befehle für Anfang und Ende von Objekten. Für ein Ausgabegerät, das ja immer die ganze Seite abbildet, sind diese Informationen nämlich unwichtig, und die Zwischensprachen wurden ausschließlich zur Bedienung dieser Geräte entworfen. Wenn also Postscript über Druckertreiber entworfen wird, dann kann dieses Postscript die Editierbarkeit von Objekten, die komplexer als eine Zeile sind, nicht unterstützen. Dasselbe gilt natürlich auch für eine PDF-Datei, die aus diesem Postscript erzeugt wird und auch für PDF-Daten, die direkt über den PDF-Writer erzeugt wurden, denn dieser ist ja nichts anderes, als ein spezieller Druckertreiber. 

Die einzige Art und Weise, dieses Manko zu umgehen, wäre die Erzeugung von PDF direkt aus dem DTP-Programm heraus. Dies wird, wenngleich auch noch recht  fehlerhaft, von einigen Programmen bereits angeboten und wird in wenigen Jahren zum Standard gehören. Es besteht also Hoffnung, daß in Bälde der Traum vom „bis ans kurz vor der Belichtung editierbaren PDF“ in den Grenzen, die diesem Datenformat inhärent sind, wahr wird. 

Oft wird auch davon (tag-)geträumt, PDF als „digitalen Proof“ zu verwenden. Ein Beispiel: ein Kunde in Paris möchte etwas in Hamburg drucken lassen. Er schickt einen Entwurf als PDF-Dokument über Kabel nach Hamburg, dort wird der Entwurf nachgearbeitet und das fertige Produkt (auch eine PDF-Datei) nach Paris zurückgeschickt. Der Kunde dort schaut sich die Datei an, gibt sein Placet und in Hamburg kann gedruckt werden. Welche Überraschungen birgt diese Vorgehensweise? 
 

  • Die Nachbearbeitung des PDF-Dokumentes ist wegen der eingeschränkten Editerbarkeit des Datenformats fraglich. Hier müßte ziemlich sicher die (offene) Orginaldatei mitgeschickt werden. Das PDF-Dokument wäre trotzdem als Muster wichtig: „So will ich es haben“. Es fehlen noch Werkzeuge zur professionellen Bearbeitung von PDF-Dateien. Außerdem kann PDF, wie oben ausgeführt, nicht alle Ansprüche an Editierbarkeit erfüllen. 
  • Die Probleme beim digitalen Proof lassen sich in drei Klassen zusammenfassen: Farbe, Schrift, OPI-Bilder. 
Farbe: 
Es gibt, wie in Postscript, in PDF die Möglichkeit, verbindliche Farben nach dem CIE-LAB Standard anzulegen. Es muß, um bei den Farben keine Überraschungen zu erleben, sichergestellt sein, daß der Autor die Farben nach diesem Standard anlegt. Aber damit nicht genug. Um völlige Übereinstimmung der Farbvorstellung zwischen Kunde und Druckerei zu ermöglichen, muß das Ausgabeverfahren an beiden Orten identisch sein: Gleiches Druckverfahren, gleicher Bedruckstoff, gleiche Beleuchtung, gleich kalibrierte Proofdrucker. Dann klappt´s (hoffentlich). 

Schrift:  
Es muß (wie bei Postscript) sichergestellt sein, daß Kunde und Druckerei exakt dieselben Schriften verwenden. Enfweder, der Kunde bettet alle Schriften in das Dokument ein (was die Dateien aufbläht) oder die Schriften stimmen exakt überein. Hier ist intensive Kommunikation und peinlich genaue Organisation notwendig. Sonst kann bei PDF durch die Schriftersetzung ein versteckter Fehler eintreten: Wenn eine Schrift bei der Druckerei nicht vorhanden ist, wird sie dort durch eine ähnliche ersetzt. Wenn dies niemand bemerkt, dann kann es auch der Kunde dem digitalen Proof nicht ansehen. Auf seinen Rechnern ist die Schrift schließlich vorhanden, also wird sie beim Ausdruck verwendet. 

OPI-Bilder:  
Das OPI-Verfahren, also die Ersetzung von Grobdatenbilder durch Feindatenbilder vor dem Belichter, ist in PDF, wie auch in Postscript, vorgesehen. Wie bei den Farben ergeben sich hier aber für den digitalen Proof einige Schwierigkeiten genereller Art: Es muß sichergestellt sein, daß die Feindatenbilder bei der Druckerei sind, und daß es sich um genau die Bilder handelt, die der Kunde haben will. Diese Bilder, deren Dateien sehr groß sein können, müssen irgendwie der Druckerei zur Verfügung gestellt werden. Bei den heutigen Übertragungsgeschwindigkeiten, kann hier die Grenze erreicht werden, bei der ein Kurrierdienst billiger wird als die Übertragung über Kabel. Dies wird sich jedoch in wenigen Jahren ändern, denn die Bandbreiten der Netze werden immer größer. 

PDF als digitaler Proof ist also höchstens mit einer enorm leistungsfähigen und genauen Arbeitsorganisation und mit intensiver Kundenkommunikation möglich. Hier ist das Format (von den kleineren Dateigrößen abgesehen) nicht besser geeignet als Postscript. 

 
 
                                Abbildung 4: Der Kurrierdienst kann billiger sein
 
Wenn Sie Interesse an der Einführung des PDF-Workflows und oder am digitalen Proof haben, können Sie sich an den Autor wenden. 

 

Axel Benz
(Beratung PDF im Betrieb)
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
axel.benz@iao.fhg.de
 

Zum Seitenanfang
 


© ADOLPH Verlag GmbH - Letztes Update 03.05.2004