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 main one. Refer to the comments in the interface for a description of the various operations.

For dealing with particular data types that are used by Imager. The sections below deal with some aspects of these data types; see also the comments in the interfaces.

For creating contexts for drawing into a bitmap.

Operations that are not applicable to every kind of context.

The Device coordinate system is in whatever units are most convenient for the implementation.

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-device transformation is accessible via ImagerBackdoor.GetT from those contexts that retain state information.

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. For most applications, the convenience procedures ScaleT, Scale2T, RotateT, TranslateT are handy. ScaleT applies a uniform scaling factor; Scale2T scales independently in x and y; RotateT applies a rotation (measured in degrees, counterclockwise if positive); and TranslateT translates the origin.

This is a constant color that comes from applying a color operator. This kind of color is represented in an unevaluated form, as simply the color operator and its argument vector. One important aspect of this kind of color is that it always makes sense to interpolate continuously between color values, so that filtering for antialiasing will always make sense (see the sampled case, below). Examples of op constant colors are various flavors of gray (GrayLinear, GrayDensity, GrayVisual, etc), RGB (red-green-blue), CMY (cyan-magenta-yellow), etc.

This is a constant color that may not be interpolated, and that may have a greater degree of device dependence. These would most often be asked for by name via ImagerColor.Find, or created via the interfaces associated with particular kinds of Imager contexts. Examples of these are device-resolution stipples and special pixel colors for color-mapped frame buffers. Special constant colors have a link (substitute) field in them, so that context implementations can search for the first appropriate case; for example a special pattern for the color display may link to a black-and-white stipple for the black-and-white display, which in turn may point to an ordinary gray that will work on any context.

This is a color that consists of an array of pixel values, together with a color operator that indicates how the pixel values are to be interpreted. There is also a transformation for controlling the size, orientation, and positioning. The array of pixels tiles the whole plane.

This is similar to a sampled color, but is restricted to one bit per pixel, and instead of a color operator there is only a Boolean to say whether zeros are white or transparent (ones are always black).

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

Font files live on subdirectories of /imagerfonts/ in the local name space. The PCedar Imager uses PFS to look up these files, so the PFS prefix map facilities may be used to tailor the font namespace to various applications. For instance,

is the file that describes Xerox/XC1-2-2/Modern-bold; the extension identifies the format ot the font files. Note the filename is all lower-case, in case it matters. The list of known extensions is currently

For details on all but the last four, see [Cyan]<PrintingDocs>FontFormats.Press. There are some changes in the way the fields of the ac fonts are interpreted; in particular the resolutionY fields in some ac fonts contain the character set information.

In no case (so far) does the Imager get multiple fonts from a single file.