Adobe Spezifikationen
Die Firma Adobe Systems hat uns 1991 die Veröffentlichung dieser Spezifikation freundlicherweise genehmigt.
Das Encapsulated PostScript File (EPSF) Format ist ein Standard-Format für den Austausch von PostScript-Files zwischen Anwendungen auf verschiedenen Plattformen. Dieser Teil beschreibt die Einzelheiten des Formats und enthält besondere Informationen über die Umgebungen des Macintosh und von MS-DOS.
Das EPSF-Format basiert auf den Document Structuring Conventions (DSC) in Appendix G des Reference Manuals (Second Edition). Wenn sich ein PostScript-File an das EPSF-Format halten soll, dann müssen die DSC-Spezifikationen richtig befolgt werden.
Dieser Teil besteht aus folgenden Hauptthemen:
Abbildung B.1: Dokument mit EPS-File
Anwendungen, die "conforming" EPS-Files erzeugen, müssen die Richtlinien in Abschnitt 2 "Richtlinien für das Erzeugen von EPS-Files" befolgen. Es gibt zwei erforderliche DSC-Kommentare, einige bedingt erforderlichen Kommentare, sowie mehrere Programmier-Richtlinien; diese stellen sicher, dass ein EPS-File in eine beliebige PostScript-Seitenbeschreibung importiert werden kann, ohne störende Seiteneffekte zu verursachen. Ein Beispiel eines Seiteneffektes ist das Löschen einer Seite des importierenden Dokuments oder das Beenden des ganzen Druckjobs.
Anwendungen, die EPS-Files importieren, müssen die Richtlinien in Abschnitt 3 "Richtlinien für das Importieren von EPS-Files" befolgen. Eine Anwendung, die ein EPS-File importiert, muss das EPS-File auf DCS-Kommentare absuchen und mindestens die Bounding Box und die Abhängigkeiten (Ressourcen) festhalten. Die Anwendung sollte zudem die Bildschirm-Darstellung einlesen und anzeigen - falls diese vorhanden ist. Enthält das EPS-File keine Bildschirm-Darstellung, dann muss die Anwendung eine Ersatz-Darstellung zur Verfügung stellen, damit der Benutzer das EPS-File am Bildschirm positionieren und transformieren kann. Die Anwendung darf die Manipulationen des Benutzers erst dann in PostScript-Befehle (translate, scale, etc.) umsetzen, wenn das Dokument auf den Drucker geschickt wird. Zudem muss die Anwendung ihre Stacks, das aktuelle Dictionary und den grafischen Status sichern, bevor das importierte EPS-File ausgeführt wird.
Beachten Sie, dass EPS-Files "final-form"-Darstellungen sind. Sind sie einmal in ein Dokument importiert, können sie nicht mehr editiert werden. Allerdings kann ein EPS-File als ganzes bis zu einem gewissen Grad manipuliert werden: Sie können ein EPS-File verschieben, drehen, vergrössern/verkleinern und zuschneiden.
Die Geräte-unabhängige Natur der PostScript-Sprache macht diese zu einem ausgezeichneten Austauschformat. Allerdings ist ein PostScript-Interpreter erforderlich, um ein EPS-File am Bildschirm betrachten zu können. Display PostScript ermöglicht es, EPS-Files dynamisch zu interpretieren. Dies garantiert eine höchstmögliche Qualität der Bildschirm-Darstellung, unabhängig von Vergrösserungsfaktor, Drehung und Bildschirm-Typ. Auf Plattformen ohne Display PostScript kann das EPS-File eine zusätzliche Bildschirm-Darstellung enthalten. Die optionale Bildschirm-Darstellung ist vom EPSF-Format ausdrücklich vorgesehen.
Das Format der Bildschirm-Darstellung unterscheidet sich je nach System. Es ist typischerweise eine PICT-Ressource des Macintosh, ein TIFF-File oder eine Geräte-unabhängige hexadezimale Bitmap. Wenn das EPS-File keine Bildschirm-Darstellung enthält, dann muss die importierende Anwendung eine Hilfsdarstellung zur Verfügung stellen, etwa ein graues Rechteck, das die Grösse der Illustration anzeigt. Mithilfe der Bildschirm-Darstellung kann der Endbenutzer das EPS-File im Dokument plazieren und skalieren.
Um EPS-Files zu unterstützen, braucht es die Zusammenarbeit zwischen der Anwendung, die EPS-Files erzeugt, und derjenigen, die EPS-Files verwendet. EPS-Files werden normalerweise von anderen Dokumenten importiert oder eingebettet.
Alle DSC-Kommentare in einem EPS-File stellen Informationen zur Verfügung. Wie eine Anwendung diese Informationen nutzt, ist Sache des Programmierers der importierenden Anwendung. Wenn Sie ein EPS-File importieren, reduzieren Sie den Informationsgehalt des EPS-Files bitte nicht, indem Sie DSC-Kommentare entfernen oder ändern. Grundsätzlich zeigen die Kommentare auf, welche Ressourcen und Spracherweiterungen wo im EPS-File verwendet werden. Encapsulated PostScript Files sind "final-form" Druckfiles, die nichts über den Drucker wissen, auf dem sie ausgedruckt werden. Falls ein EPS-File besondere Ressourcen benötigt, z.B. Fonts, dann müssen diese Erfordernisse sorgfältig erhalten und weitergegeben werden.
Eine Anwendung, die PostScript-Sprachfiles generiert, ist eine mögliche Verbraucherin und Erzeugerin von EPS-Files. Am besten dürfte es sein, nicht daran zu denken, dass man sich an einem bestimmten Ende der "Transportkette" befindet. Wenn Ihre Anwendung ein EPS-File importiert, dann ist sie verantwortlich für das Einlesen und Erkennen der Ressourcen, die vom EPS-File benötigt werden. Diese Erfordernisse sollten sich in den DSC-Kommentaren des importierenden Hauptdokuments widerspiegeln. Wenn z.B. das importierte EPS-File den Lithos-Font verwendet und der Rest des Dokuments in Times-Roman gesetzt ist, dann verwendet das Dokument jetzt ebenfalls den Lithos-Font, da das EPS-File importiert wurde. Diese Tatsache muss im äussersten %%DocumentNeededFonts-Kommentar im Hauptdokument festgehalten werden. Dies gilt sinngemäss auch für die Kommentare %%DocumentNeededResources:, %%LanguageLevel: und %%Extensions:.
%!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: llx lly urx uryDer erste der beiden Kopfkommentare informiert die einbettende Anwendung, dass das File die in diesem Teil beschriebene Version 3.0 des EPSF-Formates befolgt. Es handelt sich um den Version-Kommentar.
Der zweite erforderliche DSC-Kommentar gibt die Grösse des EPS-Files an. Dieser muss vorhanden sein, damit die importierende Anwendung die Illustration plazieren, vergrössern/verkleinern und zuschneiden kann. Es handelt sich um den Kommentar der Bounding Box.
Die vier Argumente des "Bounding Box"-Kommentars entsprechen der unteren linken Ecke (llx, lly) und der oberen rechten Ecke (urx, ury) der Bounding Box. Sie werden im PostScript-Koordinatensystem ausgedrückt (typografische Punkte). Die Bounding Box ist das kleinste Rechteck, das auf einer Einzelseite alle gezeichneten Elemente des EPS-Files umschliesst. Wenn Sie die Bounding Box berechnen möchten, müssen Informationen des grafischen Status, z.B. die aktuelle Strickstärke und der Parameter "line join", berücksichtigt werden.
Beispiel 1 zeigt ein minimal-konformes EPS-File, das ein Quadrat mit einer Strichstärke von 10 Einheiten zeichnet.
Beispiel B.1:
%!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 5 5 105 105 10 setlinewidth 10 10 moveto 0 90 rlineto 90 0 rlineto 0 -90 rlineto closepath strokeAbb. B.2 zeigt, wie die von Beispiel 1 gezeichneten Bildelemente im PostScript-Koordinatensystem positioniert sind. Falls die Strichstärke beim Berechnen der Bounding Box nicht berücksichtigt worden wäre, würde die Bounding Box auf jeder Seite des Quadrats um je fünf Einheiten von den korrekten Koordinaten abweichen. Dies könnte zu einem falsches Plazieren und Zuschneiden der importierten Illustration führen. Die in diesem Beispiel angegebene Bounding Box ist jedoch richtig.
Siehe Abbildung B.2:
Abbildung B.2: Die richtige Bounding Box berechnen
Unabhängig vom Koordinatensystem Ihrer Publishing-Anwendung können Sie die korrekte BoundingBox-Angabe wie folgt schätzen: drucken Sie die Seite, nehmen Sie einen Massstab, messen Sie den Abstand zur Illustration unten links, dann zur Illustration oben rechts, indem Sie die untere linke Ecke des Papierblatts als Ursprung nehmen. Diese Schätzung funktioniert, weil man dabei das Endresultat misst und keine Zwischenberechnung.
Die Kommentare %%Begin(End)Preview müssen die Bildschirm-Darstellung eines EPS-Files einklammern, wenn dieser Preview-Teil im Encapsulated PostScript Interchange (EPSI) Format dargestellt ist. Siehe Abschnitt 6 "Geräte-unabhängige Bildschirm-Darstellung" für Einzelheiten und für ein EPSI-Beispiel.
Der Kommentar %%Extensions: ist erforderlich, wenn das EPS-File einen PostScript-Interpreter benötigt, der bestimmte Spracherweiterungen unterstützt. Beispielsweise könnte das EPS-File CMYK-Farboperatoren enthalten und sollte daher auf einen Drucker geschickt werden, der diese Operatoren versteht. In diesem Fall muss das EPS-File den Kommentar %%Extensions: CMYK oder %%LanguageLevel: 2 enthalten.
Der Kommentar %%LanguageLevel: ist erforderlich, wenn das EPS-File Möglichkeiten von Level 2 verwendet, ohne eine allfällige Emulation zur Verfügung zu stellen. Aufgrund dieser Information kann die importierende Anwendung den Benutzer warnen und Fehler vermeiden, die von einem Level 1 Drucker generiert würden.
Falls das EPS-File Sprach-Erweiterungen oder Eigenschaften von Level 2 verwendet und eine vollständige Emulation dieser Eigenschaften durch Level 1 Operatoren anbietet, sind die Kommentare %%Extensions: und %%LanguageLevel: nicht nötig. Siehe Appendix D für die Strategie der Kompatibilität und Emulation.
Wenn das EPS-File irgendwelche Fonts, Files, Formulare, Precedure Sets oder andere Ressourcen benötigt, dann muss der entsprechende DSC-Kommentar im EPS-Kopf erscheinen. Siehe Appendix G.
In einem EPS-File sind diese Kopf-Kommentare ausdrücklich empfohlen.
banddevice exitserver quit
clear framedevice renderbands
cleardictstack grestoreall setglobal
copypage initclip setpagedevice
erasepage initgraphics setshared
initmatrix startjob
Falls richtig angewendet, sind die folgenden Operatoren in einem EPS-File erlaubt. Der Gebrauch einer dieser Operatoren muss jedoch im Einklang mit den Regeln in Appendix I des Reference Manuals (1990) erfolgen. Ein falscher Gebrauch kann zu unvorhersehbaren Resultaten führen.
nulldevice sethalftone setscreen undefinefont setgstate setmatrix settransfer
Es wird ausdrücklich empfohlen, dass ein EPS-File seine Definitionen in einem eigenen Dictionary ablegt. Es ist von Vorteil, wenn sich das importierte EPS-File sein eigenes Dictionary schafft, statt ins aktuelle Dictionary der importierenden Anwendung zu schreiben. Bei Level 1 Interpretern kann es sein, dass das Dictionary der importierenden Anwendung keinen Platz mehr für die EPS-Definitionen hat. Stellen Sie mit dem Operator end sicher, dass das Dictionary wieder vom Dictionary Stack entfernt wird, nachdem das EPS-File verarbeitet worden ist. Damit vermeiden Sie eine mögliche Fehlermeldung des Typs invalidrestore. Jedes Dictionary, welches das EPS-File mit dem begin-Operator in den Dictionary Stack gestellt hat, muss wieder mit dem entsprechenden end-Operator vom Dictionary Stack entfernt werden.
Achtung: Verwenden Sie nie die Operatoren clear oder cleardictstack, um die Stacks in einem EPS-File zu leeren. Eine derartige Putzaktion würde nicht nur Ihre Objekte von den Stacks entfernen, sondern könnte auch noch andere Objekte löschen.
Der Dictionary Such-Mechanismus durchsucht die Dictionary auf dem Dictionary-Stack. In einem EPS-File ist es illegal, für System-Namen diesen Mechanismus zu umgehen. Verwenden Sie nie einen Code des Typs:
/S systemdict /showpage get def % Illegal EPS codeDas Ueberlesen von Definitionen in der Publishing-Anwendung könnte zu falschen Resultaten im Hauptdokument führen.
Wenn das EPS-File Annahmen über den grafischen Status treffen würde (z.B. betreffend des aktuellen Clipping Path oder der Transformationsmatrix), dann könnte ein unerwartetes Ergebnis resultieren.
Im Hinblick auf den Import eines EPS-Files muss die Publishing-Anwendung den grafischen Status wie folgt setzen: aktuelle Farbe schwarz, Line Caps "square butt end", Line Joins "mitered", Strichstärke 1, Dash Pattern "solid", Miter Limit 10, und der aktuelle Pfad muss leer sein. Falls ein Level 2 Interpreter verfügbar ist, sollen Overprint und Stroke Adjust auf "false" gesetzt werden. Ein EPS-File darf annehmen, dass dies der Default-Zustand ist. Es liegt in der Verantwortlichkeit der importierenden Anwendung, einen korrekten grafischen Status zu garantieren.
%!PS-Adobe-3.0
...Document prolog of including application...
/x /lineto load def
% Application defines x to be lineto
...More of document prolog and setup...
%%BeginDocument: GRAPHIC.EPS
...Document prolog and setup for EPS file...
/proc1 { % Enter deferred execution mode
/x exch def
x 4 moveto
} bind def % x associated with lineto after bind
4 proc1 % Execute proc1 and cause error
...Rest of EPS file...
%%EndDocument
...Rest of including application document...
Im folgenden Beispiel initialisiert das EPS-File korrekterweise die Variable x, bevor die Prozedur proc1 definiert wird:
%!PS-Adobe-3.0
...Document prolog of including application...
/x /lineto load def
% Application defines x to be lineto
...More of document prolog and setup...
%%BeginDocument: GRAPHIC.EPS
...Document prolog and setup for EPS file...
/x 0 def % Initialize variables before define procs
/proc1 { % Enter deferred execution mode
/x exch def
x 4 moveto
} bind def % x associated with lineto after bind
4 proc1 % Execute Proc1
...Rest of EPS file...
%%EndDocument
...Rest of including application document...
EPS-Files dürfen sich nie auf Prozeduren abstützen, die in Applikations- oder Treiber-Prologen definiert sind, wie etwa im LaserPrep-File von Apple. Solche Definitionen können vorhanden oder nicht vorhanden sein, je nach erfolgten Aktionen des Hauptprogramms oder von vorherigen Jobs.
Da EPS-Files zwischen heterogenen Plattformen ausgetauscht werden, ist 7-Bit ASCII das empfohlene Format für Daten in EPS-Files. Obwohl Binärdaten erlaubt sind, ist Vorsicht am Platz, wenn Sie portable Daten erzeugen möchten. Der Gebrauch von binären Daten kann es verunmöglichen, über bestimmte Kommunikationskanäle auszudrucken. Binärdaten mit einer besonderen Bedeutung, wie etwa Flusskontrolle oder End-of-File, können in bestimmten Umgebungen Uebermittlungsprobleme verursachen. Das Zeichen Control-D wird in der seriellen und parallelen Kommunikation beispielsweise als End-of-File Marke verwendet. Da dieses Zeichen in seriellen und parallelen Umgebungen den Job abbricht, erzeugt der Vorsichtige kein EPS-File, das dieses Zeichen enthält.
Siehe Appendix D des Reference Manuals (1990) für die Richtlinien betreffend Kompatibilität mit "Level 1"-Interpretern, wenn Spracherweiterungen und Möglichkeiten von Level 2 genutzt werden.
CR ist das Zeichen Carriage Return (dezimal ASCII 13), LF das Zeichen Line Feed (dezimal ASCII 10).
Die Zeilen müssen mit einer der folgenden Zeichen-Kombinationen abgeschlossen werden: CR, LF, CR LF oder LF CR.
Dieser Abschnitt enthält mehrere Fragmente PostScript-Code. Ein vollständiges Beispiel mit allen diesen Segmenten findet sich in Abschnitt 7 "EPS-Beispiel".
Der BoundingBox-Kommentar kann helfen, das Verhältnis von Höhe zu Breite zu berechnen, damit der Benutzer die ursprünglichen Proportionen beibehalten kann, wenn er die Plazierungsbox angibt. Als Alternative kann die Anwendung die Bildschirm-Darstellung in voller Grösse anzeigen und anschliessend dem Benutzer ermöglichen, die Grafik zu verkleinern und zu verschieben. Unabhängig von der Methode sollte der Benutzer die Möglichkeit haben, entweder die Proportionen der Illustration zu erhalten oder aber die Illustration zu verziehen.
/showpage { } def
0 setgray 0 setlinecap 1 setlinewidth 0 setlinejoin 10 setmiterlimit [] 0 setdash newpath
false setoverprint false setstrokeadjust
/Dict_Count countdictstack def /Op_Count count def
Bevor ein EPS-File von einer Seitenbeschreibung eingebettet wird, muss die importierende Anwendung das PostScript-Koordinatensystem transformieren, je nachdem der Benutzer das EPS-File plazieren will. Die Reihenfolge der Transformationen ist:
Abb. B.3 illustriert ein EPS-File und seine Bounding Box über einer Dokument-Seite. Das EPS-File wird so gezeigt, als sei es ohne vorgängige Transformation des Koordinatensystems gezeichnet. Die Plazierungsbox im oberen rechten Teil der Seite deutet an, wo der Benutzer das EPS-File positionieren möchte.
Siehe Abbildung B.3: 
Abbildung B.3: EPS-File und Plazierungsbox
Abbildung B.4 besteht aus drei Diagrammen, die in Schritten zeigen, wie das PostScript-Koordinatensystem transformiert und skaliert werden muss, um die vom Benutzer gewünschte Plazierung auf der Seite zu erreichen.
Abbildung B.4: neuer Ursprung, verkleinern, Position
Angenommen, die im Kopf des EPS-Files angegebene Bounding Box sei
%%BoundingBox: -100 -100 100 100dann würde der folgende PostScript-Code das EPS-File auf der Seite richtig plazieren:
400 400 translate % Translate to new origin .8 .8 scale % Scale to fit "placement box" 100 100 translate % -llx -lly translateDiese Transformation muss in den PostScript-Strom eingefügt werden, bevor das EPS-File zum Drucker geschickt wird.
Die Abbildungen B.3 und B.4 und das entsprechende Code-Fragment gehen davon aus, dass das Koordinatensystem der Anwendung mit dem Default-Koordinatensystem übereinstimmt. Der folgende Abschnitt diskutiert eine allgemeinere Transformation des Koordinatensystems.
Allgemeine Transformation des Koordinatensystems
Typischerweise transformiert eine Anwendung das PostScript-Koordinatensystem so, dass die gewöhnlichen Zeichnungseinheiten im "Application Space" als Operanden von aufgerufenen PostScript-Operatoren verwendet werden können.
Betrachte Abbildung B.5, die ein beliebiges Koordinatensystem einer Anwendung sowie eine Plazierungsbox für ein EPS-File darstellt.
Abbildung B.5: Koordinatensystem der Anwendung
Um das PostScript-Koordinatensystem an das Koordinatensystem der Anwendung (Application Space) anzupassen, könnte folgendes Code-Fragment ausgeführt werden:
0 792 translate 1 -1 scaleDies setzt voraus, dass jede Einheit im "Application Space" gleich einer PostScript-Einheit ist. Würde eine Einheit der Applikation fünf PostScript-Einheiten entsprechen, dann sähe die Transformation wie folgt aus:
0 792 translate 5 -5 scaleAngenommen, das Koordinatensystem sei bereits entsprechend des Koordinatensystems der Anwendung transformiert und skaliert worden, kann das EPS-File in folgenden Schritten in die vom Benutzer gewünschte Box plaziert werden:
Ein letztes Beispiel geht davon aus, dass das PostScript-Koordinatensystem bereits entsprechend des Koordinatensystems der Anwendung transformiert wurde. Die Bounding Box des EPS-Files sei
%%BoundingBox: 20 20 100 100und der Benutzer wünsche die Plazierungsbox wie in Abbildung B.5. Wenn Sie die obige Formel verwenden, ist die Transformation vor der Ausführung des EPS-Files wie folgt:
20 60 translate .5 -.5 scale -20 -20 translateEinen Clipping Path aufsetzen
Die importierende Anwendung sollte um das EPS-File herum einen "Clipping Path" aufsetzen. Dies kann erreicht werden, indem Sie den "Clipping Path" an die Bounding Box des eingebetteten EPS-Files angleichen, nachdem die Transformationen des PostScript-Koordinatensystem gemacht worden sind. Oder der Benutzer könnte einen beliebigen "Clipping Path" angeben, um besondere Effekte zu erreichen.
Die Bildschirm-Darstellung wegwerfen
Falls ein EPS-File eine Bildschirm-Darstellung im EPSI-Format enthält, sollte die importierende Anwendung diese Darstellung entfernen, bevor das Dokument auf den Drucker zugeladen wird. Obwohl die EPSI-Darstellung in Form von PostScript-Kommentaren spezifiziert ist und dem Drucker daher keine Probleme bereiten würde, bräuchte es zusätzliche Zeit für die Uebertragung des Preview-Teils.
Sollte die Bildschirm-Darstellung des EPS-Files im Macintosh PICT-Format sein, schicken Sie die PICT-Ressource nicht auf den Drucker mit. Wenn der Preview-Teil im TIFF-Format oder im MS Windows Metafile-Format ist, denken Sie daran, den PostScript-Code zu extrahieren und auf den Drucker zu senden. Siehe Abschnitt 5.2 "Windows Metafile oder TIFF" für Einzelheiten.
Enthält das EPS-File keine Bildschirm-Darstellung (Preview-Teil), dann kann das Druckfile, das auf den PostScript-Drucker geschickt wird, das ganze EPS-File enthalten.
Kompatibilität mit Version 2.0
Die EPSF-Version 3.0 verlangt, dass ein EPS-File die Operanden- und Dictionary-Stacks so hinterlässt, wie diese vor der Ausführung des EPS-Files waren. In früheren Versionen des EPSF-Formates war dies allerdings nicht ausdrücklich vorgeschrieben. Stellen Sie daher sicher, dass die Anzahl Objekte auf den Dictionary- und Operanden-Stacks gezählt werden, bevor die Anwendung das EPS-File importiert. Nachdem das EPS-File ausgeführt ist, sollten die Stacks dieselbe Anzahl Objekte enthalten wie vor dem Importieren.
Vorbereitung für das Einbetten eines EPS-Files
Beispiel 2 zeigt die Prozedur BeginEPSF, welche eine Anwendung verwenden könnte, um das Einbetten eines EPS-Files vorzubereiten. Die Prozedur BeginEPSF ist vor dem EPS-File auszuführen.
Beispiel B.2:
/BeginEPSF { %def
/b4_Inc_state save def
% Save state for cleanup
/dict_count countdictstack def
% Count objects on dict stack
/op_count count 1 sub def
% Count objects on operand stack
userdict begin
% Push userdict on dict stack
/showpage {} def
% Redefine showpage, null proc
0 setgray 0 setlinecap
% Prepare graphics state
1 setlinewidth 0 setlinejoin
10 setmiterlimit [] 0 setdash newpath
/languagelevel where % If level not equal to 1 then
{pop languagelevel % set strokeadjust and
1 ne % overprint to their defaults
{false setstrokeadjust false setoverprint
} if
} if
} bind def
Beispiel 3 zeigt die Prozedur EndEPSF, die den PostScript-Status wieder so herstellt, wie er vor dem Einbetten und Ausführen des EPS-Files war. Die Prozedur EndEPSF ist nach dem EPS-File auszuführen.Beispiel B.3:
/EndEPSF { %def
count op_count sub {pop} repeat % Clean up stacks
countdictstack dict_count sub {end} repeat
b4_Inc_state restore
} bind def
Beispiel 4 illustriert den Gebrauch der Prozeduren BeginEPSF und EndEPSF.Beispiel B.4:
BeginEPSF % Prepare for the included EPS file left bottom translate % Place the EPS file angle rotate Xscale Yscale scale -llx -lly translate ...Set up a clipping path... %%BeginDocument: MyEPSFile ...Included EPS file here... %%EndDocument EndEPSF % Restore state, and cleanup stacks
In Systemen, die Kleinbuchstaben nicht kennen oder nicht als signifikant behandeln, können Grossbuchstaben verwendet werden.
Das EPS-File hat gewöhnlich eine grafische Bildschirm-Darstellung, die es dem Benutzer erlaubt, die Illustration am Bildschirm anzuzeigen und zu transformieren, bevor die Seite ausgedruckt wird. Abhängig von den Möglichkeiten der importierenden Anwendung kann der Benutzer diese Bildschirm-Darstellung des EPS-Files plazieren, skalieren, zuschneiden und drehen. Die Publishing-Software sollte diese Transformationen registrieren und im PostScript-Code abbilden, der schliesslich auf den Drucker zugeladen wird.
Das genaue Format der Bildschirm-Darstellung ist Maschinen-abhängig. Das heisst, dass jede Computer-Plattform oder Umgebung ihr bevorzugtes "Screen Representation Image" Format kennt, welches meist die geeignete Bildschirm-Darstellung für die entsprechende Umgebung ist. Zusätzlich ist in Abschnitt 6 "Geräte-unabhängige Bildschirm-Darstellung" das EPSI-Format spezifiziert. Adobe Systems empfiehlt, dass alle Anwendungen dieses Format unterstützen.
Aufgrund der grössenmässigen Beschränkung der PICT-Bilder werden diese Angaben bei grossen Illustrationen nicht immer übereinstimmen. Wenn es einen Widerspruch gibt, dann soll %%BoundingBox als wahr gelten, da die Bounding-Box-Angaben genau denjenigen Bereich ausweisen, der durch den PostScript-Code geschwärzt wird.
Das EPS-File hat einen binären Kopf am Fileanfang, der eine Art Inhaltsverzeichnis liefert. Dies ist notwendig, weil es im Filesystem keine zweite "Fork" gibt wie beim Macintosh.
Achtung: In der DOS-Umgebung ist es immer erlaubt, ein reines PostScript-File in ASCII als EPS-File zu haben (ohne Preview-Teil).
Die importierende Anwendung sollte die ersten vier Bytes des Files prüfen. Wenn diese mit dem Kopf - wie unten gezeigt - übereinstimmen, dann kann der binäre Kopf erwartet werden, und damit eine Bildschirm-Darstellung. Falls die ersten zwei Bytes "%!" sind, dann handelt es sich um ein reines PostScript-File in ASCII-Text.
Binärkopf eines EPS-Files im DOS:
Bytes Beschreibung
0-3 Must be hex C5D0D3C6 (byte 0=C5)
4-7 Byte position in file for start of
PostScript code section.
8-11 Byte length of PostScript section
12-15 Byte position in file for start of
Metafile screen representation.
16-19 Byte length of Metafile section
(PSize)
20-23 Byte position of TIFF representation
24-27 Byte length of TIFF section
28-29 Checksum of header
(XOR of bytes 0-27).
Note: if Checksum is FFFF then ignore it
Es wird angenommen, dass entweder Position und Länge von Metafile oder aber Position und Länge von TIFF null sind. Daraus folgt, dass nur eine der beiden Formen im EPS-File enthalten sein kann.Das Metafile sollte die Richtlinien von MS Windows befolgen. Im einzelnen sollte es weder "viewport" noch "mapping mode", jedoch "window origin" und "extent" setzen. Die importierende Publishing-Anwendung hat das Bild so zu skalieren, dass die Dimensionen den BoundingBox-Angaben im EPS-File entsprechen.
Ein EPSI-File ist wirklich transportierbar und erfordert kein besonderes Programm für das Dekomprimieren oder für ein Erkennen des Bitmap-Teils. Lediglich die hexadezimale Schreibweise (hex. FF = 255) muss verstanden werden.
Die Kommentare %%BeginPreview: width height depth lines und %%EndPreview umklammern die Bildschirm-Darstellung eines EPSI-Files. Die Felder width und height geben die Anzahl Bildpunkte (Pixels) für das Preview an. Das Feld depth besagt, wieviele Datenbits verwendet werden, um einen Bildpunkt darzustellen (1, 2, 4 oder 8). Ein 100 Pixel breites Bild hat immer die Zahl 100 im Feld width, obwohl sich die Anzahl benötigter hexadezimaler Bytes je nach depth ändert. Das Feld lines gibt an, wieviele Zeilen hexadezimaler Code der Preview-Teil enthält, sodass diese Zeilen leicht übersprungen werden können, falls sich eine Anwendung nicht dafür interessiert. Alle Argumente sind ganze Zahlen.
Die Bit-Reihenfolge der Bildschirm-Darstellung ist die gleiche wie die vom image-Operator verwendete. Das heisst, dass ein Preview sein eigenes Koordinatensystem hat. Die rechteckige Begrenzung der Bildschirm-Darstellung hat ihre linke untere Ecke an Position (0,0) und ihre rechte obere Ecke an Position (width, height). Die Byte-Reihenfolge ist fest, und sollte von (0,0) nach (width-1, 0) gehen, dann von (0,1) nach (width-1, 1), etc.
Beispiel unisiegel.epsi
Beispiel B.5:
%!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 0 0 80 24 %%Pages: 0 %%Creator: John Smith %%CreationDate: November 9, 1990 %%EndComments %%BeginPreview: 80 24 1 24 %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FF0000000000000000FF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %FFFFFFFFFFFFFFFFFFFF %%EndPreview %%EndProlog %%Page: "one" 1 4 4 moveto 72 0 rlineto 0 16 rlineto -72 0 rlineto closepath 8 setlinewidth stroke %%EOF
%!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 4 4 608 407 %%Title: (ARTWORK.EPS) %%CreationDate: (10/17/89) (5:04 PM) %%EndComments ...PostScript code for illustration... showpage %%EOF
In diesem Fall sieht die von der Anwendung erzeugte Seitenbeschreibung mit dem eingebetteten EPS-File wie folgt aus:
%!PS-Adobe-3.0
%%BoundingBox: 0 0 612 792
%%Creator: SomeApplication
%%Title: (Smith.Text)
%%CreationDate: 11/9/89 (19:58)
%%Pages: 1
%%DocumentFonts: Times-Roman Times-Italic
%%DocumentNeededFonts: Times-Roman Times-Italic
%%EndComments
%%BeginProlog
/ms {moveto show} bind def
/s /show load def
/SF {%/FontIndex FontSize /FontName SF --
findfont exch scalefont dup setfont def
} bind def
/sf /setfont load def
/rect {% llx lly w h % Used to create a clipping path
4 2 roll moveto
1 index 0 rlineto
0 exch rlineto
neg 0 rlineto
closepath
} bind def
/BeginEPSF { %def
/b4_Inc_state save def
% Save state for cleanup
/dict_count countdictstack def
% Count objects on dict stack
/op_count count 1 sub def
% Count objects on operand stack
userdict begin
% Push userdict on dict stack
/showpage {} def
% Redefine showpage, null proc
0 setgray 0 setlinecap
% Prepare graphics state
1 setlinewidth 0 setlinejoin
10 setmiterlimit [] 0 setdash newpath
/languagelevel where % If level not equal to 1 then
{pop languagelevel % set strokeadjust and
1 ne % overprint to their defaults.
{false setstrokeadjust false setoverprint
} if
} if
} bind def
/EndEPSF { %def
count op_count sub {pop} repeat % Clean up stacks
countdictstack dict_count sub {end} repeat
b4_Inc_state restore
} bind def
%%EndProlog
%%BeginSetup
%%IncludeFont: Times-Roman
%%IncludeFont: Times-Italic
%%EndSetup
%%Page: 1 1
%%BeginPageSetup
/pgsave save def
%%EndPageSetup
/F1 40 /Times-Roman SF
...Set some text with F1...
/F2 40 /Times-Italic SF
...Set some text with F2...
F1 sf
...Set some more text with F1...
F2 sf
...Set some more text with F2...
BeginEPSF
65.2 10 translate % Position the EPS file
.80 .80 scale % Scale to desired size
-4 -4 translate % Move to lower left of the EPS
4 4 604 403 rect % Set up clipping path
clip newpath % Set the clipping path
%%BeginDocument: ARTWORK.EPS
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 4 4 608 407
%%Title: (ARTWORK.EPS)
%%CreationDate: (10/17/89) (5:04 PM)
%%EndComments
...PostScript code for illustration...
showpage
%%EOF
%%EndDocument
EndEPSF
pgsave restore % restore state, cleanup stacks
showpage
%%EOF
Die folgenden bedingt erforderlichen DSC-Kommentare gehören neu zur EPSF-Version 3.0:
%%Extensions: %%LanguageLevel: %%DocumentNeededResources: %%IncludeResource: %%Begin(End)Document:
Generated with WebMaker