home *** CD-ROM | disk | FTP | other *** search
/ Photo CD Demo 1 / Demo.bin / formats / gif / gen_info / notes.lzh / EPSF.TXT < prev    next >
Encoding:
Text File  |  1989-03-02  |  12.0 KB  |  287 lines
  1.                Encapsulated PostScript File Format for
  2.                           PageMaker Import
  3.  
  4.              (For PC Windows and Macintosh Applications)
  5.  
  6.                    by John Nelson and Sheri Hargus
  7.  
  8.  
  9. The following specifies the format required for import of Encapsulated
  10. PostScript (EPS) Files into PageMaker. This specification suggests a standard
  11. for both Macintosh and PC Windows applications. PageMaker version 2.0 for the
  12. Macintosh and PageMaker version 1.0 for the IBM PC and compatibles will both
  13. support this format. The EPS format was originally developed by Jim Von Ehr
  14. of Altsys Corporation; some enhancements to that original format are included
  15. here in order to conform to Adobe PostScript Document Structuring
  16. Conventions, version 2.0, to add support for print spoolers, and to allow
  17. compatibility with Windows. This specification is compatible with EPS file
  18. specifications distributed by Adobe Systems Incorporated.
  19.  
  20.  
  21. January 5, 1987
  22. EPSF Version 1.2
  23.  
  24. Summary of changes for 1.2:
  25. * added DocumentNeededFont
  26. * LoadFont renamed to IncludeFont
  27. * added %%+ continuation lines
  28. * revised version comment
  29. * deleted Call comment
  30. * added IncludeFile comment
  31. * added TIFF screen representation
  32. * revised Windows EPS header format
  33. * made other minor changes
  34.  
  35. Previous EPS versions will be supported, but are not recommended.  This
  36. document revision supercedes all previously-dated revisions.
  37.  
  38.  
  39. Please direct comments in writing to:
  40.    Tim Davenport
  41.    Aldus Corporation
  42.    411 First Avenue South, Suite 200
  43.    Seattle, WA 98104
  44.  
  45.  
  46. INTRODUCTION
  47.  
  48. The rules that should be followed in creating importable PostScript files for
  49. PageMaker are a subset of the structuring conventions proposed by Adobe
  50. Systems Incorporated; refer to the PostScript Language Reference Manual,
  51. Appendix C, and PostScript Document Structuring Conventions, version 2.0,
  52. available from Adobe. Files must also be "well-behaved" in their use of
  53. certain PostScript operators, manipulation of the graphics state, and
  54. manipulation of the PostScript stacks and global dictionaries. These
  55. conventions are designed to allow cooperative sharing of files between many
  56. systems using PostScript.
  57.  
  58. Encapsulated PostScript FILE GUIDELINES
  59.  
  60. An EPS file should conform to version 2.0 of the Adobe Document Structuring
  61. conventions, in that any comments used should be in accordance with that
  62. specification. In addition, the %%BoundingBox comment is required.  PageMaker
  63. will scan imported files, doing minor syntax checking and handling comments
  64. as noted in the following sections.
  65.  
  66. Structuring Comments
  67. Structuring comment lines must begin with "%!" or "%%" and terminate with a
  68. newline (either return or linefeed) character. PageMaker import requires that
  69. a comment line not be longer than 256 bytes.  A comment line may be continued
  70. by beginning the continuation line with "%%+". The colon in any comment is
  71. optional. The EPS file should begin with a "header" of structuring comments
  72. (see the PostScript Language Reference Manual, Appendix C).
  73.  
  74.  
  75. Required Comments
  76.  
  77. The first comment in the header (and the first text line in the file) should
  78. be the version comment:
  79.  
  80. %!PS-Adobe-2.0 EPSF-1.2
  81. This indicates to PageMaker that the PostScript file conforms to this
  82. standard. The version number following the word Adobe indicates the level of
  83. adherence to standard PostScript comments, as defined in PostScript Document
  84. Structuring Conventions. The version number following the word EPSF indicates
  85. the level of EPSF-specific comments.
  86.  
  87. The following comment must be present in the header; if it is not present
  88. then PageMaker will issue an error message and abort the import:
  89.  
  90. %%BoundingBox: llx lly urx ury
  91. The values are in the PostScript "default user coordinate" system, in points
  92. (72nds of an inch), with the origin at the lower left.
  93.  
  94.  
  95. General Informational Comments
  96.  
  97. The following header comments are strongly recommended:
  98.  
  99. %%Creator: creator_name
  100. %%Title: PSfile_title
  101. %%CreationDate: date_and_time
  102. Creator, Title, and CreationDate information is used by PageMaker to create a
  103. screen representation of the PostScript segment if no other screen
  104. representation is included in the file.
  105.  
  106. %%EndComments
  107. This comment indicates the end of the header comments.
  108.  
  109.  
  110. Font Management Comments
  111.  
  112. If fonts are used, the following two comments should be included in the
  113. header of the EPS file:
  114.  
  115. %%DocumentFonts: font1 font2 ...
  116. The DocumentFonts comment is a full list of all fonts used by the file. Font
  117. names should refer to non-reencoded printer fonts. PageMaker will load these
  118. fonts if necessary at the beginning of the file; if this comment is not
  119. present then PageMaker will assume that no fonts need to be preloaded. (See
  120. also the %%DocumentNeededFonts and %%IncludeFont comments.) PageMaker will
  121. convert the DocumentFonts comment to a PageFonts comment for output in order
  122. to ensure compatibility with print spoolers.
  123.  
  124. Note: For PC Windows applications, it is recommended that only standard
  125. device-resident fonts be used.
  126.  
  127. %%DocumentNeededFonts: font1 font2 ...
  128. The DocumentNeededFonts comment lists all fonts that are loaded at specific
  129. points within the EPSF file as a result of IncludeFont comments. These fonts
  130. must also be listed in the DocumentFonts comment, but PageMaker will not
  131. preload these at the beginning of the file.
  132.  
  133. Within the body of the PostScript file, PageMaker will handle the following
  134. comment:
  135.  
  136. %%IncludeFont: font
  137. The IncludeFont comment signals to PageMaker that the specified font is to be
  138. loaded at that point in the imported PostScript code. PageMaker will load the
  139. specified font regardless of whether the same font has been loaded already by
  140. other preceding IncludeFont comments, since the font may be embedded within a
  141. PostScript save and restore construct. However, PageMaker will not load any
  142. font specified that has already been determined (at the beginning of the
  143. print job) to be permanently present in the printer. The names of fonts that
  144. are loaded in this way should be also included in the DocumentNeededFonts
  145. comment in the header of the file.
  146.  
  147. A font that is wholly contained, defined, and used within the EPS file should
  148. be noted in the DocumentFonts comment but not the DocumentNeededFonts
  149. comment. The font should follow conventions listed in Postscript Document
  150. Structuring Conventions in order to retain compatibility with print spoolers.
  151.  
  152.  
  153. File Inclusion Comments
  154.  
  155. %%IncludeFile: file_name
  156. This comment, which can occur only in the body of an EPS file, allows a
  157. separate file to be inserted at any point within the EPS file. The file must
  158. be present in the same working directory as PageMaker, or else the filename
  159. must be a fully qualified pathname. The file might not be searched for or
  160. inserted until printing actually occurs, so user care is required to ensure
  161. its availability. This comment is not recommended for use with PC Windows.
  162.  
  163.  
  164. "WELL-BEHAVED" RULES
  165.  
  166. PageMaker will encapsulate the imported PostScript code in a save and restore
  167. construct, which will allow all VM to be recovered and the graphics state
  168. restored. Since the code in the imported EPS file will be embedded within the
  169. PostScript that PageMaker generates for the current page, it is necessary
  170. that it obey the following rules.
  171.  
  172. Dangerous Operators
  173. The following operators should not be included in a PostScript file for
  174. PageMaker import; the result of executing any of these is not guaranteed.
  175. grestoreall
  176. initgraphics
  177. initmatrix
  178. initclip
  179. erasepage
  180. banddevice
  181. framedevice
  182. nulldevice
  183. renderbands
  184. setpageparams
  185. note
  186.  
  187. The following operator results in an error message and in PageMaker
  188. terminating the PostScript file import:
  189. exitserver
  190.  
  191. The following operators are allowed, but are removed from the code during
  192. import parsing, or are redefined to have no affect:
  193. showpage
  194. copypage
  195.  
  196. PostScript Stacks:
  197. All stacks (including the dictionary stack) should be left in the state that
  198. they were in before the imported PostScript code was executed.
  199.  
  200. Dictionaries:
  201. No global strings should be changed.
  202.  
  203. It is recommended that the imported PostScript code create its own dictionary
  204. instead of writing into the dictionary that PageMaker currently has placed on
  205. the top of the dictionary stack. However, reference to that dictionary should
  206. be removed from the dictionary stack with an end command within the EPS file.
  207.  
  208. If a special header or dictionary is required in order for the imported
  209. PostScript code to execute, then it should be included as part of  the
  210. PostScript file. However, it should be enclosed in comments as specified in
  211. the Postscript Document Structuring Conventions. No dictionary should be
  212. assumed to be already present in the printer; fonts should not be assumed to
  213. be already reencoded.
  214.  
  215.  
  216. FILE TYPES
  217.  
  218. Macintosh
  219. The Macintosh file type for application-created PostScript files is EPSF.
  220. Files of type TEXT will also be allowed so that users can create EPS files
  221. with standard Macintosh editors, although the document structuring
  222. conventions should still be strictly followed.
  223.  
  224. PC-Windows
  225. The recommended file extension is .EPS. Other file extensions will also be
  226. allowed, but it will be assumed that these files are text only files with no
  227. header, screen metafile, or TIFF section included in them.
  228.  
  229.  
  230. PAGEMAKER SCREEN REPRESENTATION
  231.  
  232. The EPS PostScript file will have a graphical screen representation so that
  233. it can be manipulated on the PageMaker page. As with other PageMaker images,
  234. a user will be able to crop, scale, and translate the PostScript
  235. representation.
  236.  
  237. Macintosh: PICT Representation
  238. A QuickDraw representation of the PostScript file can be created and stored
  239. as a PICT in the resource fork of the file. It should be given resource
  240. number 256. If the PICT exists, PageMaker will use it for screen display. The
  241. transformed (to PostScript default user coordinates) picframe  should agree
  242. with the BoundingBox comment; if it doesn't, PageMaker will scale the picture
  243. to match the bounding box.
  244.  
  245. PC-Windows: MetaFile or TIFF Representation
  246. Either a Windows MetaFile or a TIFF (Tag Image File Format) section can be
  247. included as the screen representation of an EPS file. The file format for EPS
  248. files is:
  249.  
  250.      Header:      Bytes           Description
  251.                   0-3             Must be hex C5D0D3C6 (byte 0=C5)
  252.                   4-7             Byte position in file for start of
  253.                                     PostScript code section
  254.                   8-11            Byte length of PostScript section
  255.                  12-15            Byte position in file for start of MetaFile
  256.                                     screen representation section
  257.                  16-19            Byte length of MetaFile section (PSize)
  258.                  20-23            Byte position of TIFF screen representation
  259.                  24-27            Byte length of TIFF section
  260.                  28-29            Checksum of header (XOR of bytes 0-27)
  261.                                     note: if FFFF then ignored
  262.  
  263. (Note: It is assumed that either the MetaFile or the TIFF position and length
  264. fields are zero; the non-zero section will be used by PageMaker.)
  265.  
  266.      Body: PostScript and MetaFile sections
  267.                  MetaFile section:
  268.                  0 -                           MetaFile contents
  269.                  PSize-1
  270.  
  271. The MetaFile should follow the guidelines set by Windows; in particular, it
  272. should not set the viewport or mapping mode (PageMaker always uses the
  273. anisotropic mapping mode), and it should set the window origin and extent.
  274. The picture will be scaled to fit within the BoundinBox specified in the
  275. comment.
  276.  
  277. The byte order of numeric fields (beginning with byte 4) should correspond to
  278. that expected by the PC.
  279.  
  280. If there is no MetaFile or TIFF screen representation, the header may be
  281. omitted; the file would begin with the version comment.
  282.  
  283. PageMaker-generated Representation
  284. If a screen picture presentation does not exist, PageMaker will create a
  285. framed box of BoundingBox proportions with descriptive text from the
  286. PostScript comments inside it.