specs/XKB: fixup newlines between tags and parens

Get rid of unwanted whitespace inside parens by moving them to the
lines with the tags, instead of before & after.

perl -i -0 -p \
     -e 's{(?<!--) \(\s*\n\<}{\n(<}g;' \
     -e 's{\>\s*\n\)([\.,;]?)(?! [^\n]*--)}{>)\1\n}g' *xml

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

15 files changed, 147 insertions, 147 deletions

diff --git a/specs/XKB/ch02.xml b/specs/XKB/ch02.xml
index 6d8755fe..e7d58f56 100644
--- a/specs/XKB/ch02.xml
+++ b/specs/XKB/ch02.xml
@@ -168,11 +168,11 @@ Call
 <function>XkbQueryExtension</function>
  to check for the presence and compatibility of the extension in the server and
 to initialize the extension. Because of potential version mismatches, you
-cannot use the generic extension mechanism functions (
-<function>XQueryExtension</function>
+cannot use the generic extension mechanism functions
+(<function>XQueryExtension</function>
 and
-<function>XInitExtension</function>
-) for checking for the presence of, and initializing the Xkb extension.
+<function>XInitExtension</function>)
+ for checking for the presence of, and initializing the Xkb extension.
 </para>
 
 <para>
@@ -770,10 +770,10 @@ The Xkb extension can communicate with the X input extension if it is present.
 Consequently, there can potentially be more than one input device connected to
 the server. Most Xkb library calls that require communicating with the server
 involve both a server connection (Display *
-<structfield>dpy</structfield>
-) and a device identifier (unsigned int
-<structfield>device_spec</structfield>
-). In some cases, the device identifier is implicit and is taken as the
+<structfield>dpy</structfield>)
+ and a device identifier (unsigned int
+<structfield>device_spec</structfield>).
+ In some cases, the device identifier is implicit and is taken as the
 <structfield>device_spec</structfield>
  field of an
 <structname>XkbDescRec</structname>
diff --git a/specs/XKB/ch04.xml b/specs/XKB/ch04.xml
index f02c4b71..14e5c265 100644
--- a/specs/XKB/ch04.xml
+++ b/specs/XKB/ch04.xml
@@ -790,8 +790,8 @@ type and for the core protocol
 <structname>XkbEvent</structname>
  structure, you may use the
 <structfield>type</structfield>
- field to determine if the event is an Xkb event (
-<structfield>type</structfield>
+ field to determine if the event is an Xkb event
+(<structfield>type</structfield>
  equals the Xkb base event code; see <link linkend="Initializing_the_Keyboard_Extension">section 2.4</link>). If the event is an Xkb
 event, you may then use the
 <structfield>any.xkb_type</structfield>
diff --git a/specs/XKB/ch05.xml b/specs/XKB/ch05.xml
index 9843b470..570ed1b3 100644
--- a/specs/XKB/ch05.xml
+++ b/specs/XKB/ch05.xml
@@ -195,9 +195,9 @@ The global locked or effective group changes. In this case, the changed group is
 
 The Xkb library is interpreting an event with an effective group that is legal for the keyboard as a whole, but not for the key in question. In this case, the group to use for this event only is determined using the
 <structfield>group_info</structfield>
- field of the key symbol mapping (
-<structname>XkbSymMapRec</structname>
-) for the event key.
+ field of the key symbol mapping
+(<structname>XkbSymMapRec</structname>)
+ for the event key.
   </para></listitem>
 </orderedlist>
 
@@ -314,8 +314,8 @@ If the server’s
 
 
 <para>
-The final three components of Xkb state are applicable to clients that are not linked with an Xlib containing the X keyboard extension library and therefore are not aware of the keyboard extension (
-<emphasis>Xkb-unaware</emphasis>
+The final three components of Xkb state are applicable to clients that are not linked with an Xlib containing the X keyboard extension library and therefore are not aware of the keyboard extension
+(<emphasis>Xkb-unaware</emphasis>
 clients):
 </para>
 
diff --git a/specs/XKB/ch06.xml b/specs/XKB/ch06.xml
index f731a477..ce134b3a 100644
--- a/specs/XKB/ch06.xml
+++ b/specs/XKB/ch06.xml
@@ -197,8 +197,8 @@ fields in the
 To retrieve one or more components of a keyboard device description, use
 <function>XkbGetKeyboard</function>
  (see also
-<function>XkbGetKeyboardByName</function>
-).
+<function>XkbGetKeyboardByName</function>).
+
 </para>
 
 <indexterm significance="preferred" zone="XkbGetKeyboard"><primary><function>XkbGetKeyboard</function></primary></indexterm>
diff --git a/specs/XKB/ch07.xml b/specs/XKB/ch07.xml
index 85b0759d..053fee2b 100644
--- a/specs/XKB/ch07.xml
+++ b/specs/XKB/ch07.xml
@@ -12,8 +12,8 @@ not provide a convenient way to determine the mapping of modifier bits (in
 particular
 <symbol>Mod1</symbol>
  through
-<symbol>Mod5</symbol>
-) to keysyms such as
+<symbol>Mod5</symbol>)
+ to keysyms such as
 <keysym>Num_Lock</keysym>
  and
 <keysym>Mode_switch</keysym>.
