Gripes


PostScript code is produced by many programs on the market. Unfortunately, the authors of these didn't take the time to read the documentation on the Adobe Document Structuring Conventions (DSC) contained in the PostScript Language Reference Manual, 2nd Edition. Consequently, there are a number of common errors that occur in PostScript files, which cause grief when the PostScript is processed by a document manager such as GSview or Ghostview.
%%BoundingBox: uses integers.
Do not use floating point numbers.
%%BoundingBox: should be correct.
Giving a bogus bounding box isn't helpful.
EPS files should be 0 or 1 pages.
Windows 3.x offers the option "Print To" "Encapsulated PostScript File". People think this is the way to produce PostScript multipage files. WRONG! Instead it creates a multipage file with an EPS header. This option should have been written to prevent output of any pages after the first. The correct way to get a PostScript file is to "Connect" the printer to "FILE:".

My preference is for single page EPS files with a BoundingBox that is in the printable area of most printers. These EPS files can be printed OR imported.

Use %%BeginDocument/%%EndDocument around imported files.
Imported documents should be encapsulated with %%BeginDocument / %%EndDocument to allow document managers to skip over embedded DSC comments. The Word 6 EPS import filter uses %MSEPS Preamble / %MSEPS Trailer, when it would have been just as easy to use the correct comments.
Put PostScript code where it belongs.
PostScript code should be in the prolog, setup, page or trailer sections. It should not be between the setup and page sections (Windows 95/NT). Page size changing commands should be in the setup section, not the prolog or the page sections.
Page independence.
Unless instructed otherwise with the %%PageOrder: Special comment, document managers expect that pages are independent and may be reordered. The default configuration of the Windows 3.x PostScript driver is to produce output with page dependence. This can be changed by selecting "Options | Advanced | Conform to Adobe Document Structuring Convention". If this item is not checked (the default), then Windows 3.x produces PostScript output that incorrectly claims DSC conformance. Windows 95 knows about %%PageOrder: Special. Hoorah!
Lines should be shorter than 254 characters
Microsoft Windows 3.x produces lines in a %%BeginData section that are longer than 254 characters. If you want to be really safe, make lines shorter than 80 characters so the files don't get mangled by mailers.
Use the correct DSC identifier.
OS/2 uses %!PS-Adobe- instead of %!PS-Adobe-X.X where X.X is the version number. If the PostScript doesn't conform to the DSC, then a simple %! should be used. Note that X.X is the version number of the DSC (typically 2.0, 2.1 or 3.0), not the PostScript level (1 or 2).
Ctrl-D is not PostScript
Don't start a file with a Ctrl-D since PostScript files are usually identified by the presence of %! as the first two characters. By default, Windows 3.x prepends a Ctrl-D to PostScript files. This bug can be disabled by adding CtrlD=0 to the appropriate section in win.ini. See printers.wri for more details. Ctrl-D is a part of a commonly used serial line protocol used for PostScript printers. The Ctrl-D should really be added by the Print Manager after each PostScript job is sent to a PostScript printer connected by a serial line.
Ctrl-Z is not needed at the end of file.
Using a Ctrl-Z to indicate the end of file is a hang over from CP/M (a great operating system for its time) and MS-DOS 1.0 (a clone of CP/M). This should have been abandoned in MS-DOS 2.0 because its file system includes a length count for each file. Nevertheless, many MS-DOS text editors added a Ctrl-Z at the end. This annoys PostScript interpreters and other operating systems. EPS files with a trailing Ctrl-Z cause grief when embedded in other documents.

Gripes by Russell Lang
Last updated 1999-06-03