Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

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?

share|improve this question

closed as unclear what you're asking by Martin Schröder, Svend Tveskæg, Andrew Swann, Malipivo, Jesse Apr 7 at 10:14

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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
25  
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 7 at 10:51
add comment

2 Answers

up vote 30 down vote accepted

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.

share|improve this answer
9  
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
add comment

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.

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. But it's limited to ragged-right.

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.

share|improve this answer
    
A related experiment of mine, this time a ps-markup -> formatted ASCII protocol prolog. –  luser droog Apr 20 at 6:02
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.