@@ -47,8 +47,8 @@ Each virtual modifier can be bound to any set of the real modifiers
  and
 <symbol>Mod1</symbol>
 -
-<symbol>Mod5</symbol>
-).
+<symbol>Mod5</symbol>).
+
 </para>
 
 
@@ -364,8 +364,8 @@ If the
 <emphasis>NumLock</emphasis>
  virtual modifier is not bound to any real modifiers, the effective masks for
 these two cases are identical (that is, contain only
-<symbol>Shift</symbol>
-). When it is essential to distinguish between
+<symbol>Shift</symbol>).
+ When it is essential to distinguish between
 <emphasis>OneThing</emphasis>
  and Another, Xkb considers only those modifier definitions for which all
 virtual modifiers are bound.
diff --git a/specs/XKB/ch08.xml b/specs/XKB/ch08.xml
index cc6fde6c..6fb5c891 100644
--- a/specs/XKB/ch08.xml
+++ b/specs/XKB/ch08.xml
@@ -256,8 +256,8 @@ If
 indicator map (such as
 <function>XkbSetIndicatorMap</function>
  or
-<function>XkbSetNamedIndicator</function>
-), Xkb changes the keyboard state and controls to reflect the other fields of
+<function>XkbSetNamedIndicator</function>),
+ Xkb changes the keyboard state and controls to reflect the other fields of
 the indicator map, as described in the remainder of this section. If you
 attempt to explicitly change the value of an indicator for which
 <symbol>XkbIM_LEDDrivesKB</symbol>
@@ -1164,8 +1164,8 @@ bits, as well as the indicator’s index into the
 <structname>XkbIndicatorRec</structname>
  array of indicator maps.
 <parameter>state_rtrn</parameter>
- returns the current state of the named indicator (
-<symbol>True</symbol>
+ returns the current state of the named indicator
+(<symbol>True</symbol>
  = on,
 <symbol>False</symbol>
  = off).
@@ -1246,8 +1246,8 @@ If
 indicator map (such as
 <function>XkbSetIndicatorMap</function>
  or
-<function>XkbSetNamedIndicator</function>
-), Xkb changes the keyboard state and controls to reflect the other fields of
+<function>XkbSetNamedIndicator</function>),
+ Xkb changes the keyboard state and controls to reflect the other fields of
 the indicator map. If you attempt to explicitly change the value of an
 indicator for which
 <symbol>XkbIM_LEDDrivesKB</symbol>
diff --git a/specs/XKB/ch10.xml b/specs/XKB/ch10.xml
index 3e3472f3..3243122c 100644
--- a/specs/XKB/ch10.xml
+++ b/specs/XKB/ch10.xml
@@ -1387,19 +1387,19 @@ pressed.
 </listitem>
 <listitem>
   <para>
-After 160 milliseconds (
-<structfield>mk_delay</structfield>
-), and every 40 milliseconds thereafter (
-<structfield>mk_interval</structfield>
-), the pointer moves in the X direction.
+After 160 milliseconds
+(<structfield>mk_delay</structfield>),
+ and every 40 milliseconds thereafter
+(<structfield>mk_interval</structfield>),
+ the pointer moves in the X direction.
   </para>
 </listitem>
 <listitem>
   <para>
 The distance in the X direction increases with each interval until 30 intervals
 (
-<structfield>mk_time_to_max</structfield>
-) have elapsed.
+<structfield>mk_time_to_max</structfield>)
+ have elapsed.
   </para>
 </listitem>
 <listitem>
