fps
Note: This is taken from the Chicken Wiki, where a more recent version could be available.
FPS is a portable system for doing device-independent, resolution-independent graphics from Scheme programs. It is PostScript, with the Forth computational engine replaced with Scheme.
FPS is tightly based upon PostScript. It uses *exactly* the PostScript base rendering primitives. For example, it understands PostScript AFM files, and can render text using general PostScript fonts.
The design of FPS centers on two basic data structures: paths and pictures. A path is an invisible, ideal geometric path on a plane. A picture is a description of ink on paper. Paths can be scaled, rotated, translated, and composed, creating new paths. Filling or stroking a path creates a picture. Pictures can also be scaled, rotated, translated, clipped, recolored, and composed, creating new pictures. The system is fully functional and free of side effects. The single side effect available to the user is rendering a picture to an output device. PostScript fonts are supported for generating paths and pictures from text.
The system is not a "toy." The full set of PostScript rendering primitives are provided: lines, curve, arcs, glyphs, and bitmaps. Full control is provided of the rendering engine's style parameters, such as line width, and cap style. Interchangeable RGB, CMYK, and HSB color models are provided.
The current release of FPS renders pictures to any Scheme port as a stream of straight-line, DSC-compliant PostScript text which can be submitted to any PostScript printer or viewed with ghostview. The renderer can generate EPS text if desired. The actual rendering is done on the printer, for accuracy and efficiency (the system has been carefully designed to allow for this phase-distinction between picture construction and rendering).
The current release has at least three lacunae: we do not currently support PostScript patterned fills, text kerning, or huge, CID fonts (such as Chinese).
More documentation can be found in fps-ref.txt and fps-tutorial.txt.
(require-extension fps)
Since some exported procedures clash with existing library names, all global definitions provided by this extension have been prefixed with fps:, that is compose is renamed to fps:compose and :line-width becomes fps::line-width. The exported syntax definitions with-style and with-attrib are not prefixed.
In combination with syntax-case, you can also access the exported definitions without the prefix by importing the fps module:
(import fps)
The same can be achieved with the modules egg (note that importing fps at top-level still clobbers some library functions).
syntax-case is needed for building this extension, but not for using it.
records and format-modular are required at run-time.
The AFM files for some common fonts are included in the AFM directory, located in the extension repository:
Times-Roman.afm Times-BoldItalic.afm Courier.afm Helvetica.afm Symbol.afm
To overrride that location, set the environment variable FPS_AFM_PATH to a colon-separated list of directories.
Wandy Sae-Tan and Olin Shivers
FPS is copyright the authors, Wandy Sae-tan and Olin Shivers. Don't worry about this too much. We advocate open use of the system and provide sources in our releases. We retain copyright mostly as a means of controlling the specific interface named by the term "FPS." We want there to be a reliable interface spec on which programmers can depend, so we are centralising control of that interface.
If you want to use FPS for a commercial system, send us email. There should be no trouble.
If you want to extend the system, and want to fold your changes back in to the shipped design, send us mail at wandy@mit.edu and shivers@ai.mit.edu.
Copyright © 1996 Wandy Sae-Tan and Olin Shivers