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.
|