@@ -2956,8 +2956,8 @@ and consumed in the server. These are:
 <para>
 Without the modifier processing options provided by Xkb, passive grabs set via
 translations in a client (for example,
-<emphasis>Alt&lt;KeyPress&gt;space</emphasis>
-) do not trigger if any modifiers other than those specified by the translation
+<emphasis>Alt&lt;KeyPress&gt;space</emphasis>)
+ do not trigger if any modifiers other than those specified by the translation
 are set. This results in problems in the user interface when either
 <emphasis>NumLock</emphasis>
  or a secondary keyboard group is active. The
@@ -3500,8 +3500,8 @@ The general-purpose functions that work with the
  structure use a mask to specify which controls are to be manipulated.
 <link linkend="table10.6">Table 10.6</link>
 lists these controls, the masks used to select them in the general
-function calls (
-<structfield>which</structfield>
+function calls
+(<structfield>which</structfield>
  parameter), and the data fields in the
 <structname>XkbControlsRec</structname>
  structure that comprise each of the individual controls. Also listed are the
@@ -3696,11 +3696,11 @@ is described in more detail.
 shows the actual values for the individual mask bits used to select
 controls for modification and to enable and disable the control. Note that the
 same mask bit is used to specify general modifications to the parameters used
-to configure the control (
-<structfield>which</structfield>
-), and to enable and disable the control (
-<structfield>enabled_ctrls</structfield>
-). The anomalies in the table (no "ok" in column) are for controls that have no
+to configure the control
+(<structfield>which</structfield>),
+ and to enable and disable the control
+(<structfield>enabled_ctrls</structfield>).
+ The anomalies in the table (no "ok" in column) are for controls that have no
 configurable attributes; and for controls that are not boolean controls and
 therefore cannot be enabled or disabled.
 </para>
@@ -4169,8 +4169,8 @@ The
 
 <para>
 The fields pertaining to each control are relevant only when the control is
-enabled (
-<symbol>XkbAccessXFeedbackMask</symbol>
+enabled
+(<symbol>XkbAccessXFeedbackMask</symbol>
  or
 <symbol>XkbStickyKeysMask</symbol>
  bit is turned on in the
@@ -4577,8 +4577,8 @@ the corresponding values are still updated in the X server. For example, the
  has
 <symbol>XkbRepeatKeysMask</symbol>
  set in
-<structfield>enabled_ctrls</structfield>
-). It is permissible to modify the attributes of a control in one call to
+<structfield>enabled_ctrls</structfield>).
+ It is permissible to modify the attributes of a control in one call to
 XkbSetControls and enable the control in a subsequent call. See <link linkend="The_EnabledControls_Control">section 10.1.1</link>
 for more information on enabling and disabling controls.
 </para>
@@ -4599,8 +4599,8 @@ others, then specify the
 <function>XkbSetControls</function>.
 Because this is somewhat awkward if all you want to do is enable and disable
 controls, and not modify any of their attributes, a convenience function is
-also provided for this purpose (
-<function>XkbChangeEnabledControls</function>,
+also provided for this purpose
+(<function>XkbChangeEnabledControls</function>,
 <link linkend="The_EnabledControls_Control">section 10.1.1</link>).
 </para>
 
@@ -4842,8 +4842,8 @@ and the
 <symbol>DeviceKeyRelease</symbol>,
 <symbol>ButtonPress</symbol>
  or
-<symbol>ButtonRelease</symbol>
-), and
+<symbol>ButtonRelease</symbol>),
+ and
 <structfield>req_major</structfield>
  and
 <structfield>req_minor</structfield>
diff --git a/specs/XKB/ch13.xml b/specs/XKB/ch13.xml
index 93471fed..558155d3 100644
--- a/specs/XKB/ch13.xml
+++ b/specs/XKB/ch13.xml
@@ -136,9 +136,9 @@ multiple key names to a single key.
 override those defined in the keycodes component of the server database, which
 are stored in the
 <structname>XkbNamesRec</structname>
- (
-<structfield>xkb-&gt;names</structfield>
-). Therefore, consider the key aliases defined by the geometry before
+
+(<structfield>xkb-&gt;names</structfield>).
+ Therefore, consider the key aliases defined by the geometry before
 considering key aliases supplied by the keycodes.</para></note>
 </listitem>
 <listitem>
