Unix Programming - Applying Minilanguages - Case Study: PostScript
Case Study: PostScript
PostScript is a minilanguage specialized for describing typeset
text and graphics to imaging devices. It is an import into Unix,
based on design work done at the legendary Xerox Palo Alto
along with the earliest laser printers. For years after its first
commercial release in 1984, it was available only as a proprietary
product from Adobe, Inc., and was primarily associated with Apple
computers. It was cloned under license terms very close to
open-source in 1988, and has since become the de-facto standard for
printer control under Unix. A fully open-source version is shipped
with most most modern Unixes. A good technical introduction to PostScript is also
PostScript bears some functional resemblance to troff markup;
both are intended to control printers and other imaging devices, and
both are normally generated by programs or macro packages rather than
being hand-written by humans. But where troff requests are a
jumped-up set of format-control codes with some language features
tacked on as an afterthought, PostScript was designed from the ground
up as a language and is far more expressive and powerful. The main
thing that makes Postscript useful is that algorithmic descriptions of
images written in it are far smaller than the bitmaps they render to,
and so take up less storage and communication bandwidth.
PostScript is explicitly Turing-complete, supporting
conditionals and loops and recursion and named procedures. The
ontology of types includes integers, reals, strings, and arrays (each
element of an array may be of any type) but no equivalent of
structures. Technically, PostScript is a stack-based language;
arguments of PostScript's primitive procedures (operators) are normally
popped off a push-down stack of arguments, and the result(s) are pushed
back onto it.
There are about 40 basic operators out of a total of around 400.
The one that does most of the work is show, which
draws a string onto the page. Others set the current font, change the
gray level or color, draw lines or arcs or Bezier curves, fill closed
regions, set clipping regions, etc. A PostScript interpreter is
supposed to be able to interpret these commands into bitmaps to be
thrown on a display or print medium.
Other PostScript operators implement arithmetic, control
structures, and procedures. These allow repetitive or stereotyped
images (such as text, which is composed of repeated letterforms) to be
expressed as programs that combine images. Part of the utility of
PostScript comes from the fact that PostScript programs to print text or
simple vector graphics are much less bulky than the bitmaps the text
or vectors render to, are device-resolution independent, and travel more
quickly over a network cable or serial line.
Historically, PostScript's stack-based interpretation resembles
a language called FORTH, originally designed to control telescope
motors in real time, which was briefly popular in the 1980s.
Stack-based languages are famous for supporting extremely tight,
economical coding and infamous for being difficult to read.
PostScript shares both traits.
PostScript is often implemented as firmware built into a
printer. The open-source implementation Ghostscript can translate
PostScript to various graphics formats and (weaker) printer-control
languages. Most other software treats PostScript as a final output
format, meant to be handed to a PostScript-capable imaging device but
not edited or eyeballed.
PostScript (either in the original or the trivial variant
EPSF, with a bounding box
declared around it so it can be embedded in other graphics) is a very
well designed example of a special-purpose control language and
deserves careful study as a model. It is a component of other
standards such as PDF, the Portable Document Format.
[an error occurred while processing this directive]