specs/libX11: Convert simpler eqn markup to docbook tags

Mostly "sup" to <superscript>

There's several more complicated equations that will probably need
MathML or SVG to solve.

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

3 files changed, 23 insertions, 30 deletions

diff --git a/specs/libX11/CH06.xml b/specs/libX11/CH06.xml
index 607870e2..3f5c843d 100644
--- a/specs/libX11/CH06.xml
+++ b/specs/libX11/CH06.xml
@@ -1,3 +1,6 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
 <chapter id="color_management_functions">
 <title>Color Management Functions</title>
 <!-- .sp 2 -->
@@ -1994,9 +1997,6 @@ pixels_return array.
 <para>
 <!-- .LP -->
 <!-- .eM -->
-<!-- .EQ -->
-delim %%
-<!-- .EN -->
 The
 <function>XAllocColorCells</function>
 function allocates read/write color cells.
@@ -2010,7 +2010,8 @@ and nplane plane masks are returned.
 No mask will have any bits set to 1 in common with
 any other mask or with any of the pixels.
 By ORing together each pixel with zero or more masks,
-ncolors * %2 sup nplanes% distinct pixels can be produced.
+ncolors &times; 2<superscript><emphasis>nplanes</emphasis></superscript>
+distinct pixels can be produced.
 All of these are
 allocated writable by the request.
 For 
@@ -2197,9 +2198,6 @@ Return bit masks for the red, green, and blue planes.
 <para>
 <!-- .LP -->
 <!-- .eM -->
-<!-- .EQ -->
-delim %%
-<!-- .EN -->
 The specified ncolors must be positive; 
 and nreds, ngreens, and nblues must be nonnegative,
 or a
@@ -2220,12 +2218,17 @@ each mask
 will lie within the corresponding pixel subfield.
 By ORing together
 subsets of masks with each pixel value, 
-ncolors * %2 sup (nreds+ngreens+nblues)% distinct pixel values can be produced. 
+ncolors &times; 2<superscript><emphasis>(nreds+ngreens+nblues)</emphasis></superscript>
+distinct pixel values can be produced.
 All of these are allocated by the request.
 However, in the
-colormap, there are only ncolors * %2 sup nreds% independent red entries, 
-ncolors * %2 sup ngreens% independent green entries, 
-and ncolors * %2 sup nblues% independent blue entries. 
+colormap, there are only
+ncolors &times; 2<superscript><emphasis>nreds</emphasis></superscript>
+independent red entries,
+ncolors &times; 2<superscript><emphasis>ngreens</emphasis></superscript>
+independent green entries, and
+ncolors &times; 2<superscript><emphasis>nblues</emphasis></superscript>
+independent blue entries.
 This is true even for 
 <symbol>PseudoColor</symbol>.
 When the colormap entry of a pixel
diff --git a/specs/libX11/CH15.xml b/specs/libX11/CH15.xml
index 76ff14ac..98410194 100644
--- a/specs/libX11/CH15.xml
+++ b/specs/libX11/CH15.xml
@@ -1484,9 +1484,6 @@ otherwise, they return
 <para>
 <!-- .LP -->
 <!-- .sp -->
-<!-- .EQ -->
-<!-- delim %% -->
-<!-- .EN -->
 Most applications and toolkits do not make random probes
 into a resource database to fetch resources.
 The X toolkit access pattern for a resource database is quite stylized.
@@ -1494,7 +1491,8 @@ A series of from 1 to 20 probes is made with only the
 last name/class differing in each probe.
 The 
 <function>XrmGetResource</function>
-function is at worst a %2 sup n% algorithm,  <!-- FIXME: log(n) ?  -->
+function is at worst a
+2<superscript><emphasis remap='I'>n</emphasis></superscript> algorithm,
 where <emphasis remap='I'>n</emphasis> is the length of the name/class list.
 This can be improved upon by the application programmer by prefetching a list
 of database levels that might match the first part of a name/class list.
@@ -1595,8 +1593,10 @@ otherwise, it returns
 The size of the search list that the caller must allocate is
 dependent upon the number of levels and wildcards in the resource specifiers 
 that are stored in the database.
-The worst case length is %3 sup n%,
-where <emphasis remap='I'>n</emphasis> is the number of name or class components in names or classes.
+The worst case length is
+3<superscript><emphasis remap='I'>n</emphasis></superscript>,
+where <emphasis remap='I'>n</emphasis> is the number of name or class
+components in names or classes.
 </para>
 <para>
 <!-- .LP -->
diff --git a/specs/libX11/glossary.xml b/specs/libX11/glossary.xml
index 69142d61..5d963cb6 100644
--- a/specs/libX11/glossary.xml
+++ b/specs/libX11/glossary.xml
@@ -1065,12 +1065,10 @@ displayed.
   <glossterm>Pixmap</glossterm>
   <glossdef>
 <indexterm significance="preferred"><primary>Pixmap</primary></indexterm>
-<!-- .EQ -->
-<!-- .EN -->
     <para>
 A pixmap is a three-dimensional array of bits.  
 A pixmap is normally thought of as a two-dimensional array of pixels, 
-where each pixel can be a value from 0 to %2 sup N %\-1, 
+where each pixel can be a value from 0 to 2<superscript>N</superscript>-1,
 and where N is the depth (z axis) of the pixmap.  
 A pixmap can also be thought of as a stack of N bitmaps.
 A pixmap can only be used on the screen that it was created in.
@@ -1667,19 +1665,11 @@ Manipulation of windows on the screen and much of the user interface
     <para>
 A basic set of 97 characters which are assumed to exist in all
 locales supported by Xlib.  This set contains the following characters:
-    </para>
-    <para>
-<!-- .Ds 0 -->
-<!-- .EQ -->
-<!-- .EN -->
-    </para>
-    <para>
+      <literallayout>
 a..z A..Z 0..9
 !"#$%&amp;'()*+,-./:;&lt;=&gt;?@[\\]^_`{|}~
 &lt;space&gt;, &lt;tab&gt;, and &lt;newline&gt;
-<!-- .EQ -->
-<!-- .EN -->
-<!-- .De -->
+      </literallayout>
     </para>
     <para>
 This is the left/lower half (also called the G0 set)