@@ -442,23 +442,23 @@ containing the entire section.
 <title>Rows and Keys</title>
 
 <para>
-A row description (
-<structname>XkbRowRec</structname>
-) consists of the coordinates of its origin relative to its enclosing section,
+A row description
+(<structname>XkbRowRec</structname>)
+ consists of the coordinates of its origin relative to its enclosing section,
 a flag indicating whether the row is horizontal or vertical, and a list of keys
 in the row.
 </para>
 
 
 <para>
-A key description (
-<structname>XkbKeyRec</structname>
-) consists of a key name, a shape, a key color, and a gap. The key name should
+A key description
+(<structname>XkbKeyRec</structname>)
+ consists of a key name, a shape, a key color, and a gap. The key name should
 correspond to one of the keys named in the keyboard names description, the
 shape specifies the appearance of the key, and the key color specifies the
 color of the key (not the label on the key; the label color is stored in the
-<structname>XkbGeometryRec</structname>
-). Keys are normally drawn immediately adjacent to one another from left to
+<structname>XkbGeometryRec</structname>).
+ Keys are normally drawn immediately adjacent to one another from left to
 right (or top to bottom) within a row. The gap field specifies the distance
 between a key and its predecessor.
 </para>
@@ -502,11 +502,11 @@ Xkb supports five types of doodads:
 An
 <firstterm>indicator doodad</firstterm>
  describes one of the physical keyboard indicators. Indicator doodads specify
-the shape of the indicator, the indicator color when it is lit (
-<emphasis>on_color</emphasis>
-) and the indicator color when it is dark (
-<emphasis>off_color</emphasis>
-).
+the shape of the indicator, the indicator color when it is lit
+(<emphasis>on_color</emphasis>)
+ and the indicator color when it is dark
+(<emphasis>off_color</emphasis>).
+
   </para>
 </listitem>
 <listitem>
@@ -639,17 +639,17 @@ The structures these doodads are stored in and the values of the
 <para>
 An
 <firstterm>overlay row</firstterm>
- (
-<structname>XkbOverlayRowRec</structname>
-) contains a pointer to the row it overlays and a list of
+
+(<structname>XkbOverlayRowRec</structname>)
+ contains a pointer to the row it overlays and a list of
 <firstterm>overlay keys</firstterm>.
 </para>
 
 
 <para>
-Each overlay key definition (
-<structname>XkbOverlayKeyRec</structname>
-) indicates a key that can yield multiple keycodes and consists of a field
+Each overlay key definition
+(<structname>XkbOverlayKeyRec</structname>)
+ indicates a key that can yield multiple keycodes and consists of a field
 named
 <structfield>under</structfield>,
 which specifies the primary name of the key and a field named
@@ -2216,12 +2216,12 @@ the doodad. If there is already a doodad with the name
  in the doodad array for the geometry (if
 <parameter>section</parameter>
  is
-<symbol>NULL</symbol>
-) or the section (if
+<symbol>NULL</symbol>)
+ or the section (if
 <parameter>section</parameter>
  is non-
-<symbol>NULL</symbol>
-), a pointer to that doodad is returned. To allocate space for an arbitrary
+<symbol>NULL</symbol>),
+ a pointer to that doodad is returned. To allocate space for an arbitrary
 number of doodads to a section, use the XkbAllocGeomSectionDoodads function. To
 allocate space for an arbitrary number of doodads to a keyboard geometry, use
 the XkbAllocGeomDoodads function.
diff --git a/specs/XKB/ch15.xml b/specs/XKB/ch15.xml
index e4898cc6..d22b0107 100644
--- a/specs/XKB/ch15.xml
+++ b/specs/XKB/ch15.xml
@@ -1288,8 +1288,8 @@ the key types:
 </para>
 
 <note><para>The array of key types is of fixed width and is large enough to
