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 DanielJul 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.
– JLDiazJul 22 '12 at 17:55

another analogy: the equivalence is similar to that between a chain-saw and a nail-file.
– wasteofspaceApr 7 '14 at 10:51

2 Answers
2

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.

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 ReichJul 22 '12 at 22:29

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.