specs/libX11: Glossary cross-reference links

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

1 files changed, 157 insertions, 287 deletions

diff --git a/specs/libX11/glossary.xml b/specs/libX11/glossary.xml
index 125baf38..517f359b 100644
--- a/specs/libX11/glossary.xml
+++ b/specs/libX11/glossary.xml
@@ -1,6 +1,6 @@
 <glossary id='glossary'>
 <title>Glossary</title>
-<glossentry>
+<glossentry id="glossary:Access_control_list">
   <glossterm>Access control list</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Access control list</primary></indexterm>
@@ -14,43 +14,39 @@ 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>
+<glossentry id="glossary:Active_grab">
   <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>
+<glossentry id="glossary:Ancestors">
   <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>
+<glossentry id="glossary:Atom">
   <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>
+<glossentry id="glossary:Background">
   <glossterm>Background</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Background</primary></indexterm>
@@ -61,22 +57,20 @@ 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>
+<glossentry id="glossary:Backing_store">
   <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>
+<glossentry id="glossary:Base_font_name">
   <glossterm>Base font name</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Base font name</primary></indexterm>
@@ -102,11 +96,10 @@ 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>
+<glossentry id="glossary:Bit_gravity">
   <glossterm>Bit gravity</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Bit</primary><secondary>gravity</secondary></indexterm>
@@ -117,32 +110,29 @@ 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>
+<glossentry id="glossary:Bit_plane">
   <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>
+<glossentry id="glossary:Bitmap">
   <glossterm>Bitmap</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Bitmap</primary></indexterm>
     <para>
-A bitmap is a pixmap of depth one.
-<!-- .KE -->
+A bitmap is a <glossterm linkend="glossary:Pixmap">pixmap</glossterm> of depth one.
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Border">
   <glossterm>Border</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Border</primary></indexterm>
@@ -153,11 +143,10 @@ 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>
+<glossentry id="glossary:Button_grabbing">
   <glossterm>Button grabbing</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Button</primary><secondary>grabbing</secondary></indexterm>
@@ -165,11 +154,10 @@ Exposure events are never generated for border regions.
 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>
+<glossentry id="glossary:Byte_order">
   <glossterm>Byte order</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Byte</primary><secondary>order</secondary></indexterm>
@@ -181,11 +169,10 @@ 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>
+<glossentry id="glossary:Character">
   <glossterm>Character</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Character</primary></indexterm>
@@ -194,11 +181,10 @@ 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>
+<glossentry id="glossary:Character_glyph">
   <glossterm>Character glyph</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Character glyph</primary></indexterm>
@@ -207,21 +193,19 @@ 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>
+<glossentry id="glossary:Character_set">
   <glossterm>Character set</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Character set</primary></indexterm>
     <para>
 A collection of characters.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Charset">
   <glossterm>Charset</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Charset</primary></indexterm>
@@ -244,36 +228,33 @@ not characters to character glyphs.
     <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>
+<glossentry id="glossary:Children">
   <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>
+<glossentry id="glossary:Class">
   <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>
+<glossterm linkend="glossary:InputOnly_window">InputOnly</glossterm>
 and
-<function>InputOutput</function>
+<glossterm linkend="glossary:InputOutput_window">InputOutput</glossterm>
 windows for further information about valid window types.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Client">
   <glossterm>Client</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Client</primary></indexterm>
@@ -288,11 +269,10 @@ 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>
+<glossentry id="glossary:Clipping_region">
   <glossterm>Clipping region</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Clipping region</primary></indexterm>
@@ -301,21 +281,19 @@ 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>
+<glossentry id="glossary:Coded_character">
   <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>
+<glossentry id="glossary:Coded_character_set">
   <glossterm>Coded character set</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Coded character set</primary></indexterm>
@@ -326,21 +304,19 @@ 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>
+<glossentry id="glossary:Codepoint">
   <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>
+<glossentry id="glossary:Colormap">
   <glossterm>Colormap</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Colormap</primary></indexterm>
@@ -352,11 +328,10 @@ 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>
+<glossentry id="glossary:Connection">
   <glossterm>Connection</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Connection</primary></indexterm>
@@ -364,11 +339,10 @@ that windows associated with those maps display with true colors.
 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>
+<glossentry id="glossary:Containment">
   <glossterm>Containment</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Containment</primary></indexterm>
@@ -379,11 +353,10 @@ 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>
+<glossentry id="glossary:Coordinate_system">
   <glossterm>Coordinate system</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Coordinate system</primary></indexterm>
