xenocara/doc/xorg-docs/specs/XProtocol/glossary

.\" $Xorg: glossary,v 1.3 2000/08/17 19:42:25 cpqbld Exp $
.ps 11
.nr PS 11
\&
.sp 1
.XS
Glossary
.XE
.ce 1
\s+1\fBGlossary\fP\s-1
.sp 2
.na
.LP
.KS
\fBAccess control list\fP
.IN "Access control list" "" "@DEF@"
.IP
X maintains a list of hosts from which client programs can be run.
By default, 
only programs on the local host and hosts specified in an initial list read 
by the server can use the display. 
Clients on the local host can change this access control list.
Some server implementations can also implement other authorization mechanisms 
in addition to or in place of this mechanism.
The action of this mechanism can be conditional based on the authorization 
protocol name and data received by the server at connection setup.
.KE
.KS
.LP
\fBActive grab\fP
.IN "Active grab" "" "@DEF@"
.IP
A grab is active when the pointer or keyboard is actually owned by
the single grabbing client.
.KE
.KS
.LP
\fBAncestors\fP
.IN "Ancestors" "" "@DEF@"
.IP
If W is an inferior of A, then A is an ancestor of W.
.KE
.KS
.LP
\fBAtom\fP
.IN "Atom" "" "@DEF@"
.IP
An atom is a unique ID corresponding to a string name.
Atoms are used to identify properties, types, and selections.
.KE
.KS
.LP
\fBBackground\fP
.IN "Background" "" "@DEF@"
.IP
An 
.PN InputOutput 
window can have a background, which is defined as a pixmap.
When regions of the window have their contents lost or invalidated, 
the server will automatically tile those regions with the background.
.KE
.KS
.LP
\fBBacking store\fP
.IN "Backing store" "" "@DEF@"
.IP
When a server maintains the contents of a window, 
the pixels saved off screen are known as a backing store.
.KE
.KS
.LP
\fBBit gravity\fP
.IN "Bit" "gravity" "@DEF@"
.IP
When a window is resized, 
the contents of the window are not necessarily discarded.
It is possible to request that the server relocate the previous contents 
to some region of the window (though no guarantees are made).
This attraction of window contents for some location of
a window is known as bit gravity.
.KE
.KS
.LP
\fBBit plane\fP
.IN "Bit" "plane" "@DEF@"
.IP
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a bit plane or plane.
.KE
.KS
.LP
\fBBitmap\fP
.IN "Bitmap" "" "@DEF@"
.IP
A bitmap is a pixmap of depth one.
.KE
.KS
.LP
\fBBorder\fP
.IN "Border" "" "@DEF@"
.IP
An 
.PN InputOutput 
window can have a border of equal thickness on all four sides of the window.
A pixmap defines the contents of the border,
and the server automatically maintains the contents of the border.
Exposure events are never generated for border regions.
.KE
.KS
.LP
\fBButton grabbing\fP
.IN "Button" "grabbing" "@DEF@"
.IP
Buttons on the pointer may be passively grabbed by a client.
When the button is pressed, 
the pointer is then actively grabbed by the client.
.KE
.KS
.LP
\fBByte order\fP
.IN "Byte order" "" "@DEF@"
.IP
For image (pixmap/bitmap) data, 
the server defines the byte order,
and clients with different native byte ordering must swap bytes as necessary.
For all other parts of the protocol, 
the client defines the byte order,
and the server swaps bytes as necessary.
.KE
.KS
.LP
\fBChildren\fP
.IN "Children" "" "@DEF@"
.IP
The children of a window are its first-level subwindows.
.KE
.KS
.LP
\fBClient\fP
.IN "Client" "" "@DEF@"
.IP
An application program connects to the window system server by some
interprocess communication path, such as a TCP connection or a
shared memory buffer.
This program is referred to as a client of the window system server.
More precisely, 
the client is the communication path itself; 
a program with multiple paths open to the server is viewed as
multiple clients by the protocol.
Resource lifetimes are controlled by connection lifetimes, 
not by program lifetimes.
.KE
.KS
.LP
\fBClipping region\fP
.IN "Clipping region" "" "@DEF@"
.IP
In a graphics context, 
a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window.
The image defined by the bitmap or rectangles is called a clipping region.
.KE
.KS
.LP
\fBColormap\fP
.IN "Colormap" "" "@DEF@" 
.IP
A colormap consists of a set of entries defining color values.
The colormap associated with a window is used to display the contents of
the window; each pixel value indexes the colormap to produce RGB values
that drive the guns of a monitor.
Depending on hardware limitations,
one or more colormaps may be installed at one time, 
so that windows associated with those maps display with correct colors.
.KE
.KS
.LP
\fBConnection\fP
.IN "Connection" "" "@DEF@"
.IP
The interprocess communication path between the server and client
program is known as a connection.
A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
.KE
.KS
.LP
\fBContainment\fP
.IN "Containment" "" "@DEF@"
.IP
A window ``contains'' the pointer if the window is viewable and the
hotspot of the cursor is within a visible region of the window or a
visible region of one of its inferiors.
The border of the window is included as part of the window for containment.
The pointer is ``in'' a window if the window contains the pointer 
but no inferior contains the pointer.
.KE
.KS
.LP
\fBCoordinate system\fP
.IN "Coordinate system" "" "@DEF@"
.IP
The coordinate system has the X axis horizontal and the Y axis vertical, 
with the origin [0, 0] at the upper left.
Coordinates are integral,
in terms of pixels,
and coincide with pixel centers.
Each window and pixmap has its own coordinate system.
For a window, 
the origin is inside the border at the inside upper left.
.KE
.KS
.LP
\fBCursor\fP
.IN "Cursor" "" "@DEF@"
.IP
A cursor is the visible shape of the pointer on a screen.
It consists of a hot spot, a source bitmap, a shape bitmap, 
and a pair of colors.
The cursor defined for a window controls the visible appearance 
when the pointer is in that window.
.KE
.KS
.LP
\fBDepth\fP
.IN "Depth" "" "@DEF@"
.IP
The depth of a window or pixmap is the number of bits per pixel that it has.
The depth of a graphics context is the depth of the drawables it can be
used in conjunction with for graphics output.
.KE
.KS
.LP
\fBDevice\fP
.IN "Device" "" "@DEF@"
.IP
Keyboards, mice, tablets, track-balls, button boxes, and so on are all
collectively known as input devices.
The core protocol only deals with two devices, 
``the keyboard'' and ``the pointer.''
.KE
.KS
.LP
\fBDirectColor\fP
.IN "DirectColor" "" "@DEF@"
.IP
.PN DirectColor
is a class of colormap in which a pixel value is decomposed into three
separate subfields for indexing.
The first subfield indexes an array to produce red intensity values.
The second subfield indexes a second array to produce blue intensity values.
The third subfield indexes a third array to produce green intensity values.
The RGB values can be changed dynamically.
.KE
.KS
.LP
\fBDisplay\fP
.IN "Display" "" "@DEF@"
.IP
A server, together with its screens and input devices, is called a display.
.KE
.KS
.LP
\fBDrawable\fP
.IN "Drawable" "" "@DEF@"
.IP
Both windows and pixmaps can be used as sources and destinations in
graphics operations.
These windows and pixmaps are collectively known as drawables.
However, an 
.PN InputOnly 
window cannot be used as a source or destination in a graphics operation.
.KE
.KS
.LP
\fBEvent\fP
.IN "Event" "" "@DEF@"
.IP
Clients are informed of information asynchronously by means of events.
These events can be generated either asynchronously from devices 
or as side effects of client requests.
Events are grouped into types. 
The server never sends events to a client unless the
client has specificially asked to be informed of that type of event.
However, other clients can force events to be sent to other clients.
Events are typically reported relative to a window.
.KE
.KS
.LP
\fBEvent mask\fP
.IN "Event" "mask" "@DEF@"
.IP
Events are requested relative to a window.
The set of event types that a client requests relative to a window 
is described by using an event mask.
.KE
.KS
.LP
\fBEvent synchronization\fP
.IN "Event" "synchronization" "@DEF@"
.IP
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations).
The event synchronization mechanism allows synchronous processing 
of device events.
.KE
.KS
.LP
\fBEvent propagation\fP
.IN "Event" "propagation" "@DEF@"
.IP
Device-related events propagate from the source window to ancestor
windows until some client has expressed interest in handling that type
of event or until the event is discarded explicitly.
.KE
.KS
.LP
\fBEvent source\fP
.IN "Event" "source" "@DEF@"
.IP
The window the pointer is in is the source of a device-related 
event.
.KE
.KS
.LP
\fBExposure event\fP
.IN "Event" "Exposure" "@DEF@"
.IP
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured.
Exposure events are sent to clients to inform them when contents 
of regions of windows have been lost.
.KE
.KS
.LP
\fBExtension\fP
.IN "Extension" "" "@DEF@"
.IP
Named extensions to the core protocol can be defined to extend the
system.
Extension to output requests, resources, and event types are
all possible and are expected.
.KE
.KS
.LP
\fBFocus window\fP
.IN "Focus window" "" ""@DEF@"
.IP
The focus window is another term for the input focus.
.KE
.KS
.LP
\fBFont\fP
.IN "Font" "" "@DEF@"
.IP
A font is a matrix of glyphs (typically characters).
The protocol does no translation or interpretation of character sets.
The client simply indicates values used to index the glyph array.
A font contains additional metric information to determine interglyph 
and interline spacing.
.KE
.KS
.LP
\fBGC\fP, \fBGContext\fP
.IN "GC" "" "@DEF@"
.IN "GContext" "" "@DEF@"
.IP
GC and gcontext are abbreviations for graphics context.
.KE
.KS
.LP
\fBGlyph\fP
.IN "Glyph" "" "@DEF@"
.IP
A glyph is an image, typically of a character, in a font.
.KE
.KS
.LP
\fBGrab\fP
.IN "Grab" "" "@DEF@"
.IP
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be grabbed for exclusive use by a client.
In general,
these facilities are not intended to be used by normal applications
but are intended for various input and window managers to implement
various styles of user interfaces.
.KE
.KS
.LP
\fBGraphics context\fP
.IN "Graphics context" "" "@DEF@"
.IP
Various information for graphics output is stored in a graphics context 
such as foreground pixel, background pixel, line width, clipping region, 
and so on.
A graphics context can only be used with drawables that have the same root 
and the same depth as the graphics context.
.KE
.KS
.LP
\fBGravity\fP
.IN "Gravity" "" "@DEF@"
.IP
See \fBbit gravity\fP and \fBwindow gravity\fP.
.KE
.KS
.LP
\fBGrayScale\fP
.IN "GrayScale" "" "@DEF@"
.IP
.PN GrayScale 
can be viewed as a degenerate case of 
.PN PseudoColor , 
in which the red, green, and blue values in any given colormap entry are equal,
thus producing shades of gray.
The gray values can be changed dynamically.
.KE
.KS
.LP
\fBHotspot\fP
.IN "Hotspot" "" "@DEF@"
.IP
A cursor has an associated hotspot that defines the point in the
cursor corresponding to the coordinates reported for the pointer.
.KE
.KS
.LP
\fBIdentifier\fP
.IN "Identifier" "" "@DEF@"
.IP
An identifier is a unique value associated with a resource that clients use 
to name that resource.
The identifier can be used over any connection.
.KE
.KS
.LP
\fBInferiors\fP
.IN "Inferiors" "" "@DEF@"
.IP
The inferiors of a window are all of the subwindows nested below it:
the children, the children's children, and so on.
.KE
.KS
.LP
\fBInput focus\fP
.IN "Input focus" "" "@DEF@"
.IP
The input focus is normally a window defining the scope for
processing of keyboard input.
If a generated keyboard event would normally be reported to this window 
or one of its inferiors, 
the event is reported normally.
Otherwise, the event is reported with respect to
the focus window.
The input focus also can be set such that all
keyboard events are discarded and such that the focus
window is dynamically taken to be the root window of whatever screen
the pointer is on at each keyboard event.
.KE
.KS
.LP
\fBInput manager\fP
.IN "Input manager" "" "@DEF@"
.IP
Control over keyboard input is typically provided by an input manager client.
.KE
.KS
.LP
\fBInputOnly window\fP
.IN "Window" "InputOnly" "@DEF@"
.IP
An
.PN InputOnly
window is a window that cannot be used for graphics requests.
.PN InputOnly 
windows are invisible and can be used to control such things 
as cursors, input event generation, and grabbing.
.PN InputOnly 
windows cannot have 
.PN InputOutput 
windows as inferiors.
.KE
.KS
.LP
\fBInputOutput window\fP
.IN "Window" "InputOutput" "@DEF@"
.IP
An
.PN InputOutput
window is the normal kind of opaque window, used for both input and output.
.PN InputOutput 
windows can have both 
.PN InputOutput 
and 
.PN InputOnly 
windows as inferiors.
.KE
.KS
.LP
\fBKey grabbing\fP
.IN "Key" "grabbing" "@DEF@"
.IP
Keys on the keyboard can be passively grabbed by a client.
When the key is pressed, 
the keyboard is then actively grabbed by the client.
.KE
.KS
.LP
\fBKeyboard grabbing\fP
.IN "Keyboard" "grabbing" "@DEF@"
.IP
A client can actively grab control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
.KE
.KS
.LP
\fBKeysym\fP
.IN "Keysym" "" "@DEF@"
.IP
An encoding of a symbol on a keycap on a keyboard.
.KE
.KS
.LP
\fBMapped\fP
.IN "Mapped window" "" "@DEF@"
.IP
A window is said to be mapped if a map call has been performed on it.
Unmapped windows and their inferiors are never viewable or visible.
.KE
.KS
.LP
\fBModifier keys\fP
.IN "Modifier keys" "" "@DEF@"
.IP
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called modifier keys.
.KE
.KS
.LP
\fBMonochrome\fP
.IN "Monochrome" "" "@DEF@"
.IP
Monochrome is a special case of 
.PN StaticGray 
in which there are only two colormap entries.
.KE
.KS
.LP
\fBObscure\fP
.IN "Obscure" "" "@DEF@"
.IP
A window is obscured if some other window obscures it.
Window A obscures window B if both are viewable 
.PN InputOutput 
windows, A is higher in the global stacking order, 
and the rectangle defined by the outside edges of A intersects 
the rectangle defined by the outside edges of B.
Note the distinction between obscure and occludes.
Also note that window borders are included in the calculation
and that a window can be obscured and yet still have visible regions.
.KE
.KS
.LP
\fBOcclude\fP
.IN "Occlude" "" "@DEF@"
.IP
A window is occluded if some other window occludes it.
Window A occludes window B if both are mapped, A is higher in the global
stacking order, and the rectangle defined by the outside edges of A
intersects the rectangle defined by the outside edges of B.
Note the distinction between occludes and obscures.
Also note that window borders are included in the calculation.
.KE
.KS
.LP
\fBPadding\fP
.IN "Padding" "" "@DEF@"
.IP
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries.
This increases ease of portability to some machine architectures.
.KE
.KS
.LP
\fBParent window\fP
.IN "Window" "parent" "@DEF@"
.IP
If C is a child of P, then P is the parent of C.
.KE
.KS
.LP
\fBPassive grab\fP
.IN "Passive grab" "" "@DEF@"
.IP
Grabbing a key or button is a passive grab.
The grab activates when the key or button is actually pressed.
.KE
.KS
.LP
\fBPixel value\fP
.IN "Pixel value" "" "@DEF@"
.IP
A pixel is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap (that is, 
N is the depth of the window or pixmap).
For a window,
a pixel value indexes a colormap to derive an actual color to be displayed.
.KE
.KS
.LP
\fBPixmap\fP
.IN "Pixmap" "" "@DEF@"
.IP
A pixmap is a three-dimensional array of bits.
A pixmap is normally thought of as a two-dimensional array of pixels, 
where each pixel can be a value from 0 to (2^N)-1 
and where N is the depth (z axis) of the pixmap.
A pixmap can also be thought of as a stack of N bitmaps.
.KE
.KS
.LP
\fBPlane\fP
.IN "Plane" "" "@DEF@"
.IP
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a plane or bit plane.
.KE
.KS
.LP
\fBPlane mask\fP
.IN "Plane" "mask" "@DEF@"
.IP
Graphics operations can be restricted to only affect a subset of bit
planes of a destination.
A plane mask is a bit mask describing which planes are to be modified.
The plane mask is stored in a graphics context.
.KE
.KS
.LP
\fBPointer\fP
.IN "Pointer" "" "@DEF@"
.IP
The pointer is the pointing device attached to the cursor 
and tracked on the screens.
.KE
.KS
.LP
\fBPointer grabbing\fP
.IN "Pointer" "grabbing" "@DEF@"
.IP
A client can actively grab control of the pointer. 
Then button and motion events will be sent to that client 
rather than the client the events would normally have been sent to.
.KE
.KS
.LP
\fBPointing device\fP
.IN "Pointing device" "" "@DEF@"
.IP
A pointing device is typically a mouse, tablet, or some other
device with effective dimensional motion.
There is only one visible cursor defined by the core protocol, 
and it tracks whatever pointing device is attached as the pointer.
.KE
.KS
.LP
\fBProperty\fP
.IN "Property" "" "@DEF@"
.IP
Windows may have associated properties, 
which consist of a name, a type, a data format, and some data.
The protocol places no interpretation on properties.
They are intended as a general-purpose naming mechanism for clients.
For example, clients might use properties to share information such as resize
hints, program names, and icon formats with a window manager.
.KE
.KS
.LP
\fBProperty list\fP
.IN "Property list" "" "@DEF@"
.IP
The property list of a window is the list of properties that have
been defined for the window.
.KE
.KS
.LP
\fBPseudoColor\fP
.IN "PseudoColor" "" "@DEF@"
.IP
.PN PseudoColor
is a class of colormap in which a pixel value indexes the colormap to
produce independent red, green, and blue values;
that is, the colormap is viewed as an array of triples (RGB values).
The RGB values can be changed dynamically.
.KE
.KS
.LP
\fBRedirecting control\fP
.IN "Redirecting control" "" "@DEF@"
.IP
Window managers (or client programs) may want to enforce window layout
policy in various ways.
When a client attempts to change the size or position of a window, 
the operation may be redirected to a specified client 
rather than the operation actually being performed.
.KE
.KS
.LP
\fBReply\fP
.IN "Reply" "" "@DEF@"
.IP
Information requested by a client program is sent back to the client
with a reply.
Both events and replies are multiplexed on the same connection.
Most requests do not generate replies,
although some requests generate multiple replies.
.KE
.KS
.LP
\fBRequest\fP
.IN "Request" "" "@DEF@"
.IP
A command to the server is called a request.
It is a single block of data sent over a connection.
.KE
.KS
.LP
\fBResource\fP
.IN "Resource" "" "@DEF@"
.IP
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as resources.
They all have unique identifiers associated with them for naming purposes.
The lifetime of a resource usually is bounded by the lifetime of the connection
over which the resource was created.
.KE
.KS
.LP
\fBRGB values\fP
.IN "RGB values" "" "@DEF@"
.IP
Red, green, and blue (RGB) intensity values are used to define color.
These values are always represented as 16-bit unsigned numbers, 
with 0 being the minimum intensity and 65535 being the maximum intensity.
The server scales the values to match the display hardware.
.KE
.KS
.LP
\fBRoot\fP
.IN "Root" "" "@DEF@"
.IP
The root of a pixmap, colormap, or graphics context is the same as the root of
whatever drawable was used when the pixmap, colormap, or graphics context was
created.
The root of a window is the root window under which the window was created.
.KE
.KS
.LP
\fBRoot window\fP
.IN "Window" "root" "@DEF@"
.IP
Each screen has a root window covering it.
It cannot be reconfigured or unmapped, 
but it otherwise acts as a full-fledged window.
A root window has no parent.
.KE
.KS
.LP
\fBSave set\fP
.IN "Save set" "" "@DEF@"
.IP
The save set of a client is a list of other clients' windows that,
if they are inferiors of one of the client's windows at connection close, 
should not be destroyed and that should be remapped if currently unmapped.
Save sets are typically used by window managers to avoid
lost windows if the manager terminates abnormally.
.KE
.KS
.LP
\fBScanline\fP
.IN "Scanline" "" "@DEF@"
.IP
A scanline is a list of pixel or bit values viewed as a horizontal
row (all values having the same y coordinate) of an image, with the
values ordered by increasing x coordinate.
.KE
.KS
.LP
\fBScanline order\fP
.IN "Scanline order" "" "@DEF@"
.IP
An image represented in scanline order contains scanlines ordered by
increasing y coordinate.
.KE
.KS
.LP
\fBScreen\fP
.IN "Screen" "" "@DEF@"
.IP
A server can provide several independent screens, 
which typically have physically independent monitors.
This would be the expected configuration when there is only a single keyboard 
and pointer shared among the screens.
.KE
.KS
.LP
\fBSelection\fP
.IN "Selection" "" "@DEF@"
.IP
A selection can be thought of as an indirect property with dynamic
type; that is, rather than having the property stored in the server,
it is maintained by some client (the ``owner'').
A selection is global in nature and is thought of as belonging to the user 
(although maintained by clients), rather than as being private to a particular 
window subhierarchy or a particular set of clients.
When a client asks for the contents of a selection,
it specifies a selection ``target type''.
This target type can be used to control the transmitted representation of the 
contents.
For example, 
if the selection is ``the last thing the user clicked on''
and that is currently an image, then the target type might specify
whether the contents of the image should be sent in XY format or Z format.
The target type can also be used to control the class of contents transmitted; 
for example, asking for the ``looks'' (fonts, line
spacing, indentation, and so on) of a paragraph selection rather than the
text of the paragraph.
The target type can also be used for other purposes.
The protocol does not constrain the semantics.
.KE
.KS
.LP
\fBServer\fP
.IN "Server" "" "@DEF@"
.IP
The server provides the basic windowing mechanism.
It handles connections from clients, 
multiplexes graphics requests onto the screens, 
and demultiplexes input back to the appropriate clients.
.KE
.KS
.LP
\fBServer grabbing\fP
.IN "Server" "grabbing" "@DEF@"
.IP
The server can be grabbed by a single client for exclusive use.
This prevents processing of any requests from other client connections until
the grab is completed.
This is typically only a transient state for
such things as rubber-banding, pop-up menus, or to execute requests
indivisibly.
.KE
.KS
.LP
\fBSibling\fP
.IN "Sibling" "" "@DEF@"
.IP
Children of the same parent window are known as sibling windows.
.KE
.KS
.LP
\fBStacking order\fP
.IN "Stacking order" "" "@DEF@"
.IP
Sibling windows may stack on top of each other.
Windows above other windows both obscure and occlude those lower windows.
This is similar to paper on a desk.
The relationship between sibling windows is known as the stacking order.
.KE
.KS
.LP
\fBStaticColor\fP
.IN "StaticColor" "" "@DEF@"
.IP
.PN StaticColor 
can be viewed as a degenerate case of 
.PN PseudoColor
in which the RGB values are predefined and read-only.
.KE
.KS
.LP
\fBStaticGray\fP
.IN "StaticGray" "" "@DEF@"
.IP
.PN StaticGray 
can be viewed as a degenerate case of 
.PN GrayScale
in which the gray values are predefined and read-only.
The values are typically linear or near-linear increasing ramps.
.KE
.KS
.LP
\fBStipple\fP
.IN "Stipple" "" "@DEF@"
.IP
A stipple pattern is a bitmap that is used to tile a region that will serve
as an additional clip mask for a fill operation with the foreground
color.
.KE
.KS
.LP
\fBString Equivalence\fP
.IN "String Equivalence" "" "@DEF@"
.IP
Two ISO Latin-1 STRING8 values are considered equal if they are the same
length and if corresponding bytes are either equal or are equivalent as
follows:  decimal values 65 to 90 inclusive (characters ``A'' to ``Z'') are
pairwise equivalent to decimal values 97 to 122 inclusive
(characters ``a'' to ``z''), decimal values 192 to 214 inclusive
(characters ``A grave'' to ``O diaeresis'') are pairwise equivalent to decimal
values 224 to 246 inclusive (characters ``a grave'' to ``o diaeresis''),
and decimal values 216 to 222 inclusive (characters ``O oblique'' to ``THORN'')
are pairwise equivalent to decimal values 246 to 254 inclusive
(characters ``o oblique'' to ``thorn'').
.KE
.KS
.LP
\fBTile\fP
.IN "Tile" "" "@DEF@"
.IP
A pixmap can be replicated in two dimensions to tile a region.
The pixmap itself is also known as a tile.
.KE
.KS
.LP
\fBTimestamp\fP
.IN "Timestamp" "" "@DEF@"
.IP
A timestamp is a time value, expressed in milliseconds. 
It typically is the time since the last
server reset.
Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T and half of the
timestamp space as being later in time than T.
One timestamp value (named 
.PN CurrentTime ) 
is never generated by the server.
This value is reserved for use in requests to represent the current 
server time.
.KE
.KS
.LP
\fBTrueColor\fP
.IN "TrueColor" "" "@DEF@"
.IP
.PN TrueColor
can be viewed as a degenerate case of 
.PN DirectColor
in which the subfields in the pixel value directly encode 
the corresponding RGB values; that is, the colormap has predefined 
read-only RGB values.
The values are typically linear or near-linear increasing ramps.
.KE
.KS
.LP
\fBType\fP
.IN "Type" "" "@DEF@"
.IP
A type is an arbitrary atom used to identify the interpretation of
property data.
Types are completely uninterpreted by the server
and are solely for the benefit of clients.
.KE
.KS
.LP
\fBViewable\fP
.IN "Viewable" "" "@DEF@"
.IP
A window is viewable if it and all of its ancestors are mapped.
This does not imply that any portion of the window is actually visible.
Graphics requests can be performed on a window when it is not viewable,
but output will not be retained unless the server is maintaining
backing store.
.KE
.KS
.LP
\fBVisible\fP
.IN "Visible" "" "@DEF@"
.IP
A region of a window is visible if someone looking at the screen can
actually see it; 
that is, the window is viewable and the region is not occluded by any 
other window.
.KE
.KS
.LP
\fBWindow gravity\fP
.IN "Window" "gravity" "@DEF@"
.IP
When windows are resized, 
subwindows may be repositioned automatically relative to some position 
in the window.
This attraction of a subwindow to some part of its parent is known 
as window gravity.
.KE
.KS
.LP
\fBWindow manager\fP
.IN "Window" "manager" "@DEF@"
.IP
Manipulation of windows on the screen and much of the user interface
(policy) is typically provided by a window manager client.
.KE
.KS
.LP
\fBXYFormat\fP
.IN "XYFormat" "" "@DEF@"
.IP
The data for a pixmap is said to be in XY format if it is organized as
a set of bitmaps representing individual bit planes, with the planes
appearing from most-significant to least-significant in bit order.
.KE
.KS
.LP
\fBZFormat\fP
.IN "ZFormat" "" "@DEF@"
.IP
The data for a pixmap is said to be in Z format if it is organized as
a set of pixel values in scanline order.
.KE
.LP
.bp