Remove duplicate 'See see' text in docs - take 2

15 files changed, 136 insertions, 119 deletions

diff --git a/specs/ch02.xml b/specs/ch02.xml
index e3558d1..ab7aa23 100644
--- a/specs/ch02.xml
+++ b/specs/ch02.xml
@@ -273,7 +273,7 @@ ServerInternalModifiers</emphasis>
 IgnoreLocksModifiers</emphasis>
  and <emphasis>
 IgnoreGroupLock</emphasis>
- controls, described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
+ controls, described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server
 Internal Modifiers and Ignore Locks Behavior</link>, to derive these two
 states as follows:
 </para>
@@ -355,7 +355,7 @@ The core protocol interpretation of
 keyboard modifiers does not include direct support for multiple groups, so XKB
 reports the effective keyboard group to XKB-aware clients using some of the
 reserved bits in the state field of some core protocol events, as described in
-<link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an
+<link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State Field from an
 XKB State</link>.
 </para>
 
@@ -363,7 +363,7 @@ XKB State</link>.
 This modified state field would not be interpreted correctly by XKB-unaware
 clients, so XKB provides a <emphasis>
 group compatibility mapping</emphasis>
-(see <link linkend='group_compatibility_map'>See Group Compatibility Map</link>) which
+(see <link linkend='group_compatibility_map'>Group Compatibility Map</link>) which
 remaps the keyboard group into a core modifier mask that has similar effects,
 when possible. XKB maintains three compatibility state components that are used
 to make non-XKB clients work as well as possible:
@@ -398,7 +398,7 @@ of the grab state.
 
 <para>
 Compatibility states are essentially the corresponding XKB state, but with
-keyboard group possibly encoded as one or more modifiers; <link linkend='group_compatibility_map'>See Group Compatibility Map</link> describes
+keyboard group possibly encoded as one or more modifiers; <link linkend='group_compatibility_map'>Group Compatibility Map</link> describes
 the group compatibility map, which specifies the modifier(s) that correspond to
 each keyboard group.
 </para>
diff --git a/specs/ch03.xml b/specs/ch03.xml
index 66b3353..e9ac99c 100644
--- a/specs/ch03.xml
+++ b/specs/ch03.xml
@@ -212,7 +212,7 @@ NumLock</emphasis>
 
 <para>
 The virtual modifier mapping is normally updated automatically whenever actions
