Why PostScript had to be Turing-complete makes no sense to me. Loops, code-execution, functions, it all seems so unnecessary for a markup and presentation language.
I’m not a PostScript expert but I’ve been reading a lot about it recently. It’s a rather fascinating system for 2D graphics.
That being said, in combination with exploitable vulnerabilities in particular PostScript parsers used in software like Acrobat, the Turing-completeness of PostScript makes it much harder to detect such exploits. 0days in PDF readers are "nice exploits to have", because a PDF virus can be coded such that it's represented in code inside the PDF in an unbounded number of different ways, foiling signature-based virus sanners.
gs -dNOSAFER zmachine.ps -- yourgame.z3Thankfully we learned from them and didn’t repeat that mistake over and over again.
1. a declarative language for describing the same things PostScript describes,
2. which allows the rasterization of arbitrary shapes at arbitrary DPI (PostScript is DPI-oblivious — it's up to the printer what DPI it's printing at!);
3. and which also works for vector plotters, that will never rasterize the data you're sending at all, but will actually follow the bezier curves, like the 2D version of 3D-printer GCODE;
4. and which enables the implementation of this rasterization and/or plotting on a variety of affordable hardware architectures in the 1980s — where the 1980s was a time where CPU power wasn't too expensive, but where memory prices were at an absolute premium. So your printer might have had a CPU as powerful as your computer's in it, to crunch PostScript — but definitely wouldn't have had the memory to buffer a full rasterized page.
---
To put that last constraint another way: PostScript was designed to be rasterized in a way that enabled printers to do something much akin to "Racing the Beam" (https://www.youtube.com/watch?v=sJFnWZH5FXc).
In both the display-rendering and printing cases, this was done in 1980s hardware, because 1980s memory was too expensive for most systems to be dedicating it to hold a buffer to asynchronously pre-render into and then read from when drawing.
So instead, in both cases, you must render+rasterize in one motion, programmatically and extremely efficiently. And the obvious way to do this, is by using a CPU with rasterization MMIO registers it can very quickly poke at, to change mode bits during the rendering process. A CPU whose ISA becomes, in effect, a Domain Specific Bytecode for procedurally generating raster-lines.
If printer vendors of the 1980s could have been expected to agree on a single such ISA, then chip vendors would have just made printer SoCs that conform to that ISA — and we'd have ended up with some kind of "vector-drawing abstract machine" bytecode (with real hardware impls in printer ASICs, but also virtual ones on PCs) rather than PostScript.
But as with RDBMS vendors in the 1980s, the printer vendors were all too invested in their own internal architectures to agree on what the low-level execution plan should look like.
And a with RDBMS vendors, the solution that all these 1980s manufacturers could get behind, was a standard for a (theoretically) portsable, text-based intermediate-language standard — one that could be generated by computer software, transmitted to their system, and then, inside their system, compiled down to whatever internal representation allows the system to do things its own way.
In RDBMSes, this "intermediate language" was SQL. In printers: PostScript.