specs/XKB: Add <figure> tags and make Figure references link to them

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This commit is contained in:
Alan Coopersmith 2014-07-07 22:22:28 -07:00
parent 087a233847
commit fcda446877
11 changed files with 147 additions and 110 deletions

View file

@ -105,15 +105,17 @@ server and Xlib versions must be at least X11 R6.
<para>
Figure 1.1 shows the overall structure of the Xkb extension:
<link linkend="figure1.1">Figure 1.1</link> shows the overall structure of the Xkb extension:
</para>
<mediaobject>
<imageobject>
<imagedata format="SVG" fileref="XKBlib-1.svg"/>
</imageobject>
<caption>Overall Xkb Structure</caption>
</mediaobject>
<figure id='figure1.1'>
<title>Overall Xkb Structure</title>
<mediaobject>
<imageobject>
<imagedata format="SVG" fileref="XKBlib-1.svg"/>
</imageobject>
</mediaobject>
</figure>
<para>
@ -131,7 +133,7 @@ but also potentially a set of up to 32 indicators (usually LEDs) and bells.
The keyboard description is a composite of several different data structures,
each of which may be manipulated separately. When manipulating the server
components, the design allows partial components to be transmitted between the
server and a client. The individual components are shown in Figure 1.1.
server and a client. The individual components are shown in <link linkend="figure1.1">Figure 1.1</link>.
</para>
<variablelist>

View file

@ -2,15 +2,17 @@
<title>Keyboard State</title>
<para>
Keyboard state encompasses all of the transitory information necessary to map a physical key press or release to an appropriate event. The Xkb keyboard state consists of primitive components and additional derived components that are maintained for efficiency reasons. Figure 5.1 shows the components of Xkb keyboard state and their relationships.
Keyboard state encompasses all of the transitory information necessary to map a physical key press or release to an appropriate event. The Xkb keyboard state consists of primitive components and additional derived components that are maintained for efficiency reasons. <link linkend="figure5.1">Figure 5.1</link> shows the components of Xkb keyboard state and their relationships.
</para>
<mediaobject>
<!-- <title>Keyboard State Description</title> -->
<imageobject> <imagedata format="SVG" fileref="XKBlib-2.svg"/>
</imageobject>
<caption>Xkb State</caption>
</mediaobject>
<figure id='figure5.1'>
<title>Xkb State</title>
<mediaobject>
<!-- <title>Keyboard State Description</title> -->
<imageobject> <imagedata format="SVG" fileref="XKBlib-2.svg"/>
</imageobject>
</mediaobject>
</figure>
<sect1 id='Keyboard_State_Description'>

View file

@ -16,7 +16,7 @@ The complete description of an Xkb keyboard is given by an
<emphasis>XkbDescRec</emphasis>.
The component structures in the
<emphasis>XkbDescRec</emphasis>
represent the major Xkb components outlined in Figure 1.1. <!-- xref -->
represent the major Xkb components outlined in <link linkend="figure1.1">Figure 1.1</link>.
</para>
<para><programlisting>

View file

@ -169,7 +169,7 @@ The binding of virtual modifiers to real modifiers is defined by the
structure. Each entry contains the real modifier bits that are bound to the
virtual modifier corresponding to the entry. The overall relationship of fields
dealing with virtual modifiers in the server keyboard description are shown in
Figure 16.2. <!-- xref -->
<link linkend="figure16.2">Figure 16.2</link>.
</para>

View file

@ -1457,14 +1457,17 @@ The legal values for
<para>
A distance vs. time graph of the pointer motion is shown in Figure 10.1. <!-- xref -->
A distance vs. time graph of the pointer motion is shown in
<link linkend="figure10.1">Figure 10.1</link>.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-6.svg"/>
</imageobject>
<caption>MouseKeys Acceleration</caption>
</mediaobject>
<figure id='figure10.1'>
<title>MouseKeys Acceleration</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-6.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
<H5 CLASS="Figure">

View file

