diff options
Diffstat (limited to 'libX11/specs/libX11/glossary.xml')
| -rw-r--r-- | libX11/specs/libX11/glossary.xml | 1901 |
1 files changed, 1901 insertions, 0 deletions
diff --git a/libX11/specs/libX11/glossary.xml b/libX11/specs/libX11/glossary.xml new file mode 100644 index 000000000..eda236875 --- /dev/null +++ b/libX11/specs/libX11/glossary.xml @@ -0,0 +1,1901 @@ +<glossary id='glossary'>
+<title>Glossary</title>
+<glossentry>
+ <glossterm>Access control list</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Access control list</primary></indexterm>
+ <para>
+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.
+This access control list can be changed by clients on the local host.
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Active grab</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Active grab</primary></indexterm>
+ <para>
+A grab is active when the pointer or keyboard is actually owned by the
+single grabbing client.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Ancestors</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Ancestors</primary></indexterm>
+ <para>
+If W is an inferior of A, then A is an ancestor of W.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Atom</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Atom</primary></indexterm>
+ <para>
+An atom is a unique ID corresponding to a string name.
+Atoms are used to identify properties, types, and selections.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Background</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Background</primary></indexterm>
+ <para>
+An
+<function>InputOutput</function>
+window can have a background, which is defined as a pixmap.
+When regions of the window have their contents lost
+or invalidated,
+the server automatically tiles those regions with the background.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Backing store</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Backing store</primary></indexterm>
+ <para>
+When a server maintains the contents of a window,
+the pixels saved off-screen are known as a backing store.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Base font name</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Base font name</primary></indexterm>
+ <para>
+A font name used to select a family of fonts whose members may be encoded
+in various charsets.
+The
+<function>CharSetRegistry</function>
+and
+<function>CharSetEncoding</function>
+fields of an <acronym>XLFD</acronym> name identify the charset of the font.
+A base font name may be a full <acronym>XLFD</acronym> name, with all fourteen '-' delimiters,
+or an abbreviated <acronym>XLFD</acronym> name containing only the first 12 fields of an <acronym>XLFD</acronym> name,
+up to but not including
+<function>CharSetRegistry</function>,
+with or without the thirteenth '-', or a non-<acronym>XLFD</acronym> name.
+Any <acronym>XLFD</acronym> fields may contain wild cards.
+</para>
+ <para>
+When creating an
+<function>XFontSet</function>,
+Xlib accepts from the client a list of one or more base font names
+which select one or more font families.
+They are combined with charset names obtained from the encoding of the locale
+to load the fonts required to render text.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Bit gravity</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Bit</primary><secondary>gravity</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Bit plane</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Bit</primary><secondary>plane</secondary></indexterm>
+ <para>
+When a pixmap or window is thought of as a stack of bitmaps,
+each bitmap is called a bit plane or plane.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Bitmap</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Bitmap</primary></indexterm>
+ <para>
+A bitmap is a pixmap of depth one.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Border</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Border</primary></indexterm>
+ <para>
+An
+<function>InputOutput</function>
+window can have a border of equal thickness on all four sides of the window.
+The contents of the border are defined by a pixmap,
+and the server automatically maintains the contents of the border.
+Exposure events are never generated for border regions.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Button grabbing</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Button</primary><secondary>grabbing</secondary></indexterm>
+ <para>
+Buttons on the pointer can be passively grabbed by a client.
+When the button is pressed,
+the pointer is then actively grabbed by the client.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Byte order</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Byte</primary><secondary>order</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Character</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Character</primary></indexterm>
+ <para>
+A member of a set of elements used for the organization,
+control, or representation of text (ISO2022, as adapted by XPG3).
+Note that in ISO2022 terms, a character is not bound to a coded value
+until it is identified as part of a coded character set.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Character glyph</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Character glyph</primary></indexterm>
+ <para>
+The abstract graphical symbol for a character.
+Character glyphs may or may not map one-to-one to font glyphs,
+and may be context-dependent, varying with the adjacent characters.
+Multiple characters may map to a single character glyph.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Character set</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Character set</primary></indexterm>
+ <para>
+A collection of characters.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Charset</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Charset</primary></indexterm>
+ <para>
+An encoding with a uniform, state-independent mapping from characters
+to codepoints.
+A coded character set.
+</para>
+ <para>
+For display in X,
+there can be a direct mapping from a charset to one font,
+if the width of all characters in the charset is either one or two bytes.
+A text string encoded in an encoding such as Shift-JIS cannot be passed
+directly to the X server, because the text imaging requests accept only
+single-width charsets (either 8 or 16 bits).
+Charsets which meet these restrictions can serve as ``font charsets''.
+Font charsets strictly speaking map font indices to font glyphs,
+not characters to character glyphs.
+</para>
+ <para>
+Note that a single font charset is sometimes used as the encoding of a locale,
+for example, ISO8859-1.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Children</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Children</primary></indexterm>
+ <para>
+The children of a window are its first-level subwindows.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Class</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Class</primary></indexterm>
+ <para>
+Windows can be of different classes or types.
+See the entries for
+<function>InputOnly</function>
+and
+<function>InputOutput</function>
+windows for further information about valid window types.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Client</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Client</primary></indexterm>
+ <para>
+An application program connects to the window system server by some
+interprocess communication (<acronym>IPC</acronym>) path, such as a <acronym>TCP</acronym> 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 <acronym>IPC</acronym> 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Clipping region</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Clipping region</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Coded character</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Coded character</primary></indexterm>
+ <para>
+A character bound to a codepoint.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Coded character set</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Coded character set</primary></indexterm>
+ <para>
+A set of unambiguous rules that establishes a character set
+and the one-to-one relationship between each character of the set
+and its bit representation.
+(ISO2022, as adapted by XPG3)
+A definition of a one-to-one mapping of a set of characters to a set of
+codepoints.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Codepoint</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Codepoint</primary></indexterm>
+ <para>
+The coded representation of a single character in a coded character set.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Colormap</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Colormap</primary></indexterm>
+ <para>
+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 an <acronym>RGB</acronym> value
+that drives the guns of a monitor.
+Depending on hardware limitations,
+one or more colormaps can be installed at one time so
+that windows associated with those maps display with true colors.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Connection</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Connection</primary></indexterm>
+ <para>
+The <acronym>IPC</acronym> 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Containment</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Containment</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Coordinate system</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Coordinate system</primary></indexterm>
+ <para>
+The coordinate system has X horizontal and Y vertical,
+with the origin [0, 0] at the upper left.
+Coordinates are integral 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 corner.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Cursor</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Cursor</primary></indexterm>
+ <para>
+A cursor is the visible shape of the pointer on a screen.
+It consists of a hotspot, 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Depth</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Depth</primary></indexterm>
+ <para>
+The depth of a window or pixmap is the number of bits per pixel it has.
+The depth of a graphics context is the depth of the drawables it can be
+used in conjunction with graphics output.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Device</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Device</primary></indexterm>
+ <para>
+Keyboards, mice, tablets, track-balls, button boxes, and so on are all
+collectively known as input devices.
+Pointers can have one or more buttons
+(the most common number is three).
+The core protocol only deals with two devices: the keyboard
+and the pointer.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>DirectColor</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>DirectColor</primary></indexterm>
+ <para>
+<function>DirectColor</function>
+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 <acronym>RGB</acronym> (red, green, and blue) values in the colormap entry can be
+changed dynamically.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Display</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Display</primary></indexterm>
+ <para>
+A server, together with its screens and input devices, is called a display.
+The Xlib
+<function>Display</function>
+<indexterm><primary>Display</primary><secondary>structure</secondary></indexterm>
+structure contains all information about the particular display and its screens
+as well as the state that Xlib needs to communicate with the display over a
+particular connection.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Drawable</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Drawable</primary></indexterm>
+ <para>
+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
+<function>InputOnly </function>
+window cannot be used as a source or destination in a
+graphics operation.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Encoding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Encoding</primary></indexterm>
+ <para>
+A set of unambiguous rules that establishes a character set
+and a relationship between the characters and their representations.
+The character set does not have to be fixed to a finite pre-defined set of
+characters.
+The representations do not have to be of uniform length.
+Examples are an ISO2022 graphic set, a state-independent
+or state-dependent combination of graphic sets, possibly including control
+sets, and the X Compound Text encoding.
+</para>
+ <para>
+In X, encodings are identified by a string
+which appears as: the
+<function>CharSetRegistry</function>
+and
+<function>CharSetEncoding</function>
+components of an <acronym>XLFD</acronym>
+name; the name of a charset of the locale for which a font could not be
+found; or an atom which identifies the encoding of a text property or
+which names an encoding for a text selection target type.
+Encoding names should be composed of characters from the X Portable
+Character Set.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Escapement</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Escapement</primary></indexterm>
+ <para>
+The escapement of a string is the distance in pixels in the
+primary draw direction from the drawing origin to the origin of the next
+character (that is, the one following the given string) to be drawn.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Event</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary></indexterm>
+ <para>
+Clients are informed of information asynchronously by means of events.
+These events can be either asynchronously generated from devices or
+generated as side effects of client requests.
+Events are grouped into types.
+The server never sends an event to a client unless the
+client has specifically asked to be informed of that type of event.
+However, clients can force events to be sent to other clients.
+Events are typically reported relative to a window.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Event mask</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary><secondary>mask</secondary></indexterm>
+ <para>
+Events are requested relative to a window.
+The set of event types a client requests relative to a window is described
+by using an event mask.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Event propagation</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary><secondary>propagation</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Event source</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary><secondary>source</secondary></indexterm>
+ <para>
+The deepest viewable window that the pointer is in is called
+the source of a device-related event.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Event synchronization</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary><secondary>synchronization</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Exposure event</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Event</primary><secondary>Exposure</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Extension</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Extension</primary></indexterm>
+ <para>
+Named extensions to the core protocol can be defined to extend the system.
+Extensions to output requests, resources, and event types are all possible
+and expected.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Font</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Font</primary></indexterm>
+ <para>
+A font is an array 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Font glyph</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Font glyph</primary></indexterm>
+ <para>
+The abstract graphical symbol for an index into a font.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Frozen events</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Frozen events</primary></indexterm>
+ <para>
+Clients can freeze event processing during keyboard and pointer grabs.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>GC</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>GC</primary></indexterm>
+ <para>
+GC is an abbreviation for graphics context.
+See <function>Graphics context</function>.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Glyph</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Glyph</primary></indexterm>
+ <para>
+An identified abstract graphical symbol independent of any actual image.
+(ISO/IEC/DIS 9541-1)
+An abstract visual representation of a graphic character,
+not bound to a codepoint.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Glyph image</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Glyph image</primary></indexterm>
+ <para>
+An image of a glyph, as obtained from a glyph representation displayed
+on a presentation surface.
+(ISO/IEC/DIS 9541-1)
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Grab</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Grab</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Graphics context</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Graphics context</primary></indexterm>
+ <para>
+Various information for graphics output is stored in a graphics
+context (GC), 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Gravity</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Gravity</primary></indexterm>
+ <para>
+The contents of windows and windows themselves have a gravity,
+which determines how the contents move when a window is resized.
+See <function>Bit gravity</function> and <function>Window gravity</function>.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>GrayScale</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>GrayScale</primary></indexterm>
+ <para>
+<function>GrayScale </function>
+can be viewed as a degenerate case of
+<function>PseudoColor</function>,
+in which the red, green, and blue values in any given colormap entry
+are equal and thus, produce shades of gray.
+The gray values can be changed dynamically.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Host Portable Character Encoding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Host Portable Character Encoding</primary></indexterm>
+ <para>
+The encoding of the X Portable Character Set on the host.
+The encoding itself is not defined by this standard,
+but the encoding must be the same in all locales supported by Xlib on the host.
+If a string is said to be in the Host Portable Character Encoding,
+then it only contains characters from the X Portable Character Set,
+in the host encoding.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Hotspot</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Hotspot</primary></indexterm>
+ <para>
+A cursor has an associated hotspot, which defines the point in the
+cursor corresponding to the coordinates reported for the pointer.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Identifier</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Identifier</primary></indexterm>
+ <para>
+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 to name the resource.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Inferiors</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Inferiors</primary></indexterm>
+ <para>
+The inferiors of a window are all of the subwindows nested below it:
+the children, the children's children, and so on.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Input focus</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Input</primary><secondary>focus</secondary></indexterm>
+ <para>
+The input focus is usually a window defining the scope for processing
+of keyboard input.
+If a generated keyboard event usually would be reported to this window
+or one of its inferiors,
+the event is reported as usual.
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Input manager</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Input</primary><secondary>manager</secondary></indexterm>
+ <para>
+Control over keyboard input is typically provided by an input manager
+client, which usually is part of a window manager.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>InputOnly window</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>InputOnly</secondary></indexterm>
+ <para>
+An
+<function>InputOnly</function>
+window is a window that cannot be used for graphics requests.
+<function>InputOnly </function>
+windows are invisible and are used to control such things as cursors,
+input event generation, and grabbing.
+<function>InputOnly </function>
+windows cannot have
+<function>InputOutput </function>
+windows as inferiors.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>InputOutput window</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>InputOutput</secondary></indexterm>
+ <para>
+An
+<function>InputOutput</function>
+window is the normal kind of window that is used for both input and output.
+<function>InputOutput </function>
+windows can have both
+<function>InputOutput </function>
+and
+<function>InputOnly </function>
+windows as inferiors.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Internationalization</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Internationalization</primary></indexterm>
+ <para>
+The process of making software adaptable to the requirements
+of different native languages, local customs, and character string encodings.
+Making a computer program adaptable to different locales
+without program source modifications or recompilation.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>ISO2022</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>ISO2022</primary></indexterm>
+ <para>
+ISO standard for code extension techniques for 7-bit and 8-bit coded
+character sets.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Key grabbing</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Key</primary><secondary>grabbing</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Keyboard grabbing</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Keyboard</primary><secondary>grabbing</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Keysym</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Keysym</primary></indexterm>
+ <para>
+An encoding of a symbol on a keycap on a keyboard.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Latin-1</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Latin-1</primary></indexterm>
+ <para>
+The coded character set defined by the ISO8859-1 standard.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Latin Portable Character Encoding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Latin Portable Character Encoding</primary></indexterm>
+ <para>
+The encoding of the X Portable Character Set using the Latin-1 codepoints
+plus ASCII control characters.
+If a string is said to be in the Latin Portable Character Encoding,
+then it only contains characters from the X Portable Character Set,
+not all of Latin-1.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Locale</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Locale</primary></indexterm>
+ <para>
+The international environment of a computer program defining the ``localized''
+behavior of that program at run-time.
+This information can be established from one or more sets of localization data.
+ANSI C defines locale-specific processing by C system library calls.
+See ANSI C and the X/Open Portability Guide specifications for more details.
+In this specification, on implementations that conform to the ANSI C library,
+the ``current locale'' is the current setting of the LC_CTYPE
+<function>setlocale</function>
+category.
+Associated with each locale is a text encoding. When text is processed
+in the context of a locale, the text must be in the encoding of the locale.
+The current locale affects Xlib in its:
+<!-- .RS -->
+</para>
+ <para>
+Encoding and processing of input method text
+</para>
+ <para>
+Encoding of resource files and values
+</para>
+ <para>
+Encoding and imaging of text strings
+</para>
+ <para>
+Encoding and decoding for inter-client text communication
+<!-- .RE -->
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Locale name</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Locale name</primary></indexterm>
+ <para>
+The identifier used to select the desired locale for the host C library
+and X library functions.
+On ANSI C library compliant systems,
+the locale argument to the
+<function>setlocale</function>
+function.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Localization</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Localization</primary></indexterm>
+ <para>
+The process of establishing information within a computer system specific
+to the operation of particular native languages, local customs
+and coded character sets.
+(XPG3)
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Mapped</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Mapped window</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Modifier keys</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Modifier keys</primary></indexterm>
+ <para>
+Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
+ShiftLock, and similar keys are called modifier keys.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Monochrome</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Monochrome</primary></indexterm>
+ <para>
+Monochrome is a special case of
+<function>StaticGray</function>
+in which there are only two colormap entries.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Multibyte</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Multibyte</primary></indexterm>
+ <para>
+A character whose codepoint is stored in more than one byte;
+any encoding which can contain multibyte characters;
+text in a multibyte encoding.
+The ``char *'' null-terminated string datatype in ANSI C.
+Note that references in this document to multibyte strings
+imply only that the strings <emphasis remap='I'>may</emphasis> contain multibyte characters.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Obscure</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Obscure</primary></indexterm>
+ <para>
+A window is obscured if some other window obscures it.
+A window can be partially obscured and so still have visible regions.
+Window A obscures window B if both are viewable
+<function>InputOutput </function>
+windows, if A is higher in the global stacking order,
+and if the rectangle defined by the outside
+edges of A intersects the rectangle defined by the outside edges of B.
+Note the distinction between obscures and occludes.
+Also note that window borders are included in the calculation.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Occlude</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Occlude</primary></indexterm>
+ <para>
+A window is occluded if some other window occludes it.
+Window A occludes window B if both are mapped,
+if A is higher in the global stacking order,
+and if 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
+and that
+<function>InputOnly</function>
+windows never obscure other windows but can occlude other windows.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Padding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Padding</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Parent window</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>parent</secondary></indexterm>
+ <para>
+If C is a child of P, then P is the parent of C.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Passive grab</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Passive grab</primary></indexterm>
+ <para>
+Grabbing a key or button is a passive grab.
+The grab activates when the key or button is actually pressed.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Pixel value</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Pixel value</primary></indexterm>
+ <para>
+A pixel is an N-bit value,
+where N is the number of bit planes used in a particular window or pixmap
+(that is, is the depth of the window or pixmap).
+A pixel in a window indexes a colormap to derive an actual color to be
+displayed.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Pixmap</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Pixmap</primary></indexterm>
+<!-- .EQ -->
+<!-- .EN -->
+ <para>
+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 sup 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.
+A pixmap can only be used on the screen that it was created in.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Plane</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Plane</primary></indexterm>
+ <para>
+When a pixmap or window is thought of as a stack of bitmaps, each
+bitmap is called a plane or bit plane.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Plane mask</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Plane</primary><secondary>mask</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Pointer</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Pointer</primary></indexterm>
+ <para>
+The pointer is the pointing device currently attached to the cursor
+and tracked on the screens.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Pointer grabbing</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Pointer</primary><secondary>grabbing</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Pointing device</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Pointing device</primary></indexterm>
+ <para>
+A pointing device is typically a mouse, tablet, or some other
+device with effective dimensional motion.
+The core protocol defines only one visible cursor,
+which tracks whatever pointing device is attached as the pointer.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm><acronym>POSIX</acronym></glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary><acronym>POSIX</acronym></primary></indexterm>
+ <para>
+Portable Operating System Interface, ISO/IEC 9945-1 (IEEE Std 1003.1).
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm><acronym>POSIX</acronym> Portable Filename Character Set</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary><acronym>POSIX</acronym> Portable Filename Character Set</primary></indexterm>
+ <para>
+The set of 65 characters which can be used in naming files on a <acronym>POSIX</acronym>-compliant
+host that are correctly processed in all locales.
+The set is:
+</para>
+ <para>
+<!-- .Ds 0 -->
+a..z A..Z 0..9 ._-
+<!-- .De -->
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Property</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Property</primary></indexterm>
+ <para>
+Windows can have associated properties that 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Property list</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Property list</primary></indexterm>
+ <para>
+The property list of a window is the list of properties that have
+been defined for the window.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>PseudoColor</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>PseudoColor</primary></indexterm>
+ <para>
+<function>PseudoColor</function>
+is a class of colormap in which a pixel value indexes the colormap entry to
+produce an independent <acronym>RGB</acronym> value;
+that is, the colormap is viewed as an array of triples (<acronym>RGB</acronym> values).
+The <acronym>RGB</acronym> values can be changed dynamically.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Rectangle</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Rectangle</primary></indexterm>
+ <para>
+A rectangle specified by [x,y,w,h] has an infinitely thin
+outline path with corners at [x,y], [x+w,y], [x+w,y+h], and [x, y+h].
+When a rectangle is filled,
+the lower-right edges are not drawn.
+For example,
+if w=h=0,
+nothing would be drawn.
+For w=h=1,
+a single pixel would be drawn.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Redirecting control</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Redirecting control</primary></indexterm>
+ <para>
+Window managers (or client programs) may 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Reply</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Reply</primary></indexterm>
+ <para>
+Information requested by a client program using the X protocol
+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,
+but some requests generate multiple replies.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Request</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Request</primary></indexterm>
+ <para>
+A command to the server is called a request.
+It is a single block of data sent over a connection.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Resource</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Resource</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm><acronym>RGB</acronym> values</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary><acronym>RGB</acronym> values</primary></indexterm>
+ <para>
+<acronym>RGB</acronym> values are the red, green, and blue intensity values that are used
+to define a color.
+These values are always represented as 16-bit, unsigned numbers, with 0
+the minimum intensity and 65535 the maximum intensity.
+The X server scales these values to match the display hardware.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Root</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Root</primary></indexterm>
+ <para>
+The root of a pixmap or graphics context is the same as the root
+of whatever drawable was used when the pixmap or GC was created.
+The root of a window is the root window under which the window was created.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Root window</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>root</secondary></indexterm>
+ <para>
+Each screen has a root window covering it.
+The root window cannot be reconfigured or unmapped,
+but otherwise it acts as a full-fledged window.
+A root window has no parent.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Save set</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Save set</primary></indexterm>
+ <para>
+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 should terminate abnormally.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Scanline</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Scanline</primary></indexterm>
+ <para>
+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 the x coordinate.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Scanline order</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Scanline</primary><secondary>order</secondary></indexterm>
+ <para>
+An image represented in scanline order contains scanlines ordered by
+increasing the y coordinate.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Screen</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Screen</primary></indexterm>
+ <para>
+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.
+A
+<function>Screen </function>
+<indexterm><primary>Screen</primary><secondary>structure</secondary></indexterm>
+structure contains the information about that screen
+and is linked to the
+<function>Display</function>
+<indexterm><primary>Display</primary><secondary>structure</secondary></indexterm>
+structure.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Selection</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Selection</primary></indexterm>
+ <para>
+A selection can be thought of as an indirect property with dynamic
+type.
+That is, rather than having the property stored in the X server,
+it is maintained by some client (the owner).
+A selection is global and is thought of as belonging to the user
+and being maintained by clients,
+rather than 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,
+which 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.
+</para>
+ <para>
+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 forth) 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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Server</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Server</primary></indexterm>
+ <para>
+The server, which is also referred to as the X server,
+provides the basic windowing mechanism.
+It handles <acronym>IPC</acronym> connections from clients,
+multiplexes graphics requests onto the screens,
+and demultiplexes input back to the appropriate clients.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Server grabbing</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Server</primary><secondary>grabbing</secondary></indexterm>
+ <para>
+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 executing requests indivisibly.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Shift sequence</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Shift sequence</primary></indexterm>
+ <para>
+ISO2022 defines control characters and escape sequences
+which temporarily (single shift) or permanently (locking shift) cause a
+different character set to be in effect (``invoking'' a character set).
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Sibling</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Sibling</primary></indexterm>
+ <para>
+Children of the same parent window are known as sibling windows.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Stacking order</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Stacking order</primary></indexterm>
+ <para>
+Sibling windows, similar to sheets of paper on a desk,
+can stack on top of each other.
+Windows above both obscure and occlude lower windows.
+The relationship between sibling windows is known as the stacking order.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>State-dependent encoding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>State-dependent encoding</primary></indexterm>
+ <para>
+An encoding in which an invocation of a charset can apply to multiple
+characters in sequence.
+A state-dependent encoding begins in an ``initial state''
+and enters other ``shift states'' when specific ``shift sequences''
+are encountered in the byte sequence.
+In ISO2022 terms,
+this means use of locking shifts, not single shifts.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>State-independent encoding</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>State-independent encoding</primary></indexterm>
+ <para>
+Any encoding in which the invocations of the charsets are fixed,
+or span only a single character.
+In ISO2022 terms,
+this means use of at most single shifts, not locking shifts.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>StaticColor</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>StaticColor</primary></indexterm>
+ <para>
+<function>StaticColor </function>
+can be viewed as a degenerate case of
+<function>PseudoColor</function>
+in which the <acronym>RGB</acronym> values are predefined and read-only.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>StaticGray</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>StaticGray</primary></indexterm>
+ <para>
+<function>StaticGray </function>
+can be viewed as a degenerate case of
+<function>GrayScale</function>
+in which the gray values are predefined and read-only.
+The values are typically linear or near-linear increasing ramps.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Status</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Status</primary></indexterm>
+ <para>
+Many Xlib functions return a success status.
+If the function does not succeed,
+however, its arguments are not disturbed.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Stipple</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Stipple</primary></indexterm>
+ <para>
+A stipple pattern is a bitmap that is used to tile a region to serve
+as an additional clip mask for a fill operation with the foreground
+color.
+ </para>
+ </glossdef>
+</glossentry>
+<!-- .KE -->
+<glossentry>
+ <glossterm>STRING encoding</glossterm>
+ <glossdef>
+ <para>
+Latin-1, plus tab and newline.
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>String Equivalence</glossterm>
+ <glossdef>
+ <para>
+<indexterm significance="preferred"><primary>String Equivalence</primary></indexterm>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Tile</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Tile</primary></indexterm>
+ <para>
+A pixmap can be replicated in two dimensions to tile a region.
+The pixmap itself is also known as a tile.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Timestamp</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Timestamp</primary></indexterm>
+ <para>
+A timestamp is a time value expressed in milliseconds.
+It is typically 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, represented by the constant
+<function>CurrentTime</function>,
+is never generated by the server.
+This value is reserved for use in requests to represent the current server time.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>TrueColor</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>TrueColor</primary></indexterm>
+ <para>
+<function>TrueColor</function>
+can be viewed as a degenerate case of
+<function>DirectColor</function>
+in which the subfields in the pixel value directly encode the corresponding <acronym>RGB</acronym>
+values.
+That is, the colormap has predefined read-only <acronym>RGB</acronym> values.
+The values are typically linear or near-linear increasing ramps.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Type</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Type</primary></indexterm>
+ <para>
+A type is an arbitrary atom used to identify the interpretation of property
+data.
+Types are completely uninterpreted by the server.
+They are solely for the benefit of clients.
+X predefines type atoms for many frequently used types,
+and clients also can define new types.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Viewable</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Viewable</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Visible</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Visible</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Whitespace</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Whitespace</primary></indexterm>
+ <para>
+Any spacing character.
+On implementations that conform to the ANSI C library,
+whitespace is any character for which
+<function>isspace</function>
+returns true.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Window gravity</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>gravity</secondary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Window manager</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Window</primary><secondary>manager</secondary></indexterm>
+ <para>
+Manipulation of windows on the screen and much of the user interface
+(policy) is typically provided by a window manager client.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>X Portable Character Set</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>X Portable Character Set</primary></indexterm>
+ <para>
+A basic set of 97 characters which are assumed to exist in all
+locales supported by Xlib. This set contains the following characters:
+ </para>
+ <para>
+<!-- .Ds 0 -->
+<!-- .EQ -->
+<!-- .EN -->
+ </para>
+ <para>
+a..z A..Z 0..9
+!"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~
+<space>, <tab>, and <newline>
+<!-- .EQ -->
+<!-- .EN -->
+<!-- .De -->
+ </para>
+ <para>
+This is the left/lower half (also called the G0 set)
+of the graphic character set of ISO8859-1 plus <space>, <tab>, and <newline>.
+It is also the set of graphic characters in 7-bit ASCII plus the same
+three control characters.
+The actual encoding of these characters on the host is system dependent;
+see the Host Portable Character Encoding.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm><acronym>XLFD</acronym></glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary><acronym>XLFD</acronym></primary></indexterm>
+ <para>
+The X Logical Font Description Conventions that define a standard syntax
+for structured font names.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>XY format</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>XY format</primary></indexterm>
+ <para>
+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 bit order.
+<!-- .KE -->
+ </para>
+ </glossdef>
+</glossentry>
+<glossentry>
+ <glossterm>Z format</glossterm>
+ <glossdef>
+<indexterm significance="preferred"><primary>Z format</primary></indexterm>
+ <para>
+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 -->
+ </para>
+ </glossdef>
+</glossentry>
+
+<bibliography>
+<title>References</title>
+<biblioentry>
+<title>Draft Proposed Multibyte Extension of ANSI C, Draft 1.1</title>
+<date>November 30, 1989 SC22/C WG/SWG IPSJ/ITSCJ Japan</date>
+</biblioentry>
+
+<biblioentry>
+<title>
+ISO2022: Information processing - ISO 7-bit and 8-bit coded character
+sets - Code extension techniques.
+</title>
+</biblioentry>
+
+<biblioentry>
+<title>
+ISO8859-1: Information processing - 8-bit single-byte coded graphic
+character sets - Part 1: Latin alphabet No. 1.
+</title>
+</biblioentry>
+
+<biblioentry>
+<title>
+<acronym>POSIX</acronym>: Information Technology - Portable Operating System Interface (<acronym>POSIX</acronym>) -
+Part 1: System Application Program Interface (API) [C Language],
+ISO/IEC 9945-1.
+</title>
+</biblioentry>
+
+<biblioentry>
+<title>
+Text of ISO/IEC/DIS 9541-1, Information Processing - Font Information
+Interchange - Part 1: Architecture.
+</title>
+</biblioentry>
+
+<biblioentry>
+<title>
+X/Open Portability Guide, Issue 3, December 1988 (XPG3), X/Open Company,
+Ltd, Prentice-Hall, Inc. 1989. ISBN 0-13-685835-8.
+(See especially Volume 3: XSI Supplementary Definitions.)
+</title>
+</biblioentry>
+</bibliography>
+
+</glossary>
|