PostScript notes

From Helpful
Jump to: navigation, search
These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.


PostScript is perhaps best known as a page description language used in desktop publishing. It is fully vector-based, so allows arbitrary scaling, masking, and other such transforms, and can be rasterized fairly easily.

From a programmer's view, PostScript is also a dynamically typed Turing-complete language with a reverse polish syntax.

PostScript was and still can be a convenient way of creating certain types of vector graphics. It is also a means of document transfer, though PDF has largely replaced in in that area, perhaps largely because PDF viewers are more convenient and modern than most PS viewers. PostScript is still relatively widely used in academic publishing (now alongside PDF), particularly when generated from LaTeX.

Earlier versions of PostScript were made in part for laser printers, which contain Postscript interpreters (also Raster Image Processor, RIP), allowing them to create sharp vector-based prints by transferring a compact description of vector features rather than high-DPI rasterized images, which would be very large to store and transport.

(Note that because of the ubiquity of PDFs, some people store images of pages in PDFs. Particularly users of older laser printers will notice that some documents print very slowly, which is usually because of this. The same is possible in PostScript, though less liekely because of the way it is and isn't used. It's a result of usage rather than format; PDF is actually largely the same as PS in many areas)

The differences between the versions (PostScript Level 1 (1981), PostScript Level 2, and PostScript 3 (1997)) lies mostly in increasingly more powerful library-like functionality, for example for (de)compression, error correction, though also in more predefined colors, smoother shading and better color handling.

PostScript is often used to store documents that have pages, even though concepts such as pages are not central to PostScript.


The Document Structuring Conventions (DSC) are a number of formatting conventions.

It makes the use of PostScript for typical documents (articles and such) more predictable.

Among other things, DSC specifies there should be a prolog of metadata (in PostScript comments), which can be used for printing, faster seeking to a particular page(verify), and has some other upsides.

See also:

On PS and EPS

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Encapsulated Postscript (EPS) is PostScript that meets some extra constraints that make it reasonably self-contained and, often more importantly, safe to be embedded inside other PostScript. EPS makes PostScript useful as an image format.

It's generally a decent assumption that EPS means images (no pages, sized exactly to its contents), while non-EPS usually means page-based documents.

EPS file constraints include that:

  • it must consist of one page (no showpage commands)
  • it must have a valid bounding box
  • it must have no net effect when embedded:
    • it should leave the stack exactly as it was
    • it should not affect global state, meaning they should not use certain commands (at least two dozen are off-limit)
  • lines must each be 255 characters or less

EPS may contain a raster preview to give a user an idea of how something will look, which can be nice when no PS interpreter is present. (Note that use of these previews is still specific to some software and some platforms)

See also:

PostScript Programming

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

PostScript has an RPN-like syntax and is executed in a stack-based way.

The most basic evaluation is done via the operand stack: naming operands implicitly pushes them onto the operand stack, and naming an operator will do whatever popping, calculation, and/or pushing work that is sensible for it.

Paths and coordinates

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Paths can be used to draw polygons, define clipping paths, and such, and have the effect of moving the current drawing cursor(verify),

newpath clears the current path, followed by the construction of its segments, after which it is often drawn (or stored for later use?).

Absolute movements:

x y moveto
x y lineto

Relative movements:

x y rlineto
x y rmoveto 

(line to and) arc at (x,y), with radius r, from a1 to a2 (angles in degrees), counter-clockwise:

x y r a1 a2 arc

Bezier curve to (x3,y3), with (x1,y1) and (x2,y2) as control points:

x1 y1 x2 y2 x3 y3 curveto

You can use closepath to automatically close a polygon, generating a line from the current coordinate to the first in the current path.

There is also a charpath, which adds text shapes to current path

Basic drawing

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

stroke draws a line along current path

fill fills the current path, then clears the current path (if you want to preserve the current path, one way is to do a gsave, fill, then grestore).

clip sets the clipping path to whatever the current path is (considered closed if it was not), and does not change the current path.

Since everything that is drawn is a path in some way, you can pretty much clip any shape using any other shape (shapes, text, etc.).

Since it is not easy to set clipping to a larger area once you have reduced it, you probably want to clip in a local gsave/grestore block.


User space transformations

Procedures and blocks

Stack related



See e.g.

Concepts, syntax notes

  • Arrays
  • coordinate spaces: Device space is usually only used by the interpreters when generating for a specific device('s resolution). Most postscript is generated in user space, which has (0,0) at the bottom left and a page size dependent maximum coordinate at the top right, e.g. (612,792) for Letter (8.5" by 11"). The units are postscript points, which are 1/72 inch.

  • Comments are lines that start with %
  • A dictionary stores name-value pairs. Dictionaries store variables/value, operators/code. There is a dictionary stack, and the way dictionary lookup works effectively implements (simple) scoping. Note: Dictionaries may be named and stored in other dictionaries.
  • A path is a collection of line segments (not necessarily a polyline -- may be disjoint), which is effectively virtual until you specify something to do with it (stroke, fill, clip).
    • current path has somewhat special status in the graphics state.
    • clipping path does too, and is set to the page unless custom-set.
  • graphics state refers to the system state in the interpreter. Since parts of this are useful to reuse, you can push/pop graphics state onto the graphics state stack. The state includes:
    • the current path,
    • the current font,
    • the current transformation matrix, and more.
  • Matrices: Transformation is based on (3x3) matrices
  • Names are more free-form than in many other languages; may consist of alphanumerics in any order (though starting with digits can get confusing, and sometimes be parsed as a number in scientific notation), excluding /%[](){}<>. That is, you may not use those yourself; a few are existing operators stored, and so stored in dictionaries.
  • Numbers comes in the form of integers, floats, radix#value, and mantissaEexponent (base-10, scientific notation)
  • Procedures
  • Stacks are used in various places. Some of the more interesting include:
    • the operand stack
    • the dictionary stack
    • the graphics state (verify)
  • Strings can come in various forms. The example "ABC"
    • can be bracketed as (ABC)
    • can be hex-escaped as <414243>

Further notes:

  • Escapes include:
    • \n
      : Newline, Carriage return, Horizontal Tab
    • \b
      : Backspace
    • \f
      : Form feed
    • \\
      : Backslash
    • \(
      : Left and right parenthesis
    • \ddd
      : octal escape
    • Multi-line strings using \ at the end of the line
  • The use of a /slash forces a name to be used as a variable/key, instead of dereferencing it for a value looked up in dictionaries(verify)

See also

Generating from code

Often some mix of low-level postscript and higher-level helpers, some more usable than others.


  • PyX (geared to plotting)
  • PyScript
    • also for diagrams (e.g. in various alignment), can interact with TeX to generate PS for TeX
    • pure-python
  • pypsg
    • some optional dependencies(verify))
    • pure-python
  • there is a floating about (single pure-python file, simple)

Editing, converting

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

In unices you can view and convert PS to raster images or PDF using fairly standard unix utilities (epstopdf imagemagick convert, and others), while in Windows you rely much more heavily on vector drawing applications and/or Ghostscript.

Some options for vector editing:

  • Inkscape (free)
  • Sodipodi (free)
  • Adobe Illustrator (paid-for)
  • Corel Draw (paid-for)

Such editors can often also save to PDF files and/or raster images.

Note that raster editors such as Photoshop, GIMP and such can regularly import PostScript, by rendering it into pixels.

See also


Introductions, references, techical info