spec: Fix a bunch of the .BR -> <emphasis> mappings

perl -i -p -e 's{ (\W*?)\s*</emphasis>}{</emphasis>$1}g' *.xml

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

4 files changed, 1242 insertions, 1242 deletions

diff --git a/specs/encoding.xml b/specs/encoding.xml
index 5ec5b5c..de94956 100644
--- a/specs/encoding.xml
+++ b/specs/encoding.xml
@@ -72,10 +72,10 @@ For components with a static numeric value the encode-form is:
 The value is always interpreted as an N-byte unsigned integer.
 For example,
 the first two bytes of a
-<emphasis role='bold'>Window </emphasis>
+<emphasis role='bold'>Window</emphasis>
 error are always zero (indicating an
 error in general) and three (indicating the
-<emphasis role='bold'>Window </emphasis>
+<emphasis role='bold'>Window</emphasis>
 error in particular):
 </para>
 
@@ -90,8 +90,8 @@ For components described in the protocol as:
 
 <para>
 name:
-<emphasis role='bold'>{ Name1 ,..., </emphasis>
-<emphasis role='bold'>NameI }</emphasis>
+<emphasis role='bold'>{ Name1</emphasis>,...,
+<emphasis role='bold'>NameI</emphasis>}
 </para>
 
 <para>
@@ -159,7 +159,7 @@ For example:
 
 <para>
 destination: WINDOW or
-<emphasis role='bold'>PointerWindow </emphasis>
+<emphasis role='bold'>PointerWindow</emphasis>
 or
 <emphasis role='bold'>InputFocus</emphasis>
 </para>
diff --git a/specs/glossary.xml b/specs/glossary.xml
index 5a89b2d..4bf94b5 100644
--- a/specs/glossary.xml
+++ b/specs/glossary.xml
@@ -58,7 +58,7 @@ Atoms are used to identify properties, types, and selections.
   <glossdef>
     <para>
 An
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 window can have a background, which is defined as a pixmap.
 When regions of the window have their contents lost or invalidated,
 the server will automatically tile those regions with the background.
@@ -119,7 +119,7 @@ A bitmap is a <glossterm linkend="glossary:Pixmap">pixmap</glossterm> of depth o
   <glossdef>
     <para>
 An
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 window can have a border of equal thickness on all four sides of the window.
 A pixmap defines the contents of the border,
 and the server automatically maintains the contents of the border.
@@ -333,7 +333,7 @@ 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
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window cannot be used as a source or destination in a graphics operation.
 <!-- .KE -->
     </para>
@@ -523,7 +523,7 @@ and <glossterm linkend="glossary:Window_gravity">window gravity</glossterm>.
   <indexterm significance="preferred"><primary>GrayScale</primary></indexterm>
   <glossdef>
     <para>
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 can be viewed as a degenerate case of
 <glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>,
 in which the red, green, and blue values in any given colormap entry are equal,
@@ -605,12 +605,12 @@ Control over keyboard input is typically provided by an input manager client.
 An
 <emphasis role='bold'>InputOnly</emphasis>
 window is a window that cannot be used for graphics requests.
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows are invisible and can be used to control such things
 as cursors, input event generation, and grabbing.
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows cannot have
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 windows as inferiors.
 <!-- .KE -->
     </para>
@@ -624,11 +624,11 @@ windows as inferiors.
 An
 <emphasis role='bold'>InputOutput</emphasis>
 window is the normal kind of opaque window, used for both input and output.
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 windows can have both
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 and
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows as inferiors.
 <!-- .KE -->
     </para>
@@ -709,7 +709,7 @@ in which there are only two colormap entries.
     <para>
 A window is obscured if some other window obscures it.
 Window A obscures window B if both are viewable
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 windows, A is higher in the global stacking order,
 and the rectangle defined by the outside edges of A intersects
 the rectangle defined by the outside edges of B.
@@ -1124,7 +1124,7 @@ The relationship between sibling windows is known as the stacking order.
   <indexterm significance="preferred"><primary>StaticColor</primary></indexterm>
   <glossdef>
     <para>
-<emphasis role='bold'>StaticColor </emphasis>
+<emphasis role='bold'>StaticColor</emphasis>
 can be viewed as a degenerate case of
 <glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>
 in which the RGB values are predefined and read-only.
@@ -1137,7 +1137,7 @@ in which the RGB values are predefined and read-only.
   <indexterm significance="preferred"><primary>StaticGray</primary></indexterm>
   <glossdef>
     <para>
-<emphasis role='bold'>StaticGray </emphasis>
+<emphasis role='bold'>StaticGray</emphasis>
 can be viewed as a degenerate case of
 <glossterm linkend="glossary:GrayScale"><emphasis role='bold'>GrayScale</emphasis></glossterm>
 in which the gray values are predefined and read-only.
@@ -1202,7 +1202,7 @@ always interprets timestamps from clients by treating half of the
 timestamp space as being earlier in time than T and half of the
 timestamp space as being later in time than T.
 One timestamp value (named
-<emphasis role='bold'>CurrentTime ) </emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>)
 is never generated by the server.
 This value is reserved for use in requests to represent the current
 server time.
diff --git a/specs/keysyms.xml b/specs/keysyms.xml
index 810fe3c..0b457ae 100644
--- a/specs/keysyms.xml
+++ b/specs/keysyms.xml
@@ -40,9 +40,9 @@ There are six categories of KEYSYM values.
 <title>Special KEYSYMs</title>
 <para>
 There are two special values:
-<emphasis role='bold'>NoSymbol </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>
 and
-<emphasis role='bold'>VoidSymbol .</emphasis>
+<emphasis role='bold'>VoidSymbol</emphasis>.
 They are used to indicate the absence of symbols (see
 <link linkend="keyboards">Section 5, Keyboards</link>).
 </para>
diff --git a/specs/sect1-9.xml b/specs/sect1-9.xml
index 0d3cf92..c17c93f 100644
--- a/specs/sect1-9.xml
+++ b/specs/sect1-9.xml
@@ -155,12 +155,12 @@ Events are 32 bytes long.
 Unused bytes within an event are not guaranteed to be zero.
 Every event contains an 8-bit type code.
 The most significant bit in this code is set if the event was generated from a
-<emphasis role='bold'>SendEvent </emphasis>
+<emphasis role='bold'>SendEvent</emphasis>
 request.
 Event codes 64 through 127 are reserved for extensions, although the core
 protocol does not define a mechanism for selecting interest in such events.
 Every core event (with the exception of
-<emphasis role='bold'>KeymapNotify ) </emphasis>
+<emphasis role='bold'>KeymapNotify</emphasis>)
 also contains the least significant 16 bits of the sequence number of the last
 request issued by the client that was (or is currently being) processed by
 the server.
@@ -190,7 +190,7 @@ The syntax [...] encloses a set of structure components.
   <listitem>
     <para>
 In general, TYPEs are in uppercase and
-<emphasis role='bold'>AlternativeValues </emphasis>
+<emphasis role='bold'>AlternativeValues</emphasis>
 are capitalized.
     </para>
   </listitem>
@@ -298,7 +298,7 @@ each such argument is assigned a unique bit position.
 The representation of the BITMASK will typically contain more bits than
 there are defined arguments.
 The unused bits in the value-mask must be zero (or the server generates a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error).
 The value-list contains one value for each bit set to 1 in the mask,
 from least significant to most significant bit in the mask.
@@ -604,7 +604,7 @@ byte-swap CHAR2B quantities.
 <para>
 The length, format, and interpretation of a HOST address are specific to the
 family (see
-<link linkend="requests:ChangeHosts"><emphasis role='bold'>ChangeHosts </emphasis></link>
+<link linkend="requests:ChangeHosts"><emphasis role='bold'>ChangeHosts</emphasis></link>
 request).
 </para>
 </chapter>
@@ -744,7 +744,7 @@ server.
       <entry><emphasis role='bold'>Match</emphasis><indexterm significance="preferred"><primary>Error Codes</primary><secondary>Match</secondary></indexterm></entry>
       <entry>
 An
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window is used as a DRAWABLE.
 In a graphics request, the GCONTEXT argument does not have the same
 root and depth as the destination DRAWABLE argument.
@@ -847,14 +847,14 @@ If the list (ignoring trailing NoSymbol entries) is a pair of KEYSYMs
 if it were the list
 "<emphasis remap='I'>K1 K2 K1 K2</emphasis>".
 If the list (ignoring trailing
-<emphasis role='bold'>NoSymbol </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>
 entries) is
 a triple of KEYSYMs "<emphasis remap='I'>K1 K2 K3</emphasis>",
 then the list is treated as if it were the list "
 <emphasis remap='I'>K1 K2 K3</emphasis> NoSymbol".
 When an explicit "void" element is desired in the list,
 the value
-<emphasis role='bold'>VoidSymbol </emphasis>
+<emphasis role='bold'>VoidSymbol</emphasis>
 can be used.
 </para>
 <para>
@@ -864,7 +864,7 @@ Group 1 contains the first and second KEYSYMs, Group 2 contains the third and
 fourth KEYSYMs.
 Within each group,
 if the second element of the group is
-<emphasis role='bold'>NoSymbol , </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>,
 then the group should be treated as if the second element were the
 same as the first element, except when the first element is an alphabetic
 KEYSYM "<emphasis remap='I'>K</emphasis>" for which both lowercase
@@ -877,15 +877,15 @@ of "<emphasis remap='I'>K</emphasis>".
 
 <para>
 The standard rules for obtaining a KEYSYM from a
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 event make use of only the Group 1 and Group 2 KEYSYMs; no interpretation of
 other KEYSYMs in the list is defined.  The modifier state determines which
 group to use.  Switching between groups is controlled by the KEYSYM named
 MODE SWITCH, by attaching that KEYSYM to some KEYCODE and attaching that
 KEYCODE to any one of the modifiers
-<emphasis role='bold'>Mod1 </emphasis>
+<emphasis role='bold'>Mod1</emphasis>
 through
-<emphasis role='bold'>Mod5 . </emphasis>
+<emphasis role='bold'>Mod5</emphasis>.
 This modifier is
 called the "group modifier".  For any KEYCODE, Group 1 is used when the
 group modifier is off, and Group 2 is used when the group modifier is on.
@@ -893,18 +893,18 @@ group modifier is off, and Group 2 is used when the group modifier is on.
 
 <para>
 The
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is interpreted as CapsLock when the KEYSYM named CAPS
 LOCK is attached to some KEYCODE and that KEYCODE is attached to the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier.  The
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is interpreted as ShiftLock when the KEYSYM
 named SHIFT LOCK is attached to some KEYCODE and that KEYCODE is attached
 to the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier.  If the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier could be interpreted as both
 CapsLock and ShiftLock, the CapsLock interpretation is used.
 </para>
@@ -914,9 +914,9 @@ CapsLock and ShiftLock, the CapsLock interpretation is used.
 The operation of "keypad" keys is controlled by the KEYSYM named NUM LOCK,
 by attaching that KEYSYM to some KEYCODE and attaching that KEYCODE to any
 one of the modifiers
-<emphasis role='bold'>Mod1 </emphasis>
+<emphasis role='bold'>Mod1</emphasis>
 through
-<emphasis role='bold'>Mod5 . </emphasis>
+<emphasis role='bold'>Mod5</emphasis>.
 This modifier is called the
 "numlock modifier".  The standard KEYSYMs with the prefix KEYPAD in their
 name are called "keypad" KEYSYMs; these are KEYSYMS with numeric value in
@@ -935,9 +935,9 @@ rule that is satisfied from the following list:
     <para>
 The numlock modifier is on and the second KEYSYM is a keypad KEYSYM.  In
 this case, if the
-<emphasis role='bold'>Shift </emphasis>
+<emphasis role='bold'>Shift</emphasis>
 modifier is on, or if the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is on and
 is interpreted as ShiftLock, then the first KEYSYM is used; otherwise, the
 second KEYSYM is used.
@@ -946,9 +946,9 @@ second KEYSYM is used.
   <listitem>
     <para>
 The
-<emphasis role='bold'>Shift </emphasis>
+<emphasis role='bold'>Shift</emphasis>
 and
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifiers are both off.  In this case, the first
 KEYSYM is used.
     </para>
@@ -956,9 +956,9 @@ KEYSYM is used.
   <listitem>
     <para>
 The
-<emphasis role='bold'>Shift </emphasis>
+<emphasis role='bold'>Shift</emphasis>
 modifier is off, and the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is on and is
 interpreted as CapsLock.  In this case, the first KEYSYM is used, but if
 that KEYSYM is lowercase alphabetic, then the corresponding uppercase
@@ -968,9 +968,9 @@ KEYSYM is used instead.
   <listitem>
     <para>
 The
-<emphasis role='bold'>Shift </emphasis>
+<emphasis role='bold'>Shift</emphasis>
 modifier is on, and the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is on and is interpreted
 as CapsLock.  In this case, the second KEYSYM is used, but if that KEYSYM
 is lowercase alphabetic, then the corresponding uppercase KEYSYM is used
@@ -980,9 +980,9 @@ instead.
   <listitem>
     <para>
 The
-<emphasis role='bold'>Shift </emphasis>
+<emphasis role='bold'>Shift</emphasis>
 modifier is on, or the
-<emphasis role='bold'>Lock </emphasis>
+<emphasis role='bold'>Lock</emphasis>
 modifier is on and is interpreted
 as ShiftLock, or both.  In this case, the second KEYSYM is used.
     </para>
@@ -1015,7 +1015,7 @@ Buttons are always numbered starting with one.
 <!-- .LP -->
 Predefined atoms are not strictly necessary and may not be useful in all
 environments, but they will eliminate many
-<emphasis role='bold'>InternAtom </emphasis>
+<emphasis role='bold'>InternAtom</emphasis>
 requests in most applications.
 Note that they are predefined only in the sense of having numeric values,
 not in the sense of having required semantics.
@@ -1299,7 +1299,7 @@ or
 <para>
 The client receives the following additional data if the returned success
 value is
-<emphasis role='bold'>Success ,</emphasis>
+<emphasis role='bold'>Success</emphasis>,
 and the connection is successfully established:
 </para>
 
@@ -1580,10 +1580,10 @@ No geometry is defined among screens.
 <!-- .LP -->
 The server may retain the recent history of pointer motion and do so to a
 finer granularity than is reported by
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>
 events.
 The
-<emphasis role='bold'>GetMotionEvents </emphasis>
+<emphasis role='bold'>GetMotionEvents</emphasis>
 request makes such history available.
 The motion-buffer-size gives the approximate maximum number
 of elements in the history buffer.
@@ -1595,7 +1595,7 @@ accepted by the server, in 4-byte units.
 That is, length is the maximum value that can appear in the length field of a
 request.
 Requests larger than this maximum generate a
-<emphasis role='bold'>Length </emphasis>
+<emphasis role='bold'>Length</emphasis>
 error,
 and the server will read and simply discard the entire request.
 Maximum-request-length will always be at least 4096
@@ -1627,7 +1627,7 @@ A pixmap depth of one is always supported and listed,
 but windows of depth one might not be supported.
 A depth of zero is never listed,
 but zero-depth
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows are always supported.
 </para>
 <para>
@@ -1637,7 +1637,7 @@ root window.
 Width-in-pixels and height-in-pixels specify the size of
 the root window (which cannot be changed).
 The class of the root window is always
-<emphasis role='bold'>InputOutput .</emphasis>
+<emphasis role='bold'>InputOutput</emphasis>.
 Width-in-millimeters and height-in-millimeters can be used to determine the
 physical size and the aspect ratio.
 </para>
@@ -1668,7 +1668,7 @@ unspecified two-color pattern using black-pixel and white-pixel.
 <!-- .LP -->
 Min-installed-maps specifies the number of maps that can be guaranteed
 to be installed simultaneously (with
-<emphasis role='bold'>InstallColormap ), </emphasis>
+<emphasis role='bold'>InstallColormap</emphasis>),
 regardless of the number of entries allocated in each map.
 Max-installed-maps specifies the maximum number of maps that might possibly be
 installed simultaneously, depending on their allocations.
@@ -1683,17 +1683,17 @@ Backing-stores indicates when the server supports backing stores for
 this screen, although it may be storage limited in the number of
 windows it can support at once.
 If save-unders is
-<emphasis role='bold'>True , </emphasis>
+<emphasis role='bold'>True</emphasis>,
 the server can support the save-under mode in
-<emphasis role='bold'>CreateWindow </emphasis>
+<emphasis role='bold'>CreateWindow</emphasis>
 and
-<emphasis role='bold'>ChangeWindowAttributes , </emphasis>
+<emphasis role='bold'>ChangeWindowAttributes</emphasis>,
 although again it may be storage limited.
 </para>
 <para>
 <!-- .LP -->
 The current-input-events is what
-<emphasis role='bold'>GetWindowAttributes </emphasis>
+<emphasis role='bold'>GetWindowAttributes</emphasis>
 would return for the all-event-masks for the root window.
 <!-- .SH -->
 </para>
@@ -1712,45 +1712,45 @@ more than one screen.
 <para>
 <!-- .LP -->
 For
-<emphasis role='bold'>PseudoColor , </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>,
 a pixel value indexes a colormap to produce independent RGB values;
 the RGB values can be changed dynamically.
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 is treated in the same way as
-<emphasis role='bold'>PseudoColor </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>
 except which primary drives the screen is undefined;
 thus, the client should always store the
 same value for red, green, and blue in colormaps.
 For
-<emphasis role='bold'>DirectColor , </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>,
 a pixel value is decomposed into separate RGB subfields,
 and each subfield separately indexes the colormap for the corresponding value.
 The RGB values can be changed dynamically.
-<emphasis role='bold'>TrueColor </emphasis>
+<emphasis role='bold'>TrueColor</emphasis>
 is treated in the same way as
-<emphasis role='bold'>DirectColor </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>
 except the colormap has predefined read-only RGB values.
 These values are server-dependent but provide linear or near-linear
 increasing ramps in each primary.
-<emphasis role='bold'>StaticColor </emphasis>
+<emphasis role='bold'>StaticColor</emphasis>
 is treated in the same way as
-<emphasis role='bold'>PseudoColor </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>
 except the colormap has predefined read-only RGB values,
 which are server-dependent.
-<emphasis role='bold'>StaticGray </emphasis>
+<emphasis role='bold'>StaticGray</emphasis>
 is treated in the same way as
-<emphasis role='bold'>StaticColor </emphasis>
+<emphasis role='bold'>StaticColor</emphasis>
 except the red, green, and blue values are equal for any
 single pixel value, resulting in shades of gray.
-<emphasis role='bold'>StaticGray </emphasis>
+<emphasis role='bold'>StaticGray</emphasis>
 with a two-entry colormap can be thought of as monochrome.
 </para>
 <para>
 <!-- .LP -->
 The red-mask, green-mask, and blue-mask are only defined for
-<emphasis role='bold'>DirectColor </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>
 and
-<emphasis role='bold'>TrueColor .</emphasis>
+<emphasis role='bold'>TrueColor</emphasis>.
 Each has one contiguous set of bits set to 1 with no intersections.
 Usually each mask has the same number of bits set to 1.
 </para>
@@ -1779,9 +1779,9 @@ Colormap entries are indexed from 0.
 The colormap-entries defines the number of available colormap entries in a
 newly created colormap.
 For
-<emphasis role='bold'>DirectColor </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>
 and
-<emphasis role='bold'>TrueColor , </emphasis>
+<emphasis role='bold'>TrueColor</emphasis>,
 this will usually be 2 to the power of the maximum number of bits set to 1 in
 red-mask, green-mask, and blue-mask.
 