-hold key types for the maximum legal number of groups (
-<symbol>XkbNumKbdGroups</symbol>,
+hold key types for the maximum legal number of groups
+(<symbol>XkbNumKbdGroups</symbol>,
 currently four); if a key has fewer than
 <symbol>XkbNumKbdGroups</symbol>
  groups, the extra key types are reported but ignored.</para></note>
diff --git a/specs/XKB/ch16.xml b/specs/XKB/ch16.xml
index 9166f5ab..a1eade8d 100644
--- a/specs/XKB/ch16.xml
+++ b/specs/XKB/ch16.xml
@@ -3057,14 +3057,14 @@ The
  (if
 <structfield>press</structfield>
  is
-<symbol>True</symbol>
-) or
+<symbol>True</symbol>)
+ or
 <symbol>KeyRelease</symbol>
  (if
 <structfield>press</structfield>
  is
-<symbol>False</symbol>
-) event is also sent to the client. As with all other Xkb events,
+<symbol>False</symbol>)
+ event is also sent to the client. As with all other Xkb events,
 <structname>XkbActionMessageEvent</structname>s
  are delivered to all clients requesting them, regardless of the current
 keyboard focus. However, the
@@ -4083,8 +4083,8 @@ The
       <para>
 If another member of the radio group is logically down (all members of the
 radio group have the same index, specified in
-<structfield>data</structfield>
-) when a key is pressed, the server synthesizes a key release for the member
+<structfield>data</structfield>)
+ when a key is pressed, the server synthesizes a key release for the member
 that is logically down and then processes the new key press event normally.
       </para>
       <para>
diff --git a/specs/XKB/ch17.xml b/specs/XKB/ch17.xml
index ec3ace6f..94368139 100644
--- a/specs/XKB/ch17.xml
+++ b/specs/XKB/ch17.xml
@@ -97,11 +97,11 @@ Xkb state in the server.
     <para><emphasis role='bold'>Core Keyboard Mapping to Xkb Keyboard Mapping</emphasis></para>
     <para>
 After core protocol requests received by the server to change the keyboard
-mapping (
-<systemitem>ChangeKeyboardMapping</systemitem>
+mapping
+(<systemitem>ChangeKeyboardMapping</systemitem>
  and
-<systemitem>SetModifierMapping</systemitem>
-) have been applied to the server’s core keyboard map, the results must be
+<systemitem>SetModifierMapping</systemitem>)
+ have been applied to the server’s core keyboard map, the results must be
 transformed to achieve an equivalent change of the Xkb keyboard mapping
 maintained by the server.
     </para>
@@ -110,9 +110,9 @@ maintained by the server.
     <para><emphasis role='bold'>Xkb Keyboard Mapping to Core Keyboard Mapping</emphasis></para>
     <para>
 After Xkb protocol requests received by the server to change the keyboard
-mapping (
-<function>XkbSetMap</function>
-) have been applied to the server’s Xkb keyboard map, the results are
+mapping
+(<function>XkbSetMap</function>)
+ have been applied to the server’s Xkb keyboard map, the results are
 transformed to achieve an approximately equivalent change to the core keyboard
 mapping maintained by the server.
     </para>
@@ -143,9 +143,9 @@ separate data structure discussed in <link linkend="Explicit_ComponentsAvoiding_
 <para>
 The
 <structfield>compat</structfield>
- member of an Xkb keyboard description (
-<structname>XkbDescRec</structname>
-) points to the
+ member of an Xkb keyboard description
+(<structname>XkbDescRec</structname>)
+ points to the
 <structname>XkbCompatMapRec</structname>
  structure:
 </para>
@@ -1711,9 +1711,9 @@ in <link linkend="Getting_Compatibility_Map_Components_From_the_Server">section
 <para>
 <parameter>num_si</parameter>
  specifies the total number of entries to allocate in the symbol interpretation
-vector (
-<structfield>xkb.compat.sym_interpret</structfield>
-).
+vector
+(<structfield>xkb.compat.sym_interpret</structfield>).
+
 </para>
 
 
diff --git a/specs/XKB/ch18.xml b/specs/XKB/ch18.xml
index ee2d095e..d4600cd7 100644
--- a/specs/XKB/ch18.xml
+++ b/specs/XKB/ch18.xml
@@ -195,9 +195,9 @@ name LEFT as an alias for A31 in the
 (see <xref linkend="Keyboard_Geometry" />) override those defined in the keycodes component of the server
 database, which are stored in the
 <structname>XkbNamesRec</structname>