@@ -394,11 +367,10 @@ 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>
+<glossentry id="glossary:Cursor">
   <glossterm>Cursor</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Cursor</primary></indexterm>
@@ -408,11 +380,10 @@ 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>
+<glossentry id="glossary:Depth">
   <glossterm>Depth</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Depth</primary></indexterm>
@@ -420,11 +391,10 @@ appearance when the pointer is in that window.
 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>
+<glossentry id="glossary:Device">
   <glossterm>Device</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Device</primary></indexterm>
@@ -435,11 +405,10 @@ 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>
+<glossentry id="glossary:DirectColor">
   <glossterm>DirectColor</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>DirectColor</primary></indexterm>
@@ -452,11 +421,10 @@ 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>
+<glossentry id="glossary:Display">
   <glossterm>Display</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Display</primary></indexterm>
@@ -468,11 +436,10 @@ The Xlib
 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>
+<glossentry id="glossary:Drawable">
   <glossterm>Drawable</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Drawable</primary></indexterm>
@@ -484,11 +451,10 @@ However, an
 <function>InputOnly</function>
 window cannot be used as a source or destination in a
 graphics operation.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Encoding">
   <glossterm>Encoding</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Encoding</primary></indexterm>
@@ -514,11 +480,10 @@ 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>
+<glossentry id="glossary:Escapement">
   <glossterm>Escapement</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Escapement</primary></indexterm>
@@ -526,11 +491,10 @@ Character Set.
 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>
+<glossentry id="glossary:Event">
   <glossterm>Event</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Event</primary></indexterm>
@@ -543,11 +507,10 @@ 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>
+<glossentry id="glossary:Event_mask">
   <glossterm>Event mask</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Event</primary><secondary>mask</secondary></indexterm>
@@ -555,11 +518,10 @@ Events are typically reported relative to a window.
 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>
+<glossentry id="glossary:Event_propagation">
   <glossterm>Event propagation</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Event</primary><secondary>propagation</secondary></indexterm>
@@ -567,22 +529,20 @@ by using an event mask.
 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>
+<glossentry id="glossary:Event_source">
   <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>
+<glossentry id="glossary:Event_synchronization">
   <glossterm>Event synchronization</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Event</primary><secondary>synchronization</secondary></indexterm>
@@ -593,11 +553,10 @@ 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>
+<glossentry id="glossary:Exposure_event">
   <glossterm>Exposure event</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Event</primary><secondary>Exposure</secondary></indexterm>
@@ -606,11 +565,10 @@ 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>
+<glossentry id="glossary:Extension">
   <glossterm>Extension</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Extension</primary></indexterm>
@@ -618,11 +576,10 @@ of windows have been lost.
 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>
+<glossentry id="glossary:Font">
   <glossterm>Font</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Font</primary></indexterm>
@@ -632,42 +589,38 @@ 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>
+<glossentry id="glossary:Font_glyph">
   <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>
+<glossentry id="glossary:Frozen_events">
   <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>
+<glossentry id="glossary:GC">
   <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 -->
+See <glossterm linkend="glossary:Graphics_context">Graphics context</glossterm>.
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Glyph">
   <glossterm>Glyph</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Glyph</primary></indexterm>
@@ -676,11 +629,10 @@ 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>
+<glossentry id="glossary:Glyph_image">
   <glossterm>Glyph image</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Glyph image</primary></indexterm>
@@ -688,11 +640,10 @@ not bound to a codepoint.
 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>
+<glossentry id="glossary:Grab">
   <glossterm>Grab</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Grab</primary></indexterm>
@@ -703,79 +654,74 @@ 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>
+<glossentry id="glossary:Graphics_context">
   <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
+context (<acronym>GC</acronym>), 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>
+<glossentry id="glossary:Gravity">
   <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 -->
+See <glossterm linkend="glossary:Bit_gravity">Bit gravity</glossterm> and
+<glossterm linkend="glossary:Window_gravity">Window gravity</glossterm>.
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:GrayScale">
   <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>,
+<glossterm linkend="glossary:PseudoColor"><function>PseudoColor</function></glossterm>,
 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>
+<glossentry id="glossary:Host_Portable_Character_Encoding">
   <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 of the <glossterm linkend="glossary:X_Portable_Character_Set">X Portable Character Set</glossterm> 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>
+<glossentry id="glossary:Hotspot">
   <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>
+<glossentry id="glossary:Identifier">
   <glossterm>Identifier</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Identifier</primary></indexterm>
