Wandy Sae-Tan's and Olin Shiver's Functional PostScript embeds PostScript's base imaging operators in Scheme, resulting in a portable system for doing device and resolution independent graphics from Scheme programs ... like Olin Shiver's maze generator, whose FPS backend and sample output you may want to have a look at. This and other FPS examples are listed on the page for graphics resources. Download version 1.0 of the package and a patch to load FPS into scsh version 0.5.3 or later. The following explanation has been snarfed from a historic SU project list @ ai.mit.edu. PostScript is the industry-standard description language for marking devices such as laser-printers. PostScript, in fact, is a complete programming language. When you send a PostScript file to a printer, you are really sending a complete program to be executed by the printer. As the printer executes your PostScript program, it builds up images on the page and prints them out. PostScript is a simple language. It has a base set of imaging operators (such as “fill in this outline with ink” or “rotate this image by an angle”). These basic operators are composed and applied by programs written in the Forth programming language. Functional PostScript is a UROP -designed graphics language that takes PostScript's base imaging operators, and embeds them in a Scheme engine instead of a Forth engine. A picture description is a small (or not so small) Scheme program; executing the program causes the picture to be rendered. The resulting language is something fairly similar to the “picture” language used in Structure and Interpretation of Computer Programming and the 6.001 course for building Escher-like pictures, but with the extremely powerful PostScript primitives at the base. For example, you can use any PostScript font to render text. The result is a system that provides device-independent, resolution-independent graphics support from Scheme. A full description of the system can be obtained on the Web, complete with sources. (Take a look; it's an elegant system.) The current implementation produces output by rendering the picture to a stream of straight-line PostScript text, which can then be shipped off to any PostScript printer, or viewed from Ghostview or other previewer program. We'd like to have a back-end that renders directly to the screen. This could be done by linking FPS's Scheme with the free Ghostscript C library of PostScript primitives to render to X. Then we'd have a high-level, device-independent graphics system for doing interactive screen graphics.