Imager is a successor to the Cedar Graphics package that was developed by John Warnock and Doug Wyatt. The design of Imager benefited from advice offered by Frank Crow, Butler Lampson, Scott McGregor, Ken Pier, Lyle Ramshaw, Bob Sproull, and Maureen Stone. The main designers and implementors of Imager were Michael Plass and Doug Wyatt.

The Device coordinate system is in whatever units are most convenient for the implementation, and is normally inaccessible to the client.

The Surface coordinate system covers the entire output medium, one unit per pixel, with the origin at the lower-left corner and x to the right, y up.

The View coordinate system is normally just a translation from the Surface coordinates. This is normally maintained by the window package, not by random clients. When reading Interpress documentation, read "View coordinates" wherever you see "Device Coordinates". The View has a clipping area associated with it, which is often (but not always) just a rectangle. The View clipping area, as well as the View transformation, are not affected by DoSave, or DoSaveAll.

The Client coordinate system is the one the client thinks in terms of. Initially in meters, it may be changed by the client at any time to whatever is most convenient. (If the client is using a context provided by viewers, the initial client-to-view is the identity, which is in some ways less device-independent, but often more convenient.) The client-to-view transformation is accessible as context.state.T, for contexts that retain state.

The basic procedure for changing the current (client-to-view) transformation is:

ConcatT premultiplies the current transformation by an arbitrary transformation. Procedures for building general transformations are in the ImagerTransformation interface. If you just want to do something simple, the convenience procedures ScaleT, Scale2T, RotateT, TranslateT may be handy. ScaleT applies a uniform scaling factor; Scale2T scales independently in x and y; RotateT applies a counterclockwise rotation (measured in degrees); and TranslateT translates the origin.

Fonts are named using a hierarchical naming scheme, with the components of the name separated by slashes. Examples:

Font files live on subdirectories of []<>Fonts> on the local system volume. For instance,

is the file that describes Xerox/PressFonts/Modern-brr; the extension identifies the format ot the font files. The list of known extensions is currently

For details on all but the last, see [Cyan]<PrintingDocs>FontFormats.Press.

The XC*-*-* fonts in general need multiple files to describe all the characters, because of the limitations in the old font file formats we use. There is one file for each non-empty character set (block of 256 codes). Thus the collection of files

together describe the single font Xerox/XC1-2-2/Modern-bold.

There is also a way for fonts to exist without a corresponding file, so there are fonts that will work even when you can't find them in a list. Thus if you ask for Xerox/XC0-0-0/Modern-bold, you may actually get Xerox/XC1-2-2/Modern-bold, perhaps with the codes rearranged to conform to the older standard.