@@ -783,22 +729,20 @@ cursor corresponding to the coordinates reported for the pointer.
 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>
+<glossentry id="glossary:Inferiors">
   <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>
+<glossentry id="glossary:Input_focus">
   <glossterm>Input focus</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Input</primary><secondary>focus</secondary></indexterm>
@@ -812,22 +756,20 @@ 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>
+<glossentry id="glossary:Input_manager">
   <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>
+<glossentry id="glossary:InputOnly_window">
   <glossterm>InputOnly window</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Window</primary><secondary>InputOnly</secondary></indexterm>
@@ -842,11 +784,10 @@ input event generation, and grabbing.
 windows cannot have 
 <function>InputOutput</function>
 windows as inferiors.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:InputOutput_window">
   <glossterm>InputOutput window</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Window</primary><secondary>InputOutput</secondary></indexterm>
@@ -860,11 +801,10 @@ windows can have both
 and 
 <function>InputOnly</function>
 windows as inferiors.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Internationalization">
   <glossterm>Internationalization</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Internationalization</primary></indexterm>
@@ -873,22 +813,20 @@ 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>
+<glossentry id="glossary:ISO2022">
   <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>
+<glossentry id="glossary:Key_grabbing">
   <glossterm>Key grabbing</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Key</primary><secondary>grabbing</secondary></indexterm>
@@ -896,11 +834,10 @@ character sets.
 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>
+<glossentry id="glossary:Keyboard_grabbing">
   <glossterm>Keyboard grabbing</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Keyboard</primary><secondary>grabbing</secondary></indexterm>
@@ -908,31 +845,28 @@ the keyboard is then actively grabbed by the client.
 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>
+<glossentry id="glossary:Keysym">
   <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>
+<glossentry id="glossary:Latin-1">
   <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>
+<glossentry id="glossary:Latin_Portable_Character_Encoding">
   <glossterm>Latin Portable Character Encoding</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Latin Portable Character Encoding</primary></indexterm>
@@ -942,11 +876,10 @@ 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>
+<glossentry id="glossary:Locale">
   <glossterm>Locale</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Locale</primary></indexterm>
@@ -963,25 +896,23 @@ 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>
+    <itemizedlist>
+      <listitem><para>
 Encoding and processing of input method text
-</para>
-    <para>
+      </para></listitem>
+      <listitem><para>
 Encoding of resource files and values
-</para>
-    <para>
+      </para></listitem>
+      <listitem><para>
 Encoding and imaging of text strings
-</para>
-    <para>
+      </para></listitem>
+      <listitem><para>
 Encoding and decoding for inter-client text communication
-<!-- .RE -->
-<!-- .KE -->
-    </para>
+      </para></listitem>
+    </itemizedlist></para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Locale_name">
   <glossterm>Locale name</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Locale name</primary></indexterm>
@@ -992,11 +923,10 @@ On ANSI C library compliant systems,
 the locale argument to the
 <function>setlocale</function>
 function.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Localization">
   <glossterm>Localization</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Localization</primary></indexterm>
@@ -1005,45 +935,41 @@ 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>
+<glossentry id="glossary:Mapped">
   <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>
+<glossentry id="glossary:Modifier_keys">
   <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>
+<glossentry id="glossary:Monochrome">
   <glossterm>Monochrome</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Monochrome</primary></indexterm>
     <para>
 Monochrome is a special case of 
-<function>StaticGray</function>
+<glossterm linkend="glossary:StaticGray"><function>StaticGray</function></glossterm>
 in which there are only two colormap entries.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Multibyte">
   <glossterm>Multibyte</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Multibyte</primary></indexterm>
@@ -1051,14 +977,13 @@ in which there are only two colormap entries.
 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.
+The ``<type>char *</type>'' 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>
+<glossentry id="glossary:Obscure">
   <glossterm>Obscure</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Obscure</primary></indexterm>
@@ -1072,11 +997,10 @@ 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>
+<glossentry id="glossary:Occlude">
   <glossterm>Occlude</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Occlude</primary></indexterm>
@@ -1091,11 +1015,10 @@ 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>
+<glossentry id="glossary:Padding">
   <glossterm>Padding</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Padding</primary></indexterm>
@@ -1103,32 +1026,29 @@ windows never obscure other windows but can occlude other windows.
 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>
+<glossentry id="glossary:Parent_window">
   <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>
+<glossentry id="glossary:Passive_grab">
   <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>