@ -28,14 +28,16 @@ rectangular area, but the entire rectangle may not be in alignment with the
rest of the keyboard, and instead, it is rotated from horizontal by 30
<emphasis>o</emphasis>.
Rotation for a geometry object is specified in 1/10 o increments about its
origin. An example of a keyboard with rotated sections is shown in Figure 13.1.
origin. An example of a keyboard with rotated sections is shown in <link linkend="figure13.1">Figure 13.1</link>.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-7.svg"/>
</imageobject>
<caption>Rotated Keyboard Sections</caption>
</mediaobject>
<figure id='figure13.1'>
<title>Rotated Keyboard Sections</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-7.svg"/>
</imageobject>
</mediaobject>
</figure>
<!-- <H5 CLASS="Figure">
@ -223,18 +225,20 @@ The keyboard is subdivided into named
listed in the
<emphasis>XkbGeometryRec</emphasis>
top-level keyboard geometry description. A section is composed of keys that
are physically together and logically related. Figure 13.2 shows a keyboard
are physically together and logically related. <link linkend="figure13.2">Figure 13.2</link> shows a keyboard
that is divided into four sections. A
<emphasis>doodad</emphasis>
describes some visible aspect of the keyboard that is not a key and is not a
section.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-8.svg"/>
</imageobject>
<caption>Keyboard with Four Sections</caption>
</mediaobject>
<figure id='figure13.2'>
<title>Keyboard with Four Sections</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-8.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
<H5 CLASS="Figure">
@ -388,18 +392,20 @@ A list of
A row is a list of horizontally or vertically adjacent keys. Horizontal rows
parallel the (prerotation) top of the section, and vertical rows parallel the
(prerotation) left of the section. All keys in a horizontal row share a common
top coordinate; all keys in a vertical row share a left coordinate. Figure 13.3
shows the alpha section from the keyboard shown in Figure 13.2, divided into
top coordinate; all keys in a vertical row share a left coordinate. <link linkend="figure13.3">Figure 13.3</link>
shows the alpha section from the keyboard shown in <link linkend="figure13.2">Figure 13.2</link>, divided into
rows. Rows and keys are defined below.
</para>
</listitem>
</itemizedlist>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-9.svg"/>
</imageobject>
<caption>Rows in a Section</caption>
</mediaobject>
<figure id='figure13.3'>
<title>Rows in a Section</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-9.svg"/>
</imageobject>
</mediaobject>
</figure>
@ -689,11 +695,13 @@ pointer into the array.
<MAP NAME="XKBlib-10">
</MAP>
-->
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-10.svg"/>
</imageobject>
<caption>Xkb Geometry Data Structures</caption>
</mediaobject>
<figure id='figure13.4'>
<title>Xkb Geometry Data Structures</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-10.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
<H5 CLASS="Figure">
@ -703,11 +711,13 @@ Xkb Geometry Data Structures</H5>
<MAP NAME="XKBlib-11">
</MAP>
-->
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-11.svg"/>
</imageobject>
<caption>Xkb Geometry Data Structures (Doodads)</caption>
</mediaobject>
<figure id='figure13.5'>
<title>Xkb Geometry Data Structures (Doodads)</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-11.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
<H5 CLASS="Figure">
@ -718,11 +728,13 @@ Xkb Geometry Data Structures (Doodads)</H5>
<MAP NAME="XKBlib-12">
</MAP>
-->
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-12.svg"/>
</imageobject>
<caption>Xkb Geometry Data Structures (Overlays)</caption>
</mediaobject>
<figure id='figure13.6'>
<title>Xkb Geometry Data Structures (Overlays)</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-12.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
<H5 CLASS="Figure">
@ -1211,11 +1223,13 @@ of a number of points. The bounding box of a shape is a rectangle that contains
all the outlines of that shape.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-13.svg"/>
</imageobject>
<caption>Key Surface, Shape Outlines, and Bounding Box</caption>
</mediaobject>
<figure id='figure13.7'>
<title>Key Surface, Shape Outlines, and Bounding Box</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-13.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--

View file

@ -92,11 +92,13 @@ For example, consider the following key (the gray characters indicate symbols
that are implied or expected but are not actually engraved on the key):
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-14.svg"/>
</imageobject>
<caption>Shift Levels and Groups</caption>
</mediaobject>
<figure id='figure14.1'>
<title>Shift Levels and Groups</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-14.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
@ -121,7 +123,7 @@ and the symbol for shift level two is
<para>
The standard interpretation rules for the core X keymap only allow clients to
access keys such as the one shown in Figure 14.1. That is, clients using the
access keys such as the one shown in <link linkend="figure14.1">Figure 14.1</link>. That is, clients using the
standard interpretation rules can only access one of four keysyms for any given
<symbol>KeyPress</symbol>
event — two different symbols in two different groups.

View file

@ -10,14 +10,16 @@ bound to a key and the rules to be used to interpret those symbols.
<para>
Figure 15.1 shows the relationships between elements in the client map:
<link linkend="figure15.1">Figure 15.1</link> shows the relationships between elements in the client map:
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-15.svg"/>
</imageobject>
<caption>Xkb Client Map</caption>
</mediaobject>
<figure id='figure15.1'>
<title>Xkb Client Map</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-15.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--

