A postscript library is called a prologue- in that it’s just some boilerplate that you stick at the beginning of every one of your postscript programs to setup the dsl you will be using for your real document. For example, jpeg support was added to postscript by adding a base64 and jpeg decoder function to the prologue of every postscript file with jpegs in it. Postscript fonts are nothing more than elements of a prologue. unicode support comes from prologues, not native features.
at some point it became standard practice to include something like this at the tippy top of every postscript prologue:
/M {moveto} bind def
/L {lineto} bind def
/R {rmoveto} bind def
/V {rlineto} bind def
/N {newpath moveto} bind def
/Z {closepath} bind def
/C {setrgbcolor} bind def
/f {rlineto fill} bind def
/g {setgray} bind defand so later on in the file, where there are complex path definitions, these macros would save tons of space. haha, I just got it. prologue and postscript
i don’t know exactly when or how those path macros became so ubiquitous , but if you look at a typical postscript file in the wild, it will be using those macro shortcuts for paths, almost never the native moveTo lineTo etc functions. and these postscript macros are what SVG’s pathdata standard are based onz here’s gnuplot’s prologue, where I swiped those from
it seems like a strange thing to call a library, a strange system all around. but the idea was that to have a system flexible enough to print any kind of file. so you’d have a prologue for every kind of file you’d want to print, and then to print it, you’d just send the prologue, and then the actual file itself, unaltered. the postscript prologue sets up arbitrary file formats as a printing dsl. so, if you look through github, there’s prologues for printing mail queues.
you could in principle make a prologue for nicely printing markdown documents. then to “convert” markdown to postscript, you could just cat prologue.ps readme.markdown > readme.ps
postscript fonts being prologues has legal implications. In the USA it was ruled that it is not possible to copyright the design of a font. however, it’s still possible to trademark the name of a font. in the modern era, US based font foundries hold copyrights on their fonts. but- this is critical- their copyrights are for the font programs not the font designs since computer programs are copyrightable and fonts are not. thus you could get cdroms of “10,000 fonts” which were knockoffs
is there a conclusion to this? it’s that postscript is way cooler an idea than you think, even if you already think postscript is pretty cool.
oh yeah, also this: adobe illustrator saves everything in the default document swatch and palette patterns to your document prologue. if for whatever reason you wanna get rid of garbage and shrink your adobe illustrator document, delete everything out of your document libraries.
if anything can be called a native app for the postscript language/format, it would be adobe illustrator. perhaps older versions moreso than recent versions. both postscript and illustrator were originally created by John Warnock, with illustrator evolving from an internal tool adobe was using to create postscript fonts.
the native file format for illustrator up until version 9 was postscript. after that, PDF, which is a dialect of postscript designed to avoid the wrath of Turing’s ghost
it turns out that the concept for your printing language being “cool” doesn’t prevent the major downsides of the real world practical problems with software ecosystems at scale
Postscript became the basis for the display system in the NeXT operating system, and the NeWS unix system.
there are many old timers, especially Don Hopkins, who say that NeWS was amazing and they wish modern systems were more like this.
when NeXT became Mac OSX, licensing restrictions meant Apple had to drop display postscript, which they replaced with a system called Quartz. Quartz is interesting, because it is “not postscript” in the same way that dalvik is “not java”
in Quartz, you have all the same native drawing commands and implicit context as you have in postscript- accessed via objective C or plain C drawing instructions.
in Quartz you can swap out different drawing contexts, so that usually you’re drawing to the screen, but you can also draw to a special context that produces PDFs. it turns out this is the entirity of how printing works in native cocoa apps. neat! are there other contexts for drawing directly to various bitmap formats.
when Apple created an OSX feature called Dashboard, they created a widget platform for dashboard widgets, which were little bundles of html and javascript files, plus a few extra APIs available from javascript that gave dashboard widgets some superpowers.
one of these apis was a thin javascript wrapper around Quartz2D which
you could access by including a <canvas> html
tag.
you might already know the rest of this story. Canvas tag got standardised into html5, and so now all modern browsers contain a stripped down javascriptified version of postscript inside of them.
Cairo and Pango seem exist almost only to help inplement this “not postscript”
yep, canvas tag’s lineage traces right back to postscript
i suppose that also means that if the supreme court decides you can copyright an API, that might affect Quartz, and the canvas API by extension.
i just looked at this history of Cairo and- yep- although it doesn’t derive from Quartz2D you could call it a sibling or a cousin. it was created to implement display postscript in x windows.
John Pound is an artist who has been developing his personal postscript prologue for over 20 years. He’s almost got it how he likes it.
I guess this is the POSTSCRIPT FACTS thread now. Here’s another.
I remember reading somewhere, i don’t know where, that to implement postscript on some new imaging device, you needed at minimum to implement a trapezium primitive: A four sided shape where the top and bottom edges are parallel but the other two sides are free to be any angle.
The basic postscript library defined all other primitives in terms of the trapezium
Postscript language tutorial and cookbook from Adobe
A Raster Image Processor or RIP is strange artefact of the printing industry. (I don’t even know if they’re used anymore). These are essentially standalone computers whose one job in life is turning PostScript into pixels, on/off timed signals for an imaging device- typically a film negative, direct-to-plate system or laser printer. the RIP CONTROLS LASERS MAN.
these typically had a lot more powerful CPUs and more memory than the desktop computers controlling them. 1980s era renderfarms.
wouldn’t it be funny if a Prolog library was called a postscript ?
a hypercard stack that is a #postscript tutorial
Why are 2D Vector Graphics so much harder than 3D Vector Graphics?
page 22 here describes how to convert pdf to postscript
where it menitions “procedure sets” i note that is what adobe calls the list of single letter macros mentioned up thread. Apparently PDF standardised some of them?