- (
-<structfield>xkb-&gt;names</structfield>
-). Therefore, consider the key aliases defined by the geometry before
+
+(<structfield>xkb-&gt;names</structfield>).
+ Therefore, consider the key aliases defined by the geometry before
 considering key aliases supplied by the
 <structname>XkbNamesRec</structname>.
 </para></note>
diff --git a/specs/XKB/ch20.xml b/specs/XKB/ch20.xml
index 0aae03ba..a8ac1c2e 100644
--- a/specs/XKB/ch20.xml
+++ b/specs/XKB/ch20.xml
@@ -734,14 +734,14 @@ overriding any existing definitions (it could also be written "+de(default)").
 Here is a slightly more involved example: the expression
 "acme(ascii)+de(basic)|iso9995-3" constructs a German (de) mapping for the
 ASCII keyboard supplied by the "acme" vendor. The new definition begins with
-the symbols for the ASCII keyboard for Acme (
-<literal>acme(ascii)</literal>
-), overrides them with definitions for the basic German keyboard (
-<literal>de(basic)</literal>
-), and then applies the definitions from the default iso9995-3 keyboard
+the symbols for the ASCII keyboard for Acme
+(<literal>acme(ascii)</literal>),
+ overrides them with definitions for the basic German keyboard
+(<literal>de(basic)</literal>),
+ and then applies the definitions from the default iso9995-3 keyboard
 (
-<literal>iso9995-3</literal>
-) to any undefined keys or groups of keys (part three of the iso9995 standard
+<literal>iso9995-3</literal>)
+ to any undefined keys or groups of keys (part three of the iso9995 standard
 defines a common set of bindings for the secondary group, but allows national
 layouts to override those definitions where necessary).
 </para>
@@ -790,8 +790,8 @@ possible bits in
 If a required component has not been specified in the
 <parameter>names</parameter>
  structure (the corresponding field is
-<symbol>NULL</symbol>
-), the server substitutes the expression
+<symbol>NULL</symbol>),
+ the server substitutes the expression
 “<literal>%</literal>”,
  resulting in the component values being taken from
 <parameter>device_spec</parameter>.
@@ -1052,8 +1052,8 @@ XkbGetNames(dpy, XkbKeyNamesMask | XkbKeyAliasesMask, Xkb)
 There is no way to determine which components specified in
 <parameter>want</parameter>
  (but not in
-<parameter>need</parameter>
-) were actually fetched, other than breaking the call into successive calls to
+<parameter>need</parameter>)
+ were actually fetched, other than breaking the call into successive calls to
 <function>XkbGetKeyboardByName</function>
  and specifying individual components.
 </para>
@@ -1156,8 +1156,8 @@ keyboard device. It calls
 <symbol>NULL</symbol>,
 <parameter>which</parameter>,
 <parameter>which</parameter>,
-<symbol>False</symbol>
-).
+<symbol>False</symbol>).
+
 </para>
 
 </sect1>
diff --git a/specs/XKB/ch21.xml b/specs/XKB/ch21.xml
index 7fdf4764..9dd21654 100644
--- a/specs/XKB/ch21.xml
+++ b/specs/XKB/ch21.xml
@@ -76,11 +76,11 @@ XkbGetDeviceInfo and XkbSetDeviceInfo functions described in this chapter.
 <para>
 Each device has an X Input Extension device ID. Each device may have several
 classes of feedback. For example, there are two types of feedbacks that can
-generate bells: bell feedback and keyboard feedback (
-<symbol>BellFeedbackClass</symbol>
+generate bells: bell feedback and keyboard feedback
+(<symbol>BellFeedbackClass</symbol>
  and
-<symbol>KbdFeedbackClass</symbol>
-). A device can have more than one feedback of each type; the feedback ID
+<symbol>KbdFeedbackClass</symbol>).
+ A device can have more than one feedback of each type; the feedback ID
 identifies the particular feedback within its class.
 </para>
 
@@ -201,8 +201,8 @@ The
 <structfield>type</structfield>
  field is a registered symbolic name for a class of devices (for example,
 "TABLET"). If a device is a keyboard (that is, is a member of
-<symbol>KeyClass</symbol>
-), it has its own state, and
+<symbol>KeyClass</symbol>),
+ it has its own state, and
 <structfield>has_own_state</structfield>
  is
 <symbol>True</symbol>.
@@ -501,8 +501,8 @@ If the
 <parameter>which</parameter>,
 the
 <structname>XkbDeviceInfoRec</structname>