@@ -1809,9 +1809,9 @@ red-mask, green-mask, and blue-mask.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>class</emphasis>:
-<emphasis role='bold'>{ InputOutput , </emphasis>
-<emphasis role='bold'>InputOnly , </emphasis>
-<emphasis role='bold'>CopyFromParent }</emphasis>
+<emphasis role='bold'>{ InputOutput</emphasis>,
+<emphasis role='bold'>InputOnly</emphasis>,
+<emphasis role='bold'>CopyFromParent</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -1850,13 +1850,13 @@ red-mask, green-mask, and blue-mask.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
-<emphasis role='bold'>Cursor , </emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Pixmap , </emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
+<emphasis role='bold'>Cursor</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Pixmap</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -1871,51 +1871,51 @@ This request creates an unmapped window and assigns the identifier wid to it.
 </para>
 <para>
 A class of
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 means the class is taken from the parent.
 A depth of zero for class
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 or
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 means the depth is taken from the parent.
 A visual of
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 means the visual type is taken from the parent.
 For class
-<emphasis role='bold'>InputOutput ,</emphasis>
+<emphasis role='bold'>InputOutput</emphasis>,
 the visual type and depth must be a combination supported for the screen
 (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The depth need not be the same as the parent,
 but the parent must not be of class
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For class
-<emphasis role='bold'>InputOnly ,</emphasis>
+<emphasis role='bold'>InputOnly</emphasis>,
 the depth must be zero (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results), and the visual must be one supported for the screen (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 However, the parent can have any depth and class.
 </para>
 <para>
 The server essentially acts as if
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows do not exist for the purposes of graphics requests,
 exposure processing, and
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 events.
 An
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window cannot be used as a drawable (as a source or destination for graphics
 requests).
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 and
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 windows act identically in other respects-properties,
 grabs, input control, and so on.
 </para>
@@ -1936,12 +1936,12 @@ and specify the position of the upper-left outer corner of the window
 (not the origin).
 The width and height specify the inside size (not including the border)
 and must be nonzero (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The border-width for an
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window must be zero (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 </para>
 <para>
@@ -1967,7 +1967,7 @@ The possible values are:
       <entry>background-pixmap</entry>
       <entry>
 PIXMAP or
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 or
 <emphasis role='bold'>ParentRelative</emphasis>
       </entry>
@@ -2171,9 +2171,9 @@ cursor
 
 <para>
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error to specify any other attributes for
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows.
 </para>
 <para>
@@ -2181,22 +2181,22 @@ If background-pixmap is given,
 it overrides the default background-pixmap.
 The background pixmap and the window must have the
 same root and the same depth (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 Any size pixmap can be used, although some sizes may be faster than others.
 If background
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 is specified, the window has no defined background.
 If background
-<emphasis role='bold'>ParentRelative </emphasis>
+<emphasis role='bold'>ParentRelative</emphasis>
 is specified, the parent's background is used,
 but the window must have the same depth as the parent (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 If the parent has background
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 then the window will also have background
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 A copy of the parent's background is not made.
 The parent's background is reexamined each time the window background is
 required.
@@ -2207,7 +2207,7 @@ background.
 Range checking is not performed on the background-pixel value;
 it is simply truncated to the appropriate number of bits.
 For a
-<emphasis role='bold'>ParentRelative </emphasis>
+<emphasis role='bold'>ParentRelative</emphasis>
 background,
 the background tile origin always aligns with the parent's background tile
 origin.
@@ -2218,15 +2218,15 @@ When no valid contents are available for regions of a window
 and the regions are either visible or the server is maintaining backing store,
 the server automatically tiles the regions with the window's background
 unless the window has a background of
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 If the background is
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 the previous screen contents from other windows of the same depth as the window
 are simply left in place if the contents come from the parent of the window
 or an inferior of the parent;
 otherwise, the initial contents of the exposed regions are undefined.
 Exposure events are then generated for the regions, even if the background is
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 </para>
 <para>
 The border tile origin is always the same as the background tile origin.
@@ -2234,16 +2234,16 @@ If border-pixmap is given,
 it overrides the default border-pixmap.
 The border pixmap and the window must have the same root
 and the same depth (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 Any size pixmap can be used,
 although some sizes may be faster than others.
 If
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 is given, the parent's border pixmap is copied (subsequent changes to
 the parent's border attribute do not affect the child),
 but the window must have the same depth as the parent (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The pixmap might be copied by sharing the same pixmap object between the
 child and parent or by making a complete copy of the pixmap contents.
@@ -2261,22 +2261,22 @@ so that the border is never affected.
 The bit-gravity defines which region of the window should be retained
 if the window is resized, and win-gravity defines how the window should
 be repositioned if the parent is resized (see
-<link linkend="requests:ConfigureWindow"><emphasis role='bold'>ConfigureWindow </emphasis></link>
+<link linkend="requests:ConfigureWindow"><emphasis role='bold'>ConfigureWindow</emphasis></link>
 request).
 </para>
 <para>
 A backing-store of
-<emphasis role='bold'>WhenMapped </emphasis>
+<emphasis role='bold'>WhenMapped</emphasis>
 advises the server that maintaining contents of obscured regions
 when the window is mapped would be beneficial.
 A backing-store of
-<emphasis role='bold'>Always </emphasis>
+<emphasis role='bold'>Always</emphasis>
 advises the server that maintaining contents even when the window is
 unmapped would be beneficial.
 In this case,
 the server may generate an exposure event when the window is created.
 A value of
-<emphasis role='bold'>NotUseful </emphasis>
+<emphasis role='bold'>NotUseful</emphasis>
 advises the server that maintaining contents is unnecessary,
 although a server may still choose to maintain contents while the window
 is mapped.
@@ -2290,7 +2290,7 @@ but the server may stop maintaining contents at any time.
 </para>
 <para>
 If save-under is
-<emphasis role='bold'>True , </emphasis>
+<emphasis role='bold'>True</emphasis>,
 the server is advised that when this window is
 mapped, saving the contents of windows it obscures would be beneficial.
 </para>
@@ -2331,26 +2331,26 @@ The colormap specifies the colormap that best reflects the true
 colors of the window.
 Servers capable of supporting multiple hardware colormaps may use this
 information, and window managers may use it for
-<emphasis role='bold'>InstallColormap </emphasis>
+<emphasis role='bold'>InstallColormap</emphasis>
 requests.
 The colormap must have the same visual type and root as the window (or a
 <emphasis role='bold'>Match</emphasis>
 error results).
 If
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 is specified,
 the parent's colormap is copied (subsequent changes to the parent's
 colormap attribute do not affect the child).
 However, the window must have the same visual type as the parent (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results), and the parent must not have a colormap of
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For an explanation of
-<emphasis role='bold'>None ,</emphasis>
-see <link linkend="requests:FreeColormap"><emphasis role='bold'>FreeColormap </emphasis></link>
+<emphasis role='bold'>None</emphasis>,
+see <link linkend="requests:FreeColormap"><emphasis role='bold'>FreeColormap</emphasis></link>
 request.
 The colormap is copied by sharing the colormap object between the child
 and the parent,
@@ -2360,7 +2360,7 @@ not by making a complete copy of the colormap contents.
 If a cursor is specified,
 it will be used whenever the pointer is in the window.
 If
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 is specified,
 the parent's cursor will be used when the pointer is in the window,
 and any change in the parent's cursor will cause an immediate change
@@ -2368,7 +2368,7 @@ in the displayed cursor.
 </para>
 <para>
 This request generates a
-<emphasis role='bold'>CreateNotify </emphasis>
+<emphasis role='bold'>CreateNotify</emphasis>
 event.
 </para>
 <para>
@@ -2410,12 +2410,12 @@ The server might or might not make a copy of the pixmap.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
-<emphasis role='bold'>Cursor , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Pixmap , </emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
+<emphasis role='bold'>Cursor</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Pixmap</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -2428,7 +2428,7 @@ Errors:
 <para>
 The value-mask and value-list specify which attributes are to be changed.
 The values and restrictions are the same as for
-<emphasis role='bold'>CreateWindow .</emphasis>
+<emphasis role='bold'>CreateWindow</emphasis>.
 </para>
 <para>
 Setting a new background, whether by background-pixmap or
@@ -2441,12 +2441,12 @@ Changing the background does not cause the window contents to be changed.
 Setting the border or changing the background such that the
 border tile origin changes causes the border to be repainted.
 Changing the background of a root window to
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 or
-<emphasis role='bold'>ParentRelative </emphasis>
+<emphasis role='bold'>ParentRelative</emphasis>
 restores the default background pixmap.
 Changing the border of a root window to
-<emphasis role='bold'>CopyFromParent </emphasis>
+<emphasis role='bold'>CopyFromParent</emphasis>
 restores the default border pixmap.
 </para>
 <para>
@@ -2455,9 +2455,9 @@ window.
 </para>
 <para>
 Changing the backing-store of an obscured window to
-<emphasis role='bold'>WhenMapped </emphasis>
+<emphasis role='bold'>WhenMapped</emphasis>
 or
-<emphasis role='bold'>Always </emphasis>
+<emphasis role='bold'>Always</emphasis>
 or changing the backing-planes, backing-pixel, or save-under of
 a mapped window may have no immediate effect.
 </para>
@@ -2467,13 +2467,13 @@ their event-masks are disjoint.
 When an event is generated,
 it will be reported to all interested clients.
 However, only one client at a time can select for
-<emphasis role='bold'>SubstructureRedirect , </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>,
 only one client at a time can select for
-<emphasis role='bold'>ResizeRedirect , </emphasis>
+<emphasis role='bold'>ResizeRedirect</emphasis>,
 and only one client at a time can select for
-<emphasis role='bold'>ButtonPress .</emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>.
 An attempt to violate these restrictions results in an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error.
 </para>
 <para>
@@ -2483,16 +2483,16 @@ client.
 <para>
 Changing the colormap of a window (by defining a new map, not by
 changing the contents of the existing map) generates a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event.
 Changing the colormap of a visible window might have no immediate effect
 on the screen (see
-<emphasis role='bold'>InstallColormap </emphasis>
+<emphasis role='bold'>InstallColormap</emphasis>
 request).
 </para>
 <para>
 Changing the cursor of a root window to
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 restores the default cursor.
 </para>
 <para>
@@ -2530,8 +2530,8 @@ visual: VISUALID
     <row rowsep='0'>
       <entry>
 class:
-<emphasis role='bold'>{ InputOutput , </emphasis>
-<emphasis role='bold'>InputOnly }</emphasis>
+<emphasis role='bold'>{ InputOutput</emphasis>,
+<emphasis role='bold'>InputOnly</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -2547,9 +2547,9 @@ win-gravity: WINGRAVITY
     <row rowsep='0'>
       <entry>
 backing-store:
-<emphasis role='bold'>{ NotUseful , </emphasis>
-<emphasis role='bold'>WhenMapped , </emphasis>
-<emphasis role='bold'>Always }</emphasis>
+<emphasis role='bold'>{ NotUseful</emphasis>,
+<emphasis role='bold'>WhenMapped</emphasis>,
+<emphasis role='bold'>Always</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -2581,9 +2581,9 @@ map-is-installed: BOOL
     <row rowsep='0'>
       <entry>
 map-state:
-<emphasis role='bold'>{ Unmapped , </emphasis>
-<emphasis role='bold'>Unviewable , </emphasis>
-<emphasis role='bold'>Viewable }</emphasis>
+<emphasis role='bold'>{ Unmapped</emphasis>,
+<emphasis role='bold'>Unviewable</emphasis>,
+<emphasis role='bold'>Viewable</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -2618,7 +2618,7 @@ Errors:
 <para>
 This request returns the current attributes of the window.
 A window is
-<emphasis role='bold'>Unviewable </emphasis>
+<emphasis role='bold'>Unviewable</emphasis>
 if it is mapped but some ancestor is unmapped.
 All-event-masks is the inclusive-OR of all event masks selected on the window
 by clients.
@@ -2656,15 +2656,15 @@ Errors:
 <para>
 If the argument window is mapped,
 an
-<emphasis role='bold'>UnmapWindow </emphasis>
+<emphasis role='bold'>UnmapWindow</emphasis>
 request is performed automatically.
 The window and all inferiors are then destroyed, and a
-<emphasis role='bold'>DestroyNotify </emphasis>
+<emphasis role='bold'>DestroyNotify</emphasis>
 event is generated for each window.
 The ordering of the
-<emphasis role='bold'>DestroyNotify </emphasis>
+<emphasis role='bold'>DestroyNotify</emphasis>
 events is such that for any given window,
-<emphasis role='bold'>DestroyNotify </emphasis>
+<emphasis role='bold'>DestroyNotify</emphasis>
 is generated on all inferiors of the window before being generated on
 the window itself.
 The ordering among siblings and across subhierarchies is not otherwise
@@ -2708,7 +2708,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request performs a
-<emphasis role='bold'>DestroyWindow </emphasis>
+<emphasis role='bold'>DestroyWindow</emphasis>
 request on all children of the window, in bottom-to-top stacking order.
 <!-- .sp -->
 </para>
@@ -2729,8 +2729,8 @@ request on all children of the window, in bottom-to-top stacking order.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Insert , </emphasis>
-<emphasis role='bold'>Delete }</emphasis>
+<emphasis role='bold'>{ Insert</emphasis>,
+<emphasis role='bold'>Delete</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -2738,8 +2738,8 @@ request on all children of the window, in bottom-to-top stacking order.
       <entry>
 Errors:
 <!-- .in +.2i -->
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -2753,7 +2753,7 @@ Errors:
 This request adds or removes the specified window from the client's
 save-set.
 The window must have been created by some other client (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For further information about the use of the save-set,
 see <link linkend="connection_close">section 10</link>.
@@ -2787,7 +2787,7 @@ the server automatically removes them from the save-set.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -2800,7 +2800,7 @@ Errors:
 <para>
 If the window is mapped,
 an
-<emphasis role='bold'>UnmapWindow </emphasis>
+<emphasis role='bold'>UnmapWindow</emphasis>
 request is performed automatically first.
 The window is then removed from its current position in the hierarchy
 and is inserted as a child of the specified parent.
@@ -2810,14 +2810,14 @@ window.
 The window is placed on top in the stacking order with respect
 to siblings.
 A
-<emphasis role='bold'>ReparentNotify </emphasis>
+<emphasis role='bold'>ReparentNotify</emphasis>
 event is then generated.
 The override-redirect attribute of the window is passed on in this event;
 a value of
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 indicates that a window manager should not tamper with this window.
 Finally, if the window was originally mapped, a
-<emphasis role='bold'>MapWindow </emphasis>
+<emphasis role='bold'>MapWindow</emphasis>
 request is performed automatically.
 </para>
 <para>
@@ -2827,7 +2827,7 @@ initial unmap that are immediately obscured by the final map.
 </para>
 <para>
 A
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error is generated if:
 <!-- .IP bu 5 -->
 The new parent is not on the same screen as the old parent.
@@ -2835,11 +2835,11 @@ The new parent is not on the same screen as the old parent.
 The new parent is the window itself or an inferior of the window.
 <!-- .IP bu 5 -->
 The new parent is
-<emphasis role='bold'>InputOnly , </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>,
 and the window is not.
 <!-- .IP bu 5 -->
 The window has a
-<emphasis role='bold'>ParentRelative </emphasis>
+<emphasis role='bold'>ParentRelative</emphasis>
 background, and the new parent is not the same depth as the window.
 <!-- .sp -->
 </para>
@@ -2876,15 +2876,15 @@ If the window is already mapped, this request has no effect.
 </para>
 <para>
 If the override-redirect attribute of the window is
-<emphasis role='bold'>False </emphasis>
+<emphasis role='bold'>False</emphasis>
 and some other client has selected
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent, then a
-<emphasis role='bold'>MapRequest </emphasis>
+<emphasis role='bold'>MapRequest</emphasis>
 event is generated, but the window remains unmapped.
 Otherwise, the window is mapped,
 and a
-<emphasis role='bold'>MapNotify </emphasis>
+<emphasis role='bold'>MapNotify</emphasis>
 event is generated.
 </para>
 <para>
@@ -2930,7 +2930,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request performs a
-<emphasis role='bold'>MapWindow </emphasis>
+<emphasis role='bold'>MapWindow</emphasis>
 request on all unmapped children of the window,
 in top-to-bottom stacking order.
 <!-- .sp -->
@@ -2966,7 +2966,7 @@ Errors:
 <para>
 If the window is already unmapped, this request has no effect.
 Otherwise, the window is unmapped, and an
-<emphasis role='bold'>UnmapNotify </emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>
 event is generated.
 Normal exposure processing on formerly obscured windows is performed.
 <!-- .sp -->
@@ -3001,7 +3001,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request performs an
-<emphasis role='bold'>UnmapWindow </emphasis>
+<emphasis role='bold'>UnmapWindow</emphasis>
 request on all mapped children of the window,
 in bottom-to-top stacking order.
 <!-- .sp -->
@@ -3035,8 +3035,8 @@ in bottom-to-top stacking order.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3106,48 +3106,48 @@ The x and y coordinates are relative to the parent's origin
 and specify the position of the upper-left outer corner of the window.
 The width and height specify the inside size, not including the border, and
 must be nonzero (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 Those values not specified are taken from the existing geometry of the window.
 Note that changing just the border-width leaves the outer-left corner
 of the window in a fixed position but moves the absolute position of the
 window's origin.
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error to attempt to make the border-width of an
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window nonzero.
 </para>
 <para>
 If the override-redirect attribute of the window is
-<emphasis role='bold'>False </emphasis>
+<emphasis role='bold'>False</emphasis>
 and some other client has selected
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent, a
-<emphasis role='bold'>ConfigureRequest </emphasis>
+<emphasis role='bold'>ConfigureRequest</emphasis>
 event is generated, and no further processing is performed.
 Otherwise, the following is performed:
 </para>
 <para>
 If some other client has selected
-<emphasis role='bold'>ResizeRedirect </emphasis>
+<emphasis role='bold'>ResizeRedirect</emphasis>
 on the window and the inside width or height of the window is being changed,
 a
-<emphasis role='bold'>ResizeRequest </emphasis>
+<emphasis role='bold'>ResizeRequest</emphasis>
 event is generated,
 and the current inside width and height are used instead.
 Note that the override-redirect attribute of the window has no effect on
-<emphasis role='bold'>ResizeRedirect </emphasis>
+<emphasis role='bold'>ResizeRedirect</emphasis>
 and that
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent has precedence over
-<emphasis role='bold'>ResizeRedirect </emphasis>
+<emphasis role='bold'>ResizeRedirect</emphasis>
 on the window.
 </para>
 <para>
 The geometry of the window is changed as specified,
 the window is restacked among siblings, and a
-<emphasis role='bold'>ConfigureNotify </emphasis>
+<emphasis role='bold'>ConfigureNotify</emphasis>
 event is generated if the state of the window actually changes.
 If the inside width or height of the window has actually changed,
 then children of the window are affected,
@@ -3247,16 +3247,16 @@ When a window with one of these win-gravities has its parent window resized,
 the corresponding pair defines the change in position
 of the window within the parent.
 This repositioning generates a
-<emphasis role='bold'>GravityNotify </emphasis>
+<emphasis role='bold'>GravityNotify</emphasis>
 event.
-<emphasis role='bold'>GravityNotify </emphasis>
+<emphasis role='bold'>GravityNotify</emphasis>
 events are generated after the
-<emphasis role='bold'>ConfigureNotify </emphasis>
+<emphasis role='bold'>ConfigureNotify</emphasis>
 event is generated.
 </para>
 <para>
 A gravity of
-<emphasis role='bold'>Static </emphasis>
+<emphasis role='bold'>Static</emphasis>
 indicates that the contents or origin should not move relative to the origin
 of the root window.
 If the change in size of the window is coupled with a change
@@ -3265,13 +3265,13 @@ then for bit-gravity the change in position of each pixel is [-X, -Y] and for
 win-gravity the change in position of a child when its parent is so
 resized is [-X, -Y].
 Note that
-<emphasis role='bold'>Static </emphasis>
+<emphasis role='bold'>Static</emphasis>
 gravity still only takes effect when the width or height of the
 window is changed, not when the window is simply moved.
 </para>
 <para>
 A bit-gravity of
-<emphasis role='bold'>Forget </emphasis>
+<emphasis role='bold'>Forget</emphasis>
 indicates that the window contents are always discarded after a size change,
 even if backing-store or save-under has been requested.
 The window is tiled with its background (except, if no background is defined,
@@ -3282,21 +3282,21 @@ and zero or more exposure events are generated.
 The contents and borders of inferiors are not affected by their parent's
 bit-gravity.
 A server is permitted to ignore the specified bit-gravity and use
-<emphasis role='bold'>Forget </emphasis>
+<emphasis role='bold'>Forget</emphasis>
 instead.
 </para>
 <para>
 A win-gravity of
-<emphasis role='bold'>Unmap </emphasis>
+<emphasis role='bold'>Unmap</emphasis>
 is like
-<emphasis role='bold'>NorthWest , </emphasis>
+<emphasis role='bold'>NorthWest</emphasis>,
 but the child is also unmapped when the parent is resized,
 and an
-<emphasis role='bold'>UnmapNotify </emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>
 event is generated.
-<emphasis role='bold'>UnmapNotify </emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>
 events are generated after the
-<emphasis role='bold'>ConfigureNotify </emphasis>
+<emphasis role='bold'>ConfigureNotify</emphasis>
 event is generated.
 </para>
 <para>
@@ -3419,7 +3419,7 @@ then the window is placed at the bottom of the stack.
 
 <para>
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error if a sibling is specified without a stack-mode
 or if the window is not actually a sibling.
 </para>
@@ -3428,7 +3428,7 @@ Note that the computations for
 <emphasis role='bold'>BottomIf</emphasis>,
 <emphasis role='bold'>TopIf</emphasis>,
 and
-<emphasis role='bold'>Opposite </emphasis>
+<emphasis role='bold'>Opposite</emphasis>
 are performed with respect to the window's final geometry (as controlled by
 the other arguments to the request), not to its initial geometry.
 </para>
@@ -3453,8 +3453,8 @@ Attempts to configure a root window have no effect.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>direction</emphasis>:
-<emphasis role='bold'>{ RaiseLowest , </emphasis>
-<emphasis role='bold'>LowerHighest }</emphasis>
+<emphasis role='bold'>{ RaiseLowest</emphasis>,
+<emphasis role='bold'>LowerHighest</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -3462,7 +3462,7 @@ Attempts to configure a root window have no effect.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3474,23 +3474,23 @@ Errors:
 <!-- .eM -->
 <para>
 If some other client has selected
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the window, then a
-<emphasis role='bold'>CirculateRequest </emphasis>
+<emphasis role='bold'>CirculateRequest</emphasis>
 event is generated, and no further processing is performed.
 Otherwise, the following is performed, and then a
-<emphasis role='bold'>CirculateNotify </emphasis>
+<emphasis role='bold'>CirculateNotify</emphasis>
 event is generated if the window is actually restacked.
 </para>
 <para>
 For
-<emphasis role='bold'>RaiseLowest , </emphasis>
-<emphasis role='bold'>CirculateWindow </emphasis>
+<emphasis role='bold'>RaiseLowest</emphasis>,
+<emphasis role='bold'>CirculateWindow</emphasis>
 raises the lowest mapped child (if any) that is
 occluded by another child to the top of the stack.
 For
-<emphasis role='bold'>LowerHighest ,</emphasis>
-<emphasis role='bold'>CirculateWindow </emphasis>
+<emphasis role='bold'>LowerHighest</emphasis>,
+<emphasis role='bold'>CirculateWindow</emphasis>
 lowers the highest mapped child (if any) that occludes another child to
 the bottom of the stack.
 Exposure processing is performed on formerly obscured windows.
@@ -3562,7 +3562,7 @@ and the width and height specify the inside size, not including the border.
 </para>
 <para>
 It is legal to pass an
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window as a drawable to this request.
 <!-- .sp -->
 </para>
@@ -3659,7 +3659,7 @@ atom: ATOM or
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3672,7 +3672,7 @@ Errors:
 <para>
 This request returns the atom for the given name.
 If only-if-exists is
-<emphasis role='bold'>False , </emphasis>
+<emphasis role='bold'>False</emphasis>,
 then the atom is created if it does not exist.
 The string should use the ISO Latin-1 encoding.
 Uppercase and lowercase matter.
@@ -3753,9 +3753,9 @@ This request returns the name for the given atom.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Replace , </emphasis>
-<emphasis role='bold'>Prepend , </emphasis>
-<emphasis role='bold'>Append }</emphasis>
+<emphasis role='bold'>{ Replace</emphasis>,
+<emphasis role='bold'>Prepend</emphasis>,
+<emphasis role='bold'>Append</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -3768,10 +3768,10 @@ This request returns the name for the given atom.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Atom , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Atom</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3790,27 +3790,27 @@ as necessary.
 </para>
 <para>
 If the mode is
-<emphasis role='bold'>Replace , </emphasis>
+<emphasis role='bold'>Replace</emphasis>,
 the previous property value is discarded.
 If the mode is
-<emphasis role='bold'>Prepend </emphasis>
+<emphasis role='bold'>Prepend</emphasis>
 or
-<emphasis role='bold'>Append , </emphasis>
+<emphasis role='bold'>Append</emphasis>,
 then the type and format must match the existing property value (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 If the property is undefined,
 it is treated as defined with the correct type
 and format with zero-length data.
 For
-<emphasis role='bold'>Prepend , </emphasis>
+<emphasis role='bold'>Prepend</emphasis>,
 the data is tacked on to the beginning of the existing data, and for
-<emphasis role='bold'>Append ,</emphasis>
+<emphasis role='bold'>Append</emphasis>,
 it is tacked on to the end of the existing data.
 </para>
 <para>
 This request generates a
-<emphasis role='bold'>PropertyNotify </emphasis>
+<emphasis role='bold'>PropertyNotify</emphasis>
 event on the window.
 </para>
 <para>
@@ -3846,7 +3846,7 @@ The maximum size of a property is server-dependent and may vary dynamically.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Atom ,</emphasis>
+<emphasis role='bold'>Atom</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3859,7 +3859,7 @@ Errors:
 <para>
 This request deletes the property from the specified window
 if the property exists and generates a
-<emphasis role='bold'>PropertyNotify </emphasis>
+<emphasis role='bold'>PropertyNotify</emphasis>
 event on the window unless the property does not exist.
 <!-- .sp -->
 </para>
@@ -3931,8 +3931,8 @@ value: LISTofINT8 or LISTofINT16 or LISTofINT32
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Atom , </emphasis>
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Atom</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -3945,7 +3945,7 @@ Errors:
 <para>
 If the specified property does not exist for the specified window,
 then the return type is
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 the format and bytes-after are zero,
 and the value is empty.
 The delete argument is ignored in this case.
@@ -3957,7 +3957,7 @@ the bytes-after is the length of the property in bytes
 and the value is empty.
 The delete argument is ignored in this case.
 If the specified property exists and either
-<emphasis role='bold'>AnyPropertyType </emphasis>
+<emphasis role='bold'>AnyPropertyType</emphasis>
 is specified or the specified type matches the actual type of the property,
 then the return type is the actual type of the property,
 the format is the actual format of the property (never zero),
@@ -3975,17 +3975,17 @@ A = N - (I + L)
 The returned value starts at byte index I in the property (indexing from 0),
 and its length in bytes is L.
 However, it is a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error if long-offset is given such that L is negative.
 The value of bytes-after is A,
 giving the number of trailing unread bytes in the stored
 property.
 If delete is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 and the bytes-after is zero,
 the property is also deleted from the window,
 and a
-<emphasis role='bold'>PropertyNotify </emphasis>
+<emphasis role='bold'>PropertyNotify</emphasis>
 event is generated on the window.
 <!-- .sp -->
 </para>
@@ -4018,8 +4018,8 @@ event is generated on the window.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Atom , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Atom</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4040,19 +4040,19 @@ of property names (right for positive delta, left for negative delta).
 <para>
 If delta mod N is nonzero,
 a
-<emphasis role='bold'>PropertyNotify </emphasis>
+<emphasis role='bold'>PropertyNotify</emphasis>
 event is generated for each property in the order listed.
 </para>
 <para>
 If an atom occurs more than once in the list or no property with that
 name is defined for the window,
 a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error is generated.
 If an
-<emphasis role='bold'>Atom </emphasis>
+<emphasis role='bold'>Atom</emphasis>
 or
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error is generated, no properties are changed.
 <!-- .sp -->
 </para>
@@ -4131,7 +4131,7 @@ This request returns the atoms of properties currently defined on the window.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Atom , </emphasis>
+<emphasis role='bold'>Atom</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4149,21 +4149,21 @@ than the current last-change time of the specified selection or is
 later than the current server time.
 Otherwise, the last-change time is set to the specified time
 with
-<emphasis role='bold'>CurrentTime </emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>
 replaced by the current server time.
 If the owner window is specified as
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 then the owner of the selection becomes
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 (that is, no owner).
 Otherwise, the owner of the selection becomes the client executing the request.
 If the new owner (whether a client or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 is not the same as the current owner
 and the current owner is not
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 then the current owner is sent a
-<emphasis role='bold'>SelectionClear </emphasis>
+<emphasis role='bold'>SelectionClear</emphasis>
 event.
 </para>
 <para>
@@ -4171,17 +4171,17 @@ If the client that is the owner of a selection is later terminated
 (that is, its connection is closed) or if the owner window it has
 specified in the request is later destroyed,
 then the owner of the selection automatically reverts to
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 but the last-change time is not affected.
 </para>
 <para>
 The selection atom is uninterpreted by the server.
 The owner window is returned by the
-<emphasis role='bold'>GetSelectionOwner </emphasis>
+<emphasis role='bold'>GetSelectionOwner</emphasis>
 request and is reported in
-<emphasis role='bold'>SelectionRequest </emphasis>
+<emphasis role='bold'>SelectionRequest</emphasis>
 and
-<emphasis role='bold'>SelectionClear </emphasis>
+<emphasis role='bold'>SelectionClear</emphasis>
 events.
 </para>
 <para>
@@ -4233,7 +4233,7 @@ Errors:
 This request returns the current owner window of the specified selection,
 if any.
 If
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 is returned, then there is no owner for the selection.
 <!-- .sp -->
 </para>
@@ -4273,7 +4273,7 @@ is returned, then there is no owner for the selection.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Atom , </emphasis>
+<emphasis role='bold'>Atom</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4286,13 +4286,13 @@ Errors:
 <para>
 If the specified selection has an owner,
 the server sends a
-<emphasis role='bold'>SelectionRequest </emphasis>
+<emphasis role='bold'>SelectionRequest</emphasis>
 event to that owner.
 If no owner for the specified selection exists,
 the server generates a
-<emphasis role='bold'>SelectionNotify </emphasis>
+<emphasis role='bold'>SelectionNotify</emphasis>
 event to the requestor with property
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 The arguments are passed on unchanged in either of the events.
 <!-- .sp -->
 </para>
@@ -4308,7 +4308,7 @@ The arguments are passed on unchanged in either of the events.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>destination</emphasis>: WINDOW or
-<emphasis role='bold'>PointerWindow </emphasis>
+<emphasis role='bold'>PointerWindow</emphasis>
 or
 <emphasis role='bold'>InputFocus</emphasis>
       </entry>
@@ -4333,7 +4333,7 @@ or
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4345,11 +4345,11 @@ Errors:
 <!-- .eM -->
 <para>
 If
-<emphasis role='bold'>PointerWindow </emphasis>
+<emphasis role='bold'>PointerWindow</emphasis>
 is specified,
 destination is replaced with the window that the pointer is in.
 If
-<emphasis role='bold'>InputFocus </emphasis>
+<emphasis role='bold'>InputFocus</emphasis>
 is specified and the focus window contains the pointer,
 destination is replaced with the window that the pointer is in.
 Otherwise, destination is replaced with the focus window.
@@ -4361,13 +4361,13 @@ If that client no longer exists, no event is sent.
 </para>
 <para>
 If propagate is
-<emphasis role='bold'>False , </emphasis>
+<emphasis role='bold'>False</emphasis>,
 then the event is sent to every client selecting
 on destination any of the event types in event-mask.
 </para>
 <para>
 If propagate is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 and no clients have selected on destination any
 of the event types in event-mask,
 then destination is replaced with the
@@ -4376,7 +4376,7 @@ type in event-mask and no intervening window has that type in its
 do-not-propagate-mask.
 If no such window exists or if the window is an ancestor of the focus window
 and
-<emphasis role='bold'>InputFocus </emphasis>
+<emphasis role='bold'>InputFocus</emphasis>
 was originally specified as the destination,
 then the event is not sent to any clients.
 Otherwise, the event is reported to every client selecting on the final
@@ -4385,7 +4385,7 @@ destination any of the types specified in event-mask.
 <para>
 The event code must be one of the core events or one of the events
 defined by an extension (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results) so that the server can correctly byte-swap the
 contents as necessary.
 The contents of the event are otherwise unaltered and unchecked
@@ -4423,8 +4423,8 @@ Active grabs are ignored for this request.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>pointer-mode</emphasis>, <emphasis remap='I'>keyboard-mode</emphasis>:
-<emphasis role='bold'>{ Synchronous , </emphasis>
-<emphasis role='bold'>Asynchronous }</emphasis>
+<emphasis role='bold'>{ Synchronous</emphasis>,
+<emphasis role='bold'>Asynchronous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -4455,11 +4455,11 @@ Active grabs are ignored for this request.
       <entry>
 <!-- .in +.2i -->
 status:
-<emphasis role='bold'>{ Success , </emphasis>
-<emphasis role='bold'>AlreadyGrabbed , </emphasis>
-<emphasis role='bold'>Frozen , </emphasis>
-<emphasis role='bold'>InvalidTime , </emphasis>
-<emphasis role='bold'>NotViewable }</emphasis>
+<emphasis role='bold'>{ Success</emphasis>,
+<emphasis role='bold'>AlreadyGrabbed</emphasis>,
+<emphasis role='bold'>Frozen</emphasis>,
+<emphasis role='bold'>InvalidTime</emphasis>,
+<emphasis role='bold'>NotViewable</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -4467,8 +4467,8 @@ status:
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Cursor , </emphasis>
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Cursor</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4485,11 +4485,11 @@ The request overrides any active pointer grab by this client.
 </para>
 <para>
 If owner-events is
-<emphasis role='bold'>False , </emphasis>
+<emphasis role='bold'>False</emphasis>,
 all generated pointer events are reported with respect to grab-window
 and are only reported if selected by event-mask.
 If owner-events is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 and a generated pointer event would normally be reported to this client,
 it is reported normally.
 Otherwise, the event is reported with respect to the grab-window and is
@@ -4499,30 +4499,30 @@ unreported events are simply discarded.
 </para>
 <para>
 If pointer-mode is
-<emphasis role='bold'>Asynchronous , </emphasis>
+<emphasis role='bold'>Asynchronous</emphasis>,
 pointer event processing continues normally.
 If the pointer is currently frozen by this client,
 then processing of pointer events is resumed.
 If pointer-mode is
-<emphasis role='bold'>Synchronous , </emphasis>
+<emphasis role='bold'>Synchronous</emphasis>,
 the state of the pointer (as seen by means of the protocol) appears to freeze,
 and no further pointer events are generated by the server until the
 grabbing client issues a releasing
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 request or until the pointer grab is released.
 Actual pointer changes are not lost while the pointer is frozen.
 They are simply queued for later processing.
 </para>
 <para>
 If keyboard-mode is
-<emphasis role='bold'>Asynchronous , </emphasis>
+<emphasis role='bold'>Asynchronous</emphasis>,
 keyboard event processing is unaffected by activation of the grab.
 If keyboard-mode is
-<emphasis role='bold'>Synchronous ,</emphasis>
+<emphasis role='bold'>Synchronous</emphasis>,
 the state of the keyboard (as seen by means of the protocol) appears to freeze,
 and no further keyboard events are generated by the server until the grabbing
 client issues a releasing
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 request or until the pointer grab is released.
 Actual keyboard changes are not lost while the keyboard is frozen.
 They are simply queued for later processing.
@@ -4548,29 +4548,29 @@ keep it contained in the window.
 </para>
 <para>
 This request generates
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events.
 </para>
 <para>
 The request fails with status
-<emphasis role='bold'>AlreadyGrabbed </emphasis>
+<emphasis role='bold'>AlreadyGrabbed</emphasis>
 if the pointer is actively grabbed by some other client.
 The request fails with status
-<emphasis role='bold'>Frozen </emphasis>
+<emphasis role='bold'>Frozen</emphasis>
 if the pointer is frozen by an active grab of another client.
 The request fails with status
-<emphasis role='bold'>NotViewable </emphasis>
+<emphasis role='bold'>NotViewable</emphasis>
 if grab-window or confine-to window is not viewable
 or if the confine-to window lies completely outside the boundaries
 of the root window.
 The request fails with status
-<emphasis role='bold'>InvalidTime </emphasis>
+<emphasis role='bold'>InvalidTime</emphasis>
 if the specified time is earlier than the last-pointer-grab time or later than
 the current server time.
 Otherwise, the last-pointer-grab time is set to the specified time, with
-<emphasis role='bold'>CurrentTime </emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>
 replaced by the current server time.
 <!-- .sp -->
 </para>
@@ -4598,23 +4598,23 @@ replaced by the current server time.
 <para>
 This request releases the pointer if this client has it actively grabbed (from
 either
-<emphasis role='bold'>GrabPointer </emphasis>
+<emphasis role='bold'>GrabPointer</emphasis>
 or
-<emphasis role='bold'>GrabButton </emphasis>
+<emphasis role='bold'>GrabButton</emphasis>
 or from a normal button press) and releases any queued events.
 The request has no effect if the specified time is earlier than
 the last-pointer-grab time or is later than the current server time.
 </para>
 <para>
 This request generates
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events.
 </para>
 <para>
 An
-<emphasis role='bold'>UngrabPointer </emphasis>
+<emphasis role='bold'>UngrabPointer</emphasis>
 request is performed automatically if the event window or
 confine-to window for an active pointer grab becomes not viewable
 or if window reconfiguration causes the confine-to window to lie
@@ -4660,8 +4660,8 @@ completely outside the boundaries of the root window.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>pointer-mode</emphasis>, <emphasis remap='I'>keyboard-mode</emphasis>:
-<emphasis role='bold'>{ Synchronous , </emphasis>
-<emphasis role='bold'>Asynchronous }</emphasis>
+<emphasis role='bold'>{ Synchronous</emphasis>,
+<emphasis role='bold'>Asynchronous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -4681,9 +4681,9 @@ completely outside the boundaries of the root window.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access ,</emphasis>
-<emphasis role='bold'>Cursor , </emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
+<emphasis role='bold'>Cursor</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4697,12 +4697,12 @@ Errors:
 This request establishes a passive grab.
 In the future,
 the pointer is actively grabbed as described in
-<emphasis role='bold'>GrabPointer ,</emphasis>
+<emphasis role='bold'>GrabPointer</emphasis>,
 the last-pointer-grab time is set to the time at which the button was
 pressed (as transmitted in the
-<emphasis role='bold'>ButtonPress </emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>
 event), and the
-<emphasis role='bold'>ButtonPress </emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>
 event is reported if all of the following conditions are true:
 <!-- .IP bu 5 -->
 The pointer is not grabbed and the specified button is logically pressed
@@ -4718,7 +4718,7 @@ on any ancestor of grab-window.
 </para>
 <para>
 The interpretation of the remaining arguments is the same as for
-<emphasis role='bold'>GrabPointer .</emphasis>
+<emphasis role='bold'>GrabPointer</emphasis>.
 The active grab is terminated automatically when
 the logical state of the pointer has all buttons released,
 independent of the logical state of modifier keys.
@@ -4729,29 +4729,29 @@ may lag the physical state if device event processing is frozen.
 This request overrides all previous passive grabs by the same client on
 the same button/key combinations on the same window.
 A modifier of
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 is equivalent to issuing the request for all possible modifier combinations
 (including the combination of no modifiers).
 It is not required that all specified modifiers have currently assigned
 keycodes.
 A button of
-<emphasis role='bold'>AnyButton </emphasis>
+<emphasis role='bold'>AnyButton</emphasis>
 is equivalent to issuing the request for all possible buttons.
 Otherwise, it is not required that the button specified currently be assigned
 to a physical button.
 </para>
 <para>
 An
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if some other client has already issued a
-<emphasis role='bold'>GrabButton </emphasis>
+<emphasis role='bold'>GrabButton</emphasis>
 request with the same button/key combination on the same window.
 When using
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 or
-<emphasis role='bold'>AnyButton , </emphasis>
+<emphasis role='bold'>AnyButton</emphasis>,
 the request fails completely (no grabs are established), and an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if there is a conflicting grab for any combination.
 The request has no effect on an active grab.
 <!-- .sp -->
@@ -4787,7 +4787,7 @@ The request has no effect on an active grab.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4801,11 +4801,11 @@ Errors:
 This request releases the passive button/key combination
 on the specified window if it was grabbed by this client.
 A modifiers argument of
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 is equivalent to issuing the request for all possible modifier
 combinations (including the combination of no modifiers).
 A button of
-<emphasis role='bold'>AnyButton </emphasis>
+<emphasis role='bold'>AnyButton</emphasis>
 is equivalent to issuing the request for all possible buttons.
 The request has no effect on an active grab.
 <!-- .sp -->
@@ -4841,7 +4841,7 @@ The request has no effect on an active grab.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Cursor ,</emphasis>
+<emphasis role='bold'>Cursor</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4856,10 +4856,10 @@ This request changes the specified dynamic parameters if the pointer is
 actively grabbed by the client and the specified time is no earlier than the
 last-pointer-grab time and no later than the current server time.
 The interpretation of event-mask and cursor are the same as in
-<emphasis role='bold'>GrabPointer .</emphasis>
+<emphasis role='bold'>GrabPointer</emphasis>.
 This request has no effect on the parameters of any passive grabs established
 with
-<emphasis role='bold'>GrabButton .</emphasis>
+<emphasis role='bold'>GrabButton</emphasis>.
 <!-- .sp -->
 </para>
 <para id="requests:GrabKeyboard">
@@ -4884,8 +4884,8 @@ with
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>pointer-mode</emphasis>, <emphasis remap='I'>keyboard-mode</emphasis>:
-<emphasis role='bold'>{ Synchronous , </emphasis>
-<emphasis role='bold'>Asynchronous }</emphasis>
+<emphasis role='bold'>{ Synchronous</emphasis>,
+<emphasis role='bold'>Asynchronous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -4904,11 +4904,11 @@ with
       <entry>
 <!-- .in +.2i -->
 status:
-<emphasis role='bold'>{ Success , </emphasis>
-<emphasis role='bold'>AlreadyGrabbed , </emphasis>
-<emphasis role='bold'>Frozen ,</emphasis>
-<emphasis role='bold'>InvalidTime , </emphasis>
-<emphasis role='bold'>NotViewable }</emphasis>
+<emphasis role='bold'>{ Success</emphasis>,
+<emphasis role='bold'>AlreadyGrabbed</emphasis>,
+<emphasis role='bold'>Frozen</emphasis>,
+<emphasis role='bold'>InvalidTime</emphasis>,
+<emphasis role='bold'>NotViewable</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -4916,7 +4916,7 @@ status:
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -4933,73 +4933,73 @@ This request overrides any active keyboard grab by this client.
 </para>
 <para>
 If owner-events is
-<emphasis role='bold'>False , </emphasis>
+<emphasis role='bold'>False</emphasis>,
 all generated key events are reported with respect to grab-window.
 If owner-events is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 and if a generated key event would normally be reported to this client,
 it is reported normally.
 Otherwise, the event is reported with respect to the grab-window.
 Both
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 and
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 events are always reported,
 independent of any event selection made by the client.
 </para>
 <para>
 If keyboard-mode is
-<emphasis role='bold'>Asynchronous ,</emphasis>
+<emphasis role='bold'>Asynchronous</emphasis>,
 keyboard event processing continues normally.
 If the keyboard is currently frozen by this client,
 then processing of keyboard events is resumed.
 If keyboard-mode is
-<emphasis role='bold'>Synchronous , </emphasis>
+<emphasis role='bold'>Synchronous</emphasis>,
 the state of the keyboard (as seen by means of the protocol) appears to freeze.
 No further keyboard events are generated by the server until the
 grabbing client issues a releasing
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 request or until the keyboard grab is released.
 Actual keyboard changes are not lost while the keyboard is frozen.
 They are simply queued for later processing.
 </para>
 <para>
 If pointer-mode is
-<emphasis role='bold'>Asynchronous , </emphasis>
+<emphasis role='bold'>Asynchronous</emphasis>,
 pointer event processing is unaffected by activation of the grab.
 If pointer-mode is
-<emphasis role='bold'>Synchronous , </emphasis>
+<emphasis role='bold'>Synchronous</emphasis>,
 the state of the pointer (as seen by means of the protocol) appears to freeze.
 No further pointer events are generated by the server
 until the grabbing client issues a releasing
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 request or until the keyboard grab is released.
 Actual pointer changes are not lost while the pointer is frozen.
 They are simply queued for later processing.
 </para>
 <para>
 This request generates
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events.
 </para>
 <para>
 The request fails with status
-<emphasis role='bold'>AlreadyGrabbed </emphasis>
+<emphasis role='bold'>AlreadyGrabbed</emphasis>
 if the keyboard is actively grabbed by some other client.
 The request fails with status
-<emphasis role='bold'>Frozen </emphasis>
+<emphasis role='bold'>Frozen</emphasis>
 if the keyboard is frozen by an active grab of another client.
 The request fails with status
-<emphasis role='bold'>NotViewable </emphasis>
+<emphasis role='bold'>NotViewable</emphasis>
 if grab-window is not viewable.
 The request fails with status
-<emphasis role='bold'>InvalidTime </emphasis>
+<emphasis role='bold'>InvalidTime</emphasis>
 if the specified time is earlier than the last-keyboard-grab time
 or later than the current server time.
 Otherwise, the last-keyboard-grab time is set to the specified time with
-<emphasis role='bold'>CurrentTime </emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>
 replaced by the current server time.
 <!-- .sp -->
 </para>
@@ -5027,23 +5027,23 @@ replaced by the current server time.
 <para>
 This request releases the keyboard if this client has it actively grabbed
 (as a result of either
-<emphasis role='bold'>GrabKeyboard </emphasis>
+<emphasis role='bold'>GrabKeyboard</emphasis>
 or
-<emphasis role='bold'>GrabKey ) </emphasis>
+<emphasis role='bold'>GrabKey</emphasis>)
 and releases any queued events.
 The request has no effect if the specified time is earlier than the
 last-keyboard-grab time or is later than the current server time.
 </para>
 <para>
 This request generates
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events.
 </para>
 <para>
 An
-<emphasis role='bold'>UngrabKeyboard </emphasis>
+<emphasis role='bold'>UngrabKeyboard</emphasis>
 is performed automatically if the event window for an active keyboard grab
 becomes not viewable.
 <!-- .sp -->
@@ -5082,8 +5082,8 @@ becomes not viewable.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>pointer-mode</emphasis>, <emphasis remap='I'>keyboard-mode</emphasis>:
-<emphasis role='bold'>{ Synchronous , </emphasis>
-<emphasis role='bold'>Asynchronous }</emphasis>
+<emphasis role='bold'>{ Synchronous</emphasis>,
+<emphasis role='bold'>Asynchronous</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -5091,8 +5091,8 @@ becomes not viewable.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access ,</emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -5106,12 +5106,12 @@ Errors:
 This request establishes a passive grab on the keyboard.
 In the future,
 the keyboard is actively grabbed as described in
-<emphasis role='bold'>GrabKeyboard , </emphasis>
+<emphasis role='bold'>GrabKeyboard</emphasis>,
 the last-keyboard-grab time is set to the time at which the key was pressed
 (as transmitted in the
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 event), and the
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 event is reported if all of the following conditions are true:
 <!-- .IP bu 5 -->
 The keyboard is not grabbed and the specified key
@@ -5127,7 +5127,7 @@ on any ancestor of grab-window.
 </para>
 <para>
 The interpretation of the remaining arguments is the same as for
-<emphasis role='bold'>GrabKeyboard .</emphasis>
+<emphasis role='bold'>GrabKeyboard</emphasis>.
 The active grab is terminated automatically when the logical state
 of the keyboard has the specified key released,
 independent of the logical state of modifier keys.
@@ -5138,32 +5138,32 @@ may lag the physical state if device event processing is frozen.
 This request overrides all previous passive grabs by the same client
 on the same key combinations on the same window.
 A modifier of
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 is equivalent to issuing the request for all possible modifier combinations
 (including the combination of no modifiers).
 It is not required that all modifiers specified have
 currently assigned keycodes.
 A key of
-<emphasis role='bold'>AnyKey </emphasis>
+<emphasis role='bold'>AnyKey</emphasis>
 is equivalent to issuing the request for all possible keycodes.
 Otherwise, the key must be in the range specified by min-keycode
 and max-keycode in the connection setup (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 </para>
 <para>
 An
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if some other client has issued a
-<emphasis role='bold'>GrabKey </emphasis>
+<emphasis role='bold'>GrabKey</emphasis>
 with the same key combination on the same window.
 When using
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 or
-<emphasis role='bold'>AnyKey , </emphasis>
+<emphasis role='bold'>AnyKey</emphasis>,
 the request fails completely (no grabs are established),
 and an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if there is a conflicting grab for any combination.
 <!-- .sp -->
 </para>
@@ -5198,7 +5198,7 @@ error is generated if there is a conflicting grab for any combination.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Value ,</emphasis>
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -5212,11 +5212,11 @@ Errors:
 This request releases the key combination on the specified window
 if it was grabbed by this client.
 A modifiers argument of
-<emphasis role='bold'>AnyModifier </emphasis>
+<emphasis role='bold'>AnyModifier</emphasis>
 is equivalent to issuing the request for all possible modifier combinations
 (including the combination of no modifiers).
 A key of
-<emphasis role='bold'>AnyKey </emphasis>
+<emphasis role='bold'>AnyKey</emphasis>
 is equivalent to issuing the request for all possible keycodes.
 This request has no effect on an active grab.
 <!-- .sp -->
@@ -5233,18 +5233,18 @@ This request has no effect on an active grab.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ AsyncPointer , </emphasis>
-<emphasis role='bold'>SyncPointer , </emphasis>
-<emphasis role='bold'>ReplayPointer ,</emphasis>
-<emphasis role='bold'>AsyncKeyboard , </emphasis>
+<emphasis role='bold'>{ AsyncPointer</emphasis>,
+<emphasis role='bold'>SyncPointer</emphasis>,
+<emphasis role='bold'>ReplayPointer</emphasis>,
+<emphasis role='bold'>AsyncKeyboard</emphasis>,
       </entry>
     </row>
     <row rowsep='0'>
       <entry>
-<emphasis role='bold'>SyncKeyboard , </emphasis>
-<emphasis role='bold'>ReplayKeyboard ,</emphasis>
-<emphasis role='bold'>AsyncBoth , </emphasis>
-<emphasis role='bold'>SyncBoth }</emphasis>
+<emphasis role='bold'>SyncKeyboard</emphasis>,
+<emphasis role='bold'>ReplayKeyboard</emphasis>,
+<emphasis role='bold'>AsyncBoth</emphasis>,
+<emphasis role='bold'>SyncBoth</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -5276,45 +5276,45 @@ or if the specified time is later than the current server time.
 </para>
 <para>
 For
-<emphasis role='bold'>AsyncPointer , </emphasis>
+<emphasis role='bold'>AsyncPointer</emphasis>,
 if the pointer is frozen by the client,
 pointer event processing continues normally.
 If the pointer is frozen twice by the client on behalf of two separate grabs,
-<emphasis role='bold'>AsyncPointer </emphasis>
+<emphasis role='bold'>AsyncPointer</emphasis>
 thaws for both.
-<emphasis role='bold'>AsyncPointer </emphasis>
+<emphasis role='bold'>AsyncPointer</emphasis>
 has no effect if the pointer is not frozen by the client,
 but the pointer need not be grabbed by the client.
 </para>
 <para>
 For
-<emphasis role='bold'>SyncPointer , </emphasis>
+<emphasis role='bold'>SyncPointer</emphasis>,
 if the pointer is frozen and actively grabbed by the client,
 pointer event processing continues normally until the next
-<emphasis role='bold'>ButtonPress </emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>
 or
-<emphasis role='bold'>ButtonRelease </emphasis>
+<emphasis role='bold'>ButtonRelease</emphasis>
 event is reported to the client,
 at which time the pointer again appears to freeze.
 However, if the reported event causes the pointer grab to be released,
 then the pointer does not freeze.
-<emphasis role='bold'>SyncPointer </emphasis>
+<emphasis role='bold'>SyncPointer</emphasis>
 has no effect if the pointer is not frozen by the
 client or if the pointer is not grabbed by the client.
 </para>
 <para>
 For
-<emphasis role='bold'>ReplayPointer , </emphasis>
+<emphasis role='bold'>ReplayPointer</emphasis>,
 if the pointer is actively grabbed by the client and
 is frozen as the result of an event having been sent to the client
 (either from the activation of a
-<emphasis role='bold'>GrabButton </emphasis>
+<emphasis role='bold'>GrabButton</emphasis>
 or from a previous
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 with mode
-<emphasis role='bold'>SyncPointer </emphasis>
+<emphasis role='bold'>SyncPointer</emphasis>
 but not from a
-<emphasis role='bold'>GrabPointer ), </emphasis>
+<emphasis role='bold'>GrabPointer</emphasis>),
 then the pointer grab is released and that event is completely reprocessed,
 this time ignoring any passive grabs at or above (towards the root)
 the grab-window of the grab just released.
@@ -5323,45 +5323,45 @@ or if the pointer is not frozen as the result of an event.
 </para>
 <para>
 For
-<emphasis role='bold'>AsyncKeyboard , </emphasis>
+<emphasis role='bold'>AsyncKeyboard</emphasis>,
 if the keyboard is frozen by the client,
 keyboard event processing continues normally.
 If the keyboard is frozen twice by the client on behalf of two separate grabs,
-<emphasis role='bold'>AsyncKeyboard </emphasis>
+<emphasis role='bold'>AsyncKeyboard</emphasis>
 thaws for both.
-<emphasis role='bold'>AsyncKeyboard </emphasis>
+<emphasis role='bold'>AsyncKeyboard</emphasis>
 has no effect if the keyboard is not frozen by the client,
 but the keyboard need not be grabbed by the client.
 </para>
 <para>
 For
-<emphasis role='bold'>SyncKeyboard ,</emphasis>
+<emphasis role='bold'>SyncKeyboard</emphasis>,
 if the keyboard is frozen and actively grabbed by the client,
 keyboard event processing continues normally until the next
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 or
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 event is reported to the client,
 at which time the keyboard again appears to freeze.
 However, if the reported event causes the keyboard grab to be released,
 then the keyboard does not freeze.
-<emphasis role='bold'>SyncKeyboard </emphasis>
+<emphasis role='bold'>SyncKeyboard</emphasis>
 has no effect if the keyboard is not frozen by the client or
 if the keyboard is not grabbed by the client.
 </para>
 <para>
 For
-<emphasis role='bold'>ReplayKeyboard , </emphasis>
+<emphasis role='bold'>ReplayKeyboard</emphasis>,
 if the keyboard is actively grabbed by the client
 and is frozen as the result of an event having been sent to the client
 (either from the activation of a
-<emphasis role='bold'>GrabKey </emphasis>
+<emphasis role='bold'>GrabKey</emphasis>
 or from a previous
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 with mode
-<emphasis role='bold'>SyncKeyboard </emphasis>
+<emphasis role='bold'>SyncKeyboard</emphasis>
 but not from a
-<emphasis role='bold'>GrabKeyboard ), </emphasis>
+<emphasis role='bold'>GrabKeyboard</emphasis>),
 then the keyboard grab is released and that event is completely reprocessed,
 this time ignoring any passive grabs at or above (towards the root)
 the grab-window of the grab just released.
@@ -5370,14 +5370,14 @@ or if the keyboard is not frozen as the result of an event.
 </para>
 <para>
 For
-<emphasis role='bold'>SyncBoth , </emphasis>
+<emphasis role='bold'>SyncBoth</emphasis>,
 if both pointer and keyboard are frozen by the client,
 event processing (for both devices) continues normally until the next
-<emphasis role='bold'>ButtonPress , </emphasis>
-<emphasis role='bold'>ButtonRelease , </emphasis>
-<emphasis role='bold'>KeyPress , </emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>,
+<emphasis role='bold'>ButtonRelease</emphasis>,
+<emphasis role='bold'>KeyPress</emphasis>,
 or
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 event is reported to the client for a grabbed device
 (button event for the pointer, key event for the keyboard),
 at which time the devices again appear to freeze.
@@ -5385,36 +5385,36 @@ However, if the reported event causes the grab to be released,
 then the devices do not freeze (but if the other device is still
 grabbed, then a subsequent event for it will still cause both devices
 to freeze).
-<emphasis role='bold'>SyncBoth </emphasis>
+<emphasis role='bold'>SyncBoth</emphasis>
 has no effect unless both pointer and keyboard are frozen by the client.
 If the pointer or keyboard is frozen twice by the client on behalf
 of two separate grabs,
-<emphasis role='bold'>SyncBoth </emphasis>
+<emphasis role='bold'>SyncBoth</emphasis>
 thaws for both (but a subsequent freeze for
-<emphasis role='bold'>SyncBoth </emphasis>
+<emphasis role='bold'>SyncBoth</emphasis>
 will only freeze each device once).
 </para>
 <para>
 For
-<emphasis role='bold'>AsyncBoth , </emphasis>
+<emphasis role='bold'>AsyncBoth</emphasis>,
 if the pointer and the keyboard are frozen by the client,
 event processing for both devices continues normally.
 If a device is frozen twice by the client on behalf of two separate grabs,
-<emphasis role='bold'>AsyncBoth </emphasis>
+<emphasis role='bold'>AsyncBoth</emphasis>
 thaws for both.
-<emphasis role='bold'>AsyncBoth </emphasis>
+<emphasis role='bold'>AsyncBoth</emphasis>
 has no effect unless both pointer and keyboard are frozen by the client.
 </para>
 <para>
-<emphasis role='bold'>AsyncPointer , </emphasis>
-<emphasis role='bold'>SyncPointer , </emphasis>
+<emphasis role='bold'>AsyncPointer</emphasis>,
+<emphasis role='bold'>SyncPointer</emphasis>,
 and
-<emphasis role='bold'>ReplayPointer </emphasis>
+<emphasis role='bold'>ReplayPointer</emphasis>
 have no effect on processing of keyboard events.
-<emphasis role='bold'>AsyncKeyboard , </emphasis>
-<emphasis role='bold'>SyncKeyboard , </emphasis>
+<emphasis role='bold'>AsyncKeyboard</emphasis>,
+<emphasis role='bold'>SyncKeyboard</emphasis>,
 and
-<emphasis role='bold'>ReplayKeyboard </emphasis>
+<emphasis role='bold'>ReplayKeyboard</emphasis>
 have no effect on processing of pointer events.
 </para>
 <para>
@@ -5426,7 +5426,7 @@ It is possible for a single device to be frozen because of both grabs.
 In this case, the freeze must be released on behalf of both grabs
 before events can again be processed.
 If a device is frozen twice by a single client, then a single
-<emphasis role='bold'>AllowEvents </emphasis>
+<emphasis role='bold'>AllowEvents</emphasis>
 releases both.
 <!-- .sp -->
 </para>
@@ -5513,13 +5513,13 @@ Errors:
 The root window the pointer is logically on and the pointer coordinates
 relative to the root's origin are returned.
 If same-screen is
-<emphasis role='bold'>False ,</emphasis>
+<emphasis role='bold'>False</emphasis>,
 then the pointer is not on the same screen as the argument window,
 child is
-<emphasis role='bold'>None ,</emphasis>
+<emphasis role='bold'>None</emphasis>,
 and win-x and win-y are zero.
 If same-screen is
-<emphasis role='bold'>True ,</emphasis>
+<emphasis role='bold'>True</emphasis>,
 then win-x and win-y are the pointer coordinates relative to the
 argument window's origin, and child is the child containing the
 pointer, if any.
@@ -5604,7 +5604,7 @@ The x and y coordinates are reported relative to the origin of the window.
 If the start time is later than the stop time or if the start time is
 in the future, no events are returned.
 If the stop time is in the future, it is equivalent to specifying
-<emphasis role='bold'>CurrentTime .</emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>.
 <!-- .sp -->
 </para>
 <para id="requests:TranslateCoordinates">
@@ -5668,7 +5668,7 @@ The src-x and src-y coordinates are taken relative to src-window's
 origin and are returned as dst-x and dst-y coordinates relative to
 dst-window's origin.
 If same-screen is
-<emphasis role='bold'>False , </emphasis>
+<emphasis role='bold'>False</emphasis>,
 then src-window and dst-window are on different screens,
 and dst-x and dst-y are zero.
 If the coordinates are contained in a mapped child of dst-window,
@@ -5727,14 +5727,14 @@ Errors:
 <!-- .eM -->
 <para>
 If dst-window is
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 this request moves the pointer by offsets [dst-x, dst-y]
 relative to the current position of the pointer.
 If dst-window is a window,
 this request moves the pointer to [dst-x, dst-y] relative to dst-window's
 origin.
 However, if src-window is not
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 the move only takes place if src-window contains the pointer
 and the pointer is contained in the specified rectangle of src-window.
 </para>
@@ -5768,7 +5768,7 @@ moved the pointer.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>focus</emphasis>: WINDOW or
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 or
 <emphasis role='bold'>None</emphasis>
       </entry>
@@ -5776,9 +5776,9 @@ or
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>revert-to</emphasis>:
-<emphasis role='bold'>{ Parent , </emphasis>
-<emphasis role='bold'>PointerRoot , </emphasis>
-<emphasis role='bold'>None }</emphasis>
+<emphasis role='bold'>{ Parent</emphasis>,
+<emphasis role='bold'>PointerRoot</emphasis>,
+<emphasis role='bold'>None</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -5792,8 +5792,8 @@ or
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Match ,</emphasis>
-<emphasis role='bold'>Value , </emphasis>
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
 <emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -5809,12 +5809,12 @@ The request has no effect if the specified time is earlier than the current
 last-focus-change time or is later than the current server time.
 Otherwise, the last-focus-change time is set to the specified time
 with
-<emphasis role='bold'>CurrentTime </emphasis>
+<emphasis role='bold'>CurrentTime</emphasis>
 replaced by the current server time.
 </para>
 <para>
 If
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 is specified as the focus,
 all keyboard events are discarded until a new focus window is set.
 In this case, the revert-to argument is ignored.
@@ -5828,7 +5828,7 @@ Otherwise, the event is reported with respect to the focus window.
 </para>
 <para>
 If
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 is specified as the focus,
 the focus window is dynamically taken to be the root window of whatever screen
 the pointer is on at each keyboard event.
@@ -5837,31 +5837,31 @@ the revert-to argument is ignored.
 </para>
 <para>
 This request generates
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events.
 </para>
 <para>
 The specified focus window must be viewable at the time of the request (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 If the focus window later becomes not viewable,
 the new focus window depends on the revert-to argument.
 If revert-to is
-<emphasis role='bold'>Parent , </emphasis>
+<emphasis role='bold'>Parent</emphasis>,
 the focus reverts to the parent (or the closest viewable ancestor)
 and the new revert-to value is taken to be
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 If revert-to is
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 or
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 the focus reverts to that value.
 When the focus reverts,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events are generated,
 but the last-focus-change time is not affected.
 <!-- .sp -->
@@ -5883,7 +5883,7 @@ but the last-focus-change time is not affected.
       <entry>
 <!-- .in +.2i -->
 focus: WINDOW or
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 or
 <emphasis role='bold'>None</emphasis>
       </entry>
@@ -5891,9 +5891,9 @@ or
     <row rowsep='0'>
       <entry>
 revert-to:
-<emphasis role='bold'>{ Parent , </emphasis>
-<emphasis role='bold'>PointerRoot , </emphasis>
-<emphasis role='bold'>None }</emphasis>
+<emphasis role='bold'>{ Parent</emphasis>,
+<emphasis role='bold'>PointerRoot</emphasis>,
+<emphasis role='bold'>None</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -5965,8 +5965,8 @@ may lag the physical state if device event processing is frozen.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
 <emphasis role='bold'>Name</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -6071,8 +6071,8 @@ T{
 FONTINFO:
 T}	T{
 [draw-direction:
-<emphasis role='bold'>{ LeftToRight , </emphasis>
-<emphasis role='bold'>RightToLeft }</emphasis>
+<emphasis role='bold'>{ LeftToRight</emphasis>,
+<emphasis role='bold'>RightToLeft</emphasis>}
 T}
 	\ min-char-or-byte2, max-char-or-byte2: CARD16
 	\ min-byte1, max-byte1: CARD8
@@ -6116,9 +6116,9 @@ the currently contained font is used.
 <para>
 The draw-direction is just a hint
 and indicates whether most char-infos have a positive,
-<emphasis role='bold'>LeftToRight ,</emphasis>
+<emphasis role='bold'>LeftToRight</emphasis>,
 or a negative,
-<emphasis role='bold'>RightToLeft ,</emphasis>
+<emphasis role='bold'>RightToLeft</emphasis>,
 character-width metric.
 The core protocol defines no support for vertical text.
 </para>
@@ -6157,7 +6157,7 @@ That is,
 all glyphs in the specified linear or matrix range have the same information,
 as given by min-bounds (and max-bounds).
 If all-chars-exist is
-<emphasis role='bold'>True , </emphasis>
+<emphasis role='bold'>True</emphasis>,
 then all characters in char-infos have nonzero bounding boxes.
 </para>
 <para>
@@ -6285,8 +6285,8 @@ server-dependent.
       <entry>
 <!-- .in +.2i -->
 draw-direction:
-<emphasis role='bold'>{ LeftToRight , </emphasis>
-<emphasis role='bold'>RightToLeft }</emphasis>
+<emphasis role='bold'>{ LeftToRight</emphasis>,
+<emphasis role='bold'>RightToLeft</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -6345,7 +6345,7 @@ If a gcontext is given for font,
 the currently contained font is used.
 The draw-direction, font-ascent, and font-descent are the same as
 described in
-<emphasis role='bold'>QueryFont .</emphasis>
+<emphasis role='bold'>QueryFont</emphasis>.
 The overall-ascent is the maximum of the ascent metrics of all characters
 in the string, and the overall-descent is the maximum of the descent metrics.
 The overall-width is the sum of the character-width metrics of all characters
@@ -6410,7 +6410,7 @@ names: LISTofSTRING8
 <para>
 This request returns a list
 of available font names (as controlled by the font search path; see
-<link linkend="requests:SetFontPath"><emphasis role='bold'>SetFontPath </emphasis></link>
+<link linkend="requests:SetFontPath"><emphasis role='bold'>SetFontPath</emphasis></link>
 request)
 that match the pattern.
 At most, max-names names will be returned.
@@ -6486,10 +6486,10 @@ FONTINFO: &lt;same type definition as in
 <!-- .eM -->
 <para>
 This request is similar to
-<emphasis role='bold'>ListFonts , </emphasis>
+<emphasis role='bold'>ListFonts</emphasis>,
 but it also returns information about each font.
 The information returned for each font is identical to what
-<emphasis role='bold'>QueryFont </emphasis>
+<emphasis role='bold'>QueryFont</emphasis>
 would return except that the per-character metrics are not returned.
 Note that this request can generate multiple replies.
 With each reply,
@@ -6613,9 +6613,9 @@ This request returns the current search path for fonts.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -6628,17 +6628,17 @@ Errors:
 <para>
 This request creates a pixmap and assigns the identifier pid to it.
 The width and height must be nonzero (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The depth must be one of the depths supported by the root of the specified
 drawable (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The initial contents of the pixmap are undefined.
 </para>
 <para>
 It is legal to pass an
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window as a drawable to this request.
 <!-- .sp -->
 </para>
@@ -6709,12 +6709,12 @@ The pixmap storage will be freed when no other resource references it.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>Font , </emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Pixmap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>Font</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Pixmap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -6730,7 +6730,7 @@ and assigns the identifier cid to it.
 The gcontext can be used with any destination drawable having the same root
 and depth as the specified drawable;
 use with other drawables results in a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error.
 </para>
 <para>
@@ -7118,7 +7118,7 @@ The full path of the line is drawn.
 The full path of the line is drawn,
 but the even dashes are filled differently than the odd dashes
 (see fill-style), with
-<emphasis role='bold'>Butt </emphasis>
+<emphasis role='bold'>Butt</emphasis>
 cap-style used where even and odd dashes meet.
       </entry>
     </row>
@@ -7174,7 +7174,7 @@ line) with no projection beyond.
       <entry>
 The result is a circular arc with its diameter equal to the line-width,
 centered on the endpoint; it is equivalent to
-<emphasis role='bold'>Butt </emphasis>
+<emphasis role='bold'>Butt</emphasis>
 for line-width zero.
       </entry>
     </row>
@@ -7212,7 +7212,7 @@ The join-style defines how corners are drawn for wide lines:
       <entry>
 The outer edges of the two lines extend to meet at an angle.
 However, if the angle is less than 11 degrees, a
-<emphasis role='bold'>Bevel </emphasis>
+<emphasis role='bold'>Bevel</emphasis>
 join-style is used instead.
       </entry>
     </row>
@@ -7231,7 +7231,7 @@ centered on the joinpoint.
       </entry>
       <entry>
 The result is
-<emphasis role='bold'>Butt </emphasis>
+<emphasis role='bold'>Butt</emphasis>
 endpoint styles, and then the triangular notch is filled.
       </entry>
     </row>
@@ -7344,16 +7344,16 @@ request.
 </para>
 <para>
 The tile pixmap must have the same root and depth as the gcontext (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The stipple pixmap must have depth one and must have the same root
 as the gcontext (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For fill-style
-<emphasis role='bold'>Stippled </emphasis>
+<emphasis role='bold'>Stippled</emphasis>
 (but not fill-style
-<emphasis role='bold'>OpaqueStippled ), </emphasis>
+<emphasis role='bold'>OpaqueStippled</emphasis>),
 the stipple pattern is tiled in a single plane
 and acts as an additional clip mask to be ANDed with the clip-mask.
 Any size pixmap can be used for tiling or stippling,
@@ -7463,15 +7463,15 @@ For the odd dashes for line requests with line-style
 <para>
 The dashes value allowed here is actually a simplified form of the more
 general patterns that can be set with
-<emphasis role='bold'>SetDashes .</emphasis>
+<emphasis role='bold'>SetDashes</emphasis>.
 Specifying a value of N here is equivalent to specifying
 the two element list [N, N] in
-<emphasis role='bold'>SetDashes .</emphasis>
+<emphasis role='bold'>SetDashes</emphasis>.
 The value must be nonzero (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The meaning of dash-offset and dashes are explained in the
-<emphasis role='bold'>SetDashes </emphasis>
+<emphasis role='bold'>SetDashes</emphasis>
 request.
 </para>
 <para>
@@ -7485,28 +7485,28 @@ The clip-mask origin is interpreted relative to the origin of whatever
 destination drawable is specified in a graphics request.
 If a pixmap is specified as the clip-mask,
 it must have depth 1 and have the same root as the gcontext (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 If clip-mask is
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 then pixels are always drawn, regardless of the clip origin.
 The clip-mask can also be set with the
-<emphasis role='bold'>SetClipRectangles </emphasis>
+<emphasis role='bold'>SetClipRectangles</emphasis>
 request.
 </para>
 <para>
 For
-<emphasis role='bold'>ClipByChildren , </emphasis>
+<emphasis role='bold'>ClipByChildren</emphasis>,
 both source and destination windows are additionally clipped by all viewable
-<emphasis role='bold'>InputOutput </emphasis>
+<emphasis role='bold'>InputOutput</emphasis>
 children.
 For
-<emphasis role='bold'>IncludeInferiors , </emphasis>
+<emphasis role='bold'>IncludeInferiors</emphasis>,
 neither source nor destination window is clipped by inferiors.
 This will result in including subwindow contents in the
 source and drawing through subwindow boundaries of the destination.
 The use of
-<emphasis role='bold'>IncludeInferiors </emphasis>
+<emphasis role='bold'>IncludeInferiors</emphasis>
 with a source or destination window of one depth with mapped inferiors
 of differing depth is not illegal,
 but the semantics is undefined by the core protocol.
@@ -7514,13 +7514,13 @@ but the semantics is undefined by the core protocol.
 <para>
 The fill-rule defines what pixels are inside (that is, are drawn) for
 paths given in
-<emphasis role='bold'>FillPoly </emphasis>
+<emphasis role='bold'>FillPoly</emphasis>
 requests.
-<emphasis role='bold'>EvenOdd </emphasis>
+<emphasis role='bold'>EvenOdd</emphasis>
 means a point is inside if an infinite ray with the point as origin crosses
 the path an odd number of times.
 For
-<emphasis role='bold'>Winding , </emphasis>
+<emphasis role='bold'>Winding</emphasis>,
 a point is inside if an infinite ray with the point as origin crosses an
 unequal number of clockwise and counterclockwise directed path segments.
 A clockwise directed path segment is one that crosses the ray from left
@@ -7545,16 +7545,16 @@ and are inside if and only if the polygon interior is immediately below
 </para>
 <para>
 The arc-mode controls filling in the
-<emphasis role='bold'>PolyFillArc </emphasis>
+<emphasis role='bold'>PolyFillArc</emphasis>
 request.
 </para>
 <para>
 The graphics-exposures flag controls
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 event generation for
-<emphasis role='bold'>CopyArea </emphasis>
+<emphasis role='bold'>CopyArea</emphasis>
 and
-<emphasis role='bold'>CopyPlane </emphasis>
+<emphasis role='bold'>CopyPlane</emphasis>
 requests (and any similar requests defined by extensions).
 </para>
 <para>
@@ -7736,11 +7736,11 @@ changes to a single gcontext.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Font , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Pixmap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Font</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Pixmap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -7755,14 +7755,14 @@ This request changes components in gc.
 The value-mask and value-list specify which components are to be changed.
 The values and restrictions are the same
 as for
-<emphasis role='bold'>CreateGC .</emphasis>
+<emphasis role='bold'>CreateGC</emphasis>.
 </para>
 <para>
 Changing the clip-mask also overrides any previous
-<emphasis role='bold'>SetClipRectangles </emphasis>
+<emphasis role='bold'>SetClipRectangles</emphasis>
 request on the context.
 Changing dash-offset or dashes overrides any previous
-<emphasis role='bold'>SetDashes </emphasis>
+<emphasis role='bold'>SetDashes</emphasis>
 request on the context.
 </para>
 <para>
@@ -7795,9 +7795,9 @@ a subset of the components may have been altered.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -7810,9 +7810,9 @@ Errors:
 <para>
 This request copies components from src-gc to dst-gc.
 The value-mask specifies which components to copy, as for
-<emphasis role='bold'>CreateGC .</emphasis>
+<emphasis role='bold'>CreateGC</emphasis>.
 The two gcontexts must have the same root and the same depth (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 <!-- .sp -->
 </para>
@@ -7845,8 +7845,8 @@ error results).
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -7859,7 +7859,7 @@ Errors:
 <para>
 This request sets dash-offset and dashes in gc for dashed line styles.
 Dashes cannot be empty (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 Specifying an odd-length list is equivalent to specifying the same list
 concatenated with itself to produce an even-length list.
@@ -7867,7 +7867,7 @@ The initial and alternating elements of dashes are the even dashes;
 the others are the odd dashes.
 Each element specifies a dash length in pixels.
 All of the elements must be nonzero (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The dash-offset defines the phase of the pattern,
 specifying how many pixels into dashes the pattern should actually begin in
@@ -7895,17 +7895,17 @@ of the dash, the direction of the dash, and the dash length.
 <para>
 For any graphics primitive, the total set of pixels used to render the
 primitive (both even and odd numbered dash elements) with
-<emphasis role='bold'>DoubleDash </emphasis>
+<emphasis role='bold'>DoubleDash</emphasis>
 line-style is the same as the set of pixels used to render the
 primitive with
-<emphasis role='bold'>Solid </emphasis>
+<emphasis role='bold'>Solid</emphasis>
 line-style.
 </para>
 <para>
 For any graphics primitive, if the primitive is drawn with
-<emphasis role='bold'>OnOffDash </emphasis>
+<emphasis role='bold'>OnOffDash</emphasis>
 or
-<emphasis role='bold'>DoubleDash </emphasis>
+<emphasis role='bold'>DoubleDash</emphasis>
 line-style unclipped at position [x,y] and again at position
 [x+dx,y+dy], then a point [x1,y1] is included in a dash in the first
 instance if and only if the point [x1+dx,y1+dy] is included in the dash in
@@ -7942,10 +7942,10 @@ would be included in the dash when drawn unclipped.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>ordering</emphasis>:
-<emphasis role='bold'>{ UnSorted , </emphasis>
-<emphasis role='bold'>YSorted , </emphasis>
-<emphasis role='bold'>YXSorted ,</emphasis>
-<emphasis role='bold'>YXBanded }</emphasis>
+<emphasis role='bold'>{ UnSorted</emphasis>,
+<emphasis role='bold'>YSorted</emphasis>,
+<emphasis role='bold'>YXSorted</emphasis>,
+<emphasis role='bold'>YXBanded</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -7953,9 +7953,9 @@ would be included in the dash when drawn unclipped.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -7977,11 +7977,11 @@ undefined.
 Note that the list of rectangles can be empty,
 which effectively disables output.
 This is the opposite of passing
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 as the clip-mask in
-<emphasis role='bold'>CreateGC </emphasis>
+<emphasis role='bold'>CreateGC</emphasis>
 and
-<emphasis role='bold'>ChangeGC .</emphasis>
+<emphasis role='bold'>ChangeGC</emphasis>.
 </para>
 <para>
 If known by the client,
@@ -7990,22 +7990,22 @@ argument.
 This may provide faster operation by the server.
 If an incorrect ordering is specified,
 the server may generate a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error, but it is not required to do so.
 If no error is generated,
 the graphics results are undefined.
-<emphasis role='bold'>UnSorted </emphasis>
+<emphasis role='bold'>UnSorted</emphasis>
 means that the rectangles are in arbitrary order.
-<emphasis role='bold'>YSorted </emphasis>
+<emphasis role='bold'>YSorted</emphasis>
 means that the rectangles are nondecreasing in their Y origin.
-<emphasis role='bold'>YXSorted </emphasis>
+<emphasis role='bold'>YXSorted</emphasis>
 additionally constrains
-<emphasis role='bold'>YSorted </emphasis>
+<emphasis role='bold'>YSorted</emphasis>
 order in that all rectangles with an equal Y origin are
 nondecreasing in their X origin.
-<emphasis role='bold'>YXBanded </emphasis>
+<emphasis role='bold'>YXBanded</emphasis>
 additionally constrains
-<emphasis role='bold'>YXSorted </emphasis>
+<emphasis role='bold'>YXSorted</emphasis>
 by requiring that, for every possible Y scanline,
 all rectangles that include that scanline have identical Y origins and Y
 extents.
@@ -8078,9 +8078,9 @@ and destroys the gcontext.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Match ,</emphasis>
-<emphasis role='bold'>Value , </emphasis>
-<emphasis role='bold'>Window </emphasis>
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
+<emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -8098,23 +8098,23 @@ If height is zero,
 it is replaced with the current height of the window minus y.
 If the window has a defined background tile,
 the rectangle is tiled with a plane-mask of all ones and function of
-<emphasis role='bold'>Copy </emphasis>
+<emphasis role='bold'>Copy</emphasis>
 and a subwindow-mode of
-<emphasis role='bold'>ClipByChildren .</emphasis>
+<emphasis role='bold'>ClipByChildren</emphasis>.
 If the window has background
-<emphasis role='bold'>None ,</emphasis>
+<emphasis role='bold'>None</emphasis>,
 the contents of the window are not changed.
 In either case,
 if exposures is
-<emphasis role='bold'>True , </emphasis>
+<emphasis role='bold'>True</emphasis>,
 then one or more exposure events are generated for regions of the rectangle
 that are either visible or are being retained in a backing store.
 </para>
 <para>
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error to use an
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window in this request.
 <!-- .sp -->
 </para>
@@ -8157,8 +8157,8 @@ window in this request.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8176,7 +8176,7 @@ The dst-x and dst-y are relative to dst-drawable's origin,
 each pair specifying the upper-left corner of the rectangle.
 The src-drawable must have the same root and the same depth
 as dst-drawable (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 </para>
 <para>
@@ -8187,26 +8187,26 @@ then those regions are not copied,
 but the following occurs on all corresponding destination regions that are
 either visible or are retained in backing-store.
 If the dst-drawable is a window with a background other than
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 these corresponding destination regions are tiled
 (with plane-mask of all ones and function
-<emphasis role='bold'>Copy ) </emphasis>
+<emphasis role='bold'>Copy</emphasis>)
 with that background.
 Regardless of tiling and whether the destination is a window or a pixmap,
 if graphics-exposures in gc is
-<emphasis role='bold'>True ,</emphasis>
+<emphasis role='bold'>True</emphasis>,
 then
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 events for all corresponding destination regions are generated.
 </para>
 <para>
 If graphics-exposures is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 but no
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 events are generated,
 then a
-<emphasis role='bold'>NoExposure </emphasis>
+<emphasis role='bold'>NoExposure</emphasis>
 event is generated.
 </para>
 <para>
@@ -8258,9 +8258,9 @@ graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8272,22 +8272,22 @@ Errors:
 <!-- .eM -->
 <para>
 The src-drawable must have the same root as dst-drawable (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results), but it need not have the same depth.
 The bit-plane must have exactly one bit set to 1 and the value of bit-plane
 must be less than %2 sup n% where <emphasis remap='I'>n</emphasis> is the depth of src-drawable (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 Effectively, a pixmap of the same depth as dst-drawable and with size specified
 by the source region is formed using the foreground/background pixels in gc
 (foreground everywhere the bit-plane in src-drawable contains a bit set to 1,
 background everywhere the bit-plane contains a bit set to 0),
 and the equivalent of a
-<emphasis role='bold'>CopyArea </emphasis>
+<emphasis role='bold'>CopyArea</emphasis>
 is performed, with all the same exposure semantics.
 This can also be thought of as using the specified region of the source
 bit-plane as a stipple with a fill-style of
-<emphasis role='bold'>OpaqueStippled </emphasis>
+<emphasis role='bold'>OpaqueStippled</emphasis>
 for filling a rectangular area of the destination.
 </para>
 <para>
@@ -8318,8 +8318,8 @@ clip-mask
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>coordinate-mode</emphasis>:
-<emphasis role='bold'>{ Origin , </emphasis>
-<emphasis role='bold'>Previous }</emphasis>
+<emphasis role='bold'>{ Origin</emphasis>,
+<emphasis role='bold'>Previous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -8332,9 +8332,9 @@ clip-mask
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8381,8 +8381,8 @@ clip-x-origin, clip-y-origin, clip-mask
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>coordinate-mode</emphasis>:
-<emphasis role='bold'>{ Origin , </emphasis>
-<emphasis role='bold'>Previous }</emphasis>
+<emphasis role='bold'>{ Origin</emphasis>,
+<emphasis role='bold'>Previous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -8395,9 +8395,9 @@ clip-x-origin, clip-y-origin, clip-mask
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8421,7 +8421,7 @@ If thin (zero line-width) lines intersect,
 the intersecting pixels are drawn multiple times.
 If wide lines intersect,
 the intersecting pixels are drawn only once, as though the entire
-<emphasis role='bold'>PolyLine </emphasis>
+<emphasis role='bold'>PolyLine</emphasis>
 were a single filled shape.
 </para>
 <para>
@@ -8431,7 +8431,7 @@ depending on the coordinate-mode.
 </para>
 <para>
 When either of the two lines involved in a
-<emphasis role='bold'>Bevel </emphasis>
+<emphasis role='bold'>Bevel</emphasis>
 join is neither vertical
 nor horizontal, then the slope and position of the line segment defining
 the bevel join edge is implementation dependent.  However, the computation
@@ -8491,8 +8491,8 @@ SEGMENT: [x1, y1, x2, y2: INT16]
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8551,8 +8551,8 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8564,7 +8564,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request draws the outlines of the specified rectangles, as if a five-point
-<emphasis role='bold'>PolyLine </emphasis>
+<emphasis role='bold'>PolyLine</emphasis>
 were specified for each rectangle:
 </para>
 <para>
@@ -8622,8 +8622,8 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8672,7 +8672,7 @@ tangent of the circle/ellipse at the endpoint.  When the angle of an arc
 face is not an integral multiple of 90 degrees, and the width and height of
 the arc are both are nonzero, then the shape and position of the cap at
 that face is implementation dependent.  However, for a
-<emphasis role='bold'>Butt </emphasis>
+<emphasis role='bold'>Butt</emphasis>
 cap, the face
 is defined by a straight line, and the computation of the position
 (relative to the center of the arc) and the slope of the line only
@@ -8779,16 +8779,16 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>shape</emphasis>:
-<emphasis role='bold'>{ Complex , </emphasis>
-<emphasis role='bold'>Nonconvex , </emphasis>
-<emphasis role='bold'>Convex }</emphasis>
+<emphasis role='bold'>{ Complex</emphasis>,
+<emphasis role='bold'>Nonconvex</emphasis>,
+<emphasis role='bold'>Convex</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>coordinate-mode</emphasis>:
-<emphasis role='bold'>{ Origin , </emphasis>
-<emphasis role='bold'>Previous }</emphasis>
+<emphasis role='bold'>{ Origin</emphasis>,
+<emphasis role='bold'>Previous</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -8801,9 +8801,9 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8826,36 +8826,36 @@ depending on the coordinate-mode.
 </para>
 <para>
 The shape parameter may be used by the server to improve performance.
-<emphasis role='bold'>Complex </emphasis>
+<emphasis role='bold'>Complex</emphasis>
 means the path may self-intersect.
 Contiguous coincident points in the path are not treated
 as self-intersection.
 </para>
 <para>
-<emphasis role='bold'>Nonconvex </emphasis>
+<emphasis role='bold'>Nonconvex</emphasis>
 means the path does not self-intersect,
 but the shape is not wholly convex.
 If known by the client,
 specifying
-<emphasis role='bold'>Nonconvex </emphasis>
+<emphasis role='bold'>Nonconvex</emphasis>
 over
-<emphasis role='bold'>Complex </emphasis>
+<emphasis role='bold'>Complex</emphasis>
 may improve performance.
 If
-<emphasis role='bold'>Nonconvex </emphasis>
+<emphasis role='bold'>Nonconvex</emphasis>
 is specified for a self-intersecting path,
 the graphics results are undefined.
 </para>
 <para>
-<emphasis role='bold'>Convex </emphasis>
+<emphasis role='bold'>Convex</emphasis>
 means that for every pair of points inside the polygon,
 the line segment connecting them does not intersect the path.
 If known by the client,
 specifying
-<emphasis role='bold'>Convex </emphasis>
+<emphasis role='bold'>Convex</emphasis>
 can improve performance.
 If
-<emphasis role='bold'>Convex </emphasis>
+<emphasis role='bold'>Convex</emphasis>
 is specified for a path that is not convex,
 the graphics results are undefined.
 </para>
@@ -8897,8 +8897,8 @@ tile-stipple-x-origin, tile-stipple-y-origin
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8910,7 +8910,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request fills the specified rectangles, as if a four-point
-<emphasis role='bold'>FillPoly </emphasis>
+<emphasis role='bold'>FillPoly</emphasis>
 were specified for each rectangle:
 <!-- .DS -->
 [x,y] [x+width,y] [x+width,y+height] [x,y+height]
@@ -8965,8 +8965,8 @@ tile-stipple-x-origin, tile-stipple-y-origin
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -8982,10 +8982,10 @@ this request fills the region closed by the infinitely thin path
 described by the specified arc and one or two line segments,
 depending on the arc-mode.
 For
-<emphasis role='bold'>Chord , </emphasis>
+<emphasis role='bold'>Chord</emphasis>,
 the single line segment joining the endpoints of the arc is used.
 For
-<emphasis role='bold'>PieSlice , </emphasis>
+<emphasis role='bold'>PieSlice</emphasis>,
 the two line segments joining the endpoints of the arc with the center point
 are used.
 </para>
@@ -8999,15 +8999,15 @@ they are not truncated to discrete coordinates.
 </para>
 <para>
 The arc angles are interpreted as specified in the
-<emphasis role='bold'>PolyArc </emphasis>
+<emphasis role='bold'>PolyArc</emphasis>
 request.  When
 the angle of an arc face is not an integral multiple of 90 degrees, then
 the precise endpoint on the arc is implementation dependent.  However, for
-<emphasis role='bold'>Chord </emphasis>
+<emphasis role='bold'>Chord</emphasis>
 arc-mode, the computation of the pair of endpoints (relative to the
 center of the arc) only depends on the width and height of the arc and
 the angles of the two arc faces.  For
-<emphasis role='bold'>PieSlice </emphasis>
+<emphasis role='bold'>PieSlice</emphasis>
 arc-mode, the computation of
 an endpoint only depends on the angle of the arc face for that
 endpoint and the ratio of the arc width to arc height.
@@ -9070,9 +9070,9 @@ tile-stipple-x-origin, tile-stipple-y-origin
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>format</emphasis>:
-<emphasis role='bold'>{ Bitmap , </emphasis>
-<emphasis role='bold'>XYPixmap , </emphasis>
-<emphasis role='bold'>ZPixmap }</emphasis>
+<emphasis role='bold'>{ Bitmap</emphasis>,
+<emphasis role='bold'>XYPixmap</emphasis>,
+<emphasis role='bold'>ZPixmap</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -9085,9 +9085,9 @@ tile-stipple-x-origin, tile-stipple-y-origin
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9103,43 +9103,43 @@ The dst-x and dst-y coordinates are relative to the drawable's origin.
 </para>
 <para>
 If
-<emphasis role='bold'>Bitmap </emphasis>
+<emphasis role='bold'>Bitmap</emphasis>
 format is used,
 then depth must be one (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results), and the image must be in XY format.
 The foreground pixel in gc defines the source for bits set to 1 in the image,
 and the background pixel defines the source for the bits set to 0.
 </para>
 <para>
 For
-<emphasis role='bold'>XYPixmap </emphasis>
+<emphasis role='bold'>XYPixmap</emphasis>
 and
-<emphasis role='bold'>ZPixmap , </emphasis>
+<emphasis role='bold'>ZPixmap</emphasis>,
 the depth must match the depth of the drawable (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For
-<emphasis role='bold'>XYPixmap , </emphasis>
+<emphasis role='bold'>XYPixmap</emphasis>,
 the image must be sent in XY format.
 For
-<emphasis role='bold'>ZPixmap , </emphasis>
+<emphasis role='bold'>ZPixmap</emphasis>,
 the image must be sent in the Z format defined for the given depth.
 </para>
 <para>
 The left-pad must be zero for
-<emphasis role='bold'>ZPixmap </emphasis>
+<emphasis role='bold'>ZPixmap</emphasis>
 format (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For
-<emphasis role='bold'>Bitmap </emphasis>
+<emphasis role='bold'>Bitmap</emphasis>
 and
-<emphasis role='bold'>XYPixmap </emphasis>
+<emphasis role='bold'>XYPixmap</emphasis>
 format,
 left-pad must be less than bitmap-scanline-pad as given in the server
 connection setup information (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The first left-pad bits in every scanline are to be ignored by the server.
 The actual image begins that many bits into the data.
@@ -9186,8 +9186,8 @@ GC mode-dependent components: foreground, background
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>format</emphasis>:
-<emphasis role='bold'>{ XYPixmap , </emphasis>
-<emphasis role='bold'>ZPixmap }</emphasis>
+<emphasis role='bold'>{ XYPixmap</emphasis>,
+<emphasis role='bold'>ZPixmap</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -9218,8 +9218,8 @@ data: LISTofBYTE
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9235,13 +9235,13 @@ given format.
 The x and y coordinates are relative to the drawable's origin
 and define the upper-left corner of the rectangle.
 If
-<emphasis role='bold'>XYPixmap </emphasis>
+<emphasis role='bold'>XYPixmap</emphasis>
 is specified,
 only the bit planes specified in plane-mask are transmitted,
 with the planes appearing from most significant to least significant
 in bit order.
 If
-<emphasis role='bold'>ZPixmap </emphasis>
+<emphasis role='bold'>ZPixmap</emphasis>
 is specified, then bits in all planes not specified in plane-mask are
 transmitted as zero.
 Range checking is not performed on plane-mask;
@@ -9253,12 +9253,12 @@ If the drawable is a window,
 its visual type is returned.
 If the drawable is a pixmap,
 the visual is
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 </para>
 <para>
 If the drawable is a pixmap,
 then the given rectangle must be wholly contained within the pixmap (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 If the drawable is a window,
 the window must be viewable,
@@ -9266,7 +9266,7 @@ and it must be the case that,
 if there were no inferiors or overlapping windows,
 the specified rectangle of the window would be fully visible on the screen
 and wholly contained within the outside edges of the window (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 Note that the borders of the window can be included and read with this request.
 If the window has a backing store,
@@ -9338,10 +9338,10 @@ TEXTELT8:	[delta: INT8
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>Font ,</emphasis>
-<emphasis role='bold'>GContext , </emphasis>
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>Font</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
+<emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -9368,7 +9368,7 @@ All contained FONTs are always transmitted most significant byte first.
 </para>
 <para>
 If a
-<emphasis role='bold'>Font </emphasis>
+<emphasis role='bold'>Font</emphasis>
 error is generated for an item,
 the previous items may have been drawn.
 </para>
@@ -9441,9 +9441,9 @@ TEXTELT16:	[delta: INT8
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>Font ,</emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>Font</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9455,7 +9455,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request is similar to
-<emphasis role='bold'>PolyText8 , </emphasis>
+<emphasis role='bold'>PolyText8</emphasis>,
 except 2-byte (or 16-bit) characters are used.
 For fonts defined with linear indexing rather than 2-byte matrix indexing,
 the server will interpret each CHAR2B as a 16-bit number that
@@ -9497,8 +9497,8 @@ CHAR2B is taken as the most significant byte).
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9533,15 +9533,15 @@ font-ascent + font-descent
 <para>
 The overall-width, font-ascent, and font-descent are as
 they would be returned by a
-<emphasis role='bold'>QueryTextExtents </emphasis>
+<emphasis role='bold'>QueryTextExtents</emphasis>
 call using gc and string.
 </para>
 <para>
 The function and fill-style defined in gc are ignored for this request.
 The effective function is
-<emphasis role='bold'>Copy ,</emphasis>
+<emphasis role='bold'>Copy</emphasis>,
 and the effective fill-style
-<emphasis role='bold'>Solid .</emphasis>
+<emphasis role='bold'>Solid</emphasis>.
 </para>
 <para>
 For fonts defined with 2-byte matrix indexing,
@@ -9587,8 +9587,8 @@ subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>GContext , </emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>GContext</emphasis>,
 <emphasis role='bold'>Match</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9600,7 +9600,7 @@ Errors:
 <!-- .eM -->
 <para>
 This request is similar to
-<emphasis role='bold'>ImageText8 , </emphasis>
+<emphasis role='bold'>ImageText8</emphasis>,
 except 2-byte (or 16-bit) characters are used.
 For fonts defined with linear indexing rather than 2-byte matrix indexing,
 the server will interpret each CHAR2B as a 16-bit number that
@@ -9635,8 +9635,8 @@ CHAR2B is taken as the most significant byte).
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>alloc</emphasis>:
-<emphasis role='bold'>{ None , </emphasis>
-<emphasis role='bold'>All }</emphasis>
+<emphasis role='bold'>{ None</emphasis>,
+<emphasis role='bold'>All</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -9644,11 +9644,11 @@ CHAR2B is taken as the most significant byte).
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
-<emphasis role='bold'>Value , </emphasis>
-<emphasis role='bold'>Window </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
+<emphasis role='bold'>Value</emphasis>,
+<emphasis role='bold'>Window</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -9661,59 +9661,59 @@ Errors:
 This request creates a colormap of the specified visual type for the screen
 on which the window resides and associates the identifier mid with it.
 The visual type must be one supported by the screen (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The initial values of the colormap entries are undefined for classes
-<emphasis role='bold'>GrayScale , </emphasis>
-<emphasis role='bold'>PseudoColor , </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>,
+<emphasis role='bold'>PseudoColor</emphasis>,
 and
-<emphasis role='bold'>DirectColor .</emphasis>
+<emphasis role='bold'>DirectColor</emphasis>.
 For
-<emphasis role='bold'>StaticGray , </emphasis>
-<emphasis role='bold'>StaticColor ,</emphasis>
+<emphasis role='bold'>StaticGray</emphasis>,
+<emphasis role='bold'>StaticColor</emphasis>,
 and
-<emphasis role='bold'>TrueColor , </emphasis>
+<emphasis role='bold'>TrueColor</emphasis>,
 the entries will have defined values,
 but those values are specific to the visual and are not defined
 by the core protocol.
 For
-<emphasis role='bold'>StaticGray , </emphasis>
-<emphasis role='bold'>StaticColor , </emphasis>
+<emphasis role='bold'>StaticGray</emphasis>,
+<emphasis role='bold'>StaticColor</emphasis>,
 and
-<emphasis role='bold'>TrueColor , </emphasis>
+<emphasis role='bold'>TrueColor</emphasis>,
 alloc must be specified as
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 For the other classes, if alloc is
-<emphasis role='bold'>None ,</emphasis>
+<emphasis role='bold'>None</emphasis>,
 the colormap initially has no allocated entries,
 and clients can allocate entries.
 </para>
 <para>
 If alloc is
-<emphasis role='bold'>All , </emphasis>
+<emphasis role='bold'>All</emphasis>,
 then the entire colormap is allocated writable.
 The initial values of all allocated entries are undefined.
 For
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 and
-<emphasis role='bold'>PseudoColor , </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>,
 the effect is as if an
-<emphasis role='bold'>AllocColorCells </emphasis>
+<emphasis role='bold'>AllocColorCells</emphasis>
 request returned all pixel values from zero to N - 1,
 where N is the colormap-entries value in the specified visual.
 For
-<emphasis role='bold'>DirectColor , </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>,
 the effect is as if an
-<emphasis role='bold'>AllocColorPlanes </emphasis>
+<emphasis role='bold'>AllocColorPlanes</emphasis>
 request returned a pixel value of zero and red-mask,
 green-mask, and blue-mask values containing the same bits as the
 corresponding masks in the specified visual.
 However,
 in all cases, none of these entries can be freed with
-<emphasis role='bold'>FreeColors .</emphasis>
+<emphasis role='bold'>FreeColors</emphasis>.
 <!-- .sp -->
 </para>
 <para id="requests:FreeColormap">
@@ -9749,19 +9749,19 @@ This request deletes the association between the resource ID and the colormap
 and frees the colormap storage.
 If the colormap is an installed map for a screen,
 it is uninstalled (see
-<link linkend="requests:UninstallColormap"><emphasis role='bold'>UninstallColormap </emphasis></link>
+<link linkend="requests:UninstallColormap"><emphasis role='bold'>UninstallColormap</emphasis></link>
 request).
 If the colormap is defined as the colormap for a window (by means of
-<emphasis role='bold'>CreateWindow </emphasis>
+<emphasis role='bold'>CreateWindow</emphasis>
 or
-<emphasis role='bold'>ChangeWindowAttributes ), </emphasis>
+<emphasis role='bold'>ChangeWindowAttributes</emphasis>),
 the colormap for the window is changed to
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 and a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event is generated.
 The protocol does not define the colors displayed for a window with a colormap of
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 </para>
 <para>
 This request has no effect on a default colormap for a screen.
@@ -9786,8 +9786,8 @@ This request has no effect on a default colormap for a screen.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>IDChoice</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -9807,21 +9807,21 @@ and their read-only or writable characteristics intact,
 and it frees those entries in src-cmap.
 Color values in other entries in the new colormap are undefined.
 If src-cmap was created by the client with alloc
-<emphasis role='bold'>All </emphasis>
+<emphasis role='bold'>All</emphasis>
 (see
-<link linkend="requests:CreateColormap"><emphasis role='bold'>CreateColormap </emphasis></link>
+<link linkend="requests:CreateColormap"><emphasis role='bold'>CreateColormap</emphasis></link>
 request),
 then the new colormap is also created with alloc
-<emphasis role='bold'>All , </emphasis>
+<emphasis role='bold'>All</emphasis>,
 all color values for all entries are copied from src-cmap,
 and then all entries in src-cmap are freed.
 If src-cmap was not created by the client with alloc
-<emphasis role='bold'>All , </emphasis>
+<emphasis role='bold'>All</emphasis>,
 then the allocations to be moved are all those pixels and planes that have
 been allocated by the client using either
-<emphasis role='bold'>AllocColor , </emphasis>
-<emphasis role='bold'>AllocNamedColor ,</emphasis>
-<emphasis role='bold'>AllocColorCells , </emphasis>
+<emphasis role='bold'>AllocColor</emphasis>,
+<emphasis role='bold'>AllocNamedColor</emphasis>,
+<emphasis role='bold'>AllocColorCells</emphasis>,
 or
 <emphasis role='bold'>AllocColorPlanes</emphasis>
 and that have not been freed since they were allocated.
@@ -9866,12 +9866,12 @@ except that the required list must remain installed.
 </para>
 <para>
 If cmap is not already an installed map, a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event is generated on every window having cmap as an attribute.
 In addition,
 for every other colormap that is installed or uninstalled as a result
 of the request, a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event is generated on every window having that colormap as an attribute.
 </para>
 <para>
@@ -9882,11 +9882,11 @@ where M is the min-installed-maps specified for the screen in the
 connection setup.
 The required list is maintained as follows.
 When a colormap is an explicit argument to
-<emphasis role='bold'>InstallColormap ,</emphasis>
+<emphasis role='bold'>InstallColormap</emphasis>,
 it is added to the head of the list; the list is truncated at the
 tail, if necessary, to keep the length of the list to at most M.
 When a colormap is an explicit argument to
-<emphasis role='bold'>UninstallColormap </emphasis>
+<emphasis role='bold'>UninstallColormap</emphasis>
 and it is in the required list, it is removed from the list.
 A colormap is not added to the required list when it is installed implicitly
 by the server, and the server cannot implicitly uninstall a colormap that is
@@ -9927,7 +9927,7 @@ Errors:
 <!-- .eM -->
 <para>
 If cmap is on the required list for its screen (see
-<link linkend="requests:InstallColormap"><emphasis role='bold'>InstallColormap </emphasis></link>
+<link linkend="requests:InstallColormap"><emphasis role='bold'>InstallColormap</emphasis></link>
 request),
 it is removed from the list.
 As a side effect,
@@ -9938,12 +9938,12 @@ except that the required list must remain installed.
 </para>
 <para>
 If cmap becomes uninstalled, a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event is generated on every window having cmap as an attribute.
 In addition,
 for every other colormap that is installed or uninstalled as a result of
 the request, a
-<emphasis role='bold'>ColormapNotify </emphasis>
+<emphasis role='bold'>ColormapNotify</emphasis>
 event is generated on every window having that colormap as an attribute.
 <!-- .sp -->
 </para>
@@ -9992,7 +9992,7 @@ This request returns a list of the currently installed colormaps for the
 screen of the specified window.
 The order of colormaps is not significant,
 and there is no explicit indication of the required list (see
-<link linkend="requests:InstallColormap"><emphasis role='bold'>InstallColormap </emphasis></link>
+<link linkend="requests:InstallColormap"><emphasis role='bold'>InstallColormap</emphasis></link>
 request).
 <!-- .sp -->
 </para>
@@ -10037,8 +10037,8 @@ red, green, blue: CARD16
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -10101,8 +10101,8 @@ visual-red, visual-green, visual-blue: CARD16
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Name</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10116,7 +10116,7 @@ Errors:
 This request looks up the named color with respect to the screen associated
 with the colormap.
 Then, it does an
-<emphasis role='bold'>AllocColor </emphasis>
+<emphasis role='bold'>AllocColor</emphasis>
 on cmap.
 The name should use the ISO Latin-1 encoding,
 and uppercase and lowercase do not matter.
@@ -10165,8 +10165,8 @@ pixels, masks: LISTofCARD32
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10179,7 +10179,7 @@ Errors:
 <para>
 The number of colors must be positive,
 and the number of planes must be nonnegative (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 If C colors and P planes are requested,
 then C pixels and P masks are returned.
@@ -10189,21 +10189,21 @@ By ORing together masks and pixels,
 C*%2 sup P% distinct pixels can be produced;
 all of these are allocated writable by the request.
 For
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 or
-<emphasis role='bold'>PseudoColor , </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>,
 each mask will have exactly one bit set to 1; for
-<emphasis role='bold'>DirectColor ,</emphasis>
+<emphasis role='bold'>DirectColor</emphasis>,
 each will have exactly three bits set to 1.
 If contiguous is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 and if all masks are ORed together,
 a single contiguous set of bits will be formed for
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 or
-<emphasis role='bold'>PseudoColor , </emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>,
 and three contiguous sets of bits (one within each pixel subfield) for
-<emphasis role='bold'>DirectColor .</emphasis>
+<emphasis role='bold'>DirectColor</emphasis>.
 The RGB values of the allocated entries are undefined.
 <!-- .sp -->
 </para>
@@ -10253,8 +10253,8 @@ red-mask, green-mask, blue-mask: CARD32
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10267,18 +10267,18 @@ Errors:
 <para>
 The number of colors must be positive,
 and the reds, greens, and blues must be nonnegative (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 If C colors, R reds, G greens, and B blues are requested,
 then C pixels are returned, and the masks have R, G, and B bits set,
 respectively.
 If contiguous is
-<emphasis role='bold'>True , </emphasis>
+<emphasis role='bold'>True</emphasis>,
 then each mask will have a contiguous set of bits.
 No mask will have any bits in common with any other mask
 or with any of the pixels.
 For
-<emphasis role='bold'>DirectColor , </emphasis>
+<emphasis role='bold'>DirectColor</emphasis>,
 each mask will lie within the corresponding pixel subfield.
 By ORing together subsets of masks with pixels,
 C*%2 sup R+G+B% distinct pixels can be produced;
@@ -10289,11 +10289,11 @@ there are only C*%2 sup R% independent red entries,
 C*%2 sup G% independent green entries,
 and C*%2 sup B% independent blue entries.
 This is true even for
-<emphasis role='bold'>PseudoColor .</emphasis>
+<emphasis role='bold'>PseudoColor</emphasis>.
 When the colormap entry for a pixel value is changed using
-<emphasis role='bold'>StoreColors </emphasis>
+<emphasis role='bold'>StoreColors</emphasis>
 or
-<emphasis role='bold'>StoreNamedColor , </emphasis>
+<emphasis role='bold'>StoreNamedColor</emphasis>,
 the pixel is decomposed according to the masks and the
 corresponding independent entries are updated.
 <!-- .sp -->
@@ -10327,8 +10327,8 @@ corresponding independent entries are updated.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access , </emphasis>
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10345,14 +10345,14 @@ The set of all pixels is produced by ORing together subsets of
 plane-mask with the pixels.
 The request frees all of these pixels that
 were allocated by the client (using
-<emphasis role='bold'>AllocColor , </emphasis>
-<emphasis role='bold'>AllocNamedColor ,</emphasis>
-<emphasis role='bold'>AllocColorCells , </emphasis>
+<emphasis role='bold'>AllocColor</emphasis>,
+<emphasis role='bold'>AllocNamedColor</emphasis>,
+<emphasis role='bold'>AllocColorCells</emphasis>,
 and
-<emphasis role='bold'>AllocColorPlanes ).</emphasis>
+<emphasis role='bold'>AllocColorPlanes</emphasis>).
 Note that freeing an
 individual pixel obtained from
-<emphasis role='bold'>AllocColorPlanes </emphasis>
+<emphasis role='bold'>AllocColorPlanes</emphasis>
 may not actually allow it to be reused until all of its related pixels
 are also freed.
 Similarly, a read-only entry is not actually freed until it has been
@@ -10364,17 +10364,17 @@ entry is actually freed.
 All specified pixels that are allocated by the client in cmap are freed,
 even if one or more pixels produce an error.
 A
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error is generated if a specified pixel is not a valid index into cmap.
 An
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if a specified pixel is not allocated by the
 client (that is, is unallocated or is only allocated by another client)
 or if the colormap was created with all entries writable (using an alloc
 value of
-<emphasis role='bold'>All </emphasis>
+<emphasis role='bold'>All</emphasis>
 in
-<emphasis role='bold'>CreateColormap ).</emphasis>
+<emphasis role='bold'>CreateColormap</emphasis>).
 If more than one pixel is in error,
 it is arbitrary as to which pixel is reported.
 <!-- .sp -->
@@ -10456,9 +10456,9 @@ the changes are visible immediately.
 All specified pixels that are allocated writable in cmap (by any client)
 are changed, even if one or more pixels produce an error.
 A
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error is generated if a specified pixel is not a valid index into cmap, and an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error is generated if a specified pixel is unallocated or is allocated
 read-only.
 If more than one pixel is in error,
@@ -10499,9 +10499,9 @@ it is arbitrary as to which pixel is reported.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access , </emphasis>
-<emphasis role='bold'>Colormap ,</emphasis>
-<emphasis role='bold'>Name , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
+<emphasis role='bold'>Colormap</emphasis>,
+<emphasis role='bold'>Name</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10514,16 +10514,16 @@ Errors:
 <para>
 This request looks up the named color with respect to the screen associated
 with cmap and then does a
-<emphasis role='bold'>StoreColors </emphasis>
+<emphasis role='bold'>StoreColors</emphasis>
 in cmap.
 The name should use the ISO Latin-1 encoding,
 and uppercase and lowercase do not matter.
 The
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 and
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 errors are the same as in
-<emphasis role='bold'>StoreColors .</emphasis>
+<emphasis role='bold'>StoreColors</emphasis>.
 <!-- .sp -->
 </para>
 <para id="requests:QueryColors">
@@ -10576,7 +10576,7 @@ RGB: [red, green, blue: CARD16]
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10591,7 +10591,7 @@ This request returns the hardware-specific color values stored in cmap for
 the specified pixels.
 The values returned for an unallocated entry are undefined.
 A
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error is generated if a pixel is not a valid index into cmap.
 If more than one pixel is in error,
 it is arbitrary as to which pixel is reported.
@@ -10638,7 +10638,7 @@ visual-red, visual-green, visual-blue: CARD16
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Colormap , </emphasis>
+<emphasis role='bold'>Colormap</emphasis>,
 <emphasis role='bold'>Name</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10702,9 +10702,9 @@ and uppercase and lowercase do not matter.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
-<emphasis role='bold'>Match , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Pixmap</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10718,14 +10718,14 @@ Errors:
 This request creates a cursor and associates identifier cid with it.
 The foreground and background RGB values must be specified,
 even if the server only has a
-<emphasis role='bold'>StaticGray </emphasis>
+<emphasis role='bold'>StaticGray</emphasis>
 or
-<emphasis role='bold'>GrayScale </emphasis>
+<emphasis role='bold'>GrayScale</emphasis>
 screen.
 The foreground is used for the bits set to 1 in the source,
 and the background is used for the bits set to 0.
 Both source and mask (if specified) must have depth one (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results), but they can have any root.
 The mask pixmap defines the shape of the cursor.
 That is,
@@ -10735,11 +10735,11 @@ the corresponding bits of the source pixmap are ignored.
 If no mask is given,
 all pixels of the source are displayed.
 The mask, if present, must be the same size as the source (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 The x and y coordinates define the hotspot relative to the source's origin
 and must be a point within the source (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 </para>
 <para>
@@ -10801,9 +10801,9 @@ The server might or might not make a copy of the pixmap.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
-<emphasis role='bold'>Font , </emphasis>
-<emphasis role='bold'>IDChoice , </emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
+<emphasis role='bold'>Font</emphasis>,
+<emphasis role='bold'>IDChoice</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10815,12 +10815,12 @@ Errors:
 <!-- .eM -->
 <para>
 This request is similar to
-<emphasis role='bold'>CreateCursor , </emphasis>
+<emphasis role='bold'>CreateCursor</emphasis>,
 except the source and mask bitmaps are obtained from the specified font glyphs.
 The source-char must be a defined glyph in source-font,
 and if mask-font is given, mask-char must be a defined glyph in mask-font
 (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The mask font and character are optional.
 The origins of the source and mask (if it is defined) glyphs
@@ -10933,9 +10933,9 @@ the change is visible immediately.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>class</emphasis>:
-<emphasis role='bold'>{ Cursor , </emphasis>
-<emphasis role='bold'>Tile , </emphasis>
-<emphasis role='bold'>Stipple }</emphasis>
+<emphasis role='bold'>{ Cursor</emphasis>,
+<emphasis role='bold'>Tile</emphasis>,
+<emphasis role='bold'>Stipple</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -10965,8 +10965,8 @@ width, height: CARD16
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Drawable , </emphasis>
-<emphasis role='bold'>Match ,</emphasis>
+<emphasis role='bold'>Drawable</emphasis>,
+<emphasis role='bold'>Match</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -10979,32 +10979,32 @@ Errors:
 <para>
 This request returns the best size that is closest to the argument size.
 For
-<emphasis role='bold'>Cursor , </emphasis>
+<emphasis role='bold'>Cursor</emphasis>,
 this is the largest size that can be fully displayed.
 For
-<emphasis role='bold'>Tile , </emphasis>
+<emphasis role='bold'>Tile</emphasis>,
 this is the size that can be tiled fastest.
 For
-<emphasis role='bold'>Stipple , </emphasis>
+<emphasis role='bold'>Stipple</emphasis>,
 this is the size that can be stippled fastest.
 </para>
 <para>
 For
-<emphasis role='bold'>Cursor , </emphasis>
+<emphasis role='bold'>Cursor</emphasis>,
 the drawable indicates the desired screen.
 For
-<emphasis role='bold'>Tile </emphasis>
+<emphasis role='bold'>Tile</emphasis>
 and
-<emphasis role='bold'>Stipple , </emphasis>
+<emphasis role='bold'>Stipple</emphasis>,
 the drawable indicates the screen and also possibly the window class and depth.
 An
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 window cannot be used as the drawable for
-<emphasis role='bold'>Tile </emphasis>
+<emphasis role='bold'>Tile</emphasis>
 or
-<emphasis role='bold'>Stipple </emphasis>
+<emphasis role='bold'>Stipple</emphasis>
 (or a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error results).
 <!-- .sp -->
 </para>
@@ -11132,9 +11132,9 @@ This request returns a list of all extensions supported by the server.
       <entry>
 <!-- .in +.2i -->
 status:
-<emphasis role='bold'>{ Success , </emphasis>
-<emphasis role='bold'>Busy , </emphasis>
-<emphasis role='bold'>Failed }</emphasis>
+<emphasis role='bold'>{ Success</emphasis>,
+<emphasis role='bold'>Busy</emphasis>,
+<emphasis role='bold'>Failed</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -11142,7 +11142,7 @@ status:
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -11156,26 +11156,26 @@ Errors:
 This request specifies the keycodes (if any) of the keys to be used as
 modifiers.
 The number of keycodes in the list must be 8*keycodes-per-modifier (or a
-<emphasis role='bold'>Length </emphasis>
+<emphasis role='bold'>Length</emphasis>
 error results).
 The keycodes are divided into eight sets,
 with each set containing keycodes-per-modifier elements.
 The sets are assigned to the modifiers
-<emphasis role='bold'>Shift , </emphasis>
-<emphasis role='bold'>Lock , </emphasis>
-<emphasis role='bold'>Control , </emphasis>
-<emphasis role='bold'>Mod1 ,</emphasis>
-<emphasis role='bold'>Mod2 , </emphasis>
-<emphasis role='bold'>Mod3 , </emphasis>
-<emphasis role='bold'>Mod4 , </emphasis>
+<emphasis role='bold'>Shift</emphasis>,
+<emphasis role='bold'>Lock</emphasis>,
+<emphasis role='bold'>Control</emphasis>,
+<emphasis role='bold'>Mod1</emphasis>,
+<emphasis role='bold'>Mod2</emphasis>,
+<emphasis role='bold'>Mod3</emphasis>,
+<emphasis role='bold'>Mod4</emphasis>,
 and
-<emphasis role='bold'>Mod5 ,</emphasis>
+<emphasis role='bold'>Mod5</emphasis>,
 in order.
 Only nonzero keycode values are used within each set;
 zero values are ignored.
 All of the nonzero keycodes must be in the range specified by min-keycode
 and max-keycode in the connection setup (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The order of keycodes within a set does not matter.
 If no nonzero values are specified in a set,
@@ -11191,7 +11191,7 @@ if certain keys do not generate up transitions in hardware,
 if auto-repeat cannot be disabled on certain keys,
 or if multiple keys per modifier are not supported).
 The status reply is
-<emphasis role='bold'>Failed </emphasis>
+<emphasis role='bold'>Failed</emphasis>
 if some such restriction is violated,
 and none of the modifiers is changed.
 </para>
@@ -11199,14 +11199,14 @@ and none of the modifiers is changed.
 If the new nonzero keycodes specified for a modifier differ from those
 currently defined and any (current or new) keys for that modifier are
 logically in the down state, then the status reply is
-<emphasis role='bold'>Busy , </emphasis>
+<emphasis role='bold'>Busy</emphasis>,
 and none of the modifiers is changed.
 </para>
 <para>
 This request generates a
-<emphasis role='bold'>MappingNotify </emphasis>
+<emphasis role='bold'>MappingNotify</emphasis>
 event on a
-<emphasis role='bold'>Success </emphasis>
+<emphasis role='bold'>Success</emphasis>
 status.
 <!-- .sp -->
 </para>
@@ -11246,15 +11246,15 @@ The number of keycodes in the list is 8*keycodes-per-modifier.
 The keycodes are divided into eight sets,
 with each set containing keycodes-per-modifier elements.
 The sets are assigned to the modifiers
-<emphasis role='bold'>Shift ,</emphasis>
-<emphasis role='bold'>Lock ,</emphasis>
-<emphasis role='bold'>Control ,</emphasis>
-<emphasis role='bold'>Mod1 ,</emphasis>
-<emphasis role='bold'>Mod2 ,</emphasis>
-<emphasis role='bold'>Mod3 ,</emphasis>
-<emphasis role='bold'>Mod4 ,</emphasis>
+<emphasis role='bold'>Shift</emphasis>,
+<emphasis role='bold'>Lock</emphasis>,
+<emphasis role='bold'>Control</emphasis>,
+<emphasis role='bold'>Mod1</emphasis>,
+<emphasis role='bold'>Mod2</emphasis>,
+<emphasis role='bold'>Mod3</emphasis>,
+<emphasis role='bold'>Mod4</emphasis>,
 and
-<emphasis role='bold'>Mod5 ,</emphasis>
+<emphasis role='bold'>Mod5</emphasis>,
 in order.
 The keycodes-per-modifier value is chosen arbitrarily by the server;
 zeroes are used to fill in unused elements within each set.
@@ -11292,7 +11292,7 @@ The order of keycodes within each set is chosen arbitrarily by the server.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Alloc ,</emphasis>
+<emphasis role='bold'>Alloc</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -11308,11 +11308,11 @@ starting with the specified keycode.
 The symbols for keycodes outside this range remained unchanged.
 The number of elements in the keysyms list must be a multiple of
 keysyms-per-keycode (or a
-<emphasis role='bold'>Length </emphasis>
+<emphasis role='bold'>Length</emphasis>
 error results).
 The first-keycode must be greater than or equal to min-keycode as returned
 in the connection setup (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results) and:
 <!-- .DS -->
 first-keycode + (keysyms-length / keysyms-per-keycode) - 1
@@ -11321,7 +11321,7 @@ first-keycode + (keysyms-length / keysyms-per-keycode) - 1
 <para>
 must be less than or equal to max-keycode as returned in the connection
 setup (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 KEYSYM number N (counting from zero) for keycode K has an index
 (counting from zero) of:
@@ -11334,15 +11334,15 @@ in keysyms.
 The keysyms-per-keycode can be chosen arbitrarily by the client
 to be large enough to hold all desired symbols.
 A special KEYSYM value of
-<emphasis role='bold'>NoSymbol </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>
 should be used to fill in unused elements for individual keycodes.
 It is legal for
-<emphasis role='bold'>NoSymbol </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>
 to appear in nontrailing positions of the effective list for a keycode.
 </para>
 <para>
 This request generates a
-<emphasis role='bold'>MappingNotify </emphasis>
+<emphasis role='bold'>MappingNotify</emphasis>
 event.
 </para>
 <para>
@@ -11406,7 +11406,7 @@ This request returns the symbols for the specified number of keycodes,
 starting with the specified keycode.
 The first-keycode must be greater than or equal to
 min-keycode as returned in the connection setup (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results), and:
 <!-- .DS -->
 first-keycode + count - 1
@@ -11415,7 +11415,7 @@ first-keycode + count - 1
 <para>
 must be less than or equal to max-keycode as returned in the connection setup
 (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The number of elements in the keysyms list is:
 <!-- .DS -->
@@ -11434,7 +11434,7 @@ in keysyms.
 The keysyms-per-keycode value is chosen arbitrarily by the server
 to be large enough to report all requested symbols.
 A special KEYSYM value of
-<emphasis role='bold'>NoSymbol </emphasis>
+<emphasis role='bold'>NoSymbol</emphasis>
 is used to fill in unused elements for individual keycodes.
 <!-- .sp -->
 </para>
@@ -11534,7 +11534,7 @@ The key-click-percent sets the volume for key clicks between 0 (off) and
 100 (loud) inclusive, if possible.
 Setting to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 </para>
 <para>
@@ -11542,14 +11542,14 @@ The bell-percent sets the base volume for the bell between 0 (off) and 100
 (loud) inclusive, if possible.
 Setting to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 </para>
 <para>
 The bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
 Setting to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 </para>
 <para>
@@ -11557,7 +11557,7 @@ The bell-duration sets the duration of the bell (specified in milliseconds),
 if possible.
 Setting to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 </para>
 <para>
@@ -11568,7 +11568,7 @@ then the state of all LEDs are changed, if possible.
 At most 32 LEDs, numbered from one, are supported.
 No standard interpretation of LEDs is defined.
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error if an led is specified without an led-mode.
 </para>
 <para>
@@ -11578,22 +11578,22 @@ If only auto-repeat-mode is specified,
 then the global auto-repeat mode for the entire keyboard is changed,
 if possible, without affecting the per-key settings.
 It is a
-<emphasis role='bold'>Match </emphasis>
+<emphasis role='bold'>Match</emphasis>
 error if a key is specified without an auto-repeat-mode.
 Each key has an individual mode of whether or not it should auto-repeat
 and a default setting for that mode.
 In addition, there is a global mode of whether auto-repeat should be
 enabled or not and a default setting for that mode.
 When the global mode is
-<emphasis role='bold'>On ,</emphasis>
+<emphasis role='bold'>On</emphasis>,
 keys should obey their individual auto-repeat modes.
 When the global mode is
-<emphasis role='bold'>Off ,</emphasis>
+<emphasis role='bold'>Off</emphasis>,
 no keys should auto-repeat.
 An auto-repeating key generates alternating
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 and
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 events.
 When a key is used as a modifier,
 it is desirable for the key not to auto-repeat,
@@ -11651,8 +11651,8 @@ led-mask: CARD32
     <row rowsep='0'>
       <entry>
 global-auto-repeat:
-<emphasis role='bold'>{ On , </emphasis>
-<emphasis role='bold'>Off }</emphasis>
+<emphasis role='bold'>{ On</emphasis>,
+<emphasis role='bold'>Off</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -11710,7 +11710,7 @@ Errors:
 This request rings the bell on the keyboard at a volume relative to the
 base volume for the keyboard, if possible.
 Percent can range from -100 to 100 inclusive (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The volume at which the bell is rung when percent is nonnegative is:
 <!-- .DS -->
@@ -11748,8 +11748,8 @@ base + [(base * percent) / 100]
       <entry>
 <!-- .in +.2i -->
 status:
-<emphasis role='bold'>{ Success , </emphasis>
-<emphasis role='bold'>Busy }</emphasis>
+<emphasis role='bold'>{ Success</emphasis>,
+<emphasis role='bold'>Busy</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -11770,9 +11770,9 @@ Errors:
 This request sets the mapping of the pointer.
 Elements of the list are indexed starting from one.
 The length of the list must be the same as
-<emphasis role='bold'>GetPointerMapping </emphasis>
+<emphasis role='bold'>GetPointerMapping</emphasis>
 would return (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 The index is a core button number,
 and the element of the list defines the effective number.
@@ -11781,20 +11781,20 @@ and the element of the list defines the effective number.
 A zero element disables a button.
 Elements are not restricted in value by the number of physical buttons,
 but no two elements can have the same nonzero value (or a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error results).
 </para>
 <para>
 If any of the buttons to be altered are logically in the down state,
 the status reply is
-<emphasis role='bold'>Busy ,</emphasis>
+<emphasis role='bold'>Busy</emphasis>,
 and the mapping is not changed.
 </para>
 <para>
 This request generates a
-<emphasis role='bold'>MappingNotify </emphasis>
+<emphasis role='bold'>MappingNotify</emphasis>
 event on a
-<emphasis role='bold'>Success </emphasis>
+<emphasis role='bold'>Success</emphasis>
 status.
 <!-- .sp -->
 </para>
@@ -11880,7 +11880,7 @@ Acceleration only takes effect if the pointer moves more than threshold
 number of pixels at once and only applies to the amount beyond the threshold.
 Setting a value to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error, as does a zero value for acceleration-denominator.
 <!-- .sp -->
 </para>
@@ -11935,17 +11935,17 @@ This request returns the current acceleration and threshold for the pointer.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>prefer-blanking</emphasis>:
-<emphasis role='bold'>{ Yes , </emphasis>
-<emphasis role='bold'>No , </emphasis>
-<emphasis role='bold'>Default }</emphasis>
+<emphasis role='bold'>{ Yes</emphasis>,
+<emphasis role='bold'>No</emphasis>,
+<emphasis role='bold'>Default</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>allow-exposures</emphasis>:
-<emphasis role='bold'>{ Yes , </emphasis>
-<emphasis role='bold'>No , </emphasis>
-<emphasis role='bold'>Default }</emphasis>
+<emphasis role='bold'>{ Yes</emphasis>,
+<emphasis role='bold'>No</emphasis>,
+<emphasis role='bold'>Default</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -11966,7 +11966,7 @@ Errors:
 The timeout and interval are specified in seconds;
 setting a value to -1 restores the default.
 Other negative values generate a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 If the timeout value is zero,
 screen-saver is disabled (but an activated screen-saver is not deactivated).
@@ -11985,9 +11985,9 @@ the screen is changed in a server-dependent fashion to avoid phosphor burn.
 Otherwise,
 the state of the screens does not change, and screen-saver is not activated.
 At the next keyboard or pointer input or at the next
-<emphasis role='bold'>ForceScreenSaver </emphasis>
+<emphasis role='bold'>ForceScreenSaver</emphasis>
 with mode
-<emphasis role='bold'>Reset ,</emphasis>
+<emphasis role='bold'>Reset</emphasis>,
 screen-saver is deactivated, and all screen states are restored.
 </para>
 <para>
@@ -12022,15 +12022,15 @@ timeout, interval: CARD16
     <row rowsep='0'>
       <entry>
 prefer-blanking:
-<emphasis role='bold'>{ Yes , </emphasis>
-<emphasis role='bold'>No }</emphasis>
+<emphasis role='bold'>{ Yes</emphasis>,
+<emphasis role='bold'>No</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
       <entry>
 allow-exposures:
-<emphasis role='bold'>{ Yes , </emphasis>
-<emphasis role='bold'>No }</emphasis>
+<emphasis role='bold'>{ Yes</emphasis>,
+<emphasis role='bold'>No</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -12055,8 +12055,8 @@ This request returns the current screen-saver control values.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Activate , </emphasis>
-<emphasis role='bold'>Reset }</emphasis>
+<emphasis role='bold'>{ Activate</emphasis>,
+<emphasis role='bold'>Reset</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -12075,12 +12075,12 @@ Errors:
 <!-- .eM -->
 <para>
 If the mode is
-<emphasis role='bold'>Activate </emphasis>
+<emphasis role='bold'>Activate</emphasis>
 and screen-saver is currently deactivated,
 then screen-saver is activated (even if screen-saver has been disabled with
 a timeout value of zero).
 If the mode is
-<emphasis role='bold'>Reset </emphasis>
+<emphasis role='bold'>Reset</emphasis>
 and screen-saver is currently enabled,
 then screen-saver is deactivated (if it was activated),
 and the activation timer is reset to its initial state
@@ -12099,8 +12099,8 @@ as if device input had just been received.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Insert , </emphasis>
-<emphasis role='bold'>Delete }</emphasis>
+<emphasis role='bold'>{ Insert</emphasis>,
+<emphasis role='bold'>Delete</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -12113,7 +12113,7 @@ as if device input had just been received.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access , </emphasis>
+<emphasis role='bold'>Access</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -12134,7 +12134,7 @@ method, or the server will refuse the connection.
 <para>
 The client must reside on the same host as the server and/or have been granted
 permission by a server-dependent method to execute this request (or an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error results).
 </para>
 <para>
@@ -12147,7 +12147,7 @@ A server is not required to support these families
 and may support families not listed here.
 Use of an unsupported family, an improper address format,
 or an improper address length within a supported family results in a
-<emphasis role='bold'>Value </emphasis>
+<emphasis role='bold'>Value</emphasis>
 error.
 </para>
 <para>
@@ -12219,8 +12219,8 @@ or public key encryption, are recommended.
       <entry>
 <!-- .in +.2i -->
 mode:
-<emphasis role='bold'>{ Enabled , </emphasis>
-<emphasis role='bold'>Disabled }</emphasis>
+<emphasis role='bold'>{ Enabled</emphasis>,
+<emphasis role='bold'>Disabled</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -12255,8 +12255,8 @@ Each HOST is padded to a multiple of four bytes.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Enable , </emphasis>
-<emphasis role='bold'>Disable }</emphasis>
+<emphasis role='bold'>{ Enable</emphasis>,
+<emphasis role='bold'>Disable</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -12264,7 +12264,7 @@ Each HOST is padded to a multiple of four bytes.
       <entry>
 <!-- .in +.2i -->
 Errors:
-<emphasis role='bold'>Access ,</emphasis>
+<emphasis role='bold'>Access</emphasis>,
 <emphasis role='bold'>Value</emphasis>
 <!-- .in -.2i -->
 <!-- .eM -->
@@ -12282,7 +12282,7 @@ at connection setups.
 The client must reside on the same host as the server
 and/or have been granted permission by a server-dependent method
 to execute this request (or an
-<emphasis role='bold'>Access </emphasis>
+<emphasis role='bold'>Access</emphasis>
 error results).
 <!-- .sp -->
 </para>
@@ -12298,9 +12298,9 @@ error results).
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Destroy , </emphasis>
-<emphasis role='bold'>RetainPermanent , </emphasis>
-<emphasis role='bold'>RetainTemporary }</emphasis>
+<emphasis role='bold'>{ Destroy</emphasis>,
+<emphasis role='bold'>RetainPermanent</emphasis>,
+<emphasis role='bold'>RetainTemporary</emphasis>}
 <!-- .in -.2i -->
       </entry>
     </row>
@@ -12321,7 +12321,7 @@ Errors:
 This request defines what will happen to the client's resources
 at connection close.
 A connection starts in
-<emphasis role='bold'>Destroy </emphasis>
+<emphasis role='bold'>Destroy</emphasis>
 mode.
 The meaning of the close-down mode is described
 in <link linkend="connection_close">section 10</link>.
@@ -12358,19 +12358,19 @@ Errors:
 <!-- .eM -->
 <para>
 If a valid resource is specified,
-<emphasis role='bold'>KillClient </emphasis>
+<emphasis role='bold'>KillClient</emphasis>
 forces a close-down of the client that created the resource.
 If the client has already terminated in either
-<emphasis role='bold'>RetainPermanent </emphasis>
+<emphasis role='bold'>RetainPermanent</emphasis>
 or
-<emphasis role='bold'>RetainTemporary </emphasis>
+<emphasis role='bold'>RetainTemporary</emphasis>
 mode, all of the client's resources are destroyed
 (see <link linkend="connection_close">section 10</link>).
 If
-<emphasis role='bold'>AllTemporary </emphasis>
+<emphasis role='bold'>AllTemporary</emphasis>
 is specified,
 then the resources of all clients that have terminated in
-<emphasis role='bold'>RetainTemporary </emphasis>
+<emphasis role='bold'>RetainTemporary</emphasis>
 are destroyed.
 <!-- .sp -->
 </para>
@@ -12400,31 +12400,31 @@ to begin on 64-bit boundaries.
 At connection close,
 all event selections made by the client are discarded.
 If the client has the pointer actively grabbed, an
-<emphasis role='bold'>UngrabPointer </emphasis>
+<emphasis role='bold'>UngrabPointer</emphasis>
 is performed.
 If the client has the keyboard actively grabbed, an
-<emphasis role='bold'>UngrabKeyboard </emphasis>
+<emphasis role='bold'>UngrabKeyboard</emphasis>
 is performed.
 All passive grabs by the client are released.
 If the client has the server grabbed, an
-<emphasis role='bold'>UngrabServer </emphasis>
+<emphasis role='bold'>UngrabServer</emphasis>
 is performed.
 All selections (see
-<link linkend="requests:SetSelectionOwner"><emphasis role='bold'>SetSelectionOwner </emphasis></link>
+<link linkend="requests:SetSelectionOwner"><emphasis role='bold'>SetSelectionOwner</emphasis></link>
 request)
 owned by the client are disowned.
 If close-down mode (see
-<link linkend="requests:SetCloseDownMode"><emphasis role='bold'>SetCloseDownMode </emphasis></link>
+<link linkend="requests:SetCloseDownMode"><emphasis role='bold'>SetCloseDownMode</emphasis></link>
 request) is
-<emphasis role='bold'>RetainPermanent </emphasis>
+<emphasis role='bold'>RetainPermanent</emphasis>
 or
-<emphasis role='bold'>RetainTemporary , </emphasis>
+<emphasis role='bold'>RetainTemporary</emphasis>,
 then all resources (including colormap entries)
 allocated by the client are marked as permanent or temporary,
 respectively (but this does not prevent other clients from explicitly
 destroying them).
 If the mode is
-<emphasis role='bold'>Destroy , </emphasis>
+<emphasis role='bold'>Destroy</emphasis>,
 all of the client's resources are destroyed.
 </para>
 <para>
@@ -12434,7 +12434,7 @@ if the window is an inferior of a window created by the client,
 the save-set window is reparented to the closest ancestor such that
 the save-set window is not an inferior of a window created by the client.
 If the save-set window is unmapped, a
-<emphasis role='bold'>MapWindow </emphasis>
+<emphasis role='bold'>MapWindow</emphasis>
 request is performed on it (even if it was not an inferior
 of a window created by the client).
 The reparenting leaves unchanged the absolute coordinates
@@ -12444,7 +12444,7 @@ After save-set processing,
 all windows created by the client are destroyed.
 For each nonwindow resource created by the client,
 the appropriate
-<emphasis role='bold'>Free </emphasis>
+<emphasis role='bold'>Free</emphasis>
 request is performed.
 All colors and colormap entries allocated by the client are freed.
 </para>
@@ -12453,27 +12453,27 @@ A server goes through a cycle of having no connections and having some
 connections.
 At every transition to the state of having no connections
 as a result of a connection closing with a
-<emphasis role='bold'>Destroy </emphasis>
+<emphasis role='bold'>Destroy</emphasis>
 close-down mode,
 the server resets its state as if it had just been started.
 This starts by destroying all lingering resources from clients
 that have terminated in
-<emphasis role='bold'>RetainPermanent </emphasis>
+<emphasis role='bold'>RetainPermanent</emphasis>
 or
-<emphasis role='bold'>RetainTemporary </emphasis>
+<emphasis role='bold'>RetainTemporary</emphasis>
 mode.
 It additionally includes deleting all but the predefined atom identifiers,
 deleting all properties on all root windows, resetting all device maps and
 attributes (key click, bell volume, acceleration), resetting the access
 control list, restoring the standard root tiles and cursors, restoring
 the default font path, and restoring the input focus to state
-<emphasis role='bold'>PointerRoot .</emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>.
 </para>
 <para>
 Note that closing a connection with a close-down mode of
-<emphasis role='bold'>RetainPermanent </emphasis>
+<emphasis role='bold'>RetainPermanent</emphasis>
 or
-<emphasis role='bold'>RetainTemporary </emphasis>
+<emphasis role='bold'>RetainTemporary</emphasis>
 will not cause the server to reset.
 </para>
 </chapter>
@@ -12526,9 +12526,9 @@ Client's selected pointer events on the event window
     <row rowsep='0'>
       <entry>owner-events</entry>
       <entry>
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 if the client has
-<emphasis role='bold'>OwnerGrabButton </emphasis>
+<emphasis role='bold'>OwnerGrabButton</emphasis>
 selected on the event window, otherwise
 <emphasis role='bold'>False</emphasis>
       </entry>
@@ -12554,9 +12554,9 @@ selected on the event window, otherwise
 <para>
 The grab is terminated automatically when the logical state of the pointer
 has all buttons released.
-<emphasis role='bold'>UngrabPointer </emphasis>
+<emphasis role='bold'>UngrabPointer</emphasis>
 and
-<emphasis role='bold'>ChangeActivePointerGrab </emphasis>
+<emphasis role='bold'>ChangeActivePointerGrab</emphasis>
 can both be used to modify the active grab.
 <!-- .sp -->
 </para>
@@ -12642,9 +12642,9 @@ or when the pointer logically moves.
 The generation of these logical changes may lag the physical changes
 if device event processing is frozen.
 Note that
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 and
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 are generated for all keys, even those mapped to modifier bits.
 The source of the event is the window the pointer is in.
 The window the event is reported with respect to is called the event window.
@@ -12668,7 +12668,7 @@ If the source window is an inferior of the event window,
 then child is set to the child of the event window that is an
 ancestor of (or is) the source window.
 Otherwise, it is set to
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 The state component gives the logical state of the buttons and modifier keys
 just before the event.
 The detail component type varies with the event type:
@@ -12713,41 +12713,41 @@ The detail component type varies with the event type:
 </informaltable>
 
 <para>
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>
 events are only generated when the motion begins and ends in the window.
 The granularity of motion events is not guaranteed,
 but a client selecting for motion events is guaranteed to get at least one
 event when the pointer moves and comes to rest.
 Selecting
-<emphasis role='bold'>PointerMotion </emphasis>
+<emphasis role='bold'>PointerMotion</emphasis>
 receives events independent of the state of the pointer buttons.
 By selecting some subset of
-<emphasis role='bold'>Button[1-5]Motion </emphasis>
+<emphasis role='bold'>Button[1-5]Motion</emphasis>
 instead,
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>
 events will only be received when one or more of the
 specified buttons are pressed.
 By selecting
-<emphasis role='bold'>ButtonMotion , </emphasis>
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>ButtonMotion</emphasis>,
+<emphasis role='bold'>MotionNotify</emphasis>
 events will be received only when at least one button is pressed.
 The events are always of type
-<emphasis role='bold'>MotionNotify , </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>,
 independent of the selection.
 If
-<emphasis role='bold'>PointerMotionHint </emphasis>
+<emphasis role='bold'>PointerMotionHint</emphasis>
 is selected,
 the server is free to send only one
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>
 event (with detail
-<emphasis role='bold'>Hint ) </emphasis>
+<emphasis role='bold'>Hint</emphasis>)
 to the client for the event window until
 either the key or button state changes,
 the pointer leaves the event window,
 or the client issues a
-<emphasis role='bold'>QueryPointer </emphasis>
+<emphasis role='bold'>QueryPointer</emphasis>
 or
-<emphasis role='bold'>GetMotionEvents </emphasis>
+<emphasis role='bold'>GetMotionEvents</emphasis>
 request.
 <!-- .sp -->
 </para>
@@ -12790,19 +12790,19 @@ request.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Normal , </emphasis>
-<emphasis role='bold'>Grab , </emphasis>
-<emphasis role='bold'>Ungrab }</emphasis>
+<emphasis role='bold'>{ Normal</emphasis>,
+<emphasis role='bold'>Grab</emphasis>,
+<emphasis role='bold'>Ungrab</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>detail</emphasis>:
-<emphasis role='bold'>{ Ancestor , </emphasis>
-<emphasis role='bold'>Virtual ,</emphasis>
-<emphasis role='bold'>Inferior , </emphasis>
-<emphasis role='bold'>Nonlinear , </emphasis>
-<emphasis role='bold'>NonlinearVirtual }</emphasis>
+<emphasis role='bold'>{ Ancestor</emphasis>,
+<emphasis role='bold'>Virtual</emphasis>,
+<emphasis role='bold'>Inferior</emphasis>,
+<emphasis role='bold'>Nonlinear</emphasis>,
+<emphasis role='bold'>NonlinearVirtual</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -12829,20 +12829,20 @@ request.
 <para>
 If pointer motion or window hierarchy change causes the pointer to be
 in a different window than before,
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events are generated instead of a
-<emphasis role='bold'>MotionNotify </emphasis>
+<emphasis role='bold'>MotionNotify</emphasis>
 event.
 Only clients selecting
-<emphasis role='bold'>EnterWindow </emphasis>
+<emphasis role='bold'>EnterWindow</emphasis>
 on a window receive
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 events, and only clients selecting
-<emphasis role='bold'>LeaveWindow </emphasis>
+<emphasis role='bold'>LeaveWindow</emphasis>
 receive
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events.
 The pointer position reported in the event is always the final position,
 not the initial position of the pointer.
@@ -12855,52 +12855,52 @@ then event-x and event-y are the pointer coordinates relative
 to the event window's origin.
 Otherwise, event-x and event-y are zero.
 In a
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 event, if a child of the event window contains the initial position of the
 pointer, then the child component is set to that child.
 Otherwise, it is
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 For an
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 event, if a child of the event window contains the final pointer position,
 then the child component is set to that child.
 Otherwise, it is
-<emphasis role='bold'>None .</emphasis>
+<emphasis role='bold'>None</emphasis>.
 If the event window is the focus window or an inferior of the focus window,
 then focus is
-<emphasis role='bold'>True .</emphasis>
+<emphasis role='bold'>True</emphasis>.
 Otherwise, focus is
-<emphasis role='bold'>False .</emphasis>
+<emphasis role='bold'>False</emphasis>.
 </para>
 <para>
 Normal pointer motion events have mode
-<emphasis role='bold'>Normal .</emphasis>
+<emphasis role='bold'>Normal</emphasis>.
 Pseudo-motion events when a grab activates have mode
-<emphasis role='bold'>Grab , </emphasis>
+<emphasis role='bold'>Grab</emphasis>,
 and pseudo-motion events when a grab deactivates have mode
-<emphasis role='bold'>Ungrab .</emphasis>
+<emphasis role='bold'>Ungrab</emphasis>.
 </para>
 <para>
 All
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events caused by a hierarchy change are generated after any hierarchy event
 caused by that change (that is,
-<emphasis role='bold'>UnmapNotify , </emphasis>
-<emphasis role='bold'>MapNotify ,</emphasis>
-<emphasis role='bold'>ConfigureNotify , </emphasis>
-<emphasis role='bold'>GravityNotify , </emphasis>
-<emphasis role='bold'>CirculateNotify ),</emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>,
+<emphasis role='bold'>MapNotify</emphasis>,
+<emphasis role='bold'>ConfigureNotify</emphasis>,
+<emphasis role='bold'>GravityNotify</emphasis>,
+<emphasis role='bold'>CirculateNotify</emphasis>),
 but the ordering of
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events with respect to
-<emphasis role='bold'>FocusOut , </emphasis>
-<emphasis role='bold'>VisibilityNotify , </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>,
+<emphasis role='bold'>VisibilityNotify</emphasis>,
 and
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events is not constrained.
 </para>
 <para>
@@ -12915,25 +12915,25 @@ of B:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>Ancestor </emphasis>
+<emphasis role='bold'>Ancestor</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>Virtual </emphasis>
+<emphasis role='bold'>Virtual</emphasis>
 is generated on each window between A and B exclusive (in that order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>Inferior </emphasis>
+<emphasis role='bold'>Inferior</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -12948,25 +12948,25 @@ of A:
   <listitem>
     <para>
 <!-- .IP bu 5 -->
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>Inferior </emphasis>
+<emphasis role='bold'>Inferior</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>Virtual </emphasis>
+<emphasis role='bold'>Virtual</emphasis>
 is generated on each window between A and B exclusive (in that order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>Ancestor </emphasis>
+<emphasis role='bold'>Ancestor</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -12980,33 +12980,33 @@ their least common ancestor:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window between A and C exclusive (in that order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window between C and B exclusive (in that order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -13019,36 +13019,36 @@ When the pointer moves from window A to window B on different screens:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
 If A is not a root window,
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window above A up to and including its root (in order).
     </para>
   </listitem>
   <listitem>
     <para>
 If B is not a root window,
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window from B's root down to but not including B
 (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -13057,7 +13057,7 @@ is generated on B.
 <para>
 When a pointer grab activates (but after any initial warp into a confine-to
 window and before generating any actual
-<emphasis role='bold'>ButtonPress </emphasis>
+<emphasis role='bold'>ButtonPress</emphasis>
 event that activates the grab),
 G is the grab-window for the grab, and P is the window the pointer is in:
 </para>
@@ -13065,13 +13065,13 @@ G is the grab-window for the grab, and P is the window the pointer is in:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events with mode
-<emphasis role='bold'>Grab </emphasis>
+<emphasis role='bold'>Grab</emphasis>
 are generated (as for
-<emphasis role='bold'>Normal </emphasis>
+<emphasis role='bold'>Normal</emphasis>
 above) as if the pointer were to suddenly warp from its current
 position in P to some position in G.
 However, the pointer does not warp,
@@ -13083,7 +13083,7 @@ and final positions for the events.
 
 <para>
 When a pointer grab deactivates (but after generating any actual
-<emphasis role='bold'>ButtonRelease </emphasis>
+<emphasis role='bold'>ButtonRelease</emphasis>
 event that deactivates the grab), G is the grab-window for
 the grab, and P is the window the pointer is in:
 </para>
@@ -13091,13 +13091,13 @@ the grab, and P is the window the pointer is in:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events with mode
-<emphasis role='bold'>Ungrab </emphasis>
+<emphasis role='bold'>Ungrab</emphasis>
 are generated (as for
-<emphasis role='bold'>Normal </emphasis>
+<emphasis role='bold'>Normal</emphasis>
 above) as if the pointer were to suddenly warp from
 some position in G to its current position in P.
 However, the pointer does not warp,
@@ -13129,10 +13129,10 @@ and final positions for the events.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>mode</emphasis>:
-<emphasis role='bold'>{ Normal , </emphasis>
-<emphasis role='bold'>WhileGrabbed , </emphasis>
-<emphasis role='bold'>Grab , </emphasis>
-<emphasis role='bold'>Ungrab }</emphasis>
+<emphasis role='bold'>{ Normal</emphasis>,
+<emphasis role='bold'>WhileGrabbed</emphasis>,
+<emphasis role='bold'>Grab</emphasis>,
+<emphasis role='bold'>Ungrab</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -13161,40 +13161,40 @@ and final positions for the events.
 <para>
 These events are generated when the input focus changes
 and are reported to clients selecting
-<emphasis role='bold'>FocusChange </emphasis>
+<emphasis role='bold'>FocusChange</emphasis>
 on the window.
 Events generated by
-<emphasis role='bold'>SetInputFocus </emphasis>
+<emphasis role='bold'>SetInputFocus</emphasis>
 when the keyboard is not grabbed have mode
-<emphasis role='bold'>Normal .</emphasis>
+<emphasis role='bold'>Normal</emphasis>.
 Events generated by
-<emphasis role='bold'>SetInputFocus </emphasis>
+<emphasis role='bold'>SetInputFocus</emphasis>
 when the keyboard is grabbed have mode
-<emphasis role='bold'>WhileGrabbed .</emphasis>
+<emphasis role='bold'>WhileGrabbed</emphasis>.
 Events generated when a keyboard grab activates have mode
-<emphasis role='bold'>Grab , </emphasis>
+<emphasis role='bold'>Grab</emphasis>,
 and events generated when a keyboard grab deactivates have mode
-<emphasis role='bold'>Ungrab .</emphasis>
+<emphasis role='bold'>Ungrab</emphasis>.
 </para>
 <para>
 All
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events caused by a window unmap are generated after any
-<emphasis role='bold'>UnmapNotify </emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>
 event, but the ordering of
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with respect to generated
-<emphasis role='bold'>EnterNotify , </emphasis>
-<emphasis role='bold'>LeaveNotify , </emphasis>
-<emphasis role='bold'>VisibilityNotify , </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>,
+<emphasis role='bold'>LeaveNotify</emphasis>,
+<emphasis role='bold'>VisibilityNotify</emphasis>,
 and
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events is not constrained.
 </para>
 <para>
-<emphasis role='bold'>Normal </emphasis>
+<emphasis role='bold'>Normal</emphasis>
 and
-<emphasis role='bold'>WhileGrabbed </emphasis>
+<emphasis role='bold'>WhileGrabbed</emphasis>
 events are generated as follows:
 </para>
 <para>
@@ -13205,25 +13205,25 @@ and the pointer is in window P:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Ancestor </emphasis>
+<emphasis role='bold'>Ancestor</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Virtual </emphasis>
+<emphasis role='bold'>Virtual</emphasis>
 is generated on each window between A and B exclusive (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Inferior </emphasis>
+<emphasis role='bold'>Inferior</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -13231,9 +13231,9 @@ is generated on B.
     <para>
 If P is an inferior of B
 but P is not A or an inferior of A or an ancestor of A,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window below B down to and including P (in order).
     </para>
   </listitem>
@@ -13250,33 +13250,33 @@ and the pointer is in window P:
     <para>
 If P is an inferior of A
 but P is not an inferior of B or an ancestor of B,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to but not including A (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Inferior </emphasis>
+<emphasis role='bold'>Inferior</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Virtual </emphasis>
+<emphasis role='bold'>Virtual</emphasis>
 is generated on each window between A and B exclusive (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Ancestor </emphasis>
+<emphasis role='bold'>Ancestor</emphasis>
 is generated on B.
     </para>
   </listitem>
@@ -13291,50 +13291,50 @@ least common ancestor, and the pointer is in window P:
   <listitem>
     <para>
 If P is an inferior of A,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to but not including A (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window between A and C exclusive (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window between C and B exclusive (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on B.
     </para>
   </listitem>
   <listitem>
     <para>
 If P is an inferior of B,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window below B down to and including P (in order).
     </para>
   </listitem>
@@ -13350,53 +13350,53 @@ and the pointer is in window P:
   <listitem>
     <para>
 If P is an inferior of A,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to but not including A (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
 If A is not a root window,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window above A up to and including its root (in order).
     </para>
   </listitem>
   <listitem>
     <para>
 If B is not a root window,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window from B's root down to but not including B
 (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on B.
     </para>
   </listitem>
   <listitem>
     <para>
 If P is an inferior of B,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window below B down to and including P (in order).
     </para>
   </listitem>
@@ -13404,9 +13404,9 @@ is generated on each window below B down to and including P (in order).
 
 <para>
 When the focus moves from window A to
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 (or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 and the pointer is in window P:
 </para>
 
@@ -13415,46 +13415,46 @@ and the pointer is in window P:
   <listitem>
     <para>
 If P is an inferior of A,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to but not including A (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
 If A is not a root window,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window above A up to and including its root (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 (or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 is generated on all root windows.
     </para>
   </listitem>
   <listitem>
     <para>
 If the new focus is
-<emphasis role='bold'>PointerRoot , </emphasis>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>,
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P's root down to and including P (in order).
     </para>
   </listitem>
@@ -13462,9 +13462,9 @@ is generated on each window from P's root down to and including P (in order).
 
 <para>
 When the focus moves from
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 (or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 to window A and the pointer is in window P:
 </para>
 
@@ -13476,44 +13476,44 @@ If the old focus is
 <emphasis role='bold'>PointerRoot</emphasis>,
 <emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to and including P's root (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 (or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 is generated on all root windows.
     </para>
   </listitem>
   <listitem>
     <para>
 If A is not a root window,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>NonlinearVirtual </emphasis>
+<emphasis role='bold'>NonlinearVirtual</emphasis>
 is generated on each window from A's root down to but not including A
 (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Nonlinear </emphasis>
+<emphasis role='bold'>Nonlinear</emphasis>
 is generated on A.
     </para>
   </listitem>
   <listitem>
     <para>
 If P is an inferior of A,
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window below A down to and including P (in order).
     </para>
   </listitem>
@@ -13521,9 +13521,9 @@ is generated on each window below A down to and including P (in order).
 
 <para>
 When the focus moves from
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 to
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 (or vice versa) and the pointer is in window P:
 </para>
 
@@ -13532,39 +13532,39 @@ to
     <para>
 If the old focus is
 <emphasis role='bold'>PointerRoot</emphasis>,
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P up to and including P's root (in order).
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 with detail
-<emphasis role='bold'>PointerRoot </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>
 (or
-<emphasis role='bold'>None ) </emphasis>
+<emphasis role='bold'>None</emphasis>)
 is generated on all root windows.
     </para>
   </listitem>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 (or
-<emphasis role='bold'>PointerRoot ) </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>)
 is generated on all root windows.
     </para>
   </listitem>
   <listitem>
     <para>
 If the new focus is
-<emphasis role='bold'>PointerRoot , </emphasis>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>PointerRoot</emphasis>,
+<emphasis role='bold'>FocusIn</emphasis>
 with detail
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 is generated on each window from P's root down to and including P (in order).
     </para>
   </listitem>
@@ -13573,7 +13573,7 @@ is generated on each window from P's root down to and including P (in order).
 
 <para>
 When a keyboard grab activates (but before generating any actual
-<emphasis role='bold'>KeyPress </emphasis>
+<emphasis role='bold'>KeyPress</emphasis>
 event that activates the grab), G is the grab-window for the grab,
 and F is the current focus:
 </para>
@@ -13581,13 +13581,13 @@ and F is the current focus:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events with mode
-<emphasis role='bold'>Grab </emphasis>
+<emphasis role='bold'>Grab</emphasis>
 are generated (as for
-<emphasis role='bold'>Normal </emphasis>
+<emphasis role='bold'>Normal</emphasis>
 above) as if the focus were to change from F to G.
     </para>
   </listitem>
@@ -13595,7 +13595,7 @@ above) as if the focus were to change from F to G.
 
 <para>
 When a keyboard grab deactivates (but after generating any actual
-<emphasis role='bold'>KeyRelease </emphasis>
+<emphasis role='bold'>KeyRelease</emphasis>
 event that deactivates the grab), G is the grab-window for the grab,
 and F is the current focus:
 </para>
@@ -13603,13 +13603,13 @@ and F is the current focus:
 <itemizedlist>
   <listitem>
     <para>
-<emphasis role='bold'>FocusIn </emphasis>
+<emphasis role='bold'>FocusIn</emphasis>
 and
-<emphasis role='bold'>FocusOut </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>
 events with mode
-<emphasis role='bold'>Ungrab </emphasis>
+<emphasis role='bold'>Ungrab</emphasis>
 are generated (as for
-<emphasis role='bold'>Normal </emphasis>
+<emphasis role='bold'>Normal</emphasis>
 above) as if the focus were to change from G to F.
     </para>
   </listitem>
@@ -13635,13 +13635,13 @@ above) as if the focus were to change from G to F.
 
 <para>
 The value is a bit vector as described in
-<emphasis role='bold'>QueryKeymap .</emphasis>
+<emphasis role='bold'>QueryKeymap</emphasis>.
 This event is reported to clients selecting
-<emphasis role='bold'>KeymapState </emphasis>
+<emphasis role='bold'>KeymapState</emphasis>
 on a window and is generated immediately after every
-<emphasis role='bold'>EnterNotify </emphasis>
+<emphasis role='bold'>EnterNotify</emphasis>
 and
-<emphasis role='bold'>FocusIn .</emphasis>
+<emphasis role='bold'>FocusIn</emphasis>.
 <!-- .sp -->
 </para>
 <para id="events:Expose">
@@ -13678,19 +13678,19 @@ and
 </informaltable>
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>Exposure </emphasis>
+<emphasis role='bold'>Exposure</emphasis>
 on the window.
 It is generated when no valid contents are available for regions of a window,
 and either the regions are visible, the regions are viewable
 and the server is (perhaps newly) maintaining backing store on the window,
 or the window is not viewable but the server is (perhaps newly) honoring
 window's backing-store attribute of
-<emphasis role='bold'>Always </emphasis>
+<emphasis role='bold'>Always</emphasis>
 or
-<emphasis role='bold'>WhenMapped .</emphasis>
+<emphasis role='bold'>WhenMapped</emphasis>.
 The regions are decomposed into an arbitrary set of rectangles,
 and an
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 event is generated for each rectangle.
 </para>
 <para>
@@ -13698,11 +13698,11 @@ For a given action causing exposure events,
 the set of events for a given window are guaranteed to be reported contiguously.
 If count is zero,
 then no more
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events for this window follow.
 If count is nonzero,
 then at least that many more
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events for this window follow (and possibly more).
 </para>
 <para>
@@ -13711,38 +13711,38 @@ and specify the upper-left corner of a rectangle.
 The width and height specify the extent of the rectangle.
 </para>
 <para>
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events are never generated on
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows.
 </para>
 <para>
 All
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events caused by a hierarchy change are generated after any
 hierarchy event caused by that change (for example,
-<emphasis role='bold'>UnmapNotify , </emphasis>
-<emphasis role='bold'>MapNotify , </emphasis>
-<emphasis role='bold'>ConfigureNotify ,</emphasis>
-<emphasis role='bold'>GravityNotify , </emphasis>
-<emphasis role='bold'>CirculateNotify ).</emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>,
+<emphasis role='bold'>MapNotify</emphasis>,
+<emphasis role='bold'>ConfigureNotify</emphasis>,
+<emphasis role='bold'>GravityNotify</emphasis>,
+<emphasis role='bold'>CirculateNotify</emphasis>).
 All
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events on a given window are generated after any
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 event on that window,
 but it is not required that all
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events on all windows be generated after all
-<emphasis role='bold'>Visibilitity </emphasis>
+<emphasis role='bold'>Visibilitity</emphasis>
 events on all windows.
 The ordering of
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events with respect to
-<emphasis role='bold'>FocusOut , </emphasis>
-<emphasis role='bold'>EnterNotify , </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>,
+<emphasis role='bold'>EnterNotify</emphasis>,
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events is not constrained.
 <!-- .sp -->
 </para>
@@ -13794,11 +13794,11 @@ to an obscured or out-of-bounds source region.
 All of the regions exposed by a given graphics request
 are guaranteed to be reported contiguously.
 If count is zero then no more
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 events for this window follow.
 If count is nonzero,
 then at least that many more
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 events for this window follow (and possibly more).
 </para>
 <para>
@@ -13810,9 +13810,9 @@ The width and height specify the extent of the rectangle.
 The major and minor opcodes identify the graphics request used.
 For the core protocol,
 major-opcode is always
-<emphasis role='bold'>CopyArea </emphasis>
+<emphasis role='bold'>CopyArea</emphasis>
 or
-<emphasis role='bold'>CopyPlane ,</emphasis>
+<emphasis role='bold'>CopyPlane</emphasis>,
 and minor-opcode is always zero.
 <!-- .sp -->
 </para>
@@ -13851,7 +13851,7 @@ This event is reported to a client using a graphics context
 with graphics-exposures selected
 and is generated when a graphics request
 that might produce
-<emphasis role='bold'>GraphicsExposure </emphasis>
+<emphasis role='bold'>GraphicsExposure</emphasis>
 events does not produce any.
 The drawable specifies the destination used for the graphics request.
 </para>
@@ -13859,9 +13859,9 @@ The drawable specifies the destination used for the graphics request.
 The major and minor opcodes identify the graphics request used.
 For the core protocol,
 major-opcode is always
-<emphasis role='bold'>CopyArea </emphasis>
+<emphasis role='bold'>CopyArea</emphasis>
 or
-<emphasis role='bold'>CopyPlane ,</emphasis>
+<emphasis role='bold'>CopyPlane</emphasis>,
 and the minor-opcode is always zero.
 <!-- .sp -->
 </para>
@@ -13882,9 +13882,9 @@ and the minor-opcode is always zero.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>state</emphasis>:
-<emphasis role='bold'>{ Unobscured , </emphasis>
-<emphasis role='bold'>PartiallyObscured , </emphasis>
-<emphasis role='bold'>FullyObscured }</emphasis>
+<emphasis role='bold'>{ Unobscured</emphasis>,
+<emphasis role='bold'>PartiallyObscured</emphasis>,
+<emphasis role='bold'>FullyObscured</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -13895,61 +13895,61 @@ and the minor-opcode is always zero.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>VisibilityChange </emphasis>
+<emphasis role='bold'>VisibilityChange</emphasis>
 on the window.
 In the following,
 the state of the window is calculated ignoring all of the window's subwindows.
 When a window changes state from partially or fully obscured or
 not viewable to viewable and completely unobscured,
 an event with
-<emphasis role='bold'>Unobscured </emphasis>
+<emphasis role='bold'>Unobscured</emphasis>
 is generated.
 When a window changes state from viewable and completely unobscured,
 from viewable and completely obscured,
 or from not viewable, to viewable and partially obscured,
 an event with
-<emphasis role='bold'>PartiallyObscured </emphasis>
+<emphasis role='bold'>PartiallyObscured</emphasis>
 is generated.
 When a window changes state from viewable and completely unobscured,
 from viewable and partially obscured,
 or from not viewable to viewable and fully obscured,
 an event with
-<emphasis role='bold'>FullyObscured </emphasis>
+<emphasis role='bold'>FullyObscured</emphasis>
 is generated.
 </para>
 <para>
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 events are never generated on
-<emphasis role='bold'>InputOnly </emphasis>
+<emphasis role='bold'>InputOnly</emphasis>
 windows.
 </para>
 <para>
 All
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 events caused by a hierarchy change are generated after any hierarchy event
 caused by that change (for example,
-<emphasis role='bold'>UnmapNotify , </emphasis>
-<emphasis role='bold'>MapNotify , </emphasis>
-<emphasis role='bold'>ConfigureNotify ,</emphasis>
-<emphasis role='bold'>GravityNotify , </emphasis>
-<emphasis role='bold'>CirculateNotify ).</emphasis>
+<emphasis role='bold'>UnmapNotify</emphasis>,
+<emphasis role='bold'>MapNotify</emphasis>,
+<emphasis role='bold'>ConfigureNotify</emphasis>,
+<emphasis role='bold'>GravityNotify</emphasis>,
+<emphasis role='bold'>CirculateNotify</emphasis>).
 Any
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 event on a given window is generated before any
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events on that window,
 but it is not required that all
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 events on all windows be generated before all
-<emphasis role='bold'>Expose </emphasis>
+<emphasis role='bold'>Expose</emphasis>
 events on all windows.
 The ordering of
-<emphasis role='bold'>VisibilityNotify </emphasis>
+<emphasis role='bold'>VisibilityNotify</emphasis>
 events with respect to
-<emphasis role='bold'>FocusOut , </emphasis>
-<emphasis role='bold'>EnterNotify , </emphasis>
+<emphasis role='bold'>FocusOut</emphasis>,
+<emphasis role='bold'>EnterNotify</emphasis>,
 and
-<emphasis role='bold'>LeaveNotify </emphasis>
+<emphasis role='bold'>LeaveNotify</emphasis>
 events is not constrained.
 <!-- .sp -->
 </para>
@@ -13990,11 +13990,11 @@ events is not constrained.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent
 and is generated when the window is created.
 The arguments are as in the
-<emphasis role='bold'>CreateWindow </emphasis>
+<emphasis role='bold'>CreateWindow</emphasis>
 request.
 <!-- .sp -->
 </para>
@@ -14020,9 +14020,9 @@ request.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window and to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent.
 It is generated when the window is destroyed.
 The event is the window on which the event was generated,
@@ -14030,9 +14030,9 @@ and the window is the window that is destroyed.
 </para>
 <para>
 The ordering of the
-<emphasis role='bold'>DestroyNotify </emphasis>
+<emphasis role='bold'>DestroyNotify</emphasis>
 events is such that for any given window,
-<emphasis role='bold'>DestroyNotify </emphasis>
+<emphasis role='bold'>DestroyNotify</emphasis>
 is generated on all inferiors of the window
 before being generated on the window itself.
 The ordering among siblings and across subhierarchies is not
@@ -14066,18 +14066,18 @@ otherwise constrained.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window and to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent.
 It is generated when the window changes state from mapped to unmapped.
 The event is the window on which the event was generated,
 and the window is the window that is unmapped.
 The from-configure flag is
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 if the event was generated as a result of the window's parent being resized
 when the window itself had a win-gravity of
-<emphasis role='bold'>Unmap .</emphasis>
+<emphasis role='bold'>Unmap</emphasis>.
 <!-- .sp -->
 </para>
 <para id="events:MapNotify">
@@ -14107,9 +14107,9 @@ when the window itself had a win-gravity of
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window and to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent.
 It is generated when the window changes state from unmapped to mapped.
 The event is the window on which the event was generated,
@@ -14139,11 +14139,11 @@ The override-redirect flag is from the window's attribute.
 <!-- .eM -->
 <para>
 This event is reported to the client selecting
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent and is generated when a
-<emphasis role='bold'>MapWindow </emphasis>
+<emphasis role='bold'>MapWindow</emphasis>
 request is issued on an unmapped window with an override-redirect attribute of
-<emphasis role='bold'>False .</emphasis>
+<emphasis role='bold'>False</emphasis>.
 <!-- .sp -->
 </para>
 <para id="events:ReparentNotify">
@@ -14178,9 +14178,9 @@ request is issued on an unmapped window with an override-redirect attribute of
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on either the old or the new parent and to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window.
 It is generated when the window is reparented.
 The event is the window on which the event was generated.
@@ -14234,12 +14234,12 @@ The override-redirect flag is from the window's attribute.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window and to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent.
 It is generated when a
-<emphasis role='bold'>ConfigureWindow </emphasis>
+<emphasis role='bold'>ConfigureWindow</emphasis>
 request actually changes the state of the window.
 The event is the window on which the event was generated,
 and the window is the window that is changed.
@@ -14247,7 +14247,7 @@ The x and y coordinates are relative to the new parent's origin
 and specify the position of the upper-left outer corner of the window.
 The width and height specify the inside size, not including the border.
 If above-sibling is
-<emphasis role='bold'>None , </emphasis>
+<emphasis role='bold'>None</emphasis>,
 then the window is on the bottom of the stack with respect to siblings.
 Otherwise, the window is immediately on top of the specified sibling.
 The override-redirect flag is from the window's attribute.
@@ -14280,9 +14280,9 @@ The override-redirect flag is from the window's attribute.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent and to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window.
 It is generated when a window is moved because of a change in size
 of the parent.
@@ -14319,9 +14319,9 @@ and specify the position of the upper-left outer corner of the window.
 <!-- .eM -->
 <para>
 This event is reported to the client selecting
-<emphasis role='bold'>ResizeRedirect </emphasis>
+<emphasis role='bold'>ResizeRedirect</emphasis>
 on the window and is generated when a
-<emphasis role='bold'>ConfigureWindow </emphasis>
+<emphasis role='bold'>ConfigureWindow</emphasis>
 request by some other client on the window attempts to change the size
 of the window.
 The width and height are the requested inside size, not including the border.
@@ -14360,11 +14360,11 @@ The width and height are the requested inside size, not including the border.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>stack-mode</emphasis>:
-<emphasis role='bold'>{ Above , </emphasis>
-<emphasis role='bold'>Below , </emphasis>
-<emphasis role='bold'>TopIf , </emphasis>
-<emphasis role='bold'>BottomIf , </emphasis>
-<emphasis role='bold'>Opposite }</emphasis>
+<emphasis role='bold'>{ Above</emphasis>,
+<emphasis role='bold'>Below</emphasis>,
+<emphasis role='bold'>TopIf</emphasis>,
+<emphasis role='bold'>BottomIf</emphasis>,
+<emphasis role='bold'>Opposite</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -14380,9 +14380,9 @@ The width and height are the requested inside size, not including the border.
 <!-- .eM -->
 <para>
 This event is reported to the client selecting
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent and is generated when a
-<emphasis role='bold'>ConfigureWindow </emphasis>
+<emphasis role='bold'>ConfigureWindow</emphasis>
 request is issued on the window by some other client.
 The value-mask indicates which components were specified in the request.
 The value-mask and the corresponding values are reported as given
@@ -14390,9 +14390,9 @@ in the request.
 The remaining values are filled in from the current geometry of the window,
 except in the case of sibling and stack-mode,
 which are reported as
-<emphasis role='bold'>None </emphasis>
+<emphasis role='bold'>None</emphasis>
 and
-<emphasis role='bold'>Above </emphasis>
+<emphasis role='bold'>Above</emphasis>
 (respectively) if not given in the request.
 <!-- .sp -->
 </para>
@@ -14413,8 +14413,8 @@ and
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>place</emphasis>:
-<emphasis role='bold'>{ Top , </emphasis>
-<emphasis role='bold'>Bottom }</emphasis>
+<emphasis role='bold'>{ Top</emphasis>,
+<emphasis role='bold'>Bottom</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -14425,17 +14425,17 @@ and
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>StructureNotify </emphasis>
+<emphasis role='bold'>StructureNotify</emphasis>
 on the window and to clients selecting
-<emphasis role='bold'>SubstructureNotify </emphasis>
+<emphasis role='bold'>SubstructureNotify</emphasis>
 on the parent.
 It is generated when the window is actually restacked from a
-<emphasis role='bold'>CirculateWindow </emphasis>
+<emphasis role='bold'>CirculateWindow</emphasis>
 request.
 The event is the window on which the event was generated,
 and the window is the window that is restacked.
 If place is
-<emphasis role='bold'>Top , </emphasis>
+<emphasis role='bold'>Top</emphasis>,
 the window is now on top of all siblings.
 Otherwise, it is below all siblings.
 <!-- .sp -->
@@ -14457,8 +14457,8 @@ Otherwise, it is below all siblings.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>place</emphasis>:
-<emphasis role='bold'>{ Top , </emphasis>
-<emphasis role='bold'>Bottom }</emphasis>
+<emphasis role='bold'>{ Top</emphasis>,
+<emphasis role='bold'>Bottom</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -14469,9 +14469,9 @@ Otherwise, it is below all siblings.
 <!-- .eM -->
 <para>
 This event is reported to the client selecting
-<emphasis role='bold'>SubstructureRedirect </emphasis>
+<emphasis role='bold'>SubstructureRedirect</emphasis>
 on the parent and is generated when a
-<emphasis role='bold'>CirculateWindow </emphasis>
+<emphasis role='bold'>CirculateWindow</emphasis>
 request is issued on the parent and a window actually needs to be restacked.
 The window specifies the window to be restacked,
 and the place specifies what the new position in the stacking order should be.
@@ -14499,8 +14499,8 @@ and the place specifies what the new position in the stacking order should be.
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>state</emphasis>:
-<emphasis role='bold'>{ NewValue , </emphasis>
-<emphasis role='bold'>Deleted }</emphasis>
+<emphasis role='bold'>{ NewValue</emphasis>,
+<emphasis role='bold'>Deleted</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -14516,26 +14516,26 @@ and the place specifies what the new position in the stacking order should be.
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>PropertyChange </emphasis>
+<emphasis role='bold'>PropertyChange</emphasis>
 on the window and is generated with state
-<emphasis role='bold'>NewValue </emphasis>
+<emphasis role='bold'>NewValue</emphasis>
 when a property of the window is changed using
-<emphasis role='bold'>ChangeProperty </emphasis>
+<emphasis role='bold'>ChangeProperty</emphasis>
 or
-<emphasis role='bold'>RotateProperties ,</emphasis>
+<emphasis role='bold'>RotateProperties</emphasis>,
 even when adding zero-length data using
-<emphasis role='bold'>ChangeProperty </emphasis>
+<emphasis role='bold'>ChangeProperty</emphasis>
 and when replacing all or part of a property with identical data using
-<emphasis role='bold'>ChangeProperty </emphasis>
+<emphasis role='bold'>ChangeProperty</emphasis>
 or
-<emphasis role='bold'>RotateProperties .</emphasis>
+<emphasis role='bold'>RotateProperties</emphasis>.
 It is generated with state
-<emphasis role='bold'>Deleted </emphasis>
+<emphasis role='bold'>Deleted</emphasis>
 when a property of the
 window is deleted using request
-<emphasis role='bold'>DeleteProperty </emphasis>
+<emphasis role='bold'>DeleteProperty</emphasis>
 or
-<emphasis role='bold'>GetProperty .</emphasis>
+<emphasis role='bold'>GetProperty</emphasis>.
 The timestamp indicates the server time when the property was changed.
 <!-- .sp -->
 </para>
@@ -14572,10 +14572,10 @@ The timestamp indicates the server time when the property was changed.
 <para>
 This event is reported to the current owner of a selection
 and is generated when a new owner is being defined by means of
-<emphasis role='bold'>SetSelectionOwner .</emphasis>
+<emphasis role='bold'>SetSelectionOwner</emphasis>.
 The timestamp is the last-change time recorded for the selection.
 The owner argument is the window that was specified by the current owner in its
-<emphasis role='bold'>SetSelectionOwner </emphasis>
+<emphasis role='bold'>SetSelectionOwner</emphasis>
 request.
 <!-- .sp -->
 </para>
@@ -14629,19 +14629,19 @@ request.
 <para>
 This event is reported to the owner of a selection
 and is generated when a client issues a
-<emphasis role='bold'>ConvertSelection </emphasis>
+<emphasis role='bold'>ConvertSelection</emphasis>
 request.
 The owner argument is the window that was specified in the
-<emphasis role='bold'>SetSelectionOwner </emphasis>
+<emphasis role='bold'>SetSelectionOwner</emphasis>
 request.
 The remaining arguments are as in the
-<emphasis role='bold'>ConvertSelection </emphasis>
+<emphasis role='bold'>ConvertSelection</emphasis>
 request.
 </para>
 <para>
 The owner should convert the selection based on the specified target type
 and send a
-<emphasis role='bold'>SelectionNotify </emphasis>
+<emphasis role='bold'>SelectionNotify</emphasis>
 back to the requestor.
 A complete specification for using selections is given in the X.Org
 standard <emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis>.
@@ -14686,15 +14686,15 @@ standard <emphasis remap='I'>Inter-Client Communication Conventions Manual</emph
 <!-- .eM -->
 <para>
 This event is generated by the server in response to a
-<emphasis role='bold'>ConvertSelection </emphasis>
+<emphasis role='bold'>ConvertSelection</emphasis>
 request when there is no owner for the selection.
 When there is an owner,
 it should be generated by the owner using
-<emphasis role='bold'>SendEvent .</emphasis>
+<emphasis role='bold'>SendEvent</emphasis>.
 The owner of a selection should send this event to a requestor either
 when a selection has been converted and stored as a property
 or when a selection conversion could not be performed (indicated with property
-<emphasis role='bold'>None ).</emphasis>
+<emphasis role='bold'>None</emphasis>).
 <!-- .sp -->
 </para>
 <para id="events:ColormapNotify">
@@ -14725,8 +14725,8 @@ or when a selection conversion could not be performed (indicated with property
     <row rowsep='0'>
       <entry>
 <emphasis remap='I'>state</emphasis>:
-<emphasis role='bold'>{ Installed , </emphasis>
-<emphasis role='bold'>Uninstalled }</emphasis>
+<emphasis role='bold'>{ Installed</emphasis>,
+<emphasis role='bold'>Uninstalled</emphasis>}
 <!-- .in -.2i -->
 <!-- .eM -->
       </entry>
@@ -14737,13 +14737,13 @@ or when a selection conversion could not be performed (indicated with property
 <!-- .eM -->
 <para>
 This event is reported to clients selecting
-<emphasis role='bold'>ColormapChange </emphasis>
+<emphasis role='bold'>ColormapChange</emphasis>
 on the window.
 It is generated with value
-<emphasis role='bold'>True </emphasis>
+<emphasis role='bold'>True</emphasis>
 for new when the colormap attribute of the window is changed
 and is generated with value
-<emphasis role='bold'>False </emphasis>
+<emphasis role='bold'>False</emphasis>
 for new when the colormap of a window is installed or uninstalled.
 In either case,
 the state indicates whether the colormap is currently installed.
@@ -14761,9 +14761,9 @@ the state indicates whether the colormap is currently installed.
       <entry>
 <!-- .in +.2i -->
 <emphasis remap='I'>request</emphasis>:
-<emphasis role='bold'>{ Modifier , </emphasis>
-<emphasis role='bold'>Keyboard , </emphasis>
-<emphasis role='bold'>Pointer }</emphasis>
+<emphasis role='bold'>{ Modifier</emphasis>,
+<emphasis role='bold'>Keyboard</emphasis>,
+<emphasis role='bold'>Pointer</emphasis>}
       </entry>
     </row>
     <row rowsep='0'>
@@ -14781,18 +14781,18 @@ the state indicates whether the colormap is currently installed.
 This event is sent to all clients.
 There is no mechanism to express disinterest in this event.
 The detail indicates the kind of change that occurred:
-<emphasis role='bold'>Modifiers </emphasis>
+<emphasis role='bold'>Modifiers</emphasis>
 for a successful
-<emphasis role='bold'>SetModifierMapping , </emphasis>
-<emphasis role='bold'>Keyboard </emphasis>
+<emphasis role='bold'>SetModifierMapping</emphasis>,
+<emphasis role='bold'>Keyboard</emphasis>
 for a successful
-<emphasis role='bold'>ChangeKeyboardMapping , </emphasis>
+<emphasis role='bold'>ChangeKeyboardMapping</emphasis>,
 and
-<emphasis role='bold'>Pointer </emphasis>
+<emphasis role='bold'>Pointer</emphasis>
 for a successful
-<emphasis role='bold'>SetPointerMapping .</emphasis>
+<emphasis role='bold'>SetPointerMapping</emphasis>.
 If the detail is
-<emphasis role='bold'>Keyboard , </emphasis>
+<emphasis role='bold'>Keyboard</emphasis>,
 then first-keycode and count indicate the range of altered keycodes.
 <!-- .sp -->
 </para>
@@ -14833,7 +14833,7 @@ then first-keycode and count indicate the range of altered keycodes.
 <!-- .eM -->
 <para>
 This event is only generated by clients using
-<emphasis role='bold'>SendEvent .</emphasis>
+<emphasis role='bold'>SendEvent</emphasis>.
 The type specifies how the data is to be interpreted by the receiving client;
 the server places no interpretation on the type or the data.
 The format specifies whether the data should be viewed as a list of 8-bit,