+<glossentry id="glossary:Pixel_value">
   <glossterm>Pixel value</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Pixel value</primary></indexterm>
@@ -1138,11 +1058,10 @@ 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>
+<glossentry id="glossary:Pixmap">
   <glossterm>Pixmap</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Pixmap</primary></indexterm>
@@ -1155,22 +1074,20 @@ 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>
+<glossentry id="glossary:Plane">
   <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>
+<glossentry id="glossary:Plane_mask">
   <glossterm>Plane mask</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Plane</primary><secondary>mask</secondary></indexterm>
@@ -1179,22 +1096,20 @@ 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>
+<glossentry id="glossary:Pointer">
   <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>
+<glossentry id="glossary:Pointer_grabbing">
   <glossterm>Pointer grabbing</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Pointer</primary><secondary>grabbing</secondary></indexterm>
@@ -1202,11 +1117,10 @@ and tracked on the screens.
 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>
+<glossentry id="glossary:Pointing_device">
   <glossterm>Pointing device</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Pointing device</primary></indexterm>
@@ -1215,21 +1129,19 @@ 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>
+<glossentry id="glossary:POSIX">
   <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>
+<glossentry id="glossary:POSIX_Portable_Filename_Character_Set">
   <glossterm><acronym>POSIX</acronym> Portable Filename Character Set</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary><acronym>POSIX</acronym> Portable Filename Character Set</primary></indexterm>
@@ -1242,11 +1154,10 @@ The set is:
 <!-- .Ds 0 -->
 a..z A..Z 0..9 ._-
 <!-- .De -->
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Property">
   <glossterm>Property</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Property</primary></indexterm>
@@ -1257,22 +1168,20 @@ 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>
+<glossentry id="glossary:Property_list">
   <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>
+<glossentry id="glossary:PseudoColor">
   <glossterm>PseudoColor</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>PseudoColor</primary></indexterm>
@@ -1282,11 +1191,10 @@ 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>
+<glossentry id="glossary:Rectangle">
   <glossterm>Rectangle</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Rectangle</primary></indexterm>
@@ -1300,11 +1208,10 @@ if w=h=0,
 nothing would be drawn.
 For w=h=1,
 a single pixel would be drawn.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Redirecting_control">
   <glossterm>Redirecting control</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Redirecting control</primary></indexterm>
@@ -1314,11 +1221,10 @@ 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>
+<glossentry id="glossary:Reply">
   <glossterm>Reply</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Reply</primary></indexterm>
@@ -1328,22 +1234,20 @@ 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>
+<glossentry id="glossary:Request">
   <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>
+<glossentry id="glossary:Resource">
   <glossterm>Resource</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Resource</primary></indexterm>
@@ -1353,11 +1257,10 @@ 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>
+<glossentry id="glossary:RGB_values">
   <glossterm><acronym>RGB</acronym> values</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary><acronym>RGB</acronym> values</primary></indexterm>
@@ -1367,11 +1270,10 @@ 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>
+<glossentry id="glossary:Root">
   <glossterm>Root</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Root</primary></indexterm>
@@ -1379,11 +1281,10 @@ The X server scales these values to match the display hardware.
 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>
+<glossentry id="glossary:Root_window">
   <glossterm>Root window</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Window</primary><secondary>root</secondary></indexterm>
@@ -1392,11 +1293,10 @@ 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>
+<glossentry id="glossary:Save_set">
   <glossterm>Save set</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Save set</primary></indexterm>
@@ -1407,11 +1307,10 @@ 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>
+<glossentry id="glossary:Scanline">
   <glossterm>Scanline</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Scanline</primary></indexterm>
@@ -1419,22 +1318,20 @@ lost windows if the manager should terminate abnormally.
 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>
+<glossentry id="glossary:Scanline_order">
   <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>
+<glossentry id="glossary:Screen">
   <glossterm>Screen</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Screen</primary></indexterm>
@@ -1451,11 +1348,10 @@ and is linked to the
 <function>Display</function>
 <indexterm><primary>Display</primary><secondary>structure</secondary></indexterm>
 structure.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Selection">
   <glossterm>Selection</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Selection</primary></indexterm>
@@ -1485,11 +1381,10 @@ 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>
+<glossentry id="glossary:Server">
   <glossterm>Server</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Server</primary></indexterm>
@@ -1499,11 +1394,10 @@ 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>
+<glossentry id="glossary:Server_grabbing">
   <glossterm>Server grabbing</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Server</primary><secondary>grabbing</secondary></indexterm>
