17

THE POSTSCRIPT® LANGUAGE is a simple interpretive programming language with powerful graphics capabilities.

... Because of the importance of text in most applications, the PostScript language provides special capabilities for organizing sets of characters as fonts and for painting characters efficiently.

Can the PostScript Language be used to fully replace TeX?

Alan Munn
  • 218,180
kiss my armpit
  • 36,086
  • You can compile a simple document with latex and dvips. After this you can open the ps-file with you favorite text editor. – Marco Daniel Jul 22 '12 at 17:53
  • 26
    Your question is equivalent to "Can intel assembly language fully used to replace C programmming language?". If you are a programmer, you can make full sense of this analogy. – JLDiaz Jul 22 '12 at 17:55
  • another analogy: the equivalence is similar to that between a chain-saw and a nail-file. – wasteofspace Apr 07 '14 at 10:51

2 Answers2

32

PostScript and TeX are designed for different purposes and for this reason one would never exchange one for the other as a replacement. However, from a purely theoretical point of view, both are Turing-complete languages and therefore anything that could be expressed in TeX could be also expressed in PostScript and vice versa.

That aside, PostScript is designed as a page description language and TeX as a typesetting system (or language). PostScript deals with lines, characters, rotation of a coordination system, scaling and colors whereas TeX deals with paragraphs, macros to define a markup language and generally provides many high-level services that PostScript hasn't built in: line breaking, hyphenation, breaking paragraphs into pages, footnotes, typesetting of math. Hence, PostScript is much more low level and indeed is one of the target languages for TeX engines: TeX is compiled to PostScript code (via dvips) or to PDF which can be considered a subset of PostScript.

Community
  • 1
Christian Lindig
  • 14,627
  • 10
    You know this, so for the audience: the Turing-completeness of TeX and PostScript is a red herring here, as your examples of their respective strengths show. TeX could provide line breaking, hyphenation, pagination, inserts, and math typesetting without being complete, and still be valuable as a typesetting tool. PostScript can only do these things by, effectively, building a virtual typesetting machine within itself using its Turing-complete language. Each language may be capable of reimplementing the other, but internally they have different abilities. – Ryan Reich Jul 22 '12 at 22:29
13

There have been many attempts to use Postscript's programming power to implement a fuller document-production environment. AFAIK they all fall short of TeX's line-fitting abilities.

The most basic is the typewriter emulator from the Postscript Tutorial (Blue Book), which is then extended in the later Reid books (the Green Book and Thinking In Postscript) to handle embedded control-codes for font changes. These ones operate by reinterpreting the program stream, so I often call them "protocol-prolog" style.

Another style is to implement a set of commands with short mnemonic names and implement the document in the RPN syntax. Examples include the Gonzo Tools, Practical Postscript. This is also the primary technique for designing the output for a postscript driver. (The Green Book and Thinking in PostScript are also good resources for this avenue.)

A hybrid of the above approaches is illustrated by Anastigmatix's tools which even implement the Knuth-Liang hyphenation algorithm.

Not as powerful as Anastigmatix's tools, but stealing as many of his ideas as I could, my own effort (disclosure: it's also my resume, nudge nudge.) includes a combination of the above approaches, with a set of mnemonic procedures and embedded control-codes (including arbitrary postscript code) in the strings which contain the text. Edit: A more complete program of mine is available for review on codereview.se. As predicted, it too falls short of tex's line-fitting capability.

On the other end of the issue is capturing the drawing output as a flattened ps document. The traditional tool for this is still.ps (in some sense, still.ps is to Distiller what cfront was to a native C++ compiler, by supplementing and extending the existing programmability (the ps interpreter on the one hand, the c compiler on the other). not really going anywhere with this, but I find it interesting). With ghostscript's -sDEVICE=ps2write (and sDEVICE=pdfwrite) still.ps is largely unnecessary nowadays, but it remains a goldmine of postscript programming idioms and style.

One other notable example is Julian Wiseman's code for creating Wine-tasting placemats. It is a large, heavily customizable postscript "document" which defines many layout choices.

luser droog
  • 894