- returned will have the button actions (
-<structfield>btn_acts</structfield>
+ returned will have the button actions
+(<structfield>btn_acts</structfield>
  field) filled in for all buttons.
 </para>
 
@@ -693,11 +693,11 @@ by the
 <parameter>device_info</parameter>
  and waits for a reply. If successful,
 <function>XkbGetDeviceButtonActions</function>
- backfills the button actions (
-<structfield>btn_acts</structfield>
+ backfills the button actions
+(<structfield>btn_acts</structfield>
  field of
-<parameter>device_info</parameter>
-) for only the requested buttons, updates the
+<parameter>device_info</parameter>)
+ for only the requested buttons, updates the
 <structfield>name</structfield>,
 <structfield>type</structfield>,
 <structfield>supported</structfield>,
@@ -734,11 +734,11 @@ extension has not been properly initialized, XkbGetDeviceButtonActions returns
 <errorname>BadAccess</errorname>.
 If allocation errors occur, a
 <errorname>BadAlloc</errorname>
- status is returned. If the specified device (
-<parameter>device_info</parameter>
+ status is returned. If the specified device
+(<parameter>device_info</parameter>
 -&gt;
-<structfield>device_spec</structfield>
-) is invalid, a
+<structfield>device_spec</structfield>)
+ is invalid, a
 <errorname>BadKeyboard</errorname>
  status is returned. If the device has no buttons, a
 <errorname>BadMatch</errorname>
diff --git a/specs/XKB/glossary.xml b/specs/XKB/glossary.xml
index c4f2c204..854852b7 100644
--- a/specs/XKB/glossary.xml
+++ b/specs/XKB/glossary.xml
@@ -234,9 +234,9 @@ legal for the keyboard as a whole, but not for the key in question, the group
 <emphasis>for that event only</emphasis>
  is normalized using the algorithm specified by the
 <structfield>group_info</structfield>
- member of the key symbol map (
-<structname>XkbSymMapRec</structname>
-).
+ member of the key symbol map
+(<structname>XkbSymMapRec</structname>).
+
     </para>
   </glossdef>
 </glossentry>
@@ -742,15 +742,15 @@ to a keysym.
     <para>
 A modifier is a logical condition that is either set or unset. The modifiers
 control the Shift Level selected when a key event occurs. Xkb supports the core
-protocol eight modifiers (
-<symbol>Shift</symbol>,
+protocol eight modifiers
+(<symbol>Shift</symbol>,
 <symbol>Lock</symbol>,
 <symbol>Control</symbol>,
 and
 <symbol>Mod1</symbol>
  through
-<symbol>Mod5</symbol>
-), called the
+<symbol>Mod5</symbol>),
+ called the
 <emphasis>real</emphasis>
  modifiers. In addition, Xkb extends modifier flexibility by providing a set of
 sixteen named virtual modifiers, each of which can be bound to any set of the
@@ -864,15 +864,15 @@ be logically depressed at one time.
   <glossterm>Real Modifier</glossterm>
   <glossdef>
     <para>
-Xkb supports the eight core protocol modifiers (
-<symbol>Shift</symbol>,
+Xkb supports the eight core protocol modifiers
+(<symbol>Shift</symbol>,
 <symbol>Lock</symbol>,
 <symbol>Control</symbol>,
 and
 <symbol>Mod1</symbol>
  through
-<symbol>Mod5</symbol>
-); these are called the
+<symbol>Mod5</symbol>);
+ these are called the
 <emphasis>real</emphasis>
  modifiers, as opposed to the set of sixteen named virtual modifiers that can
 be bound to any set of the eight real modifiers.
@@ -959,15 +959,15 @@ slider, or a dial.
     <para>
 Xkb provides a set of sixteen named virtual modifiers that can be bound to any
 set of the eight real modifiers. Each virtual modifier can be bound to any set
-of the real modifiers (
-<symbol>Shift</symbol>,
+of the real modifiers
+(<symbol>Shift</symbol>,
 <symbol>Lock</symbol>,
 <symbol>Control</symbol>,
  and
 <symbol>Mod1</symbol>
 -
-<symbol>Mod5</symbol>
-).
+<symbol>Mod5</symbol>).
+
     </para>
   </glossdef>
 </glossentry>