@@ -1513,11 +1407,10 @@ 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>
+<glossentry id="glossary:Shift_sequence">
   <glossterm>Shift sequence</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Shift sequence</primary></indexterm>
@@ -1525,21 +1418,19 @@ pop-up menus, or executing requests indivisibly.
 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>
+<glossentry id="glossary:Sibling">
   <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>
+<glossentry id="glossary:Stacking_order">
   <glossterm>Stacking order</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Stacking order</primary></indexterm>
@@ -1548,11 +1439,10 @@ 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>
+<glossentry id="glossary:State-dependent_encoding">
   <glossterm>State-dependent encoding</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>State-dependent encoding</primary></indexterm>
@@ -1564,11 +1454,10 @@ 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>
+<glossentry id="glossary:State-independent_encoding">
   <glossterm>State-independent encoding</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>State-independent encoding</primary></indexterm>
@@ -1577,38 +1466,35 @@ 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>
+<glossentry id="glossary:StaticColor">
   <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>
+<glossterm linkend="glossary:PseudoColor"><function>PseudoColor</function></glossterm>
 in which the <acronym>RGB</acronym> values are predefined and read-only.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:StaticGray">
   <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>
+<glossterm linkend="glossary:GrayScale"><function>GrayScale</function></glossterm>
 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>
+<glossentry id="glossary:Status">
   <glossterm>Status</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Status</primary></indexterm>
@@ -1616,11 +1502,10 @@ The values are typically linear or near-linear increasing ramps.
 Many Xlib functions return a success status.
 If the function does not succeed,
 however, its arguments are not disturbed.
-<!-- .KE -->
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:Stipple">
   <glossterm>Stipple</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Stipple</primary></indexterm>
@@ -1631,16 +1516,15 @@ color.
     </para>
   </glossdef>
 </glossentry>
-<!-- .KE -->
-<glossentry>
+<glossentry id="glossary:STRING_encoding">
   <glossterm>STRING encoding</glossterm>
   <glossdef>
     <para>
-Latin-1, plus tab and newline.
+<glossterm linkend="glossary:Latin-1">Latin-1</glossterm>, plus tab and newline.
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:String_Equivalence">
   <glossterm>String Equivalence</glossterm>
   <glossdef>
     <para>
@@ -1655,22 +1539,20 @@ 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>
+<glossentry id="glossary:Tile">
   <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>
+<glossentry id="glossary:Timestamp">
   <glossterm>Timestamp</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Timestamp</primary></indexterm>
@@ -1686,27 +1568,25 @@ 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>
+<glossentry id="glossary:TrueColor">
   <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>
+<glossterm linkend="glossary:DirectColor"><function>DirectColor</function></glossterm>
 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>
+<glossentry id="glossary:Type">
   <glossterm>Type</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Type</primary></indexterm>
@@ -1717,11 +1597,10 @@ 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>
+<glossentry id="glossary:Viewable">
   <glossterm>Viewable</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Viewable</primary></indexterm>
@@ -1731,11 +1610,10 @@ 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>
+<glossentry id="glossary:Visible">
   <glossterm>Visible</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Visible</primary></indexterm>
@@ -1743,11 +1621,10 @@ backing store.
 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>
+<glossentry id="glossary:Whitespace">
   <glossterm>Whitespace</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Whitespace</primary></indexterm>
@@ -1757,11 +1634,10 @@ 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>
+<glossentry id="glossary:Window_gravity">
   <glossterm>Window gravity</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Window</primary><secondary>gravity</secondary></indexterm>
@@ -1771,22 +1647,20 @@ 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>
+<glossentry id="glossary:Window_manager">
   <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>
+<glossentry id="glossary:X_Portable_Character_Set">
   <glossterm>X Portable Character Set</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>X Portable Character Set</primary></indexterm>
@@ -1813,23 +1687,21 @@ of the graphic character set of ISO8859-1 plus &lt;space&gt;, &lt;tab&gt;, and &
 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 -->
+see the <glossterm linkend="glossary:Host_Portable_Character_Encoding">Host Portable Character Encoding</glossterm>.
     </para>
   </glossdef>
 </glossentry>
-<glossentry>
+<glossentry id="glossary:XLFD">
   <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>
+<glossentry id="glossary:XY_format">
   <glossterm>XY format</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>XY format</primary></indexterm>
@@ -1837,18 +1709,16 @@ for structured font names.
 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>
+<glossentry id="glossary:Z_format">
   <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>