1. How to Use Registered Colors
While most colors in the Imager and Interpress are specified relative to a color model (for example, that defined by the additive primaries, red, green, and blue), some colors cannot be easily specified this way. One example is the colors used in VLSI design, which use different device dependent tricks to give the effect of transparency. Such colors, often called functional colors can be implemented in the Imager/Interpress world by defining a set of names, one per color, and producing specialized implementations for these names, one for each device. In practice, the standard implementation of a registered color contains a default value which uses one of the standard color models, so not every device needs to have a unique implementation. Once these colors are registered, all clients in the environment can use them.
The names of theses colors are hierarchical, like the Interpress fonts. An example is "Xerox/Research/ChipNDale/CMosB/Poly". The Xerox/Research/ prefix indicates that the color is defined in the Xerox research environment, just like the Xerox/Research/ that starts all our font names. The rest of the name depends on the application. Further naming conventions are given in the implementation section below.
As is the case for fonts, the implementation for the registered colors must be available when the color is used in an image. For Cedar users, the ColorRegistry provides these implementations. All Cedar workstations and printers should have the ColorRegistry installed as a standard part of the environment (it only takes 1 GFI). Please put "Install ColorRegistry" in your user profile as part of your CommandTool.BootCommands (recommended as it takes a few seconds to start up) or as part of your CommandTool.NewUser commands.
The rest of this section describes the colors that are currently part of the ColorRegistry. To use any of these colors, you simply call ImagerColor.Find with the color's name (case is not important). Gargoyle and the ColorTool will soon be modified so you can type the registered name into the ColorTool's text subwindow, set it as the current color, and color objects in Gargoyle with it.
Distinct Colors
When using colors for highlighting or distinguishing among several similar objects, such as lines on a graph, the most important function of the colors is that the different colors be distinct. Given a small number of colors, this distinction not usually difficult to maintain on color devices. However, the usual approximation for colors on black/white devices is not guaranteed to maintain the distinction. The Distinct Color set has been implemented to support applications that need a small number colors that will remain distinct over a wide range of devices.
There are 7 distinct colors: Red, Green, Blue, Yellow, Black, White, Gray. These names are based on the current theory of human color vision which defines one achromatic channel (Black, Gray, White) and two chromatic channels (Red-Green) and (Blue-Yellow). If you think of these channels as three dimensions of a color space, we are using the 2 endpoints of each of the three axes, plus the point in the middle (Gray).
The Distinct colors have been implemented for all the common color and black/white devices in the lab except the Interpress (as opposed to PD) printers: Quoth, Tim's Printer and the Platemaker. The Interpress implementations are coming soon.
Hierarchical name: Xerox/Research/Distinct/
Color names: Red, Green, Blue, Yellow, Black, White, Gray
Devices: LF display
Color Displays: Dither8, Dither4, FullColor, BlackAndWhite
PD Files: Color400, ColorVersatec, BW400, Versatec, Raven384
ChipNDale Colors
The VLSI design tool ChipNDale produces the effect of transparent colors by special manipulation of the colormap on the color display, and by overlapping stipples on the color printers. Until the use of registered colors, it was impossible to make an Interpress master which looked just like the displays or PD plots produced by ChipNDale. The ChipNDale registered colors have been implemented to provide this ability.
Note that the ChipNDale colors are transparent, that is, they depend on the color of the background. Clients of these colors should set the background to white for black/white devices, and to Xerox/Research/ChipNDale/CD/InitialColor before starting. It is also necessary to have the appropriate CMosB colormap loaded for the color display.
The current set of ChipNDale colors support the basic ChipNDale layers plus the CMosB technology. While the basic implementation is identical for all ChipNDale colors, the actual data used to generate the stipples or layers varies with each technology. The ChipNDale colors are therefore arranged into a two level hierarchy. We will add more technologies later if there is sufficient interest.
Hierarchical name: Xerox/Research/ChipNDale/CD/
Color names: UndefLayer, ShadeLayer, ErrorLayer, BackGround, Outline, Selection, Comment, Blue, Red, Green, Yellow, Gray, InitialColor
Devices: LF display
Color Displays: Dither8, Dither4, BlackAndWhite
PD Files: Color400, ColorVersatec
Hierarchical name: Xerox/Research/ChipNDale/CMosB/
Color names: NDif, PDif, PWel, NWel, PWelCont, NWelCont, Pol, Met, Met2, Ovg, Cut, Cut2, Imp, Bur
Devices: LF display
Color Displays: Dither8, Dither4, BlackAndWhite
PD Files: Color400, ColorVersatec
2. How to Implement Registered Colors
It is assumed that the implementations of all commonly used registered colors will lie in RegisteredColorsImpl. Clients can locally define colors using the techniques described below. However, the implementations will not be generally available unless they are released with the ColorRegistry.
The implementation of a registered color is an ImagerColor.SpecialColor. The Special color variant of the imager color representation is defined as:
special => [
-- XOR, stipples, named colors, and the like
type: ATOM, -- identifies the kind of special color this is
name: ROPE, -- hierarchical name
data: REF, -- implementation-specific data
substitute: ConstantColor -- use this if you don't recognize type
]
Registered colors usually come in sets or classes, grouped according to their implementations. Each set is identified by the type ATOM in the special color. Currently defined types are: $Distinct, $ChipNDale, $BitmapTile and $Stipple (the last two are built into the Imager).
The substitute field may also be a special color, and the device implementations will chain down the through the various substitutes until they find one they recognize. The only universal color specification in Interpress is MAKEGRAY. Clients of the Imager can count on ImagerColor.ColorFromGray, ImagerColor.ColorFromRGB and ImagerColor.ColorFromStipple to produce universally recognized colors (within PARC, at least).
ColorRegistry.mesa
The Data TYPE
ColorRegistry.mesa defines the type used for the
data
REF in the Special color definition above.
Data: TYPE = REF DataRec;
DataRec: TYPE = RECORD[colorIndex: NAT, id: ATOM, colorValues: ColorSequence];
ColorSequence: TYPE = REF ColorSequenceRec;
ColorSequenceRec: TYPE = RECORD[elements: SEQUENCE length: NAT OF DeviceSequence];
DeviceSequence: TYPE = REF DeviceSequenceRec;
DeviceSequenceRec: TYPE = RECORD[elements: SEQUENCE length: NAT OF REF];
Each color in each type (defined by the type field of the SpecialColor type) has a unique number, which is recorded in the colorIndex field. This index is used to find the sequence of device dependent implementations for that color. Each device also has a unique index (see ColorRegistryImpl for the current list). The device index is used to select the implementation out of the DeviceSequence. The principal advantage of this implementation is its speed; to get to the implementation for a particular color for a particular device takes two array references and two NARROW's. The cost is that we store at least a REF for every device for every color. There are currently 14 devices and 34 colors.
The id ATOM in the DataRec is used to provide a quick way of distinguishing which special color of a class is this is (in case the implementation needs to do something special). For example, Black and White are treated specially in the PD device implementation of the Distinct colors. While this information is available from both the name and the colorIndex, the name is time consuming to parse, and the colorIndex is effectively an opaque type; that is, we don't want to have change an interface, or all the implementations, if we add another color or reorder the colors in a set.
Typical implementation TYPEs
The interface ColorRegistry provides two useful TYPEs for device implementations that need to use an array of samples to define a color:
ImagerPDPublic.Toner: TYPE ~ {black, cyan, magenta, yellow, last}; --ignore last
ColorPDBrick: TYPE = RECORD[toner: ImagerPDPublic.Toner, tile: ImagerBrick.Brick];
DisplayBrick: TYPE = RECORD[function: ImagerSample.Function ← [null, null], tile: ImagerBitmapContext.Brick];
ImagerBrick.Brick: TYPE ~ RECORD [maxSample: CARDINAL, sampleMap: Imager.SampleMap, phase: NAT];
ImagerBitmapContext.Brick: TYPE ~ RECORD [maxSample: CARDINAL, sampleMap: ImagerSample.RasterSampleMap, phase: NAT];
ImagerBrick.Brick and ImagerBitmapContext.Brick are effectively the same type, although there are two different record definition. The ImagerBrick.Brick is actually slightly more general, as it could include a SampleMap defined by a function as well as one defined by an array of pixels. If this additional flexibility is needed, I'll change the type.
For color printers, the common implementations are either REF CMYK or LIST of REF ColorPDBrick, providing one ColorPDBrick per toner. All the display implementations use either a REF ImagerBitmapContext.Brick or let the color default to a $BitmapTile or $Stipple color.
Naming Conventions
All registered color names should begin "Xerox/Research/." The next level of the hierarchy should indicate the type or class, and be the print name of the ATOM in the type field of the SpecialColor record. Beyond that, clients are pretty much on their own. One further convention that has been followed to date is that the leaf name of the color match the id ATOM in the DataRec. However, if this field is used to provide subgroups, then this would not be a useful convention.
Device Implementations
To make a device recognize a special color, the SetColor procedure of the device implementation must be changed. In CSL, the device implementations live in the following places:
The LF display and the BlackAndWhite context for the color display are implemented by ImagerBitmapContextImpl,which is part of the Imager.
ImagerColorDisplay.df contains all the color display contexts except BlackAndWhite
ImagerPD.df contains the PD device implementation
ImagerBitmapContextImpl,which is part of the Imager is also used for Quoth, TimsPrinter and the Platemaker. The Platemaker will be changed soon to use a separate bitmap context.
If you are using the data type defined in ColorRegistry, the device implementation must now import that interface. This is impossible for the BitmapContext, as packages that live on the Cedar cannot import packages that live on CedarChest. For most colors, the $BitmapTile special color will provide sufficient flexibility on the bitmap displays. Provide it as the first substitute for the special color you are implementing, and with the guaranteed default as the substitute for the $BitmapTile special color.