updatd CH13.xml

1 files changed, 190 insertions, 405 deletions

diff --git a/specs/CH13.xml b/specs/CH13.xml
index 9796a1c..fa78a46 100644
--- a/specs/CH13.xml
+++ b/specs/CH13.xml
@@ -1,64 +1,7 @@
-<!-- .\" $Xorg: CH13,v 1.3 2000/08/17 19:42:47 cpqbld Exp $ -->
-<!-- .\" Copyright \(co 1985, 1986, 1987, 1988, 1991, 1994 -->
-<!-- .\" X Consortium -->
-<!-- .\" -->
-<!-- .\" Permission is hereby granted, free of charge, to any person obtaining -->
-<!-- .\" a copy of this software and associated documentation files (the -->
-<!-- .\" "Software"), to deal in the Software without restriction, including -->
-<!-- .\" without limitation the rights to use, copy, modify, merge, publish, -->
-<!-- .\" distribute, sublicense, and/or sell copies of the Software, and to -->
-<!-- .\" permit persons to whom the Software is furnished to do so, subject to -->
-<!-- .\" the following conditions: -->
-<!-- .\" -->
-<!-- .\" The above copyright notice and this permission notice shall be included -->
-<!-- .\" in all copies or substantial portions of the Software. -->
-<!-- .\" -->
-<!-- .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -->
-<!-- .\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -->
-<!-- .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -->
-<!-- .\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR -->
-<!-- .\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -->
-<!-- .\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -->
-<!-- .\" OTHER DEALINGS IN THE SOFTWARE. -->
-<!-- .\" -->
-<!-- .\" Except as contained in this notice, the name of the X Consortium shall -->
-<!-- .\" not be used in advertising or otherwise to promote the sale, use or -->
-<!-- .\" other dealings in this Software without prior written authorization -->
-<!-- .\" from the X Consortium. -->
-<!-- .\" -->
-<!-- .\" Copyright \(co 1985, 1986, 1987, 1988, 1991, 1994 -->
-<!-- .\" Digital Equipment Corporation, Maynard, Massachusetts. -->
-<!-- .\" -->
-<!-- .\" Permission to use, copy, modify and distribute this documentation for any -->
-<!-- .\" purpose and without fee is hereby granted, provided that the above copyright -->
-<!-- .\" notice appears in all copies and that both that copyright notice and this -->
-<!-- .\" permission notice appear in supporting documentation, and that the name of -->
-<!-- .\" Digital not be used in in advertising or publicity pertaining -->
-<!-- .\" to distribution of the software without specific, written prior permission. -->
-<!-- .\" Digital makes no representations about the suitability of the -->
-<!-- .\" software described herein for any purpose. -->
-<!-- .\" It is provided ``as is'' without express or implied warranty. -->
-<!-- .\" -->
-\&
-<!-- .sp 1 -->
-<!-- .ce 3 -->
-\s+1<function>Chapter 13</function>\s-1
-
-\s+1<function>Evolution of the (xI</function>\s-1
-<!-- .sp 2 -->
-<!-- .nr H1 13 -->
-<!-- .nr H2 0 -->
-<!-- .nr H3 0 -->
-<!-- .nr H4 0 -->
-<!-- .nr H5 0 -->
-<para>
-<!-- .LP -->
-<!-- .XS -->
-<!-- Chapter 13 \(em Evolution of the (xI -->
-<!-- .XE -->
-</para>
-<para>
-<!-- .LP -->
+<chapter id='Evolution_of_the_Intrinsics'>
+<title>Evolution of the Intrinsics</title>
+
+<para>
 The interfaces described by this specification have undergone several
 sets of revisions in the course of adoption as an X Consortium
 standard specification.  Having now been adopted by the Consortium as
@@ -69,65 +12,51 @@ implementations of these specifications may be produced that provide
 source compatibility with widgets and applications written to
 previous Consortium standard revisions.
 </para>
+
 <para>
-<!-- .LP -->
-The (xI do not place any special requirement on widget
+The Intrinsics do not place any special requirement on widget
 programmers to retain source or binary compatibility for their widgets
 as they evolve, but several conventions have been established to
 assist those developers who want to provide such compatibility.
 </para>
+
 <para>
-<!-- .LP -->
 In particular, widget programmers may wish to conform to the convention
 described in Section 1.6.12 when defining class extension records.
-
 </para>
-<sect2 id="Determining_Specification_Revision_Level">
+<sect1 id="Determining_Specification_Revision_Level">
 <title>Determining Specification Revision Level</title>
-<!-- .XS -->
-<!-- <function>(SN Determining Specification Revision Level</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 Widget and application developers who wish to maintain a common source
-pool that will build properly with implementations of the (xI
+pool that will build properly with implementations of the Intrinsics
 at different revision levels of these specifications but that take
 advantage of newer features added in later revisions may use the
 symbolic macro
-<function>XtSpecificationRelease .</function>
+<function>XtSpecificationRelease</function>.
 </para>
-<para>
-<!-- .LP -->
 <literallayout class="monospaced">
 #define XtSpecificationRelease 6
 </literallayout>
-<!-- .IN "XtSpecificationRelease" "" "@DEF@" -->
-</para>
 <para>
-<!-- .LP -->
 As the symbol
 <function>XtSpecificationRelease</function>
 was new to Release 4, widgets and
 applications desiring to build against earlier implementations should
 test for the presence of this symbol and assume only Release 3
 interfaces if the definition is not present.
-
 </para>
-</sect2>
-<sect2 id="Release_to_Release_Compatibility">
+</sect1>
+
+<sect1 id="Release_to_Release_Compatibility">
 <title>Release 3 to Release 4 Compatibility</title>
-<!-- .XS -->
-<!-- <function>(SN Release 3 to Release 4 Compatibility</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 At the data structure level, Release 4 retains binary compatibility
 with Release 3 (the first X Consortium standard release) for all data
 structures except
 <function>WMShellPart,</function>
-<function>TopLevelShellPart ,</function>
+<function>TopLevelShellPart</function>,
 and
-<function>TransientShellPart .</function>
+<function>TransientShellPart</function>.
 Release 4 changed the argument type to most procedures that now take
 arguments of type
 <function>XtPointer</function>
@@ -137,8 +66,8 @@ in order to avoid potential ANSI C conformance problems.  It is
 expected that most implementations will be binary compatible with the
 previous definition.
 </para>
+
 <para>
-<!-- .LP -->
 Two fields in
 <function>CoreClassPart</function>
 were changed from
@@ -148,18 +77,13 @@ to
 to allow implementations additional freedom in specifying the
 representations of each.  This change should require no source
 modification.
-
 </para>
-<sect3 id="Additional_Arguments">
+<sect2 id="Additional_Arguments">
 <title>Additional Arguments</title>
-<!-- .XS -->
-<!-- (SN Additional Arguments -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 Arguments were added to the procedure definitions for
-<function>XtInitProc ,</function>
-<function>XtSetValuesFunc ,</function>
+<function>XtInitProc</function>,
+<function>XtSetValuesFunc</function>,
 and
 <function>XtEventHandler</function>
 to provide more information and to
@@ -171,42 +95,34 @@ and
 make the initialize_hook and set_values_hook methods
 obsolete, but the hooks have been retained for those widgets that used
 them in Release 3.
-
 </para>
-</sect3>
-<sect3 id="set_values_almost_Procedures">
+</sect2>
+
+<sect2 id="set_values_almost_Procedures">
 <title>set_values_almost Procedures</title>
-<!-- .XS -->
-<!-- (SN set_values_almost Procedures -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The use of the arguments by a set_values_almost procedure was poorly
 described in Release 3 and was inconsistent with other conventions.
 </para>
+
 <para>
-<!-- .LP -->
 The current specification for the manner in which a set_values_almost
-procedure returns information to the (xI is not compatible with
+procedure returns information to the Intrinsics is not compatible with
 the Release 3 specification, and all widget implementations should
 verify that any set_values_almost procedures conform to the current
 interface.
 </para>
+
 <para>
-<!-- .LP -->
-No known implementation of the (xI correctly implemented the
+No known implementation of the Intrinsics correctly implemented the
 Release 3 interface, so it is expected that the impact of this
 specification change is small.
-
 </para>
-</sect3>
-<sect3 id="Query_Geometry">
+</sect2>
+
+<sect2 id="Query_Geometry">
 <title>Query Geometry</title>
-<!-- .XS -->
-<!-- (SN Query Geometry -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 A composite widget layout routine that calls
 <function>XtQueryGeometry</function>
 is now expected to store the complete new geometry in the intended structure;
@@ -215,56 +131,48 @@ make''.  Only by storing the complete geometry does the child have
 any way to know what other parts of the geometry may still be
 flexible.  Existing widgets should not be affected by this, except
 to take advantage of the new information.
-
 </para>
-</sect3>
-<sect3 id="unrealizeCallback_Callback_List">
+</sect2>
+
+<sect2 id="unrealizeCallback_Callback_List">
 <title>unrealizeCallback Callback List</title>
-<!-- .XS -->
-<!-- (SN unrealizeCallback Callback List -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 In order to provide a mechanism for widgets to be notified when they
 become unrealized through a call to
-<function>XtUnrealizeWidget ,</function>
+<function>XtUnrealizeWidget</function>,
 the callback
-list name ``unrealizeCallback'' has been defined by the (xI.  A
+list name ``unrealizeCallback'' has been defined by the Intrinsics.  A
 widget class that requires notification on unrealize may declare a
 callback list resource by this name.  No class is required to declare
 this resource, but any class that did so in a prior revision may find
 it necessary to modify the resource name if it does not wish to use the new
 semantics.
-
 </para>
-</sect3>
-<sect3 id="Subclasses_of_WMShell">
+</sect2>
+
+<sect2 id="Subclasses_of_WMShell">
 <title>Subclasses of WMShell</title>
-<!-- .XS -->
-<!-- (SN Subclasses of WMShell -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
-The formal adoption of the <emphasis remap='I'>(xC</emphasis> as
+The formal adoption of the <emphasis remap='I'>Inter-Client Communication Conventions Manual.</emphasis> as
 an X Consortium standard has meant the addition of four fields to
 <function>WMShellPart</function>
 and one field to
-<function>TopLevelShellPart .</function>
+<function>TopLevelShellPart</function>.
 In deference to some
 widget libraries that had developed their own additional conventions
 to provide binary compatibility, these five new fields were added at
 the end of the respective data structures.
 </para>
+
 <para>
-<!-- .LP -->
 To provide more convenience for TransientShells, a field was added
 to the previously empty
-<function>TransientShellPart .</function>
+<function>TransientShellPart</function>.
 On some architectures the size of the part structure will not
 have changed as a result of this.
 </para>
+
 <para>
-<!-- .LP -->
 Any widget implementation whose class is a subclass of
 TopLevelShell
 or
@@ -280,17 +188,13 @@ a subclass that expected to do a single structure assignment of an
 structure to the <emphasis remap='I'>size_hints</emphasis> field of
 <function>WMShellPart</function>
 must be revised, though the old fields remain at the same positions within
-<function>WMShellPart .</function>
-
+<function>WMShellPart</function>.
 </para>
-</sect3>
-<sect3 id="Resource_Type_Converters">
+</sect2>
+
+<sect2 id="Resource_Type_Converters">
 <title>Resource Type Converters</title>
-<!-- .XS -->
-<!-- (SN Resource Type Converters -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 A new interface declaration for resource type converters was defined
 to provide more information to converters, to support conversion
 cache cleanup with resource reference counting, and to allow
@@ -299,44 +203,36 @@ interfaces remain (in the compatibility section), and a new set of
 procedures was defined that work only with the new type converter
 interface.
 </para>
+
 <para>
-<!-- .LP -->
 In the now obsolete old type converter interface, converters are
 reminded that they must return the size of the converted value as well
 as its address.  The example indicated this, but the description of
 <function>XtConverter</function>
 was incomplete.
-
 </para>
-</sect3>
-<sect3 id="KeySym_Case_Conversion_Procedure">
+</sect2>
+
+<sect2 id="KeySym_Case_Conversion_Procedure">
 <title>KeySym Case Conversion Procedure</title>
-<!-- .XS -->
-<!-- (SN KeySym Case Conversion Procedure -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The specification for the
 <function>XtCaseProc</function>
 function type has been changed
 to match the Release 3 implementation, which included necessary
 additional information required by the function (a pointer to the
 display connection), and corrects the argument type of the source
-KeySym parameter.  No known implementation of the (xI
+KeySym parameter.  No known implementation of the Intrinsics
 implemented the previously documented interface.
-
 </para>
-</sect3>
-<sect3 id="Nonwidget_Objects">
+</sect2>
+
+<sect2 id="Nonwidget_Objects">
 <title>Nonwidget Objects</title>
-<!-- .XS -->
-<!-- (SN Nonwidget Objects -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 Formal support for nonwidget objects is new to Release 4.  A
 prototype implementation was latent in at least one Release 3
-implementation of the (xI, but the specification has changed
+implementation of the Intrinsics, but the specification has changed
 somewhat.  The most significant change is the requirement for a
 composite widget to declare the
 <function>CompositeClassExtension</function>
@@ -344,8 +240,8 @@ record with the <emphasis remap='I'>accepts_objects</emphasis> field set to
 <function>True</function>
 in order to permit a client to create a nonwidget child.
 </para>
+
 <para>
-<!-- .LP -->
 The addition of this extension field ensures that composite widgets
 written under Release 3 will not encounter unexpected errors if an
 application attempts to create a nonwidget child.  In Release 4 there
@@ -353,26 +249,22 @@ is no requirement that all composite widgets implement the extra
 functionality required to manage windowless children, so the
 <emphasis remap='I'>accepts_objects</emphasis> field allows a composite widget to declare that it
 is not prepared to do so.
-
 </para>
-</sect3>
 </sect2>
-<sect2 id="Release_to_Release_Compatibility">
+</sect1>
+
+<sect1 id="Release_to_Release_Compatibility_2">
 <title>Release 4 to Release 5 Compatibility</title>
-<!-- .XS -->
-<!-- <function>(SN Release 4 to Release 5 Compatibility</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 At the data structure level, Release 5 retains complete binary
 compatibility with Release 4.  The specification of the
-<function>ObjectPart ,</function>
-<function>RectObjPart ,</function>
-<function>CorePart ,</function>
-<function>CompositePart ,</function>
-<function>ShellPart ,</function>
-<function>WMShellPart ,</function>
-<function>TopLevelShellPart ,</function>
+<function>ObjectPart</function>,
+<function>RectObjPart</function>,
+<function>CorePart</function>,
+<function>CompositePart</function>,
+<function>ShellPart</function>,
+<function>WMShellPart</function>,
+<function>TopLevelShellPart</function>,
 and
 <function>ApplicationShellPart</function>
 instance records was made less strict to permit implementations to
@@ -383,21 +275,15 @@ The Xlib specification for
 and
 <function>XrmOptionDescRec</function>
 was updated to use a new type,
-<function>XPointer ,</function>
+<function>XPointer</function>,
 for the <emphasis remap='I'>addr</emphasis> and <emphasis remap='I'>value</emphasis> fields, respectively, to avoid
 ANSI C conformance problems.  The definition of
 <function>XPointer</function>
 is binary compatible with the previous implementation.
-
 </para>
-<sect3 id="baseTranslations_Resource">
+<sect2 id="baseTranslations_Resource">
 <title>baseTranslations Resource</title>
-<!-- .XS -->
-<!-- <function>(SN baseTranslations Resource</function> -->
-<!-- .XE -->
-
 <para>
-<!-- .LP -->
 A new pseudo-resource, XtNbaseTranslations, was defined to permit
 application developers to specify translation tables in application
 defaults files while still giving end users the ability to augment
@@ -406,8 +292,8 @@ only those applications that wish to take advantage of the new
 functionality or those widgets that may have previously defined
 a resource named ``baseTranslations''.
 </para>
+
 <para>
-<!-- .LP -->
 Applications wishing to take advantage of the new functionality
 would change their application defaults file, e.g., from
 <literallayout class="monospaced">
@@ -422,17 +308,12 @@ compatibility of the defaults file between different versions
 of the application running under Release 4 and Release 5,
 the full translations can be replicated in both the ``translations''
 and the ``baseTranslations'' resource.
-
 </para>
-</sect3>
-<sect3 id="Resource_File_Search_Path">
-<title>Resource File Search Path</title>
-<!-- .XS -->
-<!-- <function>(SN Resource File Search Path</function> -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Resource_File_Search_Path">
+<title>Resource File Search Path</title>
 <para>
-<!-- .LP -->
 The current specification allows implementations greater flexibility
 in defining the directory structure used to hold the application class
 and per-user application defaults files.  Previous specifications
@@ -448,17 +329,12 @@ their own
 and
 <function>\s-1XUSERFILESEARCHPATH\s+1</function>
 values when overriding the system defaults.
-
 </para>
-</sect3>
-<sect3 id="Customization_Resource">
-<title>Customization Resource</title>
-<!-- .XS -->
-<!-- <function>(SN Customization Resource</function> -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Customization_Resource">
+<title>Customization Resource</title>
 <para>
-<!-- .LP -->
 <function>XtResolvePathname</function>
 supports a new substitution string, %C, for specifying separate
 application class resource files according to arbitrary user-specified
@@ -469,85 +345,75 @@ database for the application resource name ``customization'', class
 ``Customization''.  Any application that previously used this
 resource name and class will need to be aware of the possibly
 conflicting semantics.
-
 </para>
-</sect3>
-<sect3 id="Per_Screen_Resource_Database">
-<title>Per-Screen Resource Database</title>
-<!-- .XS -->
-<!-- <function>(SN Per-Screen Resource Database</function> -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Per_Screen_Resource_Database">
+<title>Per-Screen Resource Database</title>
 <para>
-<!-- .LP -->
 To allow a user to specify separate preferences for each screen of a
 display, a per-screen resource specification string has been added and
 multiple resource databases are created; one for each screen.  This
 will affect any application that modified the (formerly unique)
-resource database associated with the display subsequent to the (xI
+resource database associated with the display subsequent to the Intrinsics
 database initialization.  Such applications will need to be aware
 of the particular screen on which each shell widget is to be created.
 </para>
+
 <para>
-<!-- .LP -->
 Although the wording of the specification changed substantially in the
 description of the process by which the resource database(s) is
 initialized, the net effect is the same as in prior releases with the
 exception of the added per-screen resource specification and the new
 customization substitution string in
-<function>XtResolvePathname .</function>
-
+<function>XtResolvePathname</function>.
 </para>
-</sect3>
-<sect3 id="Internationalization_of_Applications">
-<title>Internationalization of Applications</title>
-<!-- .XS -->
-<!-- <function>(SN Internationalization of Applications</function> -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Internationalization_of_Applications">
+<title>Internationalization of Applications</title>
 <para>
-<!-- .LP -->
 Internationalization as defined by ANSI is a technology that
 allows support of an application in a single locale.  In
-adding support for internationalization to the (xI
+adding support for internationalization to the Intrinsics
 the restrictions of this model have been followed.
-In particular, the new (xI interfaces are designed not to
+In particular, the new Intrinsics interfaces are designed not to
 preclude an application from using other alternatives.
-For this reason, no (xI routine makes a call to establish the
+For this reason, no Intrinsics routine makes a call to establish the
 locale.   However, a convenience routine to establish the
 locale at initialize time has been provided, in the form
 of a default procedure that must be explicitly installed
 if the application desires ANSI C locale behavior.
 </para>
+
 <para>
-<!-- .LP -->
 As many objects in X, particularly resource databases, now inherit
 the global locale when they are created, applications wishing to use
 the ANSI C locale model should use the new function
 <function>XtSetLanguageProc</function>
 to do so.
 </para>
+
 <para>
-<!-- .LP -->
 The internationalization additions also define event filters
 as a part of the Xlib Input Method specifications.  The
-(xI enable the use of event filters through additions to
-<function>XtDispatchEvent .</function>
+Intrinsics enable the use of event filters through additions to
+<function>XtDispatchEvent</function>.
 Applications that may not be dispatching all events through
 <function>XtDispatchEvent</function>
 should be reviewed in the context of this new input method mechanism.
 </para>
+
 <para>
-<!-- .LP -->
 In order to permit internationalization of error messages, the name
 and path of the error database file are now allowed to be
 implementation-dependent.
 No adequate standard mechanism has yet been suggested to
-allow the (xI to locate the database from localization information
+allow the Intrinsics to locate the database from localization information
 supplied by the client.
 </para>
+
 <para>
-<!-- .LP -->
 The previous specification for the syntax of the language string
 specified by
 <function>xnlLanguage</function>
@@ -555,20 +421,15 @@ has been dropped to avoid potential conflicts with other standards.
 The language string syntax is now implementation-defined.
 The example syntax cited is consistent with the previous
 specification.
-
 </para>
-</sect3>
-<sect3 id="Permanently_Allocated_Strings">
-<title>Permanently Allocated Strings</title>
-<!-- .XS -->
-<!-- (SN Permanently Allocated Strings -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Permanently_Allocated_Strings">
+<title>Permanently Allocated Strings</title>
 <para>
-<!-- .LP -->
 In order to permit additional memory savings, an Xlib interface was
 added to allow the resource manager to avoid copying certain string
-constants.  The (xI specification was updated to explicitly require
+constants.  The Intrinsics specification was updated to explicitly require
 the Object <emphasis remap='I'>class_name</emphasis>, <emphasis remap='I'>resource_name</emphasis>, <emphasis remap='I'>resource_class</emphasis>,
 <emphasis remap='I'>resource_type</emphasis>, <emphasis remap='I'>default_type</emphasis> in resource tables, Core <emphasis remap='I'>actions</emphasis>
 <emphasis remap='I'>string</emphasis> field, and Constraint <emphasis remap='I'>resource_name</emphasis>, <emphasis remap='I'>resource_class</emphasis>,
@@ -576,78 +437,64 @@ the Object <emphasis remap='I'>class_name</emphasis>, <emphasis remap='I'>resour
 permanently allocated.  This explicit requirement is expected to
 affect only applications that may create and destroy classes
 on the fly.
-
 </para>
-</sect3>
-<sect3 id="Arguments_to_Existing_Functions">
-<title>Arguments to Existing Functions</title>
-<!-- .XS -->
-<!-- <function>(SN Arguments to Existing Functions</function> -->
-<!-- .XE -->
+</sect2>
 
+<sect2 id="Arguments_to_Existing_Functions">
+<title>Arguments to Existing Functions</title>
 <para>
-<!-- .LP -->
 The <emphasis remap='I'>args</emphasis> argument to
-<function>XtAppInitialize ,</function>
-<function>XtVaAppInitialize ,</function>
-<function>XtOpenDisplay ,</function>
-<function>XtDisplayInitialize ,</function>
+<function>XtAppInitialize</function>,
+<function>XtVaAppInitialize</function>,
+<function>XtOpenDisplay</function>,
+<function>XtDisplayInitialize</function>,
 and
 <function>XtInitialize</function>
 were changed from
-<function>Cardinal *</function>
+<function>Cardinal</function>*
 to int* to conform to pre-existing convention and avoid otherwise
 annoying typecasting in ANSI C environments.
-
 </para>
-</sect3>
 </sect2>
-<sect2 id="Release_to_Release_Compatibility">
+</sect1>
+
+<sect1 id="Release_to_Release_Compatibility_3">
 <title>Release 5 to Release 6 Compatibility</title>
-<!-- .XS -->
-<!-- <function>(SN Release 5 to Release 6 Compatibility</function> -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 At the data structure level, Release 6 retains binary compatibility
 with Release 5 for all data structures except
-<function>WMShellPart .</function>
+<function>WMShellPart</function>.
 Three resources were added to the specification.
 The known implementations had unused space in the data structure,
 therefore on some architectures and implementations,
 the size of the part structure will not have changed as a result of this.
-
 </para>
-<sect3 id="Widget_Internals">
+<sect2 id="Widget_Internals">
 <title>Widget Internals</title>
-<!-- .XS -->
-<!-- (SN Widget Internals -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 Two new widget methods for instance allocation and deallocation were added
 to the Object class.  These new methods
 allow widgets to be treated as C++ objects in the C++ environment
 when an appropriate allocation method is specified or inherited
 by the widget class.
 </para>
+
 <para>
-<!-- .LP -->
 The textual descriptions of the processes of widget creation and
 widget destruction have been edited to provide clarification to widget
 writers.  Widgets writers may have reason to rely on the specific order of
 the stages of widget creation and destruction; with that motivation,
 the specification now more exactly describes the process.
 </para>
+
 <para>
-<!-- .LP -->
 As a convenience, an interface to locate a widget class extension
 record on a linked list,
-<function>XtGetClassExtension ,</function>
+<function>XtGetClassExtension</function>,
 has been added.
 </para>
+
 <para>
-<!-- .LP -->
 A new option to allow bundled changes to the managed set of a Composite
 widget is introduced in the Composite class extension record.
 Widgets that define a change_managed procedure that can accommodate
@@ -655,83 +502,75 @@ additions and deletions to the managed set of children in a single
 invocation should set allows_change_managed_set to <function>True</function> in the
 extension record.
 </para>
+
 <para>
-<!-- .LP -->
 The wording of the process followed by
 <function>XtUnmanageChildren</function>
 has changed slightly to better handle changes to the managed set
 during phase 2 destroy processing.
 </para>
+
 <para>
-<!-- .LP -->
 A new exposure event compression flag,
-<function>XtExposeNoRegion ,</function>
+<function>XtExposeNoRegion</function>,
 was added.  Many widgets specify exposure compression, but either
 ignore the actual damage region passed to the core expose procedure or
 use only the cumulative bounding box data available in the event.
 Widgets with expose procedures that do not make use of exact
-exposure region information can indicate that the (xI need not
+exposure region information can indicate that the Intrinsics need not
 compute the region.
-
 </para>
-</sect3>
-<sect3 id="General_Application_Development">
+</sect2>
+
+<sect2 id="General_Application_Development">
 <title>General Application Development</title>
-<!-- .XS -->
-<!-- (SN General Application Development -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 <function>XtOpenApplication</function>
 is a new convenience procedure to initialize the toolkit, create an
 application context, open an X display connection, and create the
 root of the widget instance tree.  It is identical to the interface
 it replaces,
-<function>XtAppInitialize ,</function>
+<function>XtAppInitialize</function>,
 in all respects except that it takes an additional argument specifying
 the widget class of the root shell to create.
 This interface is now the recommended one so that clients may easily
 become session participants.
 The old convenience procedures appear in the compatibility section.
 </para>
+
 <para>
-<!-- .LP -->
 The toolkit initialization function
 <function>XtToolkitInitialize</function>
 may be called multiple times without penalty.
 </para>
+
 <para>
-<!-- .LP -->
 In order to optimize changes in geometry to a set of geometry-managed
 children, a new interface,
-<function>XtChangeManagedSet ,</function>
+<function>XtChangeManagedSet</function>,
 has been added.
-
 </para>
-</sect3>
-<sect3 id="Communication_with_Window_and_Session_Managers">
+</sect2>
+
+<sect2 id="Communication_with_Window_and_Session_Managers">
 <title>Communication with Window and Session Managers</title>
-<!-- .XS -->
-<!-- (SN Communication with Window and Session Managers -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
-The revision of the <emphasis remap='I'>(xC</emphasis> as an X Consortium standard has resulted
+The revision of the <emphasis remap='I'>Inter-Client Communication Conventions Manual.</emphasis> as an X Consortium standard has resulted
 in the addition of three fields to the specification of
-<function>WMShellPart .</function>
+<function>WMShellPart</function>.
 These are <emphasis remap='I'>urgency</emphasis>, <emphasis remap='I'>client_leader</emphasis>, and <emphasis remap='I'>window_role</emphasis>.
 </para>
+
 <para>
-<!-- .LP -->
 The adoption of the <emphasis remap='I'>X Session Management Protocol</emphasis> as an X Consortium
 standard has resulted in the addition of a new shell widget,
-<function>SessionShell ,</function>
+<function>SessionShell</function>,
 and an accompanying subclass verification interface,
-<function>XtIsSessionShell .</function>
+<function>XtIsSessionShell</function>.
 This widget provides support for communication between an application
 and a session manager, as well as a window manager.
 In order to preserve compatibility with existing subclasses of
-<function>ApplicationShell ,</function>
+<function>ApplicationShell</function>,
 the
 <function>ApplicationShell</function>
 was subclassed to create the new widget class.
@@ -743,13 +582,13 @@ the application's notification of and responses to messages from the session
 manager by use of various callback lists and by use of the new interfaces
 <function>XtSessionGetToken</function>
 and
-<function>XtSessionReturnToken .</function>
+<function>XtSessionReturnToken</function>.
 There is also a new command line argument, -xtsessionID, which facilitates
-the session manager in restarting applications based on the (xI.
+the session manager in restarting applications based on the Intrinsics.
 </para>
+
 <para>
-<!-- .LP -->
-The resource name and class strings defined by the (xI shell
+The resource name and class strings defined by the Intrinsics shell
 widgets in
 <function>&lt; X11/Shell.h &gt;</function>
 are now listed in Appendix E.  The addition of a new symbol
@@ -764,54 +603,46 @@ The resource representation type of the XtNwinGravity resource of the
 <function>WMShell</function>
 was changed to XtRGravity in order to register a type
 converter so that window gravity resource values could be specified by name.
-
 </para>
-</sect3>
-<sect3 id="Geometry_Management">
+</sect2>
+
+<sect2 id="Geometry_Management">
 <title>Geometry Management</title>
-<!-- .XS -->
-<!-- (SN Geometry Management -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 A clarification to the specification was made to indicate that geometry
 requests may include current values along with the requested changes.
-
 </para>
-</sect3>
-<sect3 id="Event_Management">
+</sect2>
+
+<sect2 id="Event_Management">
 <title>Event Management</title>
-<!-- .XS -->
-<!-- (SN Event Management -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 In Release 6, support is provided for registering selectors
 and event handlers for events generated by X protocol extensions
 and for dispatching those events to the appropriate widget.
 The new event handler registration interfaces are
 <function>XtInsertEventTypeHandler</function>
 and
-<function>XtRemoveEventTypeHandler .</function>
+<function>XtRemoveEventTypeHandler</function>.
 Since the mechanism to indicate selection of extension events is specific
-to the extension being used, the (xI introduces
-<function>XtRegisterExtensionSelector ,</function>
+to the extension being used, the Intrinsics introduces
+<function>XtRegisterExtensionSelector</function>,
 which allows the application to select for the events of interest.
 In order to change the dispatching algorithm to accommodate extension events
 as well as core X protocol events,
-the (xI event dispatcher may now be replaced or enveloped
+the Intrinsics event dispatcher may now be replaced or enveloped
 by the application with
-<function>XtSetEventDispatcher .</function>
+<function>XtSetEventDispatcher</function>.
 The dispatcher may wish to call
 <function>XtGetKeyboardFocusWidget</function>
-to determine the widget with the current (xI keyboard focus.
+to determine the widget with the current Intrinsics keyboard focus.
 A dispatcher, after determining the destination widget, may use
 <function>XtDispatchEventToWidget</function>
 to cause the event to be dispatched to the event handlers registered
 by a specific widget.
 </para>
+
 <para>
-<!-- .LP -->
 To permit the dispatching of events
 for nonwidget drawables, such as pixmaps that are not associated
 with a widget's window,
@@ -820,77 +651,69 @@ and
 <function>XtUnregisterDrawable</function>
 have been added to the library.  A related update was made to
 the description of
-<function>XtWindowToWidget .</function>
+<function>XtWindowToWidget</function>.
 </para>
+
 <para>
-<!-- .LP -->
 The library is now thread-safe, allowing one thread at a time to
 enter the library and protecting global data as necessary from concurrent use.
 Threaded toolkit applications are supported by the
 new interfaces
-<function>XtToolkitThreadInitialize ,</function>
-<function>XtAppLock ,</function>
-<function>XtAppUnlock ,</function>
-<function>XtAppSetExitFlag ,</function>
+<function>XtToolkitThreadInitialize</function>,
+<function>XtAppLock</function>,
+<function>XtAppUnlock</function>,
+<function>XtAppSetExitFlag</function>,
 and
-<function>XtAppGetExitFlag .</function>
+<function>XtAppGetExitFlag</function>.
 Widget writers may also use
 <function>XtProcessLock</function>
 and
-<function>XtProcessUnlock .</function>
+<function>XtProcessUnlock</function>.
 </para>
+
 <para>
-<!-- .LP -->
 Safe handling of POSIX signals and other asynchronous notifications
 is now provided by use of
-<function>XtAppAddSignal ,</function>
-<function>XtNoticeSignal ,</function>
+<function>XtAppAddSignal</function>,
+<function>XtNoticeSignal</function>,
 and
-<function>XtRemoveSignal .</function>
+<function>XtRemoveSignal</function>.
 </para>
+
 <para>
-<!-- .LP -->
 The application can receive notification of an impending block
-in the (xI event manager by registering interest through
+in the Intrinsics event manager by registering interest through
 <function>XtAppAddBlockHook</function>
 and
-<function>XtRemoveBlockHook .</function>
+<function>XtRemoveBlockHook</function>.
 </para>
+
 <para>
-<!-- .LP -->
 <function>XtLastEventProcessed</function>
 returns the most recent event passed to
 <function>XtDispatchEvent</function>
 for a specified display.
-
 </para>
-</sect3>
-<sect3 id="Resource_Management">
+</sect2>
+
+<sect2 id="Resource_Management">
 <title>Resource Management</title>
-<!-- .XS -->
-<!-- (SN Resource Management -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
-Resource converters are registered by the (xI for window gravity
+Resource converters are registered by the Intrinsics for window gravity
 and for three new resource types associated with session participation:
 RestartStyle, CommandArgArray and DirectoryString.
 </para>
+
 <para>
-<!-- .LP -->
 The file search path syntax has been extended to make it easier to
 include the default search path, which controls resource
 database construction, by using the new substitution string, %D.
-
 </para>
-</sect3>
-<sect3 id="Translation_Management">
+</sect2>
+
+<sect2 id="Translation_Management">
 <title>Translation Management</title>
-<!-- .XS -->
-<!-- (SN Translation Management -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The default key translator now recognizes the NumLock modifier.
 If NumLock is on and the second keysym is a keypad keysym
 (a standard keysym named with a ``KP'' prefix or a
@@ -899,18 +722,14 @@ then the default key translator will
 use the first keysym if Shift and/or ShiftLock is on and will
 use the second keysym if neither is on.  Otherwise, it will
 ignore NumLock and apply the normal protocol semantics.
-
 </para>
-</sect3>
-<sect3 id="Selections">
+</sect2>
+
+<sect2 id="Selections">
 <title>Selections</title>
-<!-- .XS -->
-<!-- (SN Selections -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 The targets of selection requests may be parameterized, as described
-by the revised <emphasis remap='I'>(xC</emphasis>.
+by the revised <emphasis remap='I'>Inter-Client Communication Conventions Manual.</emphasis>.
 When such requests are made,
 <function>XtSetSelectionParameters</function>
 is used by the requestor to specify the target parameters and
@@ -918,27 +737,23 @@ is used by the requestor to specify the target parameters and
 is used by the selection owner to retrieve the parameters.
 When a parameterized target is specified in the context of a bundled
 request for multiple targets,
-<function>XtCreateSelectionRequest ,</function>
-<function>XtCancelSelectionRequest ,</function>
+<function>XtCreateSelectionRequest</function>,
+<function>XtCancelSelectionRequest</function>,
 and
 <function>XtSendSelectionRequest</function>
 are used to envelop the assembly of the request.
 When the parameters themselves are the names of properties,
-the (xI provides support for the economical use of property atom names;
+the Intrinsics provides support for the economical use of property atom names;
 see
 <function>XtReservePropertyAtom</function>
 and
-<function>XtReleasePropertyAtom .</function>
-
+<function>XtReleasePropertyAtom</function>.
 </para>
-</sect3>
-<sect3 id="External_Agent_Hooks">
+</sect2>
+
+<sect2 id="External_Agent_Hooks">
 <title>External Agent Hooks</title>
-<!-- .XS -->
-<!-- (SN External Agent Hooks -->
-<!-- .XE -->
 <para>
-<!-- .LP -->
 External agent hooks were added for the benefit of applications
 that instrument other applications for purposes of accessibility,
 testing, and customization.  The external agent and the application
@@ -947,41 +762,11 @@ The hook callbacks permit the external agent to register interest
 in groups or classes of toolkit activity and to be notified of the
 type and details of the activity as it occurs.  The new interfaces
 related to this effort are
-<function>XtHooksOfDisplay ,</function>
+<function>XtHooksOfDisplay</function>,
 which returns the hook registration widget, and
-<function>XtGetDisplays ,</function>
+<function>XtGetDisplays</function>,
 which returns a list of the X displays associated with an application context.
-<!-- .bp -->
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 </para>
-</sect3>
 </sect2>
+</sect1>
 </chapter>
-</book>