-are assigned to keys (see <link linkend='changing_the_keyboard_mapping_using_the_core_protocol'>See Changing
+are assigned to keys (see <link linkend='changing_the_keyboard_mapping_using_the_core_protocol'>Changing
 the Keyboard Mapping Using the Core Protocol</link> for details) and few
 applications should need to change the virtual modifier mapping explicitly.
 </para>
diff --git a/specs/ch04.xml b/specs/ch04.xml
index 631d1b0..ab1547a 100644
--- a/specs/ch04.xml
+++ b/specs/ch04.xml
@@ -99,7 +99,7 @@ whether or not it is supported.
 
 
 <para>
-<link linkend='querying_and_changing_per_client_flags'>See Querying and Changing Per-Client
+<link linkend='querying_and_changing_per_client_flags'>Querying and Changing Per-Client
 Flags</link> describes the <emphasis>
 XkbPerClientFlags</emphasis>
  request, which reports or changes values for all of the per-client flags, and
@@ -148,7 +148,7 @@ rejection or release of any key to interested clients using <emphasis>
 AccessXNotify</emphasis>
  events. The <emphasis>
 AccessXNotify</emphasis>
- event is described in more detail in <link linkend='events'>See Events</link>.
+ event is described in more detail in <link linkend='events'>Events</link>.
 </para>
 
 </sect1>
@@ -183,7 +183,7 @@ interested clients by sending an <emphasis>
 AccessXNotify</emphasis>
  event. The <emphasis>
 AccessXNotify</emphasis>
- event is described in more detail in <link linkend='events'>See Events</link>.
+ event is described in more detail in <link linkend='events'>Events</link>.
 </para>
 
 </sect1>
@@ -375,7 +375,7 @@ When <emphasis>
 MouseKeys</emphasis>
  are active and a <emphasis>
 SA_MovePtr</emphasis>
- key action (see <link linkend='key_actions'>See Key
+ key action (see <link linkend='key_actions'>Key
 Actions</link>) is activated, a pointer motion event is generated immediately.
 If <emphasis>
 MouseKeysAccel</emphasis>
@@ -515,11 +515,10 @@ StickyKeys</emphasis>
 
 <para>
 Some of these key sequences optionally generate audible feedback of the change
-in state, as described in <link linkend='the_accessxfeedback_control'>See The
+in state, as described in <link linkend='the_accessxfeedback_control'>The
 AccessXFeedback Control</link>, or cause <emphasis>
 XkbAccessXNotify</emphasis>
- events as described in <link linkend='events'>See
-Events</link>.
+ events as described in <link linkend='events'>Events</link>.
 </para>
 
 
@@ -779,7 +778,7 @@ should generate when that overlay is enabled, assign it either the <emphasis>
 KB_Overlay1</emphasis>
  or <emphasis>
 KB_Overlay2</emphasis>
- key behaviors, as described in <link linkend='key_behavior'>See
+ key behaviors, as described in <link linkend='key_behavior'>
 Key Behavior</link>.
 </para>
 
@@ -791,10 +790,10 @@ Key Behavior</link>.
 <para>
 All of the controls described above, along with the <emphasis>
 AudibleBell</emphasis>
- control (described in <link linkend='disabling_server_generated_bells'>See Disabling
+ control (described in <link linkend='disabling_server_generated_bells'>Disabling
 Server Generated Bells</link>) and the <emphasis>
 IgnoreGroupLock</emphasis>
- control (described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
+ control (described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server
 Internal Modifiers and Ignore Locks Behavior</link>) comprise the <emphasis>
 boolean controls</emphasis>
 . In addition to any parameters listed in the descriptions of the individual
@@ -813,18 +812,18 @@ EnabledControls</emphasis>
  control or specified in any context that accepts only boolean controls:
 <emphasis>
 GroupsWrap</emphasis>
- (<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
+ (<link linkend='computing_effective_modifier_and_group'>Computing Effective Modifier and
 Group</link>), <emphasis>
 EnabledControls</emphasis>
 , <emphasis>
 InternalMods</emphasis>
- (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
+ (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server Internal Modifiers and
 Ignore Locks Behavior</link>), and <emphasis>
 IgnoreLockMods</emphasis>
- (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
+ (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server Internal Modifiers and
 Ignore Locks Behavior</link>) and <emphasis>
 PerKeyRepeat</emphasis>
- (<link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>)
+ (<link linkend='the_repeatkeys_control'>The RepeatKeys Control</link>)
 </para>
 
 
@@ -836,7 +835,7 @@ PerKeyRepeat</emphasis>
 The <emphasis>
 auto-reset controls</emphasis>
  are a per-client value which consist of two masks that can contain any of the
-boolean controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean"
+boolean controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>"Boolean"
 Controls and The EnabledControls Control</link>). Whenever the client exits
 for any reason, any boolean controls specified in the <emphasis>
 auto-reset mask</emphasis>
@@ -851,7 +850,7 @@ automatically, even if abnormally terminated.
 For example, a client that replace the keyboard bell with some other audible
 cue might want to turn off the <emphasis>
 AudibleBell</emphasis>
- control (<link linkend='disabling_server_generated_bells'>See Disabling Server
+ control (<link linkend='disabling_server_generated_bells'>Disabling Server
 Generated Bells</link>) to prevent the server from also generating a sound and
 thus avoid cacophony. If the client were to exit without resetting the
 <emphasis>
diff --git a/specs/ch05.xml b/specs/ch05.xml
index e712d56..fc9a185 100644
--- a/specs/ch05.xml
+++ b/specs/ch05.xml
@@ -19,7 +19,8 @@ elapsed while the <emphasis>
 RepeatKeys</emphasis>
  control can cause multiple X events from a single physical key press if the
 key is held down for an extended period. The global keyboard controls affect
-all of the keys on the keyboard and are described in <link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>.
+all of the keys on the keyboard and are described in
+<link linkend='global_keyboard_controls'>Global Keyboard Controls</link>.
   </para>
 </listitem>
 <listitem>
@@ -29,7 +30,8 @@ keyboard overlays, in which a key generates an alternate keycode under certain
 circumstances, can be implemented using per-key behavior. Every key has a
 single behavior, so the effect of key behavior does not depend on keyboard
 modifier or group state, though it might depend on global keyboard controls.
-Per-key behaviors are described in detail in <link linkend='key_behavior'>See Key Behavior</link>.
+Per-key behaviors are described in detail in
+<link linkend='key_behavior'>Key Behavior</link>.
   </para>
 </listitem>
 <listitem>
@@ -37,7 +39,7 @@ Per-key behaviors are described in detail in <link linkend='key_behavior'>See Ke
 keyboard has some action associated with it. The key action tells the server
 what to do when an event which yields the corresponding keysym is generated.
 Key actions might change or suppress the event, generate some other event, or
-change some aspect of the server. Key actions are described in <link linkend='key_actions'>See Key Actions</link>.
+change some aspect of the server. Key actions are described in <link linkend='key_actions'>Key Actions</link>.
   </para>
 </listitem>
 </orderedlist>
@@ -50,13 +52,13 @@ event, the client which receives the event processes it in several steps.
 <orderedlist>
 <listitem>
   <para>First the client extracts the effective keyboard group and a set of
-modifiers from the state field of the event. See <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an XKB
+modifiers from the state field of the event. See <link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State Field from an XKB
 State</link> for details.
   </para>
 </listitem>
 <listitem>
   <para>Using the modifiers and effective keyboard group, the client selects a
-symbol from the list of keysyms bound to the key. <link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated with a
+symbol from the list of keysyms bound to the key. <link linkend='determining_the_keysym_associated_with_a_key_event'>Determining the KeySym Associated with a
 Key Event</link> discusses symbol selection.
   </para>
 </listitem>
@@ -66,7 +68,9 @@ using any modifiers that are "left over" from the process of looking up a
 symbol. For example, if the <emphasis>
 Lock</emphasis>
  modifier is left over, the resulting keysym is capitalized according to the
-capitalization rules specified by the system. See <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym Associated with a
+capitalization rules specified by the system. See
+<link linkend='transforming_the_keysym_associated_with_a_key_event'>
+Transforming the KeySym Associated with a
 Key Event</link> for a more detailed discussion of the transformations defined
 by XKB.
   </para>
diff --git a/specs/ch06.xml b/specs/ch06.xml
index 6476750..6351760 100644
--- a/specs/ch06.xml
+++ b/specs/ch06.xml
@@ -262,7 +262,7 @@ list of symbols associated with the key (i.e. it has one action per symbol
 associated with the key). For key press events, the server looks up the action
 to be applied from this list using the key symbol mapping associated with the
 event key, just as a client looks up symbols as described in <link
-linkend="determining_the_keysym_associated_with_a_key_event">See Determining the KeySym Associated with a
+linkend="determining_the_keysym_associated_with_a_key_event">Determining the KeySym Associated with a
 Key Event</link>; if the event key does not have any actions, the server uses
 the <emphasis>
 SA_NoAction</emphasis>
@@ -292,7 +292,7 @@ delay between the activation of one and the other.
 
 <para>
 Most actions which affect keyboard modifier state accept a modifier definition
-(see <link linkend="virtual_modifiers">See Virtual Modifiers</link>)
+(see <link linkend="virtual_modifiers">Virtual Modifiers</link>)
 named <emphasis>
 mods</emphasis>
  and a boolean flag name <emphasis>
@@ -679,7 +679,7 @@ MouseKeysAccel</emphasis>
  keyboard control is enabled, key press also initiates the mouse keys timer for
 this key; every time this timer expires, the cursor moves again. The distance
 the cursor moves in these subsequent events is determined by the mouse keys
-acceleration as described in <link linkend="the_mousekeysaccel_control">See The
+acceleration as described in <link linkend="the_mousekeysaccel_control">The
 MouseKeysAccel Control</link>.
   </para>
 </listitem>
@@ -1627,7 +1627,7 @@ event that caused them.
 Events sent to clients that have not issued an <emphasis>
 XkbUseExtension</emphasis>
  request contain a compatibility state in place of the actual XKB keyboard
-state. See <link linkend="effects_of_xkb_on_core_protocol_events">See Effects of XKB on Core
+state. See <link linkend="effects_of_xkb_on_core_protocol_events">Effects of XKB on Core
 Protocol Events</link> for a description of this compatibility mapping.
 </para>
 
@@ -1647,7 +1647,7 @@ the following changes:
 <listitem>
   <para>A passive grab triggers if the modifier state specified in the grab
 matches the grab compatibility state (described in <link
-linkend="compatibility_components_of_keyboard_state">See Compatibility Components of Keyboard
+linkend="compatibility_components_of_keyboard_state">Compatibility Components of Keyboard
 State</link>). Clients can choose to use the XKB grab state instead by setting
 the <emphasis>
 GrabsUseXKBState</emphasis>
@@ -1678,14 +1678,14 @@ LookupStateWhenGrabbed</emphasis>
 <listitem>
   <para>Otherwise, the state field of events that do not trigger a passive grab
 report is derived from the XKB effective modifiers and group, as described in
-<link linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an
+<link linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an
 XKB State</link>.
   </para>
 </listitem>
 <listitem>
   <para>If a key release event is the result of an autorepeating key that is
 being held down, and the client to which the event is reported has requested
-detectable autorepeat (see <link linkend="detectable_autorepeat">See
+detectable autorepeat (see <link linkend="detectable_autorepeat">
 Detectable Autorepeat</link>), the event is not delivered to the client.
   </para>
 </listitem>
@@ -1720,7 +1720,7 @@ interact.
 <listitem>
   <para>The largest problems arise from the fact that an XKB state field
 encodes an explicit keyboard group in bits 13-14 (as described in <link
-linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an XKB
+linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an XKB
 State</link>), while pre-XKB clients use one of the eight keyboard modifiers
 to select an alternate keyboard group. To make existing clients behave
 reasonably, XKB normally uses the compatibility grab state instead of the XKB
diff --git a/specs/ch07.xml b/specs/ch07.xml
index 500357f..700f28f 100644
--- a/specs/ch07.xml
+++ b/specs/ch07.xml
@@ -7,7 +7,7 @@ client map</emphasis>
  for a keyboard is the collection of information a client needs to interpret
 key events that come from that keyboard. It contains a global list of <emphasis>
 key types</emphasis>
-, described in <link linkend='key_types'>See Key Types</link>,
+, described in <link linkend='key_types'>Key Types</link>,
 and an array of <emphasis>
 key symbol map</emphasis>
 s, each of which describes the symbols bound to one particular key and the
@@ -19,7 +19,7 @@ rules to be used to interpret those symbols.
 
 <para>
 XKB associates a two-dimensional array of symbols with each key. Symbols are
-addressed by keyboard group (see <link linkend='keyboard_state'>See
+addressed by keyboard group (see <link linkend='keyboard_state'>
 Keyboard State</link>) and shift level, where level is defined as in the
 ISO9995 standard:
 </para>
@@ -86,13 +86,13 @@ group and shift level that correspond to the event.
 
 <para>
 Group is reported in bits 13-14 of the state field of the key event, as
-described in <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State
+described in <link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State
 Field from an XKB State</link>. The keyboard group reported in the event might
 be out-of-range for any particular key because the number of groups can vary
 from key to key. The XKB description of each key contains a <emphasis>
 group info</emphasis>
  field which is interpreted identically to the global groups wrap control (see
-<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
+<link linkend='computing_effective_modifier_and_group'>Computing Effective Modifier and
 Group</link>) and which specifies the interpretation of groups that are
 out-of-range for that key.
 </para>
@@ -104,7 +104,7 @@ determine the shift level. The description of a key includes a <emphasis>
 key type</emphasis>
  for each group of symbols bound to the key. Given the modifiers from the key
 event, this key type yields a shift level and a set of "leftover" modifiers, as
-described in <link linkend='key_types'>See Key Types</link>
+described in <link linkend='key_types'>Key Types</link>
 below.
 </para>
 
@@ -125,7 +125,7 @@ map</emphasis>
  field specifies the shift level that corresponds to some XKB modifier
 definition; any combination of modifiers that is not explicitly listed
 somewhere in the map yields shift level one. Map entries which specify unbound
-virtual modifiers (see <link linkend='inactive_modifier_definitions'>See Inactive
+virtual modifiers (see <link linkend='inactive_modifier_definitions'>Inactive
 Modifier Definitions</link>) are not considered; each entry contains an
 automatically-updated <emphasis>
 active</emphasis>
@@ -161,7 +161,7 @@ Any modifiers specified in <emphasis>
 modifiers</emphasis>
  are normally <emphasis>
 consumed</emphasis>
- (see <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym
+ (see <link linkend='transforming_the_keysym_associated_with_a_key_event'>Transforming the KeySym
 Associated with a Key Event</link>), which means that they are not considered
 during any of the later stages of event processing. For those rare occasions
 that a modifier <emphasis>
@@ -427,7 +427,9 @@ Control</emphasis>
     <entry>Report the control character associated with the symbol. This
 extension defines the control characters associated with the ASCII alphabetic
 characters (both upper and lower case) and for a small set of punctuation
-characters (see <link linkend="default_symbol_transformations">Default Symbol Transformations</link>). Applications are
+characters (see
+<link linkend="default_symbol_transformations">Default Symbol Transformations</link>).
+Applications are
 free to associate control characters with any symbols that are not specified by
 this extension.</entry>
   </row>
@@ -449,11 +451,9 @@ Interpretation of other modifiers is application dependent.
 
 <note><para>This definition of capitalization is fundamentally different from
 the core protocol’s, which uses the lock modifier to select from the symbols
-bound to the key. Consider key 9 in the example keyboard on <link
-linkend="client_map_example">See Consider a simple, if
-unlikely, keyboard with the following keys (gray characters indicate symbols
-that are implied or expected but are not actually engraved on the
-key):</link>; the core protocol provides no way to generate the capital form
+bound to the key. Consider key 9 in the
+<link linkend="client_map_example">client map example</link>;
+the core protocol provides no way to generate the capital form
 of either symbol bound to this key. XKB specifies that we first look up the
 symbol and then capitalize, so XKB yields the capital form of the two symbols
 when caps lock is active. </para></note>
@@ -677,7 +677,7 @@ to be used. The key type determines which symbol is chosen from the list.
 
 
 <para>
-<link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated
+<link linkend='determining_the_keysym_associated_with_a_key_event'>Determining the KeySym Associated
 with a Key Event</link> details the procedure to map from a key event to a
 symbol and/or a string.
 </para>
diff --git a/specs/ch08.xml b/specs/ch08.xml
index 2dd04a9..cbf4b78 100644
--- a/specs/ch08.xml
+++ b/specs/ch08.xml
@@ -86,7 +86,9 @@ symbols</emphasis>
 geometry</emphasis>
  names typically correspond to the keyboard components from which the current
 keyboard description was assembled. These components are stored individually in
-the server’s database of keyboard components, described in <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+the server’s database of keyboard components, described in
+<link linkend='the_server_database_of_keyboard_components'>
+The Server Database of Keyboard
 Components</link>, and can be combined to assemble a complete keyboard
 description.
 </para>
@@ -130,7 +132,7 @@ customizations are straightforward.
 
 <para>
 Key aliases can be specified both in the symbolic names component and in the
-keyboard geometry (see <link linkend='keyboard_geometry'>See Keyboard
+keyboard geometry (see <link linkend='keyboard_geometry'>Keyboard
 Geometry</link>). Both sets of aliases are always valid, but key alias
 definitions in the keyboard geometry have priority; if both symbolic names and
 geometry include aliases, applications should consider the definitions from the
diff --git a/specs/ch09.xml b/specs/ch09.xml
index c78eba9..8a0eb87 100644
--- a/specs/ch09.xml
+++ b/specs/ch09.xml
@@ -60,7 +60,7 @@ keyboard, it cannot be directly changed under program control. It is possible,
 however, for the set of physical indicators to be change if a new keyboard is
 attached or if a completely new keyboard description is loaded by the <emphasis>
 XkbGetKeyboardByName</emphasis>
- request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
+ request (see <link linkend='using_the_servers_database_of_keyboard_components'>Using the Server’s
 Database of Keyboard Components</link>).
 </para>
 
@@ -88,7 +88,7 @@ XkbGetNames</emphasis>
  request reports the symbolic names for all keyboard components, including the
 indicators. Use the <emphasis>
 XkbSetNames</emphasis>
- request to change symbolic names. Both requests are described in <link linkend='querying_and_changing_symbolic_names'>See Querying and Changing Symbolic
+ request to change symbolic names. Both requests are described in <link linkend='querying_and_changing_symbolic_names'>Querying and Changing Symbolic
 Names</link>.
 </para>
 
@@ -232,7 +232,7 @@ mods</emphasis>
  fields of an indicator map determine how the state of the keyboard modifiers
 affect the corresponding indicator. The <emphasis>
 mods</emphasis>
- field is an XKB modifier definition, as described in <link linkend='modifier_definitions'>See Modifier Definitions</link>, which can
+ field is an XKB modifier definition, as described in <link linkend='modifier_definitions'>Modifier Definitions</link>, which can
 specify both real and virtual modifiers. The mods field takes effect even if
 some or all of the virtual indicators specified in <emphasis>
 mods</emphasis>
@@ -305,7 +305,7 @@ IM_UseCompat</emphasis>
 <para>
 The <emphasis>
 controls</emphasis>
- field specifies a subset of the boolean keyboard controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean" Controls and The
+ field specifies a subset of the boolean keyboard controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>"Boolean" Controls and The
 EnabledControls Control</link>). The indicator is lit whenever any of the
 boolean controls specified in <emphasis>
 controls</emphasis>
diff --git a/specs/ch10.xml b/specs/ch10.xml
index c20622b..bfb99ae 100644
--- a/specs/ch10.xml
+++ b/specs/ch10.xml
@@ -110,7 +110,7 @@ sounds other than simple tones, but it is not required to do so.
 <para>
 Aside from those used by the XKB <emphasis>
 AccessXFeedback</emphasis>
- control (see <link linkend='the_accessxfeedback_control'>See The AccessXFeedback
+ control (see <link linkend='the_accessxfeedback_control'>The AccessXFeedback
 Control</link>), this extension does not specify bell names or their
 interpretation.
 </para>
diff --git a/specs/ch11.xml b/specs/ch11.xml
index 1be90dd..9a32496 100644
--- a/specs/ch11.xml
+++ b/specs/ch11.xml
@@ -79,7 +79,7 @@ structures refer to geometry properties.
 <listitem>
   <para>A list of <emphasis>
 key aliases</emphasis>
-, as described in <link linkend='symbolic_names'>See Symbolic
+, as described in <link linkend='symbolic_names'>Symbolic
 Names</link>.
   </para>
 </listitem>
@@ -89,7 +89,7 @@ shapes</emphasis>
 ; other keyboard components refer to shapes by their index in this list. A
 shape consists of a name and one or more closed-polygons called <emphasis>
 outlines</emphasis>
-. Shapes and outlines are described in detail in <link linkend='shapes_and_outlines'>See Shapes and Outlines</link>.
+. Shapes and outlines are described in detail in <link linkend='shapes_and_outlines'>Shapes and Outlines</link>.
   </para>
 </listitem>
 </itemizedlist>
diff --git a/specs/ch12.xml b/specs/ch12.xml
index cd21a48..d30a213 100644
--- a/specs/ch12.xml
+++ b/specs/ch12.xml
@@ -53,7 +53,7 @@ of a keyboard mapping and XKB and explains the ways they can interact.
 <title>Group Compatibility Map</title>
 
 <para>
-As described in <link linkend='keyboard_state'>See Keyboard
+As described in <link linkend='keyboard_state'>Keyboard
 State</link>, the current keyboard group is reported to XKB-aware clients in
 bits 13-14 of the state field of many core protocol events. XKB-unaware clients
 cannot interpret those bits, but they might use a keyboard modifier to
@@ -243,40 +243,40 @@ field for a key can contain any combination of the following values:
     <entry>ExplicitKeyType1</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group1</emphasis>
- (see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+ (see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
 Symbols for a Key</link>)</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType2</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group2 </emphasis>
-(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
 Symbols for a Key</link>)</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType3</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group3 </emphasis>
-(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
 Symbols for a Key</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType4</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group4 </emphasis>
-(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
 Symbols for a Key</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitInterpret</entry>
     <entry>Application of any of the fields of a symbol interpretation to the
-key in question (see <link linkend='assigning_actions_to_keys'>See Assigning
+key in question (see <link linkend='assigning_actions_to_keys'>Assigning
 Actions To Keys</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitAutoRepeat</entry>
     <entry>Automatic determination of autorepeat status for the key, as
-specified in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+specified in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>Assigning Actions To
 Keys</link>).</entry>
   </row>
   <row rowsep='0'>
@@ -285,14 +285,14 @@ Keys</link>).</entry>
 KB_Lock</emphasis>
  behavior to the key, if the <emphasis>
 LockingKey</emphasis>
- flag is set in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+ flag is set in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>Assigning Actions To
 Keys</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitVModMap</entry>
     <entry>Automatic determination of the virtual modifier map for the key
 based on the actions assigned to the key and the symbol interpretations which
-match the key (see <link linkend='assigning_actions_to_keys'>See Assigning
+match the key (see <link linkend='assigning_actions_to_keys'>Assigning
 Actions To Keys</link>).</entry>
   </row>
 </tbody>
@@ -310,7 +310,7 @@ ChangeKeyboardMapping</emphasis>
 groups that are defined for the key and the width of each group. The XKB
 extension does not change key types in response to core protocol <emphasis>
 SetModifierMapping</emphasis>
- requests, but it does choose key actions as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>.
+ requests, but it does choose key actions as described in <link linkend='assigning_actions_to_keys'>Assigning Actions To Keys</link>.
 </para>
 
 
@@ -487,7 +487,7 @@ ALPHABETIC</emphasis>
     <entry>Describes alphabetic keys that have exactly two symbols per group.
 The default definition of the <emphasis>
 ALPHABETIC</emphasis>
- type provides shift-cancels-caps behavior as described in <link linkend='key_types'>See Key Types</link>. Index <emphasis>
+ type provides shift-cancels-caps behavior as described in <link linkend='key_types'>Key Types</link>. Index <emphasis>
 2</emphasis>
  in any key symbol map specifies key type <emphasis>
 ALPHABETIC</emphasis>
@@ -733,7 +733,7 @@ locking key</emphasis>
  field is set in the symbol interpretation, the behavior of the key is changed
 to <emphasis>
 KB_Lock</emphasis>
- (see <link linkend='key_behavior'>See Key Behavior</link>). The
+ (see <link linkend='key_behavior'>Key Behavior</link>). The
 <emphasis>
 ExplicitBehavior</emphasis>
  component prevents this change.
@@ -787,7 +787,7 @@ indicator maps, internal modifiers or ignore locks modifiers.
 After applying server actions which modify the base, latched or locked modifier
 or group state of the keyboard, the X server recomputes the effective group and
 state. Several components of the keyboard state are reported to XKB-aware
-clients depending on context (see <link linkend='keyboard_state'>See
+clients depending on context (see <link linkend='keyboard_state'>
 Keyboard State</link> for a detailed description of each of the keyboard state
 components):
 </para>
@@ -963,7 +963,7 @@ by all of the actions associated with the key plus all of the modifiers
 associated with any virtual modifiers bound to the key by the virtual modifier
 mapping. If any of the actions associated with a key affect any component of
 the keyboard group, any modifiers specified in any entry of the group
-compatibility map (see <link linkend='group_compatibility_map'>See Group
+compatibility map (see <link linkend='group_compatibility_map'>Group
 Compatibility Map</link>) are reported in the modifier mask. The <emphasis>
 SA_ISOLock</emphasis>
  action can theoretically affect any modifier, but the modifier map of an
diff --git a/specs/ch13.xml b/specs/ch13.xml
index f00a467..9efa7b2 100644
--- a/specs/ch13.xml
+++ b/specs/ch13.xml
@@ -275,7 +275,8 @@ types</emphasis>
  component of a keyboard mapping specifies the key types that can be associated
 with the various keyboard keys. It affects the <emphasis>
 types</emphasis>
- symbolic name and the list of types associated with the keyboard (see <link linkend='key_types'>See Key Types</link>). The types component
+ symbolic name and the list of types associated with the keyboard (see
+<link linkend='key_types'>Key Types</link>). The types component
 of a keyboard mapping can also optionally contain real modifier bindings and
 symbolic names for one or more virtual modifiers.
 </para>
diff --git a/specs/ch14.xml b/specs/ch14.xml
index fcf127a..2da16db 100644
--- a/specs/ch14.xml
+++ b/specs/ch14.xml
@@ -9,7 +9,7 @@ keycodes. The server can generate an <emphasis>
 XkbNewKeyboardNotify</emphasis>
  event when it detects a new keyboard, or in response to an <emphasis>
 XkbGetKeyboardByName</emphasis>
- request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
+ request (see <link linkend='using_the_servers_database_of_keyboard_components'>Using the Server’s
 Database of Keyboard Components</link>) which loads a new keyboard description.
 </para>
 
diff --git a/specs/ch15.xml b/specs/ch15.xml
index 7cca36a..6c56ad6 100644
--- a/specs/ch15.xml
+++ b/specs/ch15.xml
@@ -113,7 +113,7 @@ Keyboard</emphasis>
 
 <para>
 The XKB extension optionally allows clients to assign any key action (see
-<link linkend='key_actions'>See Key Actions</link>) to core
+<link linkend='key_actions'>Key Actions</link>) to core
 pointer or input extension device buttons. This makes it possible to control
 the keyboard or generate keyboard key events from extension devices or from the
 core pointer.
diff --git a/specs/ch16.xml b/specs/ch16.xml
index aeaec30..643ebce 100644
--- a/specs/ch16.xml
+++ b/specs/ch16.xml
@@ -1215,7 +1215,7 @@ affectWhich</emphasis>
 <para>
 If any components are specified in a client’s event masks, the X server sends
 the client an appropriate event whenever any of those components change state.
-Unless explicitly modified, all event detail masks are empty. <link linkend='events'>See Events</link> describes all XKB events
+Unless explicitly modified, all event detail masks are empty. <link linkend='events'>Events</link> describes all XKB events
 and the conditions under which the server generates them.
 </para>
 
@@ -1532,7 +1532,7 @@ effective modifiers minus any server internal modifiers. The <emphasis>
 grabMods</emphasis>
  return value reports the grab modifiers, which consist of the lookup modifiers
 minus any members of the ignore locks mask that are not either latched or
-logically depressed. <link linkend='keyboard_state'>See Keyboard
+logically depressed. <link linkend='keyboard_state'>Keyboard
 State</link> describes the lookup modifiers and grab modifiers in more detail.
 </para>
 
@@ -1556,7 +1556,7 @@ compatGrabMods</emphasis>
  return values report the core protocol compatibility states that correspond to
 the XKB lookup and grab state. All of the compatibility states are computed by
 applying the group compatibility mapping to the corresponding XKB modifier and
-group states, as described in <link linkend='group_compatibility_map'>See
+group states, as described in <link linkend='group_compatibility_map'>
 Group Compatibility Map</link>.
 </para>
 
@@ -1821,13 +1821,14 @@ The <emphasis>
 numGroups</emphasis>
  return value reports the current number of groups, and <emphasis>
 groupsWrap</emphasis>
- reports the treatment of out-of-range groups, as described in <link linkend='key_symbol_map'>See Key Symbol Map</link>. The <emphasis>
+ reports the treatment of out-of-range groups, as described in <link linkend='key_symbol_map'>Key Symbol Map</link>. The <emphasis>
 internalMods</emphasis>
  and <emphasis>
 ignoreLockMods</emphasis>
  return values report the current values of the server internal and ignore
-locks modifiers as described in <link linkend='keyboard_state'>See
-Keyboard State</link>. Both are modifier definitions (<link linkend='modifier_definitions'>See Modifier Definitions</link>) which
+locks modifiers as described in <link linkend='keyboard_state'>
+Keyboard State</link>. Both are modifier definitions (
+<link linkend='modifier_definitions'>Modifier Definitions</link>) which
 report the real modifiers, virtual modifiers, and the resulting combination of
 real modifiers that are bound to the corresponding control.
 </para>
@@ -1854,7 +1855,7 @@ mouseKeysMaxSpeed</emphasis>
  and <emphasis>
 mouseKeysCurve</emphasis>
  return values report the current acceleration applied to mouse keys, as
-described in <link linkend='the_mousekeysaccel_control'>See The MouseKeysAccel
+described in <link linkend='the_mousekeysaccel_control'>The MouseKeysAccel
 Control</link>. All times are reported in milliseconds.
 </para>
 
@@ -2221,7 +2222,8 @@ If applied, <emphasis>
 repeatDelay</emphasis>
  and <emphasis>
 repeatInterval</emphasis>
- change the autorepeat characteristics of the keyboard, as described in <link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>. If
+ change the autorepeat characteristics of the keyboard, as described in
+<link linkend='the_repeatkeys_control'>The RepeatKeys Control</link>. If
 specified, <emphasis>
 repeatDelay</emphasis>
  and <emphasis>
@@ -2237,7 +2239,7 @@ If applied, the <emphasis>
 slowKeysDelay</emphasis>
  field specifies a new delay for the <emphasis>
 SlowKeys</emphasis>
- control, as defined in <link linkend='the_slowkeys_control'>See The
+ control, as defined in <link linkend='the_slowkeys_control'>The
 SlowKeys Control</link>. If specified, <emphasis>
 slowKeysDelay</emphasis>
  must be non-zero, or a <emphasis>
@@ -2251,7 +2253,7 @@ If applied, the <emphasis>
 debounceDelay</emphasis>
  field specifies a new delay for the <emphasis>
 BounceKeys</emphasis>
- control, as described in <link linkend='the_bouncekeys_control'>See The
+ control, as described in <link linkend='the_bouncekeys_control'>The
 BounceKeys Control</link>. If present, the <emphasis>
 debounceDelay</emphasis>
  must be non-zero or a <emphasis>
@@ -2272,7 +2274,7 @@ SA_LockPtrBtn</emphasis>
 mouseKeysDfltBtn</emphasis>
  must specify a legal button for the core pointer device, or a <emphasis>
 Value</emphasis>
- error results. <link linkend='key_actions'>See Key
+ error results. <link linkend='key_actions'>Key
 Actions</link> describes the <emphasis>
 SA_PtrBtn</emphasis>
  and <emphasis>
@@ -2295,7 +2297,7 @@ mouseKeysCurve</emphasis>
  fields change the rate at which the pointer moves when a key which generates a
 <emphasis>
 SA_MovePtr</emphasis>
- action is held down. <link linkend='the_mousekeysaccel_control'>See The
+ action is held down. <link linkend='the_mousekeysaccel_control'>The
 MouseKeysAccel Control</link> describes these <emphasis>
 MouseKeysAccel</emphasis>
  parameters in more detail. If defined, the <emphasis>
@@ -2321,7 +2323,8 @@ Value</emphasis>
 <para>
 If applied, the <emphasis>
 accessXOptions</emphasis>
- field sets the AccessX options, which are described in detail in <link linkend='the_accessxkeys_control'>See The AccessXKeys Control</link>. If
+ field sets the AccessX options, which are described in detail in
+<link linkend='the_accessxkeys_control'>The AccessXKeys Control</link>. If
 either one of <emphasis>
 XkbStickyKeysMask</emphasis>
  and <emphasis>
@@ -2355,7 +2358,7 @@ accessXTimeoutOptionsMask</emphasis>
  and <emphasis>
 accessXTimeoutOptionsValues</emphasis>
  fields change the behavior of the AccessX Timeout control, as described in
-<link linkend='the_accessxtimeout_control'>See The AccessXTimeout
+<link linkend='the_accessxtimeout_control'>The AccessXTimeout
 Control</link>. The <emphasis>
 accessXTimeout</emphasis>
  must be greater than zero, or a <emphasis>
@@ -2383,7 +2386,7 @@ Match</emphasis>
 If present, the <emphasis>
 groupsWrap</emphasis>
  field specifies the treatment of out-of-range keyboard groups, as described in
-<link linkend='key_symbol_map'>See Key Symbol Map</link>. If the
+<link linkend='key_symbol_map'>Key Symbol Map</link>. If the
 <emphasis>
 groupsWrap</emphasis>
  field does not specify a legal treatment for out-of-range groups, a <emphasis>
@@ -3323,7 +3326,7 @@ flags</emphasis>
 last key type specified by this request is the last element in the list. If the
 list of key types is shrunk, any existing key definitions that use key types
 that eliminated are automatically assigned key types from the list of canonical
-key types as described in <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See
+key types as described in <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>
 Assigning Types To Groups of Symbols for a Key</link>. The list of key types
 bound to a keyboard must always include the four canonical types and cannot
 have more than <emphasis>
@@ -3736,7 +3739,8 @@ XkbSetMapRecomputeActions</emphasis>
  bit is set in <emphasis>
 flags</emphasis>
 , the actions associated with any keys for which symbol or modifier bindings
-were changed by this request are recomputed as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>. Note
+were changed by this request are recomputed as described in
+<link linkend='assigning_actions_to_keys'>Assigning Actions To Keys</link>. Note
 that actions are recomputed <emphasis>
 after </emphasis>
 any actions specified in this request are bound to keys, so the actions
@@ -4082,7 +4086,7 @@ recomputeActions</emphasis>
 True</emphasis>
 , the server regenerates recalculates the actions bound to all keyboard keys by
 applying the new symbol interpretations to the entire key symbol map, as
-described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+described in <link linkend='assigning_actions_to_keys'>Assigning Actions To
 Keys</link>.
 </para>
 
@@ -4239,7 +4243,7 @@ XkbIndicatorStateNotify</emphasis>
 The <emphasis>
 maps</emphasis>
  return value reports the requested indicator maps. Indicator maps are
-described in <link linkend='indicator_maps'>See Indicator Maps</link>
+described in <link linkend='indicator_maps'>Indicator Maps</link>
 </para>
 
 
@@ -4713,7 +4717,7 @@ If <emphasis>
 setMap </emphasis>
 is <emphasis>
 True</emphasis>
-, XKB changes the map for the indicator (see <link linkend='indicator_maps'>See Indicator Maps</link>) to reflect the
+, XKB changes the map for the indicator (see <link linkend='indicator_maps'>Indicator Maps</link>) to reflect the
 values specified in <emphasis>
 map</emphasis>
 .
@@ -5522,7 +5526,7 @@ name</emphasis>
  is a valid atom other than <emphasis>
 None</emphasis>
 , the server returns the keyboard geometry description with that name in the
-server database of keyboard components (see <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+server database of keyboard components (see <link linkend='the_server_database_of_keyboard_components'>The Server Database of Keyboard
 Components</link>) if one exists. If <emphasis>
 deviceSpec</emphasis>
  does not specify a valid keyboard device, a <emphasis>
@@ -5562,7 +5566,7 @@ found</emphasis>
 True</emphasis>
 , the remaining fields of the reply describe the requested keyboard geometry.
 The interpretation of the components that make up a keyboard geometry is
-described in detail in <link linkend='keyboard_geometry'>See Keyboard
+described in detail in <link linkend='keyboard_geometry'>Keyboard
 Geometry</link>
 </para>
 
@@ -5855,35 +5859,35 @@ per-client-flags are:
     <entry><emphasis>
 XkbPCF_DetectableAutorepeat</emphasis>
 </entry>
-    <entry><link linkend='detectable_autorepeat'>See Detectable
+    <entry><link linkend='detectable_autorepeat'>Detectable
 Autorepeat</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_GrabsUseXKBStateMask</emphasis>
 </entry>
-    <entry><link linkend='setting_a_passive_grab_for_an_xkb_state'>See Setting a Passive Grab
+    <entry><link linkend='setting_a_passive_grab_for_an_xkb_state'>Setting a Passive Grab
 for an XKB State</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_AutoResetControlsMask</emphasis>
 </entry>
-    <entry><link linkend='automatic_reset_of_boolean_controls'>See Automatic Reset of
+    <entry><link linkend='automatic_reset_of_boolean_controls'>Automatic Reset of
 Boolean Controls</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_LookupStateWhenGrabbed</emphasis>
 </entry>
-    <entry><link linkend='effects_of_xkb_on_core_protocol_events'>See Effects of XKB on Core
+    <entry><link linkend='effects_of_xkb_on_core_protocol_events'>Effects of XKB on Core
 Protocol Events</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_SendEventUsesXKBState</emphasis>
 </entry>
-    <entry><link linkend='sending_events_to_clients'>See Sending Events to
+    <entry><link linkend='sending_events_to_clients'>Sending Events to
 Clients</link></entry>
   </row>
 </tbody>
@@ -6109,7 +6113,7 @@ components.
 <para>
 Each pattern uses the ISO Latin-1 encoding and should contain only parentheses,
 the wildcard characters "?" and "*" or characters that are permitted in a
-component class or member name (see <link linkend='component_names'>See Component Names</link>). Illegal
+component class or member name (see <link linkend='component_names'>Component Names</link>). Illegal
 characters in a pattern are simply ignored; no error results if a pattern
 contains illegal characters.
 </para>
@@ -6153,14 +6157,14 @@ compatMaps</emphasis>
 symbols</emphasis>
  and <emphasis>
 geometries</emphasis>
- return the hints (see <link linkend='component_hints'>See Component
+ return the hints (see <link linkend='component_hints'>Component
 Hints</link>) and names of any components from the server database that match
 the corresponding pattern.
 </para>
 
 
 <para>
-<link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+<link linkend='the_server_database_of_keyboard_components'>The Server Database of Keyboard
 Components</link> describes the X server database of keyboard components in
 more detail.
 </para>
@@ -6300,7 +6304,7 @@ compatMapSpec</emphasis>
 symbolsSpec</emphasis>
  and <emphasis>
 geometrySpec</emphasis>
- component expressions (see <link linkend='partial_components_and_combining_multiple_components'>See
+ component expressions (see <link linkend='partial_components_and_combining_multiple_components'>
 Partial Components and Combining Multiple Components</link>) specify the
 database components to be used to assemble the keyboard description.
 </para>
@@ -6410,7 +6414,7 @@ If either field contains a GBN component that depends on some database
 component for which the request does not supply an expression, XKB
 automatically substitutes the special pattern "%" which copies the
 corresponding component from the current keyboard description, as described in
-<link linkend='partial_components_and_combining_multiple_components'>See Partial Components and Combining
+<link linkend='partial_components_and_combining_multiple_components'>Partial Components and Combining
 Multiple Components</link>.
 </para>
 
@@ -6434,7 +6438,8 @@ If all necessary components are both specified and found, the new keyboard
 description is loaded. If the new keyboard description has a different geometry
 or keycode range than the previous keyboard description, XKB sends <emphasis>
 XkbNewKeyboardNotify</emphasis>
- events to all interested clients. See <link linkend='replacing_the_keyboard_on_the_fly'>See Replacing the Keyboard
+ events to all interested clients. See
+<link linkend='replacing_the_keyboard_on_the_fly'>Replacing the Keyboard
 "On-the-Fly"</link> for more information about the effects of replacing the
 keyboard description on the fly.
 </para>
@@ -6885,7 +6890,9 @@ deviceID</emphasis>
 which values are being returned. The <emphasis>
 supported</emphasis>
  return value reports the set of optional XKB extension device features that
-are supported by this implementation (see <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between XKB and the X Input
+are supported by this implementation (see
+<link linkend='interactions_between_xkb_and_the_x_input_extension'>
+Interactions Between XKB and the X Input
 Extension</link>) for the specified device, and the unsupported return value
 reports any <emphasis>
 unsupported</emphasis>
@@ -7532,7 +7539,7 @@ Once a client receives a new keyboard notify event which reports a new keycode
 range, the X server reports events from all keys in the new range to that
 client. Clients that do not request or receive new keyboard notify events
 receive events only from keys that fall in the last range for legal keys
-reported to that client. See <link linkend='replacing_the_keyboard_on_the_fly'>See
+reported to that client. See <link linkend='replacing_the_keyboard_on_the_fly'>
 Replacing the Keyboard "On-the-Fly"</link> for a more detailed explanation.
 </para>
 
@@ -7898,9 +7905,9 @@ requestMajor, requestMinor: CARD8</entry>
 </informaltable>
 
 <para>
-An <emphasis>
-XkbStateNotify</emphasis>
- event reports that some component of the XKB state (see <link linkend='keyboard_state'>See Keyboard State</link>) has changed.
+An <emphasis>XkbStateNotify</emphasis>
+event reports that some component of the XKB state (see
+<link linkend='keyboard_state'>Keyboard State</link>) has changed.
 State notify events are usually caused by key or pointer activity, but they can
 also result from explicit state changes requested by the <emphasis>
 XkbLatchLockState</emphasis>
@@ -7914,7 +7921,8 @@ deviceID</emphasis>
  field reports the keyboard on which some state component changed. The
 <emphasis>
 changed</emphasis>
- field reports the XKB state components (see <link linkend='keyboard_state'>See Keyboard State</link>) that have changed
+ field reports the XKB state components (see
+<link linkend='keyboard_state'>Keyboard State</link>) that have changed
 and contain any combination of:
 </para>
 
@@ -8163,8 +8171,10 @@ requestMinor: CARD8</entry>
 An <emphasis>
 XkbControlsNotify</emphasis>
  event reports a change in one or more of the global keyboard controls (see
-<link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>)
-or in the internal modifiers or ignore locks masks (see <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and Ignore
+<link linkend='global_keyboard_controls'>Global Keyboard Controls</link>)
+or in the internal modifiers or ignore locks masks (see
+<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>
+Server Internal Modifiers and Ignore
 Locks Behavior</link>). Controls notify events are usually caused by and
 <emphasis>
 XkbSetControls</emphasis>
@@ -9167,8 +9177,9 @@ detail</emphasis>
 slowKeysDelay</emphasis>
  and <emphasis>
 debounceDelay</emphasis>
- fields always reports the current slow keys acceptance delay (see <link linkend='the_slowkeys_control'>See The SlowKeys Control</link>) and
-debounce delay (see <link linkend='the_bouncekeys_control'>See The BounceKeys
+ fields always reports the current slow keys acceptance delay (see
+<link linkend='the_slowkeys_control'>The SlowKeys Control</link>) and
+debounce delay (see <link linkend='the_bouncekeys_control'>The BounceKeys
 Control</link>) for the specified keyboard.
 </para>
 
@@ -9333,7 +9344,7 @@ extension device feature that is not supported by the XKB implementation in the
 server for the specified device. The <emphasis>
 unsupported</emphasis>
  mask reports the requested features that are not available on the specified
-device. See <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between
+device. See <link linkend='interactions_between_xkb_and_the_x_input_extension'>Interactions Between
 XKB and the X Input Extension</link> for more information about possible XKB
 interactions with the X Input Extension.
 </para>