View file

@ -10,14 +10,16 @@ to the Xkb server map.
<para>
Figure 16.1 shows the relationships between elements in the server map:
<link linkend="figure16.1">Figure 16.1</link> shows the relationships between elements in the server map:
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-16.svg"/>
</imageobject>
<caption>Server Map Relationships</caption>
</mediaobject>
<figure id='figure16.1'>
<title>Server Map Relationships</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-16.svg"/>
</imageobject>
</mediaobject>
</figure>
<!--
@ -4577,14 +4579,16 @@ use virtual modifier mappings.
<para>
The overall relationship of fields dealing with virtual modifiers in an Xkb
keyboard description are shown in Figure 16.2.
keyboard description are shown in <link linkend="figure16.2">Figure 16.2</link>.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-17.svg"/>
</imageobject>
<caption>Virtual Modifier Relationships</caption>
</mediaobject>
<figure id='figure16.2'>
<title>Virtual Modifier Relationships</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-17.svg"/>
</imageobject>
</mediaobject>
</figure>

View file

@ -2,7 +2,7 @@
<title>The Xkb Compatibility Map</title>
<para>
As shown in Figure 17.1, the X server is normally dealing with more than one
As shown in <link linkend="figure17.1">Figure 17.1</link>, the X server is normally dealing with more than one
client, each of which may be receiving events from the keyboard, and each of
which may issue requests to modify the keyboard in some manner. Each client may
be either Xkb-unaware, Xkb-capable, or Xkb-aware. The server itself may be
@ -15,11 +15,13 @@ Consequently, for some situations, conversions must be made between Xkb state /
keyboard mappings and core protocol state / keyboard mappings, and vice versa.
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-18.svg"/>
</imageobject>
<caption>Server Interaction with Types of Clients</caption>
</mediaobject>
<figure id='figure17.1'>
<title>Server Interaction with Types of Clients</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-18.svg"/>
</imageobject>
</mediaobject>
</figure>
@ -50,17 +52,19 @@ to update its Xkb keyboard mapping. When the server receives an
the request, then uses its compatibility map to update the corresponding parts
of its core keyboard map. Consequently, the servers Xkb keyboard map and
also its core keyboard map may contain components that were set directly and
others that were computed. Figure 17.2 illustrates these relationships.
others that were computed. <link linkend="figure17.2">Figure 17.2</link> illustrates these relationships.
</para>
<note><para>The core keyboard map is contained only in the server, not in any
client-side data structures.</para></note>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-19.svg"/>
</imageobject>
<caption>Server Derivation of State and Keyboard Mapping Components</caption>
</mediaobject>
<figure id='figure17.2'>
<title>Server Derivation of State and Keyboard Mapping Components</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-19.svg"/>
</imageobject>
</mediaobject>
</figure>
@ -157,11 +161,13 @@ typedef struct _XkbCompatMapRec {
} <emphasis>XkbCompatMapRec</emphasis>, *XkbCompatMapPtr;
</programlisting></para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-20.svg"/>
</imageobject>
<caption>Xkb Compatibility Data Structures</caption>
</mediaobject>
<figure id='figure17.3'>
<title>Xkb Compatibility Data Structures</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-20.svg"/>
</imageobject>
</mediaobject>
</figure>
<para>
@ -174,7 +180,7 @@ transformations are made.
<title>Xkb State to Core Protocol State Transformation</title>
<para>
As shown in Figure 17.3, there are four
As shown in <link linkend="figure17.3">Figure 17.3</link>, there are four
<emphasis>group compatibility maps</emphasis>
(contained in
<emphasis>groups</emphasis>
@ -396,7 +402,7 @@ using
<emphasis>sym_interpret</emphasis>
field of an
<emphasis>XkbCompatMapRec</emphasis>
(see Figure 17.3).
(see <link linkend="figure17.3">Figure 17.3</link>).
</para>
<sect3 id='Symbol_Interpretations__the_XkbSymInterpretRec_Structure'>

View file

@ -966,11 +966,13 @@ database of components and returning all or part of it is diagrammed in Figure
20.1:
</para>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-21.svg"/>
</imageobject>
<caption>Building a New Keyboard Description from the Server Database</caption>
</mediaobject>
<figure id='figure20.1'>
<title>Building a New Keyboard Description from the Server Database</title>
<mediaobject>
<imageobject> <imagedata format="SVG" fileref="XKBlib-21.svg"/>
</imageobject>
</mediaobject>
</figure>
<para>
The information returned to the client in the