25% done with Chap 1.

1 files changed, 201 insertions, 566 deletions

diff --git a/specs/CH01.xml b/specs/CH01.xml
index ad17cb8..7df45fa 100644
--- a/specs/CH01.xml
+++ b/specs/CH01.xml
@@ -40,36 +40,20 @@
 <!-- .\" It is provided ``as is'' without express or implied warranty. -->
 <!-- .\" -->
 \&
-<!-- .sp 1 -->
-<!-- .ce 3 -->
-\s+1<function>Chapter 1</function>\s-1
-
-\s+1<function>Intrinsics and Widgets</function>\s-1
-<!-- .sp 2 -->
-<!-- .if \n(GS .nr nh*hl 1 -->
-<!-- .nr H1 1 -->
-<!-- .nr H2 0 -->
-<!-- .nr H3 0 -->
-<!-- .nr H4 0 -->
-<!-- .nr H5 0 -->
-<para>
-<!-- .LP -->
-<!-- .XS -->
-<!-- <function>Chapter 1 \(em Intrinsics and Widgets</function> -->
-<!-- .XE -->
+
+<chapter id='Intrinsics_and_Widgets'>
+<title>Intrinsics and Widgets</title>
+<sect1>
+<para>
 The (xI are a programming library tailored to the special requirements
 of user interface construction within a network window system,
 specifically the X Window System.
 The (xI and a widget set make up an (tk.
-
 </para>
+
 <sect2 id="Intrinsics">
 <title>Intrinsics</title>
-<!-- .XS -->
-<!-- <function>(SN Intrinsics</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The (xI provide the base mechanism necessary to build
 a wide variety of interoperating widget sets and application environments.
 The Intrinsics are a layer on top of Xlib, the
@@ -78,8 +62,8 @@ fundamental abstractions provided by the X Window System while still
 remaining independent of any particular user interface policy or
 style.
 </para>
+
 <para>
-<!-- .LP -->
 The Intrinsics use object-oriented programming techniques to supply a
 consistent architecture for constructing and composing user interface
 components, known as widgets.  This
@@ -88,7 +72,6 @@ deriving new widgets from existing ones (subclassing) or by writing
 entirely new widgets following the established conventions.
 </para>
 <para>
-<!-- .LP -->
 When the (xI were first conceived, the root of the object
 hierarchy was a widget class named
 Core.
@@ -107,16 +90,12 @@ for each Intrinsics procedure and Chapter 12 describe which operations
 are defined for the nonwidget superclasses of Core.  The reader may
 determine by context whether a specific reference to <emphasis remap='I'>widget</emphasis>
 actually means ``widget'' or ``object.''
-
 </para>
 </sect2>
+
 <sect2 id="Languages">
 <title>Languages</title>
-<!-- .XS -->
-<!-- <function>(SN Languages</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The Intrinsics are intended to be used for two programming purposes.
 Programmers writing widgets will be using most of the facilities
 provided by the
@@ -135,8 +114,8 @@ from the C language.  In these cases, the usual C programming
 conventions apply.  In this specification, the term <emphasis remap='I'>client</emphasis> refers to
 any module, widget, or application that calls an Intrinsics procedure.
 </para>
+
 <para>
-<!-- .LP -->
 Applications that use the (xI mechanisms
 must include the header files
 <function>&lt; X11/Intrinsic.h &gt;</function>
@@ -153,7 +132,6 @@ instead of
 <function>&lt; X11/Intrinsic.h &gt;.</function>
 </para>
 <para>
-<!-- .LP -->
 The applications must also include the additional header files for
 each widget class that they are to use (for example,
 <function>&lt; X11/Xaw/Label.h &gt;</function>
@@ -166,13 +144,10 @@ and is usually referenced as \-lXt when linking the application.
 
 </para>
 </sect2>
+
 <sect2 id="Procedures_and_Macros">
 <title>Procedures and Macros</title>
 <para>
-<!-- .LP -->
-<!-- .XS -->
-<!-- <function>(SN Procedures and Macros</function> -->
-<!-- .XE -->
 All functions defined in this specification except those specified below
 may be implemented as C macros with arguments.  C applications may use
 ``#undef'' to remove a macro definition and ensure that the actual function
@@ -181,31 +156,24 @@ has the same precedence as a function call and that evaluates each
 of its arguments exactly once, fully protected by parentheses, so that
 arbitrary expressions may be used as arguments.
 </para>
+
 <para>
-<!-- .LP -->
 The following symbols are macros that do not have function
 equivalents and that may expand their arguments in a manner other
 than that described above:
-<function>XtCheckSubclass ,</function>
-<function>XtNew ,</function>
-<function>XtNumber ,</function>
-<function>XtOffsetOf ,</function>
-<function>XtOffset ,</function>
+<function>XtCheckSubclass</function>,
+<function>XtNew</function>,
+<function>XtNumber</function>,
+<function>XtOffsetOf</function>,
+<function>XtOffset</function>,
 and
-<function>XtSetArg .</function>
-
+<function>XtSetArg</function>.
 </para>
 </sect2>
+
 <sect2 id="Widgets">
 <title>Widgets</title>
 <para>
-<!-- .LP -->
-<!-- .XS -->
-<!-- <function>(SN Widgets</function> -->
-<!-- .XE -->
-</para>
-<para>
-<!-- .LP -->
 The fundamental abstraction and data type of the (tk is the widget,
 which is a combination of an X window and its associated
 input and display semantics
@@ -216,8 +184,8 @@ Some widgets are output-only and do not react to pointer or keyboard input,
 and others change their display in response to input
 and can invoke functions that an application has attached to them.
 </para>
+
 <para>
-<!-- .LP -->
 Every widget belongs to exactly one widget class, which is statically
 allocated and initialized and which contains the operations allowable on
 widgets of that class.
@@ -235,16 +203,16 @@ which takes place when the first widget of the class or subclass is created.)
 For further information,
 see Section 2.5.
 </para>
+
 <para>
-<!-- .LP -->
 The distribution of the declarations and code for a new widget class
 among a public .h file for application programmer use, a private .h file
 for widget programmer use,
 and the implementation .c file is described in Section 1.6.
 The predefined widget classes adhere to these conventions.
 </para>
+
 <para>
-<!-- .LP -->
 A widget instance is composed of two parts:
 </para>
 <itemizedlist>
@@ -260,26 +228,21 @@ all widgets of that class.
     </para>
   </listitem>
 </itemizedlist>
+
 <para>
-<!-- .LP -->
 Much of the input/output of a widget (for example, fonts, colors, sizes,
 or border widths) is customizable by users.
 </para>
+
 <para>
-<!-- .LP -->
 This chapter discusses the base widget classes,
 Core, Composite, and Constraint, and
 ends with a discussion of widget classing.
-
 </para>
+
 <sect3 id="Core_Widgets">
 <title>Core Widgets</title>
-<!-- .XS -->
-<!-- (SN Core Widgets -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
-<!-- .IN "Core" "" "@DEF@" -->
 The
 Core
 widget class contains the definitions of fields common to all widgets.
@@ -290,26 +253,17 @@ which is defined by the
 and
 <function>CorePart</function>
 structures.
-
 </para>
+
 <sect4 id="CoreClassPart_Structure">
 <title>CoreClassPart Structure</title>
-<!-- .XS -->
-<!-- (SN CoreClassPart Structure -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 All widget classes contain the fields defined in the
 <function>CoreClassPart</function>
 structure.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CoreClassPart" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3.5i -->
-<!-- .ta .5i 3.5i -->
 typedef struct {
 	WidgetClass superclass;	See Section 1.6
 	String class_name;	See Chapter 9
@@ -345,10 +299,8 @@ typedef struct {
 	XtPointer extension;	See Section 1.6
 } CoreClassPart;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 All widget classes have the Core class fields as their first component.
 The prototypical
 <function>WidgetClass</function>
@@ -356,64 +308,46 @@ and
 <function>CoreWidgetClass</function>
 are defined with only this set of fields.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "Core" -->
-<!-- .IN "WidgetClass" "" "@DEF@" -->
-<!-- .IN "CoreWidgetClass" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct {
 	CoreClassPart core_class;
 } WidgetClassRec, *WidgetClass, CoreClassRec, *CoreWidgetClass;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 Various routines can cast widget class pointers, as needed,
 to specific widget class types.
 </para>
+
 <para>
-<!-- .LP -->
 The single occurrences of the class record and pointer for
 creating instances of Core are
 </para>
+
 <para>
-<!-- .LP -->
 In
 <function>IntrinsicP.h :</function>
 </para>
+
 <para>
-<!-- .LP -->
-<!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
 <!-- .ta .5i 3i -->
 extern WidgetClassRec widgetClassRec;
 #define coreClassRec widgetClassRec
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 In
 <function>Intrinsic.h :</function>
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 extern WidgetClass widgetClass, coreWidgetClass;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 The opaque types
 <function>Widget</function>
 and
@@ -426,36 +360,20 @@ does not allow applications to access private data, the (xI use
 incomplete structure definitions in
 <function>Intrinsic.h :</function>
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct _WidgetClassRec *WidgetClass, *CoreWidgetClass;
 </literallayout>
-<!-- .eM -->
-
-</para>
 </sect4>
+
 <sect4 id="CorePart_Structure">
 <title>CorePart Structure</title>
-<!-- .XS -->
-<!-- (SN CorePart Structure -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 All widget instances contain the fields defined in the
 <function>CorePart</function>
 structure.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CorePart" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct _CorePart {
 	Widget self;	Described below
 	WidgetClass widget_class;	See Section 1.6
@@ -487,92 +405,57 @@ typedef struct _CorePart {
 	Boolean mapped_when_managed;	See Chapter 3
 } CorePart;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 All widget instances have the Core fields as their first component.
 The prototypical type
 <function>Widget</function>
 is defined with only this set of fields.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "Widget" "" "@DEF@" -->
-<!-- .IN "CoreWidget" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct {
 	CorePart core;
 } WidgetRec, *Widget, CoreRec, *CoreWidget;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 Various routines can cast widget pointers, as needed,
 to specific widget types.
 </para>
+
 <para>
-<!-- .LP -->
 In order to make these types opaque and ensure that the compiler
 does not allow applications to access private data, the (xI use
 incomplete structure definitions in
-<function>Intrinsic.h .</function>
+<function>Intrinsic.h</function>.
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct _WidgetRec *Widget, *CoreWidget;
 </literallayout>
-<!-- .eM -->
 
-</para>
 </sect4>
 <sect4 id="Core_Resources">
 <title>Core Resources</title>
 <para>
-<!-- .LP -->
-<!-- .XS -->
-<!-- <function>(SN Core Resources</function> -->
-<!-- .XE -->
-</para>
-<para>
-<!-- .LP -->
-<!-- .IN "CoreWidget" "Resources" -->
 The resource names, classes, and representation types specified in the
 <function>coreClassRec</function>
 resource list are
 </para>
-<para>
-<!-- .LP -->
+
 <informaltable>
-  <tgroup cols='4' align='center'>
+  <tgroup cols='3' align='center'>
   <colspec colname='c1'/>
   <colspec colname='c2'/>
   <colspec colname='c3'/>
-  <colspec colname='c4'/>
   <tbody>
     <row>
-      <entry>lw(1.5i) lw(1.5i) lw(2.5i) .</entry>
-    </row>
-    <row>
-      <entry>_</entry>
-    </row>
-    <row>
       <entry>Name</entry>
       <entry>Class</entry>
       <entry>Representation</entry>
     </row>
     <row>
-      <entry>_</entry>
-    </row>
-    <row>
       <entry>XtNaccelerators</entry>
       <entry>XtCAccelerators</entry>
       <entry>XtRAcceleratorTable</entry>
@@ -622,101 +505,50 @@ resource list are
       <entry>XtCTranslations</entry>
       <entry>XtRTranslationTable</entry>
     </row>
-    <row>
-      <entry>_</entry>
-    </row>
   </tbody>
   </tgroup>
 </informaltable>
-</para>
+
 <para>
-<!-- .LP -->
 Additional resources are defined for all widgets via the
 <function>objectClassRec</function>
 and
 <function>rectObjClassRec</function>
 resource lists; see Sections 12.2 and 12.3 for details.
-
 </para>
 </sect4>
+
 <sect4 id="CorePart_Default_Values">
 <title>CorePart Default Values</title>
-<!-- .XS -->
-<!-- (SN CorePart Default Values -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The default values for the Core fields, which are filled in by the (xI,
 from the resource lists, and by the initialize procedures, are
 </para>
-<para>
-<!-- .LP -->
+
 <informaltable>
-  <tgroup cols='3' align='center'>
+  <tgroup cols='2' align='center'>
   <colspec colname='c1'/>
   <colspec colname='c2'/>
-  <colspec colname='c3'/>
   <tbody>
     <row>
-      <entry>lw(1.5i) lw(4.25i) .</entry>
-    </row>
-    <row>
-      <entry>_</entry>
-    </row>
-    <row>
       <entry>Field</entry>
       <entry>Default Value</entry>
     </row>
     <row>
-      <entry>_</entry>
-    </row>
-    <row>
       <entry>self</entry>
       <entry>Address of the widget structure (may not be changed).</entry>
     </row>
     <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>widget_class</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
-      <entry><emphasis remap='I'>widget_class</emphasis> argument to</entry>
-    </row>
-    <row>
-      <entry><function>XtCreateWidget</function></entry>
-    </row>
-    <row>
-      <entry>(may not be changed).</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>T{</entry>
+      <entry><emphasis remap='I'>widget_class</emphasis> argument to
+      <function>XtCreateWidget</function>
+      (may not be changed).</entry>
     </row>
     <row>
       <entry>parent</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
-      <entry><emphasis remap='I'>parent</emphasis> argument to</entry>
-    </row>
-    <row>
-      <entry><function>XtCreateWidget</function></entry>
-    </row>
-    <row>
-      <entry>(may not be changed).</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
+      <entry><emphasis remap='I'>parent</emphasis> argument to
+      <function>XtCreateWidget</function>
+      (may not be changed).</entry>
     </row>
     <row>
       <entry>being_destroyed</entry>
@@ -751,81 +583,31 @@ from the resource lists, and by the initialize procedures, are
       <entry>1</entry>
     </row>
     <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>managed</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>False</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>sensitive</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>True</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
       <entry>ancestor_sensitive</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
-      <entry>logical AND of parent's <emphasis remap='I'>sensitive</emphasis> and</entry>
-    </row>
-    <row>
-      <entry><emphasis remap='I'>ancestor_sensitive</emphasis> values.</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
+      <entry>logical AND of parent's <emphasis remap='I'>sensitive</emphasis> and
+      <emphasis remap='I'>ancestor_sensitive</emphasis> values.</entry>
     </row>
     <row>
       <entry>accelerators</entry>
       <entry>NULL</entry>
     </row>
     <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>border_pixel</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>XtDefaultForeground</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
       <entry>border_pixmap</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>XtUnspecifiedPixmap</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
       <entry>popup_list</entry>
       <entry>NULL</entry>
     </row>
@@ -834,45 +616,15 @@ from the resource lists, and by the initialize procedures, are
       <entry>0</entry>
     </row>
     <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>name</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
-      <entry><emphasis remap='I'>name</emphasis> argument to</entry>
-    </row>
-    <row>
-      <entry><function>XtCreateWidget</function></entry>
-    </row>
-    <row>
-      <entry>(may not be changed).</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>T{</entry>
+      <entry><emphasis remap='I'>name</emphasis> argument to
+      <function>XtCreateWidget</function>
+      (may not be changed).</entry>
     </row>
     <row>
       <entry>screen</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
-      <entry>Parent's <emphasis remap='I'>screen</emphasis>; top-level widget gets screen from display specifier</entry>
-    </row>
-    <row>
-      <entry>(may not be changed).</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
+      <entry>Parent's <emphasis remap='I'>screen</emphasis>; top-level widget gets screen from display specifier
+      (may not be changed).</entry>
     </row>
     <row>
       <entry>colormap</entry>
@@ -887,91 +639,39 @@ from the resource lists, and by the initialize procedures, are
       <entry>Parent's <emphasis remap='I'>depth</emphasis>; top-level widget gets root window depth.</entry>
     </row>
     <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>background_pixel</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>XtDefaultBackground</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
       <entry>background_pixmap</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>XtUnspecifiedPixmap</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>visible</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>True</function></entry>
     </row>
     <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry>mapped_when_managed</entry>
-    </row>
-    <row>
-      <entry>T}</entry>
-      <entry>T{</entry>
-    </row>
-    <row>
       <entry><function>True</function></entry>
     </row>
-    <row>
-      <entry>T}</entry>
-    </row>
-    <row>
-      <entry>_</entry>
-    </row>
   </tbody>
   </tgroup>
 </informaltable>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .IN XtUnspecifiedPixmap "" "@DEF@" -->
 <function>XtUnspecifiedPixmap</function>
 is a symbolic constant guaranteed to be unequal to
 any valid Pixmap id,
-<function>None ,</function>
+<function>None</function>,
 and
-<function>ParentRelative .</function>
-
+<function>ParentRelative</function>.
 </para>
 </sect4>
 </sect3>
+
 <sect3 id="Composite_Widgets">
 <title>Composite Widgets</title>
-<!-- .XS -->
-<!-- (SN Composite Widgets -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
-<!-- .IN "Composite" "" "@DEF@" -->
 The Composite
 widget class is a subclass of the
 Core
@@ -982,27 +682,18 @@ The additional data used by composite widgets are defined by the
 and
 <function>CompositePart</function>
 structures.
-
 </para>
+
 <sect4 id="CompositeClassPart_Structure">
 <title>CompositeClassPart Structure</title>
-<!-- .XS -->
-<!-- (SN CompositeClassPart Structure -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 In addition to the
 Core
 class fields,
 widgets of the Composite class have the following class fields.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CompositeClassPart" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3.5i -->
-<!-- .ta .5i 3.5i -->
 typedef struct {
 	XtGeometryHandler geometry_manager;	See Chapter 6
 	XtWidgetProc change_managed;	See Chapter 3
@@ -1011,10 +702,8 @@ typedef struct {
 	XtPointer extension;	See Section 1.6
 } CompositeClassPart;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 The extension record defined for
 <function>CompositeClassPart</function>
 with <emphasis remap='I'>record_type</emphasis>
@@ -1023,14 +712,8 @@ equal to
 is
 <function>CompositeClassExtensionRec .</function>
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CompositeClassExtensionRec" "" "@DEF@" -->
-<!-- .IN "CompositeClassExtension" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3.5i -->
-<!-- .ta .5i 3.5i -->
 typedef struct {
 	XtPointer next_extension;	See Section 1.6.12
 	XrmQuark record_type;	See Section 1.6.12
@@ -1040,65 +723,46 @@ typedef struct {
 	Boolean allows_change_managed_set;	See Section 3.4.3
 } CompositeClassExtensionRec, *CompositeClassExtension;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 Composite
 classes have the Composite class fields immediately following the
 Core class fields.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CompositeWidgetClass" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct {
 	CoreClassPart core_class;
 	CompositeClassPart composite_class;
 } CompositeClassRec, *CompositeWidgetClass;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 The single occurrences of the class record and pointer for creating
 instances of Composite are
 </para>
+
 <para>
-<!-- .LP -->
 In
 <function>IntrinsicP.h :</function>
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 extern CompositeClassRec compositeClassRec;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 In
 <function>Intrinsic.h :</function>
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
 <!-- .ta .5i 3i -->
 extern WidgetClass compositeWidgetClass;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 The opaque types
 <function>CompositeWidget</function>
 and
@@ -1117,25 +781,15 @@ uses an incomplete structure
 definition to ensure that the compiler catches attempts to access
 private data.
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct _CompositeClassRec *CompositeWidgetClass;
 </literallayout>
-<!-- .eM -->
-
-</para>
 </sect4>
+
 <sect4 id="CompositePart_Structure">
 <title>CompositePart Structure</title>
-<!-- .XS -->
-<!-- (SN CompositePart Structure -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 In addition to the
 Core instance
 fields,
@@ -1144,13 +798,7 @@ instance fields defined in the
 <function>CompositePart</function>
 structure.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CompositePart" "" "@DEF@" -->
-<!-- .sM -->
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct {
 	WidgetList children;	See Chapter 3
 	Cardinal num_children;	See Chapter 3
@@ -1158,53 +806,40 @@ typedef struct {
 	XtOrderProc insert_position;	See Section 3.2
 } CompositePart;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 Composite
 widgets have the Composite instance fields immediately following the Core
 instance fields.
 </para>
-<para>
-<!-- .LP -->
-<!-- .IN "CompositeWidget" "" "@DEF@" -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct {
 	CorePart core;
 	CompositePart composite;
 } CompositeRec, *CompositeWidget;
 </literallayout>
-</para>
+
 <para>
-<!-- .LP -->
-<!-- .eM -->
 <function>Intrinsic.h</function>
 uses an incomplete structure definition to ensure that the
 compiler catches attempts to access private data.
 </para>
-<para>
-<!-- .LP -->
-<!-- .sM -->
+
 <literallayout class="monospaced">
-<!-- .TA .5i 3i -->
-<!-- .ta .5i 3i -->
 typedef struct _CompositeRec *CompositeWidget;
 </literallayout>
-<!-- .eM -->
 
 </para>
 </sect4>
+
 <sect4 id="Composite_Resources">
 <title>Composite Resources</title>
 <!-- .XS -->
 <!-- <function>(SN Composite Resources</function> -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 <!-- .IN "CompositeWidget" "Resources" -->
 The resource names, classes, and representation types
 that are specified in
@@ -1213,7 +848,7 @@ the
 resource list are
 </para>
 <para>
-<!-- .LP -->
+
 <informaltable>
   <tgroup cols='4' align='center'>
   <colspec colname='c1'/>
@@ -1265,7 +900,7 @@ resource list are
 <!-- (SN CompositePart Default Values -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The default values for the Composite fields,
 which are filled in from the
 Composite
@@ -1274,7 +909,7 @@ Composite
 initialize procedure, are
 </para>
 <para>
-<!-- .LP -->
+
 <informaltable>
   <tgroup cols='' align='center'>
   <tbody>
@@ -1301,7 +936,7 @@ initialize procedure, are
 </informaltable>
 </para>
 <para>
-<!-- .LP -->
+
 The <emphasis remap='I'>children</emphasis>, <emphasis remap='I'>num_children</emphasis>,
 and <emphasis remap='I'>insert_position</emphasis> fields are declared
 as resources;
@@ -1325,7 +960,7 @@ widget class procedures.
 <!-- (SN Constraint Widgets -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 <!-- .IN "Constraint" "" "@DEF@" -->
 The Constraint
 widget class is a subclass of the
@@ -1347,7 +982,7 @@ structures.
 <!-- (SN ConstraintClassPart Structure -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 In addition to the
 Core
 and
@@ -1357,7 +992,7 @@ widgets of the Constraint class
 have the following class fields.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "ConstraintClassPart" "" "@DEF@" -->
 <!-- .sM -->
 <literallayout class="monospaced">
@@ -1375,7 +1010,7 @@ typedef struct {
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The extension record defined for
 <function>ConstraintClassPart</function>
@@ -1385,7 +1020,7 @@ is
 <function>ConstraintClassExtensionRec .</function>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "ConstraintClassExtensionRec" "" "@DEF@" -->
 <!-- .IN "ConstraintClassExtension" "" "@DEF@" -->
 <!-- .sM -->
@@ -1402,14 +1037,14 @@ typedef struct {
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 Constraint
 classes have the Constraint class fields immediately following the
 Composite class fields.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "ConstraintWidgetClass" "" "@DEF@" -->
 <!-- .sM -->
 <literallayout class="monospaced">
@@ -1423,18 +1058,18 @@ typedef struct _ConstraintClassRec {
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The single occurrences of the class record and pointer for creating
 instances of Constraint are
 </para>
 <para>
-<!-- .LP -->
+
 In
 <function>IntrinsicP.h :</function>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
@@ -1443,13 +1078,13 @@ extern ConstraintClassRec constraintClassRec;
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 In
 <function>Intrinsic.h :</function>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
@@ -1458,7 +1093,7 @@ extern WidgetClass constraintWidgetClass;
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The opaque types
 <function>ConstraintWidget</function>
@@ -1479,7 +1114,7 @@ uses an incomplete structure definition to ensure that the
 compiler catches attempts to access private data.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
@@ -1496,7 +1131,7 @@ typedef struct _ConstraintClassRec *ConstraintWidgetClass;
 <!-- (SN ConstraintPart Structure -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 In addition to the
 Core
 and
@@ -1508,7 +1143,7 @@ instance fields defined in the
 structure
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "ConstraintPart" "" "@DEF@" -->
 <!-- .sM -->
 <literallayout class="monospaced">
@@ -1520,14 +1155,14 @@ typedef struct {
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 Constraint
 widgets have the Constraint instance fields immediately following the
 Composite instance fields.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "ConstraintWidget" "" "@DEF@" -->
 <!-- .sM -->
 <literallayout class="monospaced">
@@ -1541,14 +1176,14 @@ typedef struct {
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 <function>Intrinsic.h</function>
 uses an incomplete structure definition to ensure that the
 compiler catches attempts to access private data.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
@@ -1565,7 +1200,7 @@ typedef struct _ConstraintRec *ConstraintWidget;
 <!-- <function>(SN Constraint Resources</function> -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The
 <function>constraintClassRec</function>
 <emphasis remap='I'>core_class</emphasis> and <emphasis remap='I'>constraint_class resources</emphasis> fields are NULL,
@@ -1585,14 +1220,14 @@ Constraint.
 <!-- <function>(SN Implementation-Specific Types</function> -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 To increase the portability of widget and application source code
 between different system environments, the (xI define several
 types whose precise representation is explicitly dependent upon,
 and chosen by, each individual implementation of the (xI.
 </para>
 <para>
-<!-- .LP -->
+
 These implementation-defined types are
 <!-- .IN "Boolean" "" "@DEF@" -->
 </para>
@@ -1674,7 +1309,7 @@ respectively.
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 In addition to these specific types, the precise order of the
 fields within the structure declarations for any of the instance
 part records
@@ -1710,7 +1345,7 @@ fields may be assumed.
 <sect2 id="Widget_Classing">
 <title>Widget Classing</title>
 <para>
-<!-- .LP -->
+
 <!-- .XS -->
 <!-- <function>(SN Widget Classing</function> -->
 <!-- .XE -->
@@ -1727,7 +1362,7 @@ Such procedures are applicable to all widgets
 of that class and also to widgets whose classes are subclasses of that class.
 </para>
 <para>
-<!-- .LP -->
+
 All widget classes are a subclass of
 Core
 and can be subclassed further.
@@ -1742,7 +1377,7 @@ Subclasses usually inherit many of their superclasses' procedures
 (for example, the expose procedure or geometry handler).
 </para>
 <para>
-<!-- .LP -->
+
 Subclassing, however, can be taken too far.
 If you create a subclass that inherits none of the procedures of its
 superclass,
@@ -1750,7 +1385,7 @@ you should consider whether you have chosen the most
 appropriate superclass.
 </para>
 <para>
-<!-- .LP -->
+
 To make good use of subclassing,
 widget declarations and naming conventions are highly stylized.
 A widget consists of three files:
@@ -1780,7 +1415,7 @@ A .c file, which implements the widget.
 <!-- <function>(SN Widget Naming Conventions</function> -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The (xI provide a vehicle by which programmers can create
 new widgets and organize a collection of widgets into an application.
 To ensure that applications need not deal with as many styles of capitalization
@@ -1899,7 +1534,7 @@ they start with a capital letter, and compound names use uppercase
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 The symbolic identifiers XtN..., XtC..., and XtR...
 may be implemented
 as macros, as global symbols, or as a mixture of the two.  The
@@ -1922,7 +1557,7 @@ simultaneously.
 <!-- (SN Widget Subclassing in Public .h Files -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The public .h file for a widget class is imported by clients
 and contains
 </para>
@@ -1965,12 +1600,12 @@ Entry points for new class methods.
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 For example, the following is the public .h file for a possible
 implementation of a Label widget:
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .5i 1.75i -->
 <!-- .ta .5i 1.75i -->
@@ -2003,13 +1638,13 @@ extern String LabelGetText();
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 The conditional inclusion of the text allows the application
 to include header files for different widgets without being concerned
 that they already may be included as a superclass of another widget.
 </para>
 <para>
-<!-- .LP -->
+
 To accommodate operating systems with file name length restrictions,
 the name of the public .h file is the first ten characters of the
 widget class.
@@ -2027,7 +1662,7 @@ widget class is
 <!-- (SN Widget Subclassing in Private .h Files -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The private .h file for a widget is imported by widget classes that are
 subclasses of the widget and contains
 </para>
@@ -2120,11 +1755,11 @@ An inherit constant for each new procedure in the widget class part structure.
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 For example, the following is the private .h file for a possible Label widget:
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
 <!-- .ta .5i 3i -->
@@ -2198,7 +1833,7 @@ extern LabelClassRec labelClassRec;
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 To accommodate operating systems with file name length restrictions,
 the name of the private .h file is the first nine characters of the
 widget class followed by a capital P.
@@ -2216,7 +1851,7 @@ widget class is
 <!-- (SN Widget Subclassing in .c Files -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 The .c file for a widget contains the structure initializer
 for the class record variable,
 which contains the following parts:
@@ -2247,7 +1882,7 @@ the widget).
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 <!-- .IN "superclass" "" "@DEF@" -->
 The <emphasis remap='I'>superclass</emphasis> field points to the superclass
 global class
@@ -2261,7 +1896,7 @@ inheriting or enveloping a superclass's operations
 (see Sections 1.6.7, 1.6.9, and 1.6.10).
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "class_name" "" "@DEF@" -->
 The <emphasis remap='I'>class_name</emphasis> field contains the text name for this class,
 which is used by
@@ -2274,14 +1909,14 @@ subsequently deallocated.
 
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "widget_size" "" "@DEF@" -->
 The <emphasis remap='I'>widget_size</emphasis> field is the size of the corresponding widget
 instance structure
 (not the size of the class structure).
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .IN "version" "" "@DEF@" -->
 The <emphasis remap='I'>version</emphasis> field indicates the toolkit
 implementation version number and is used for
@@ -2304,7 +1939,7 @@ allows the (xI implementation to recognize widget binaries
 that were compiled with older implementations.
 </para>
 <para>
-<!-- .LP -->
+
 The <emphasis remap='I'>extension</emphasis> field is for future upward compatibility.
 If the widget programmer adds fields to class parts,
 all subclass structure layouts change,
@@ -2314,11 +1949,11 @@ an extension field at the end of each class part can point to a record
 that contains any additional class information required.
 </para>
 <para>
-<!-- .LP -->
+
 All other fields are described in their respective sections.
 </para>
 <para>
-<!-- .LP -->
+
 The .c file also contains the declaration of the global class
 structure pointer variable used to create instances of the class.
 The following is an abbreviated version of the .c file
@@ -2326,7 +1961,7 @@ for a Label widget.
 The resources table is described in Chapter 9.
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .5i 1.5i 3i -->
 <!-- .ta .5i 1.5i 3i -->
@@ -2431,13 +2066,13 @@ void LabelSetText(w, text)
 <!-- (SN Widget Class and Superclass Look Up -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 To obtain the class of a widget, use
 <function>XtClass .</function>
 <!-- .IN "XtClass" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2458,7 +2093,7 @@ Specifies the widget. (oI
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The
 <function>XtClass</function>
@@ -2466,13 +2101,13 @@ function returns a pointer to the widget's class structure.
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 To obtain the superclass of a widget, use
 <function>XtSuperclass .</function>
 <!-- .IN "XtSuperclass" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2493,7 +2128,7 @@ Specifies the widget. (oI
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The
 <function>XtSuperclass</function>
@@ -2507,13 +2142,13 @@ function returns a pointer to the widget's superclass class structure.
 <!-- (SN Widget Subclass Verification -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 To check the subclass to which a widget belongs, use
 <function>XtIsSubclass .</function>
 <!-- .IN "XtIsSubclass" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2546,7 +2181,7 @@ Specifies the widget class for which to test. (oC
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The
 <function>XtIsSubclass</function>
@@ -2563,7 +2198,7 @@ to find out if a widget belongs to the desired class of objects.
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 To test if a given widget belongs to a subclass of an (xI-defined
 class, the (xI define macros or functions equivalent to
 <function>XtIsSubclass</function>
@@ -2597,11 +2232,11 @@ and
 <!-- .IN "XtIsSessionShell" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 All these macros and functions have the same argument description.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2622,7 +2257,7 @@ Specifies the widget or object instance whose class is to be checked.  (oI
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 These procedures may be faster than calling
 <function>XtIsSubclass</function>
@@ -2630,7 +2265,7 @@ directly for the built-in classes.
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 To check a widget's class
 and to generate a debugging error message, use
 <function>XtCheckSubclass ,</function>
@@ -2639,7 +2274,7 @@ defined in
 <!-- .IN "XtCheckSubclass" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2685,7 +2320,7 @@ Specifies the message to be used.
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The
 <function>XtCheckSubclass</function>
@@ -2703,7 +2338,7 @@ should be used at the entry point of exported routines to ensure
 that the client has passed in a valid widget class for the exported operation.
 </para>
 <para>
-<!-- .LP -->
+
 <function>XtCheckSubclass</function>
 is only executed when the module has been compiled with the compiler symbol
 DEBUG defined; otherwise, it is defined as the empty string
@@ -2717,7 +2352,7 @@ and generates no code.
 <!-- (SN Superclass Chaining -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 <!-- .IN "Chaining" "superclass" -->
 <!-- .IN "Chaining" "Subclass" -->
 <!-- .IN "Superclass Chaining" "" "@DEF@" -->
@@ -2783,7 +2418,7 @@ In Shell widget classes:	<emphasis remap='I'>root_geometry_manager</emphasis>
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 With downward superclass chaining,
 the invocation of an operation first accesses the field from the
 Object,
@@ -2811,7 +2446,7 @@ that widget's class structure.  These superclass-to-subclass fields are
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 In addition, for subclasses of
 Constraint,
 the following fields of the
@@ -2833,7 +2468,7 @@ class down to the subclass:
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 With upward superclass chaining,
 the invocation of an operation first accesses the field from the widget
 class structure, then from the superclass structure,
@@ -2853,7 +2488,7 @@ The subclass-to-superclass fields are
 <!-- .sp -->
 </para>
 <para>
-<!-- .LP -->
+
 For subclasses of
 Constraint,
 the following field of
@@ -2873,7 +2508,7 @@ Constraint class:
 <!-- (SN Class Initialization: class_initialize and class_part_initialize Procedures -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 <!-- .IN "Class Initialization" -->
 <!-- .IN "Initialization" -->
 Many class records can be initialized completely at compile or link time.
@@ -2882,7 +2517,7 @@ a class may need to register type converters or perform other sorts of
 once-only runtime initialization.
 </para>
 <para>
-<!-- .LP -->
+
 Because the C language does not have initialization procedures
 that are invoked automatically when a program starts up,
 a widget class can declare a class_initialize procedure
@@ -2893,20 +2528,20 @@ A class initialization procedure pointer is of type
 <!-- .IN "XtProc" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
 typedef void (*XtProc)(void);
 <!-- .FN -->
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 A widget class indicates that it has no class initialization procedure by
 specifying NULL in the <emphasis remap='I'>class_initialize</emphasis> field.
 </para>
 <para>
-<!-- .LP -->
+
 In addition to the class initialization that is done exactly once,
 some classes perform initialization for fields in their parts
 of the class record.
@@ -2919,7 +2554,7 @@ The class_part_initialize procedure pointer is of type
 <!-- .IN "XtWidgetClassProc" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -2940,7 +2575,7 @@ Points to the class structure for the class being initialized.
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 During class initialization,
 the class part initialization procedures for the class and all its superclasses
@@ -2971,13 +2606,13 @@ or that need no extra processing for them can specify NULL
 in the <emphasis remap='I'>class_part_initialize</emphasis> field.
 </para>
 <para>
-<!-- .LP -->
+
 All widget classes, whether they have a class initialization procedure or not,
 must start with their <emphasis remap='I'>class_inited</emphasis> field
 <function>False .</function>
 </para>
 <para>
-<!-- .LP -->
+
 The first time a widget of a class is created,
 <function>XtCreateWidget</function>
 ensures that the widget class and all superclasses are initialized, in
@@ -2991,11 +2626,11 @@ After the one-time initialization,
 a class structure is constant.
 </para>
 <para>
-<!-- .LP -->
+
 The following example provides the class initialization procedure for a Label class.
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .5i 2i -->
 <!-- .ta .5i 2i -->
@@ -3015,7 +2650,7 @@ static void ClassInitialize()
 <!-- .XE -->
 <!-- .IN "Widget" "class initialization" -->
 <para>
-<!-- .LP -->
+
 A class is initialized when the first widget of that class or any
 subclass is created.
 To initialize a widget class without creating any widgets, use
@@ -3023,7 +2658,7 @@ To initialize a widget class without creating any widgets, use
 <!-- .IN "XtInitializeWidgetClass" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -3047,14 +2682,14 @@ or any subclass thereof.
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 If the specified widget class is already initialized,
 <function>XtInitializeWidgetClass</function>
 returns immediately.
 </para>
 <para>
-<!-- .LP -->
+
 If the class initialization procedure registers type converters,
 these type converters are not available until the first object
 of the class or subclass is created or
@@ -3070,7 +2705,7 @@ is called
 <!-- (SN Inheritance of Superclass Operations -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 A widget class is free to use any of its superclass's self-contained
 operations rather than implementing its own code.
 The most frequently inherited operations are
@@ -3108,14 +2743,14 @@ set_values_almost
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 To inherit an operation <emphasis remap='I'>xyz</emphasis>,
 specify the constant
 <function>XtInherit <emphasis remap='I'>Xyz</emphasis></function>
 in your class record.
 </para>
 <para>
-<!-- .LP -->
+
 Every class that declares a new procedure in its widget class part must
 provide for inheriting the procedure in its class_part_initialize
 procedure.
@@ -3127,7 +2762,7 @@ specify NULL for chained procedures
 in their class records.
 </para>
 <para>
-<!-- .LP -->
+
 Inheriting works by comparing the value of the field with a known, special
 value and by copying in the superclass's value for that field if a match
 occurs.
@@ -3139,13 +2774,13 @@ cast to the appropriate type.
 is a procedure that issues an error message if it is actually called.
 </para>
 <para>
-<!-- .LP -->
+
 For example,
 <function>CompositeP.h</function>
 contains these definitions:
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .25i 1.5i 3i -->
 <!-- .ta .25i 1.5i 3i -->
@@ -3156,11 +2791,11 @@ contains these definitions:
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 Composite's class_part_initialize procedure begins as follows:
 </para>
 <para>
-<!-- .LP -->
+
 <literallayout class="monospaced">
 <!-- .TA .2i 1.5i 3i -->
 <!-- .ta .2i 1.5i 3i -->
@@ -3183,14 +2818,14 @@ static void CompositeClassPartInitialize(widgetClass)
 </literallayout>
 </para>
 <para>
-<!-- .LP -->
+
 Nonprocedure fields may be inherited in the same manner as procedure
 fields.  The class may declare any reserved value it wishes for
 the inheritance constant for its new fields.  The following inheritance
 constants are defined:
 </para>
 <para>
-<!-- .LP -->
+
 For Object:
 </para>
 <itemizedlist>
@@ -3206,7 +2841,7 @@ For Object:
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 For Core:
 </para>
 <itemizedlist>
@@ -3252,7 +2887,7 @@ For Core:
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 For Composite:
 </para>
 <itemizedlist>
@@ -3278,7 +2913,7 @@ For Composite:
   </listitem>
 </itemizedlist>
 <para>
-<!-- .LP -->
+
 For Shell:
 </para>
 <itemizedlist>
@@ -3296,7 +2931,7 @@ For Shell:
 <!-- (SN Invocation of Superclass Operations -->
 <!-- .XE -->
 <para>
-<!-- .LP -->
+
 A widget sometimes needs to call a superclass operation
 that is not chained.
 For example,
@@ -3311,7 +2946,7 @@ and then calling
 to add the child to the managed set.
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .NT -->
 A class method should not use
 <function>XtSuperclass</function>
@@ -3333,7 +2968,7 @@ This technique is referred to as <emphasis remap='I'>enveloping</emphasis> the s
 <!-- .XE -->
 <!-- .IN "Widget" "class extension records" -->
 <para>
-<!-- .LP -->
+
 It may be necessary at times to add new fields to already existing
 widget class structures.  To permit this to be done without requiring
 recompilation of all subclasses, the last field in a class part structure
@@ -3342,7 +2977,7 @@ have yet been defined, subclasses should initialize the value of the
 extension pointer to NULL.
 </para>
 <para>
-<!-- .LP -->
+
 If extension fields exist, as is the case with the
 Composite,
 Constraint,
@@ -3357,7 +2992,7 @@ in the extension record must always check the <emphasis remap='I'>extension</emp
 some appropriate default action if it is NULL.
 </para>
 <para>
-<!-- .LP -->
+
 In order to permit multiple subclasses and libraries to chain extension
 records from a single <emphasis remap='I'>extension</emphasis> field, extension records should be
 declared as a linked list, and each extension record definition should
@@ -3365,7 +3000,7 @@ contain the following four fields at the beginning of the structure
 declaration:
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 <literallayout class="monospaced">
 <!-- .TA .5i 3i -->
@@ -3424,7 +3059,7 @@ extension record.
 </variablelist>
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The <emphasis remap='I'>record_type</emphasis> field identifies the contents of the extension record
 and is used by the definer of the record to locate its particular
@@ -3442,7 +3077,7 @@ part extension field to identify the extension record unique to that
 particular class.
 </para>
 <para>
-<!-- .LP -->
+
 The <emphasis remap='I'>version</emphasis> field is an owner-defined constant that may be used to
 identify binary files that have been compiled with alternate
 definitions of the remainder of the extension record data structure.  The private
@@ -3453,7 +3088,7 @@ should normally be initialized with
 <function>sizeof ().</function>
 </para>
 <para>
-<!-- .LP -->
+
 Any value stored in the class part extension fields of
 <function>CompositeClassPart ,</function>
 <function>ConstraintClassPart ,</function>
@@ -3462,19 +3097,19 @@ or
 must point to an extension record conforming to this definition.
 </para>
 <para>
-<!-- .LP -->
+
 The (xI provide a utility function for widget writers to locate a
 particular class extension record in a linked list, given a widget class
 and the offset of the <emphasis remap='I'>extension</emphasis> field in the class record.
 </para>
 <para>
-<!-- .LP -->
+
 To locate a class extension record, use
 <function>XtGetClassExtension .</function>
 <!-- .IN "XtGetClassExtension" "" "@DEF@" -->
 </para>
 <para>
-<!-- .LP -->
+
 <!-- .sM -->
 </para>
 <!-- .FD 0 -->
@@ -3547,7 +3182,7 @@ extension record required for a match, or 0.
   </varlistentry>
 </variablelist>
 <para>
-<!-- .LP -->
+
 <!-- .eM -->
 The list of extension records at the specified offset in the specified
 object class will be searched for a match on the specified type,