diff options
authorAlan Coopersmith <>2010-07-16 20:41:33 -0700
committerAlan Coopersmith <>2010-07-16 20:41:33 -0700
commitc7b7e59b3b22221d0be6286c540001c360308f69 (patch)
parent897486c54c6a54771867d667441aaf9a4b9c35ca (diff)
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 <>
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"
+ "">
<chapter id="color_management_functions">
<title>Color Management Functions</title>
<!-- .sp 2 -->
@@ -1994,9 +1997,6 @@ pixels_return array.
<!-- .LP -->
<!-- .eM -->
-<!-- .EQ -->
-delim %%
-<!-- .EN -->
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.
@@ -2197,9 +2198,6 @@ Return bit masks for the red, green, and blue planes.
<!-- .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
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
<!-- .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.
-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.
<!-- .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.
<indexterm significance="preferred"><primary>Pixmap</primary></indexterm>
-<!-- .EQ -->
-<!-- .EN -->
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
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
&lt;space&gt;, &lt;tab&gt;, and &lt;newline&gt;
-<!-- .EQ -->
-<!-- .EN -->
-<!-- .De -->
+ </literallayout>
This is the left/lower half (also called the G0 set)