Strip trailing whitespace from sgml docs

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

17 files changed, 1073 insertions, 1073 deletions

diff --git a/sgml/Japanese/1st.sgml b/sgml/Japanese/1st.sgml
index b67b234..354a5fd 100644
--- a/sgml/Japanese/1st.sgml
+++ b/sgml/Japanese/1st.sgml
@@ -46,7 +46,7 @@ ML、FreeBSD98-hackers ML、seraphim-bugs ML、seraphim-beta MLで多くの議論、
 <sect>クレジット<p>
 	PC98用コードはThe XFree86 Project Incと以下のX98 CORE TEAM、および
 	その他の協力者により作成されました。
-  
+
 <p>X98 CORE TEAM
 <itemize>
         <ITEM>会津 宏幸<it/&lt;aizu@jaist.ac.jp&gt;/
@@ -63,7 +63,7 @@ ML、FreeBSD98-hackers ML、seraphim-bugs ML、seraphim-beta MLで多くの議論、
         <ITEM>加藤 康之<it/&lt;yasuyuki@acaets0.anritsu.co.jp&gt;/
         <ITEM>木村 聡<it/&lt;KFB03633@nifty.ne.jp&gt;/
         <ITEM>小池 達也<it/&lt;koiket@focus.rim.or.jp&gt;/
-        <ITEM>H.Komatsuzaki	
+        <ITEM>H.Komatsuzaki
         <ITEM>坂本 崇<it/&lt;sakamoto@yajima.kuis.kyoto-u.ac.jp&gt;/
         <ITEM>佐久間 淳<it/&lt;i931361@jks.is.tsukuba.ac.jp&gt;/
         <ITEM>神保 道夫<it/&lt;karl@spnet.ne.jp&gt;/
diff --git a/sgml/Japanese/read98.sgml b/sgml/Japanese/read98.sgml
index 93909e4..01e59bc 100644
--- a/sgml/Japanese/read98.sgml
+++ b/sgml/Japanese/read98.sgml
@@ -83,9 +83,9 @@ XFree86)されており、従来のボード/チップセット毎のサーバもなくなりました。
 <tag>scanpci</tag>
         厳格な動作確認を行っていませんが、動作するようです。
 <tag>デフォルトのコンパイル時の設定</tag>
-	昔のPC98用サーバと異なり、XFree86は、GetValuesBC NO,BuildPexExt 
+	昔のPC98用サーバと異なり、XFree86は、GetValuesBC NO,BuildPexExt
 	YES,BuildXIE YESと定義されています。ご注意下さい。xengine等で
-	はGetValuesについてソースの修正が必要です。 
+	はGetValuesについてソースの修正が必要です。
 <tag>16MBシステム空間の設定</tag>
 	ボード/チップセットによっては、15M-16Mの領域を使用する物があります。
 	その様なボードを使用している場合、システムセットアップメニューで、
diff --git a/sgml/LICENSE.sgml b/sgml/LICENSE.sgml
index 6289629..84fc425 100644
--- a/sgml/LICENSE.sgml
+++ b/sgml/LICENSE.sgml
@@ -93,7 +93,7 @@ Copyright (C) <Emphasis remap="it">&lt;date&gt;</Emphasis> X Consortium
 </Para>
 
 <Para>
-Permission is hereby granted, free of charge, to any person obtaining a 
+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,
@@ -582,7 +582,7 @@ POSSIBILITY OF SUCH DAMAGE.
 <Title>NVIDIA Corp</Title>
 
 <Para>
-Copyright (c) 1996 NVIDIA, Corp.  All rights reserved.        
+Copyright (c) 1996 NVIDIA, Corp.  All rights reserved.
 </Para>
 
 <Para>
@@ -902,7 +902,7 @@ distribute, sublicense and/or sell copies of Subject Software (defined below)
 in both source code and executable form, and to permit persons to whom the
 Subject Software is furnished in accordance with this License to do the same,
 subject to all of the following terms and conditions, which Recipient accepts
-by engaging in any such use, copying, modifying, merging, publication, 
+by engaging in any such use, copying, modifying, merging, publication,
 distributing, sublicensing or selling:
 </Para>
 
@@ -917,9 +917,9 @@ that is described in Exhibit A as Original Software.</QUOTE
 <Para>
 <QUOTE
 >b. "Modifications" means any addition to or deletion from the
-substance or structure of either the Original Software or any 
-previous Modifications. When Subject Software is released as a 
-series of files, a Modification means (i) any addition to or 
+substance or structure of either the Original Software or any
+previous Modifications. When Subject Software is released as a
+series of files, a Modification means (i) any addition to or
 deletion from the contents of a file containing Original Software
 or previous Modifications and (ii) any new file that contains any
 part of the Original Code or previous Modifications. </QUOTE
@@ -928,7 +928,7 @@ part of the Original Code or previous Modifications. </QUOTE
 
 <Para>
 <QUOTE
->c. "Subject Software" means the Original Software or Modifications 
+>c. "Subject Software" means the Original Software or Modifications
 or the combination of the Original Software and Modifications, or
 portions of any of the foregoing. </QUOTE
 >
@@ -936,13 +936,13 @@ portions of any of the foregoing. </QUOTE
 
 <Para>
 <QUOTE
->d. "Recipient" means an individual or a legal entity exercising 
-rights under the terms of this License. For legal entities, 
-"Recipient" includes any entity that controls, is controlled by, 
+>d. "Recipient" means an individual or a legal entity exercising
+rights under the terms of this License. For legal entities,
+"Recipient" includes any entity that controls, is controlled by,
 or is under common control with Recipient. For purposes of this
-definition, "control" of an entity means (i) the power, direct or 
+definition, "control" of an entity means (i) the power, direct or
 indirect, to direct or manage such entity, or (ii) ownership of
-fifty percent (50&percnt;) or more of the outstanding shares or 
+fifty percent (50&percnt;) or more of the outstanding shares or
 beneficial ownership of such entity.</QUOTE
 >
 </Para>
@@ -957,162 +957,162 @@ License. </QUOTE
 <Para>
 <QUOTE
 >f. "Accompanying Technology" means any software or other technology
-that is not a Modification and that is distributed or made 
-publicly available by Recipient with the Subject Software. 
+that is not a Modification and that is distributed or made
+publicly available by Recipient with the Subject Software.
 Separate software files that do not contain any Original Software
-or any previous Modification shall not be deemed a Modification, 
-even if such software files are aggregated as part of a product, 
-or in any medium of storage, with any file that does contain 
+or any previous Modification shall not be deemed a Modification,
+even if such software files are aggregated as part of a product,
+or in any medium of storage, with any file that does contain
 Original Software or any previous Modification.</QUOTE
 >
 </Para>
 
 <Para>
 2. License Terms. All distribution of the Subject Software must be made
-subject to the terms of this License. A copy of this License and the 
-Required Notice must be included in any documentation for Subject 
+subject to the terms of this License. A copy of this License and the
+Required Notice must be included in any documentation for Subject
 Software where Recipient's rights relating to Subject Software and/or
-any Accompanying Technology are described. Distributions of Subject 
-Software in source code form must also include the Required Notice in 
+any Accompanying Technology are described. Distributions of Subject
+Software in source code form must also include the Required Notice in
 every file distributed. In addition, a ReadMe file entitled "Important
 Legal Notice" must be distributed with each distribution of one or more
-files that incorporate Subject Software. That file must be included with 
-distributions made in both source code and executable form. A copy of 
+files that incorporate Subject Software. That file must be included with
+distributions made in both source code and executable form. A copy of
 the License and the Required Notice must be included in that file.
 Recipient may distribute Accompanying Technology under a license of
 Recipient's choice, which may contain terms different from this License,
-provided that (i) Recipient is in compliance with the terms of this 
-License, (ii) such other license terms do not modify or supersede the 
-terms of this License as applicable to the Subject Software, (iii) 
+provided that (i) Recipient is in compliance with the terms of this
+License, (ii) such other license terms do not modify or supersede the
+terms of this License as applicable to the Subject Software, (iii)
 Recipient hereby indemnifies SGI for any liability incurred by SGI as a
-result of the distribution of Accompanying Technology or the use of 
+result of the distribution of Accompanying Technology or the use of
 other license terms.
 </Para>
 
 <Para>
-3. Termination. This License and the rights granted hereunder will 
+3. Termination. This License and the rights granted hereunder will
 terminate automatically if Recipient fails to comply with terms herein
-and fails to cure such breach within 30 days of the breach. Any 
-sublicense to the Subject Software that is properly granted shall 
+and fails to cure such breach within 30 days of the breach. Any
+sublicense to the Subject Software that is properly granted shall
 survive any termination of this License absent termination by the terms
 of such sublicense. Provisions which, by their nature, must remain in
 effect beyond the termination of this License shall survive.
 </Para>
 
 <Para>
-4. Trademark Rights. This License does not grant any rights to use any 
-trade name, trademark or service mark whatsoever. No trade name, 
-trademark or service mark of SGI may be used to endorse or promote 
-products derived from or incorporating any Subject Software without 
+4. Trademark Rights. This License does not grant any rights to use any
+trade name, trademark or service mark whatsoever. No trade name,
+trademark or service mark of SGI may be used to endorse or promote
+products derived from or incorporating any Subject Software without
 prior written permission of SGI.
 </Para>
 
 <Para>
-5. No Other Rights. No rights or licenses not expressly granted hereunder 
-shall arise by implication, estoppel or otherwise. Title to and 
-ownership of the Original Software at all times remains with SGI. All 
-rights in the Original Software not expressly granted under this 
+5. No Other Rights. No rights or licenses not expressly granted hereunder
+shall arise by implication, estoppel or otherwise. Title to and
+ownership of the Original Software at all times remains with SGI. All
+rights in the Original Software not expressly granted under this
 License are reserved.
 </Para>
 
 <Para>
 6. Compliance with Laws; Non-Infringement. Recipient shall comply with all
 applicable laws and regulations in connection with use and distribution
-of the Subject Software, including but not limited to, all export and 
-import control laws and regulations of the U.S. government and other 
+of the Subject Software, including but not limited to, all export and
+import control laws and regulations of the U.S. government and other
 countries. Recipient may not distribute Subject Software that (i) in any
 way infringes (directly or contributorily) the rights (including patent,
 copyright, trade secret, trademark or other intellectual property rights
-of any kind) of any other person or entity, or (ii) breaches any 
+of any kind) of any other person or entity, or (ii) breaches any
 representation or warranty, express, implied or statutory, which under
-any applicable law it might be deemed to have been distributed. 
+any applicable law it might be deemed to have been distributed.
 </Para>
 
 <Para>
-7. Claims of Infringement. If Recipient at any time has knowledge of any 
-one or more third party claims that reproduction, modification, use, 
+7. Claims of Infringement. If Recipient at any time has knowledge of any
+one or more third party claims that reproduction, modification, use,
 distribution, import or sale of Subject Software (including particular
-functionality or code incorporated in Subject Software) infringes the 
+functionality or code incorporated in Subject Software) infringes the
 third party's intellectual property rights, Recipient must place in a
-well-identified web page bearing the title "LEGAL" a description of 
+well-identified web page bearing the title "LEGAL" a description of
 each such claim and a description of the party making each such claim in
-sufficient detail that a user of the Subject Software will know whom to 
-contact regarding the claim. Also, upon gaining such knowledge of any 
+sufficient detail that a user of the Subject Software will know whom to
+contact regarding the claim. Also, upon gaining such knowledge of any
 such claim, Recipient must conspicuously include the URL for such web
-page in the Required Notice, and in the text of any related 
-documentation, license agreement or collateral in which Recipient 
+page in the Required Notice, and in the text of any related
+documentation, license agreement or collateral in which Recipient
 describes end user's rights relating to the Subject Software. If
-Recipient obtains such knowledge after it makes Subject Software 
-available to any other person or entity, Recipient shall take other 
-steps (such as notifying appropriate mailing lists or newsgroups) 
+Recipient obtains such knowledge after it makes Subject Software
+available to any other person or entity, Recipient shall take other
+steps (such as notifying appropriate mailing lists or newsgroups)
 reasonably calculated to provide such knowledge to those who received
 the Subject Software.
 </Para>
 
 <Para>
 8. DISCLAIMER OF WARRANTY. SUBJECT SOFTWARE IS PROVIDED ON AN "AS IS"
-BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 
-INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE SUBJECT SOFTWARE IS 
-FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR 
-NON-INFRINGING. SGI ASSUMES NO RISK AS TO THE QUALITY AND PERFORMANCE 
+BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE SUBJECT SOFTWARE IS
+FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR
+NON-INFRINGING. SGI ASSUMES NO RISK AS TO THE QUALITY AND PERFORMANCE
 OF THE SOFTWARE. SHOULD ANY SOFTWARE PROVE DEFECTIVE IN ANY RESPECT, SGI
-ASSUMES NO COST OR LIABILITY FOR ANY SERVICING, REPAIR OR CORRECTION. 
-THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS 
+ASSUMES NO COST OR LIABILITY FOR ANY SERVICING, REPAIR OR CORRECTION.
+THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS
 LICENSE. NO USE OF ANY SUBJECT SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT
 UNDER THIS DISCLAIMER.
 </Para>
 
 <Para>
-9. LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL 
-THEORY, WHETHER TORT (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE OR 
+9. LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL
+THEORY, WHETHER TORT (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE OR
 STRICT LIABILITY), CONTRACT, OR OTHERWISE, SHALL SGI OR ANY SGI LICENSOR
-BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
+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 SUBJECT SOFTWARE OR THE USE OR OTHER DEALINGS IN
 THE SUBJECT SOFTWARE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
 LIMITATION OF CERTAIN DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT
-APPLY TO RECIPIENT TO THE EXTENT SO DISALLOWED. 
+APPLY TO RECIPIENT TO THE EXTENT SO DISALLOWED.
 </Para>
 
 <Para>
-10. Indemnity. Recipient shall be solely responsible for damages arising, 
-directly or indirectly, out of its utilization of rights under this 
-License. Recipient will defend, indemnify and hold SGI and its 
-successors and assigns harmless from and against any loss, liability, 
-damages, costs or expenses (including the payment of reasonable 
-attorneys fees) arising out of (Recipient's use, modification, 
-reproduction and distribution of the Subject Software or out of any 
+10. Indemnity. Recipient shall be solely responsible for damages arising,
+directly or indirectly, out of its utilization of rights under this
+License. Recipient will defend, indemnify and hold SGI and its
+successors and assigns harmless from and against any loss, liability,
+damages, costs or expenses (including the payment of reasonable
+attorneys fees) arising out of (Recipient's use, modification,
+reproduction and distribution of the Subject Software or out of any
 representation or warranty made by Recipient.
 </Para>
 
 <Para>
-11. U.S. Government End Users. The Subject Software is a "commercial item" 
+11. U.S. Government End Users. The Subject Software is a "commercial item"
 consisting of "commercial computer software" as such terms are defined
 in title 48 of the Code of Federal Regulations and all U.S. Government
-End Users acquire only the rights set forth in this License and are 
+End Users acquire only the rights set forth in this License and are
 subject to the terms of this License.
 </Para>
 
 <Para>
 12. Miscellaneous. This License represents the complete agreement concerning
-subject matter hereof. If any provision of this License is held to be 
-unenforceable by any judicial or administrative authority having proper 
-jurisdiction with respect thereto, such provision shall be reformed so 
-as to achieve as nearly as possible the same economic effect as the 
-original provision and the remainder of this License will remain in 
-effect. This License shall be governed by and construed in accordance 
-with the laws of the United States and the State of California as 
-applied to agreements entered into and to be performed entirely within 
-California between California residents. Any litigation relating to 
-this License shall be subject to the exclusive jurisdiction of the 
-Federal Courts of the Northern District of California (or, absent 
+subject matter hereof. If any provision of this License is held to be
+unenforceable by any judicial or administrative authority having proper
+jurisdiction with respect thereto, such provision shall be reformed so
+as to achieve as nearly as possible the same economic effect as the
+original provision and the remainder of this License will remain in
+effect. This License shall be governed by and construed in accordance
+with the laws of the United States and the State of California as
+applied to agreements entered into and to be performed entirely within
+California between California residents. Any litigation relating to
+this License shall be subject to the exclusive jurisdiction of the
+Federal Courts of the Northern District of California (or, absent
 subject matter jurisdiction in such courts, the courts of the State of
-California), with venue lying exclusively in Santa Clara County, 
+California), with venue lying exclusively in Santa Clara County,
 California, with the losing party responsible for costs, including
-without limitation, court costs and reasonable attorneys fees and 
+without limitation, court costs and reasonable attorneys fees and
 expenses. The application of the United Nations Convention on Contracts
-for the International Sale of Goods is expressly excluded. Any law or 
-regulation that provides that the language of a contract shall be 
+for the International Sale of Goods is expressly excluded. Any law or
+regulation that provides that the language of a contract shall be
 construed against the drafter shall not apply to this License.
 </Para>
 
@@ -1126,29 +1126,29 @@ Copyright (c) 1994-1999 Silicon Graphics, Inc.
 
 <Para>
 The contents of this file are subject to the CID Font Code Public License
-Version 1.0 (the "License"). You may not use this file except in compliance 
-with the License. You may obtain a copy of the License at Silicon Graphics, 
+Version 1.0 (the "License"). You may not use this file except in compliance
+with the License. You may obtain a copy of the License at Silicon Graphics,
 Inc., attn: Legal Services, 2011 N. Shoreline Blvd., Mountain View, CA 94043
 or at http://www.sgi.com/software/opensource/cid/license.html
 </Para>
 
 <Para>
-Software distributed under the License is distributed on an "AS IS" basis. 
-ALL WARRANTIES ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED 
+Software distributed under the License is distributed on an "AS IS" basis.
+ALL WARRANTIES ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE OR OF
 NON-INFRINGEMENT. See the License for the specific language governing rights
 and limitations under the License.
 </Para>
 
 <Para>
-The Original Software (as defined in the License) is CID font code that was 
+The Original Software (as defined in the License) is CID font code that was
 developed by Silicon Graphics, Inc. Those portions of the Subject Software
 (as defined in the License) that were created by Silicon Graphics, Inc. are
 Copyright (c) 1994-1999 Silicon Graphics, Inc. All Rights Reserved.
 </Para>
 
 <Para>
-&lsqb;NOTE: When using this text in connection with Subject Software delivered 
+&lsqb;NOTE: When using this text in connection with Subject Software delivered
 solely in object code form, Recipient may replace the words "this file" with
 "this software" in both the first and second sentences.]
 </Para>
@@ -1237,51 +1237,51 @@ fonts at gnome dot org.
 <Title>Bigelow &amp; Holmes Inc and URW++ GmbH Luxi font license</Title>
 
 <Para>
-Luxi fonts copyright (c) 2001 by Bigelow &amp; Holmes Inc. Luxi font 
-instruction code copyright (c) 2001 by URW++ GmbH. All Rights 
+Luxi fonts copyright (c) 2001 by Bigelow &amp; Holmes Inc. Luxi font
+instruction code copyright (c) 2001 by URW++ GmbH. All Rights
 Reserved. Luxi is a registered trademark of Bigelow &amp; Holmes Inc.
 </Para>
 
 <Para>
-Permission is hereby granted, free of charge, to any person obtaining 
-a copy of these Fonts and associated documentation files (the "Font 
-Software"), to deal in the Font Software, including without 
-limitation the rights to use, copy, merge, publish, distribute, 
-sublicense, and/or sell copies of the Font Software, and to permit 
-persons to whom the Font Software is furnished to do so, subject to 
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of these Fonts and associated documentation files (the "Font
+Software"), to deal in the Font Software, including without
+limitation the rights to use, copy, merge, publish, distribute,
+sublicense, and/or sell copies of the Font Software, and to permit
+persons to whom the Font Software is furnished to do so, subject to
 the following conditions:
 </Para>
 
 <Para>
-The above copyright and trademark notices and this permission notice 
+The above copyright and trademark notices and this permission notice
 shall be included in all copies of one or more of the Font Software.
 </Para>
 
 <Para>
-The Font Software may not be modified, altered, or added to, and in 
-particular the designs of glyphs or characters in the Fonts may not 
-be modified nor may additional glyphs or characters be added to the 
-Fonts. This License becomes null and void when the Fonts or Font 
+The Font Software may not be modified, altered, or added to, and in
+particular the designs of glyphs or characters in the Fonts may not
+be modified nor may additional glyphs or characters be added to the
+Fonts. This License becomes null and void when the Fonts or Font
 Software have been modified.
 </Para>
 
 <Para>
-THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF 
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT 
-OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT.  IN NO EVENT SHALL 
-BIGELOW &amp; HOLMES INC. OR URW++ GMBH. BE LIABLE FOR ANY CLAIM, DAMAGES 
-OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, 
-INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF 
-CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR 
-INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT 
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT.  IN NO EVENT SHALL
+BIGELOW &amp; HOLMES INC. OR URW++ GMBH. BE LIABLE FOR ANY CLAIM, DAMAGES
+OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT,
+INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF
+CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR
+INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT
 SOFTWARE.
 </Para>
 
 <Para>
-Except as contained in this notice, the names of Bigelow &amp; Holmes 
-Inc. and URW++ GmbH. shall not be used in advertising or otherwise to 
-promote the sale, use or other dealings in this Font Software without 
+Except as contained in this notice, the names of Bigelow &amp; Holmes
+Inc. and URW++ GmbH. shall not be used in advertising or otherwise to
+promote the sale, use or other dealings in this Font Software without
 prior written authorization from Bigelow &amp; Holmes Inc. and URW++ GmbH.
 </Para>
 
diff --git a/sgml/README.sgml b/sgml/README.sgml
index 59c86cd..52124a0 100644
--- a/sgml/README.sgml
+++ b/sgml/README.sgml
@@ -197,8 +197,8 @@ in that document, please contact us with details at
 >xf&lowbar;board@x.org</email
 >.
 While the current licenses are all open source licenses, the
-X.Org Foundation is attempting, with time, to bring as much as 
-possible of the code's licenses in the distribution into compliance with the 
+X.Org Foundation is attempting, with time, to bring as much as
+possible of the code's licenses in the distribution into compliance with the
 <ulink
 url="http://www.debian.org/social_contract#guidelines"
 >Debian Free Software Guidelines</ulink
@@ -234,7 +234,7 @@ Additional information may be available at the <ulink url="http://wiki.x.org/"
 Current information about the X.Org Foundation public mailing lists is
 available on <ulink url="http://lists.x.org/mailman/listinfo/">the X.Org mailing list page</ulink> and related desktop
 technology mailing lists can be found on <ulink
-url="http://freedesktop.org/mailman/listinfo">Freedesktop.org's mailing list 
+url="http://freedesktop.org/mailman/listinfo">Freedesktop.org's mailing list
 page</ulink>.
 </para>
 
diff --git a/sgml/RELNOTES.sgml b/sgml/RELNOTES.sgml
index 5589a3b..773a0da 100644
--- a/sgml/RELNOTES.sgml
+++ b/sgml/RELNOTES.sgml
@@ -64,7 +64,7 @@ as well as what is new in the latest full release (&fullrelvers;).
 ]]>
 <![ %majorrel [
 The next section describes what is new in the latest full release
-(&relvers;) compared with the previous full release 
+(&relvers;) compared with the previous full release
 (&prevrelvers;).
 ]]>
 <![ %minorrel [
@@ -85,15 +85,15 @@ The next section describes what is new in the latest version
 
 <sect1>
     <title>Summary of new features in X11R&relvers;</title>
-    
+
     <para>
     This is a sampling of the new features in X11R&relvers;.
     A more complete list of changes can be found in the ChangeLog files that
     are part of the X source tree.
     </para>
-    
+
     <para>
-    
+
     <itemizedlist>
         <listitem>
             <para>
@@ -120,7 +120,7 @@ The next section describes what is new in the latest version
             the protocol, improved threading support, and extensibility. In
             addition to providing a new programming interface, it also
             provides a libX11 compatibility layer to allow it to be used
-            transparently in place of libX11. 
+            transparently in place of libX11.
             </para>
         </listitem>
         <listitem>
@@ -129,21 +129,21 @@ The next section describes what is new in the latest version
             *BSD family
             </para>
         </listitem>
-        
+
         <listitem>
             <para>
-            Platform support enhancements for x86, amd64, sparc64, and ia64 
+            Platform support enhancements for x86, amd64, sparc64, and ia64
             </para>
         </listitem>
-        
+
         <listitem>
             <para>
-            ... and the usual assortment of correctness and crash fixes.  
+            ... and the usual assortment of correctness and crash fixes.
             </para>
         </listitem>
     </itemizedlist>
     </para>
-    
+
     <sect2>
         <title>Updated keyboard mappings</title>
         <para>
@@ -159,7 +159,7 @@ The next section describes what is new in the latest version
         X11R&relvers; release.
         </para>
     </sect2>
-    
+
     <sect2>
         <title>Video driver enhancements</title>
         <para>
@@ -209,7 +209,7 @@ The next section describes what is new in the latest version
             <row>
                 <entry><Literal remap="tt">ati</Literal></entry>
                 <entry>ATI</entry>
-                <entry><ulink URL="ati.html">README.ati</ulink>, 
+                <entry><ulink URL="ati.html">README.ati</ulink>,
                     <ulink URL="r128.html">README.r128</ulink>,
                     <ulink URL="r128.4.html">r128(4)</ulink>,
                     <ulink URL="radeon.4.html">radeon(4)</ulink></entry>
@@ -281,7 +281,7 @@ The next section describes what is new in the latest version
             <row>
                 <entry><Literal remap="tt">newport</Literal> (-)</entry>
                 <entry>SGI Newport</entry>
-                <entry><ulink URL="newport.html">README.newport</ulink>, 
+                <entry><ulink URL="newport.html">README.newport</ulink>,
                     <ulink URL="newport.4.html">newport(4)</ulink></entry>
             </row>
             <row>
@@ -443,11 +443,11 @@ The next section describes what is new in the latest version
     <para>
     Drivers marked with (+) are for Linux/Sparc only.
     </para>
-    
+
     <para>
     Drivers marked with (-) are for Linux/mips only.
     </para>
-    
+
     <para>
     Darwin/Mac OS X uses IOKit drivers and does not use the module loader
     drivers listed above. Further information can be found in <ulink
@@ -628,7 +628,7 @@ The next section describes what is new in the latest version
     dynamically, and in that manner load the video drivers, input drivers,
     and other modules that are needed.
     </para>
-    
+
     <para>
     X11R&relvers; has currently has support for Linux, Solaris, and some BSD OSs
     on Alpha, PowerPC, IA-64, AMD64, Intel x86, Sparc, and MIPS platforms.
@@ -636,16 +636,16 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>Loader and Modules</title>
-        
+
         <para>
-        The X server 
+        The X server
         relies on the operating system's native module loader support for
         handling program modules. The X server makes use of modules for
         video drivers, X server extensions, font rasterisers, input device
         drivers, framebuffer layers, and internal components used by some
         drivers (like XAA),
         </para>
-        
+
         <para>
         The module interfaces (both API and ABI) used in this release are
         subject to change without notice.  While we will attempt to provide
@@ -654,10 +654,10 @@ The next section describes what is new in the latest version
         not guaranteed because new modules may rely on interfaces added in
         new releases.
         </para>
-        
+
         <para>
         <emphasis remap="bf">Note about module security</emphasis>
-        <quote>The X server runs with root privileges, i.e., 
+        <quote>The X server runs with root privileges, i.e.,
         the X server loadable modules also run with these privileges.
         For this reason we recommend that all users be careful to only
         use loadable modules from reliable sources,  otherwise the
@@ -670,18 +670,18 @@ The next section describes what is new in the latest version
 
     <sect2 id="config">
         <title>Configuration File</title>
-        
+
         <para>
         The X server uses a configuration file as the primary mechanism
         for providing configuration and run-time parameters.  The configuration
         file format is described in detail in the <ulink URL="xorg.conf.5.html">
         xorg.conf(5)</ulink> manual page.
         </para>
-        
+
         <para>
         The recommended method for generating a configuration file is to use
         the Xorg server itself.  Run as root:
-        
+
         <screen>
         Xorg -configure
         </screen>
@@ -695,13 +695,13 @@ The next section describes what is new in the latest version
         It can also be used to customize existing configurations. This
         tool is deprecated, although it is still available for use.
         </para>
-        
+
         <para>
         Finally, if all else fails, the old standby text-based tool
         "<literal remap="tt">xorgconfig</literal>" can also be used for
         generating X server config files.
         </para>
-        
+
         <para>
         At least one, and hopefully, all of these configuration options will
         give you a reasonable starting point for a suitable configuration
@@ -710,7 +710,7 @@ The next section describes what is new in the latest version
         for running the server without a configuration file, so many users
         may find that that they don't need a configuration file.
         </para>
-        
+
         <para>
         If you do need to customize the configuration file, see the <ulink
         URL="xorg.conf.5.html"
@@ -722,7 +722,7 @@ The next section describes what is new in the latest version
 
     <Sect2>
         <title>Command Line Options</title>
-        
+
         <para>
         Command line options can be used to override some default
         parameters and parameters provided in the configuration file.
@@ -733,17 +733,17 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>XAA</title>
-        
+
         <para>
         The XFree86 Acceleration Architecture (XAA) was completely rewritten
-        from scratch for XFree86 4.x and is used in X11R&relvers;.  
+        from scratch for XFree86 4.x and is used in X11R&relvers;.
         Most drivers implement acceleration by making use of the XAA module.
         </para>
     </sect2>
 
     <sect2>
         <title>EXA</title>
-        
+
         <para>
         EXA was created as a new driver acceleration architecture to
         replace XAA. EXA was designed specifically to accelerate Render
@@ -756,12 +756,12 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>Multi-head</title>
-        
+
         <para>
         Some multi-head configurations are supported in X11R&relvers;, primarily
         with multiple PCI/AGP cards.
         </para>
-        
+
         <para>
         One of the main problems is with drivers not sufficiently
         initializing cards that were not initialized at boot time.  This
@@ -785,16 +785,16 @@ The next section describes what is new in the latest version
         all have the same root depth, so it isn't possible, for example, to use
         an 8-bit screen together with a 16-bit screen in Xinerama mode.
         </para>
-        
+
         <para>
         Xinerama is not enabled by default, and can be enabled with the
         <literal remap="tt">+xinerama</literal> command line option for the
         X server.
         </para>
-        
+
         <para>
         Known problems:
-        
+
         <itemizedlist>
             <listitem>
                 <para>
@@ -812,7 +812,7 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>DGA version 2</title>
-        
+
         <para>
         DGA 2.0 is included in &relvers;.  Documentation for the client
         libraries can be found in the <ulink
@@ -825,14 +825,14 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>DDC</title>
-        
+
         <para>
         The VESA&reg; Display Data Channel (DDC&trade;) standard allows the
         monitor to tell the video card (or on some cases the computer
         directly) about itself; particularly the supported screen
         resolutions and refresh rates.
         </para>
-        
+
         <para>
         Partial or complete DDC support is available in most of the video
         drivers.  DDC is enabled by default, but can be disabled with a
@@ -842,17 +842,17 @@ The next section describes what is new in the latest version
         "NoDDC1"</Literal> and <literal remap="tt">Option
         "NoDDC2"</literal>.
         </para>
-        
+
         <para>
         At startup the server prints out DDC information from the display,
         and can use this information to set the default monitor parameters,
         or to warn about monitor sync limits if those provided in the
         configuration file don't match those that are detected.
         </para>
-        
+
         <sect3>
             <title>Changed behavior caused by DDC.</title>
-            
+
             <para>
             Several drivers uses DDC information to set the screen size and
             pitch.  This can be overridden by explicitly resetting it to
@@ -867,7 +867,7 @@ The next section describes what is new in the latest version
 
     <sect2>
         <title>GLX and the Direct Rendering Infrastructure (DRI)</title>
-        
+
         <para>
         Direct rendered OpenGL&reg; support is provided for several
         hardware platforms by the Direct Rendering Infrastructure (DRI).
@@ -897,21 +897,21 @@ The next section describes what is new in the latest version
 
     <Sect2 id="render">
         <Title>X Rendering Extension (Render) </Title>
-        
+
         <Para>
         The X Rendering extension provides a 2D rendering model that more
         closely matches application demands and hardware capabilities.  It
         provides a rendering model derived from Plan 9 based on Porter/Duff
         image composition rather than binary raster operations.
         </Para>
-        
+
         <Para>
         Using simple compositing operators provided by most hardware, Render
-        can draw anti-aliased text and geometric objects as well as perform 
-        translucent image overlays and other image operations not possible with 
+        can draw anti-aliased text and geometric objects as well as perform
+        translucent image overlays and other image operations not possible with
         the core X rendering system.
         </Para>
-        
+
         <Para>
         Unlike the core protocol, Render provides no font support for
         applications, rather it allows applications to upload glyphs for
@@ -920,10 +920,10 @@ The next section describes what is new in the latest version
         information while still providing hardware acceleration.  The Xft
         library provides font access for Render applications.
         </Para>
-        
+
         <Sect3>
             <Title>The Xft Library</Title>
-            
+
             <Para>
             On the client side, the Xft library provides access to fonts
             for applications using the FreeType library, version 2.  One
@@ -933,7 +933,7 @@ The next section describes what is new in the latest version
             DDC, you may want to add that information to <Literal
             remap="tt">xorg.conf</Literal>.
             </Para>
-            
+
             <Para>
             To allow a graceful transition for applications moving from
             core text rendering to the Render extension, Xft can use either
@@ -942,21 +942,21 @@ The next section describes what is new in the latest version
             configuring X11R&relvers; to use an existing FreeType
             installation.
             </Para>
-            
+
             <Para>
             The Xft library uses configuration files, <Literal
             remap="tt">/etc/fonts/fonts.conf</Literal> and <Literal
             remap="tt">/etc/fonts/local.conf</Literal>, which contains
             information about which directories contain font files and also
             provides a sophisticated font aliasing mechanism.
-            Documentation for that file is included in the 
+            Documentation for that file is included in the
             <ulink URL="Xft.3.man">Xft(3)</ulink> man page.
             </Para>
         </Sect3>
-        
+
         <Sect3>
             <Title>Application Support For Anti-Aliased Text</Title>
-            
+
             <Para>
             Only four applications have been modified in X11R&relvers; to
             work with the Render extension and the Xft and FreeType
@@ -964,25 +964,25 @@ The next section describes what is new in the latest version
             x11perf and xclock.  Migration of other applications may occur
             in future releases.
             </Para>
-            
+
             <Para>
             By default, xterm uses core fonts through the standard core
             API.  It has a command line option and associated resource to
             direct it to use Xft instead:
-            
+
             <ItemizedList>
             <ListItem>
-            
+
             <Para>
             <Literal remap="tt">-fa</Literal> family / <Literal remap="tt">.VT100.faceName:</Literal> family.  Selects the font
             family to use.
             </Para>
             </ListItem>
-            
+
             </ItemizedList>
-            
+
             </Para>
-            
+
             <Para>
             Xditview will use Xft instead of the core API by default.
             X11perf includes tests to measure the performance of text
@@ -991,13 +991,13 @@ The next section describes what is new in the latest version
             Render extension, a path which is currently somewhat slower
             than core text.
             </Para>
-            
+
             <Para>
             Xclock uses the Render extension to draw the analog face and
             shares the -fa option and faceName resources with xterm to
             select a font for the digital mode.
             </Para>
-        
+
         </Sect3>
     </Sect2>
 
@@ -1026,17 +1026,17 @@ The next section describes what is new in the latest version
 
     <Sect2>
         <Title>Font support</Title>
-        
+
         <Para>
         Details about the font support in X11R&relvers;.x can be
-        found in the <ulink URL="fonts.html">README.fonts</ulink> 
+        found in the <ulink URL="fonts.html">README.fonts</ulink>
         document.
         </Para>
     </Sect2>
-    
+
     <Sect2>
         <Title>TrueType support</Title>
-        
+
         <Para>
         X11R6.7 came with two TrueType backends.  The functionality from
         the `X-TrueType' backend has been integrated into the `FreeType'
@@ -1046,10 +1046,10 @@ The next section describes what is new in the latest version
         fontenc-based encoding system.
         </Para>
     </Sect2>
-    
+
     <Sect2>
         <Title>Internationalisation of the scalable font backends</Title>
-        
+
         <Para>
         X11R&relvers; has a ``fontenc'' layer to allow the
         scalable font backends to use a common method of font re-encoding.  This
@@ -1058,10 +1058,10 @@ The next section describes what is new in the latest version
         FreeType backends.
         </Para>
     </Sect2>
-    
+
     <Sect2>
         <Title>Large font optimization</Title>
-        
+
         <Para>
         The glyph metrics array, which all the X clients using a particular font
         have access to, is placed in shared memory, so as to reduce redundant
@@ -1069,14 +1069,14 @@ The next section describes what is new in the latest version
         transmitted in a compressed format.
         </Para>
     </Sect2>
-    
+
     <Sect2>
         <Title>Unicode/ISO 10646 support</Title>
-        
+
         <Para>
         What is included in X11R&relvers;
         </Para>
-        
+
         <Para>
         <ItemizedList>
             <ListItem>
@@ -1106,7 +1106,7 @@ The next section describes what is new in the latest version
                 covers all ISO-2022-JP-2 (RFC 1554) characters. The 9x18 font
                 can also be used to implement simple combining characters by
                 accent overstriking. For more information, read Markus Kuhn's
-                <ulink URL="http://www.cl.cam.ac.uk/~mgk25/unicode.html">UTF-8 
+                <ulink URL="http://www.cl.cam.ac.uk/~mgk25/unicode.html">UTF-8
                 and Unicode FAQ</ulink>.
                 </Para>
             </ListItem>
@@ -1131,16 +1131,16 @@ The next section describes what is new in the latest version
         </ItemizedList>
         </Para>
     </Sect2>
-    
+
     <Sect2 id="compose">
         <Title>Xlib Compose file support and extensions </Title>
-        
+
         <Para>
         A more flexible Compose file processing system was added to Xlib in
-        X11R&relvers;.  The compose file is searched for in 
+        X11R&relvers;.  The compose file is searched for in
         the following order:
         </Para>
-        
+
         <Para>
         <OrderedList>
             <ListItem>
@@ -1168,56 +1168,56 @@ The next section describes what is new in the latest version
             </ListItem>
         </OrderedList>
         </Para>
-        
+
         <Para>
         Compose files can now use an "include" instruction.  This allows
         local modifications to be made to existing compose files without
         including all of the content directly.  For example, the system's
         iso8859-1 compose file can be included with a line like this:
-        
+
         <Screen>
         include "/usr/X11R6/lib/X11/locale/iso8859-1/Compose"
         </Screen>
         There are two substitutions that can be made in the file name of the
         include instruction.  <Emphasis remap="bf">&percnt;H</Emphasis> expands to the user's home directory
         (the <Emphasis remap="bf">$HOME</Emphasis> environment variable), and <Emphasis remap="bf">&percnt;L</Emphasis> expands to the
-        name of the locale specific Compose file (i.e., 
+        name of the locale specific Compose file (i.e.,
         "&lt;<Emphasis remap="it">xlocaledir</Emphasis>&gt;<Literal remap="tt">/</Literal>&lt;<Emphasis remap="it">localename</Emphasis>&gt;<Literal remap="tt">/Compose</Literal>").
         </Para>
-        
+
         <Para>
         For example, you can include in your compose file the default Compose file
         by using:
-        
+
         <Screen>
         include "%L"
         </Screen>
         and then rewrite only the few rules that you need to change.  New
         compose rules can be added, and previous ones replaced.
         </Para>
-        
+
         <Para>
         Finally, it is no longer necessary to specify in the right part of
         a rule a locale encoded string in addition to the keysym name.  If
         the string is omitted, Xlib figures it out from the keysym
         according to the current locale.  I.e., if a rule looks like:
-        
+
         <Screen>
         &#60;dead_grave&#62; &#60;A&#62; : "\300" Agrave
         </Screen>
         the result of the composition is always the letter with the "\300"
         code.  But if the rule is:
-        
+
         <Screen>
         &#60;dead_grave&#62; &#60;A&#62; : Agrave
         </Screen>
         the result depends on how Agrave is mapped in the current locale.
         </Para>
     </Sect2>
-    
+
     <Sect2 id="vera">
         <Title>Bitstream Vera fonts </Title>
-        
+
         <Para>
         X11R7.1 includes the Bitstream Vera family of typefaces in TrueType
         format.  This family includes the ``Bitstream Vera Sans'',
@@ -1227,16 +1227,16 @@ The next section describes what is new in the latest version
         fonts include all of the glyphs needed for ISO&nbsp; 8859 parts 1 9
         and 15.
         </Para>
-        
+
         <Para>
         The license terms for the Vera fonts are included in the file
         <Literal remap="tt">COPYRIGHT.Vera</Literal>.
         </Para>
     </Sect2>
-    
+
     <Sect2 id="luxi">
         <Title>Luxi fonts from Bigelow and Holmes </Title>
-        
+
         <Para>
         The X distribution includes the ``Luxi'' family of Type&nbsp;1
         fonts and TrueType fonts.  This family consists of the fonts
@@ -1250,13 +1250,13 @@ The next section describes what is new in the latest version
         glyphs in the Adobe Standard encoding and the Windows 3.1
         character set.
         </Para>
-        
+
         <Para>
         The glyph coverage of the Type&nbsp;1 versions is somewhat reduced,
         and only covers ISO&nbsp;8859 parts 1, 2 and 15 as well as the Adobe
         Standard encoding.
         </Para>
-        
+
         <Para>
         The Luxi fonts are original designs by Kris Holmes and Charles Bigelow
         from Bigelow and Holmes Inc., who developed the Luxi typeface designs
@@ -1265,13 +1265,13 @@ The next section describes what is new in the latest version
         implemented the grid-fitting "hints" and kerning tables in the Luxi
         fonts.
         </Para>
-        
+
         <Para>
         The license terms for the Luxi fonts are included in the file
-        `<Literal remap="tt">COPYRIGHT.BH</Literal>', as well as in the 
-        <ulink URL="LICENSE.html">License document</ulink>.  For further 
-        information, please contact <EMAIL>design@bigelowandholmes.com</EMAIL> 
-        or <EMAIL>info@urwpp.de</EMAIL>, or consult the 
+        `<Literal remap="tt">COPYRIGHT.BH</Literal>', as well as in the
+        <ulink URL="LICENSE.html">License document</ulink>.  For further
+        information, please contact <EMAIL>design@bigelowandholmes.com</EMAIL>
+        or <EMAIL>info@urwpp.de</EMAIL>, or consult the
         <ulink URL="http://www.urwpp.de">URW++ web site</ulink>.
         </Para>
     </Sect2>
@@ -1280,33 +1280,33 @@ The next section describes what is new in the latest version
 
 <Sect1>
     <Title>Miscellaneous</Title>
-    
+
     <Para>
     This section describes other items of note for the
     X11R&relvers; release.
     </Para>
-    
+
     <Sect2>
         <Title>Socket directory ownership and permissions</Title>
-        
+
         <Para>
         The socket directories created in <Literal remap="tt">/tmp</Literal> are now required to be
         owned by root and have their sticky-bit set.  If the permissions are not
         set correctly, the component using this directory will print an error
         message and fail to start.  Common socket directories that are known to
         be affected include:
-        
+
         <Screen>
         /tmp/.font-unix
         /tmp/.ICE-unix
         /tmp/.X11-unix
         </Screen>
-        
+
         These directories are used by the font server, <Literal
         remap="tt">xfs</Literal>, applications using the Inter-Client
         Exchange protocol (ICE) and the X server, respectively.
         </Para>
-        
+
         <Para>
         There are several solutions to the problem of when to create these
         directories.  They could be created at install time by the system's
@@ -1316,17 +1316,17 @@ The next section describes what is new in the latest version
         scripts).  Or, they could be created by PAM modules at service
         startup or user login time.
         </Para>
-        
+
         <Para>
         The solution chosen is platform dependent, and the system administrator
         should be able to handle creating those directories on any systems that
         do not have the correct ownership or permissions.
         </Para>
     </Sect2>
-    
+
     <Sect2>
         <Title>Composite exposes extra visuals</Title>
-        
+
         <Para>
         When the Composite extension is enabled via <Literal
         remap="tt">xorg.conf</Literal> or the command line, a new visual is
@@ -1334,7 +1334,7 @@ The next section describes what is new in the latest version
         applications in that it includes an alpha component.  It is used by
         the compositing manager and other Composite aware applications.
         </Para>
-        
+
         <Para>
         Most X applications ignore this visual since it is not useful to
         them; however some applications mistakenly try to use it, which
@@ -1345,7 +1345,7 @@ The next section describes what is new in the latest version
         the Composite is enabled, try setting this environment variable
         before starting the application.
         </Para>
-        
+
         <Para>
         Since Composite is not enabled by default, it is not expected that this
         issue will be visible to most users.
@@ -1355,7 +1355,7 @@ The next section describes what is new in the latest version
 
 <Sect1>
     <Title>Deprecated components and removal plans</Title>
-    
+
     <Para>
     This section lists current plans for removal of obsolete or deprecated
     components in the X.Org releases.  As our releases are open source,
@@ -1369,7 +1369,7 @@ The next section describes what is new in the latest version
     take over maintainership, either inside or outside of the Xorg release
     process.
     </Para>
-    
+
     <Para>
     <VariableList>
         <VarListEntry>
@@ -1379,7 +1379,7 @@ The next section describes what is new in the latest version
             The LBX extension is has been removed in this release.
             </Para>
             </ListItem>
-        </VarListEntry> 
+        </VarListEntry>
         <VarListEntry>
             <Term>CID Fonts</Term>
             <ListItem>
@@ -1406,7 +1406,7 @@ The next section describes what is new in the latest version
 
 <Sect1>
     <Title>Attributions/Acknowledgements/Credits</Title>
-    
+
     <![ %snapshot [
     <emphasis remap="bf">THIS IS A DRAFT OF THE X11R&relvers; CREDITS
     SECTION.</emphasis>
@@ -1414,8 +1414,8 @@ The next section describes what is new in the latest version
     please
     send details to <email>xorg@lists.freedesktop.org</email>.
     ]]>
-    
-    
+
+
     <Para>
     This section lists the credits for the X11R&relvers;
     release.  For a more detailed breakdown, refer to the ChangeLog file in
@@ -1425,84 +1425,84 @@ The next section describes what is new in the latest version
     > or the
     'cvs log' information for individual source files.
     </Para>
-    
+
     <Para>
     <VariableList>
-    
+
     <VarListEntry>
     <Term>These people contributed in some way to X11R7.1</Term>
     <ListItem>
     <Para>
-    Jonathan Adamczewski, 
-    Dave Airlie, 
-    Paul Anderson, 
-    Eric Anholt, 
-    Andrei Barbu, 
-    Jesse Barnes, 
-    Donnie Berkholz, 
-    Alan Coopersmith, 
-    Michel D&auml;nzer, 
-    Alex Deucher, 
-    Radek Doulik, 
-    Egbert Eich, 
-    Eduard Fuchs, 
-    George Fufutos, 
-    Alexander Gottwald, 
-    Matthieu Herrb, 
-    Ben Herrenschmidt, 
-    Thomas Hellstr&ouml;m, 
-    Fredrik H&ouml;glund, 
-    Kristian H&oslash;gsberg, 
-    Matthias Hopf, 
-    Zephaniah E. Hull, 
-    Alan Hourihane, 
-    Valery Inozemtsev, 
-    Adam Jackson, 
-    Deron Johnson, 
-    Nicholas Joly, 
-    Jaymz Julian, 
-    Lars Knoll, 
-    Egmont Koblinger, 
-    Felix K&uuml;hling, 
-    Philip Langdale, 
-    Kevin E. Martin, 
-    Keith Packard, 
-    Drew Parsons, 
-    Hong Bo Peng, 
-    Aaron Plattner, 
-    Jeremy C. Reed, 
-    David Reveman, 
-    Ian Romanick, 
-    Zack Rusin, 
-    S&oslash;ren Sandmann, 
-    Tilman Sauerbeck, 
-    Roland Scheidegger, 
-    Dag-Erling Sm&oslash;rgrav, 
-    Daniel Stone, 
-    Carl Switzky, 
-    Luc Verhaegen, 
-    Julio M. Merino Vidal, 
-    Zhenyu Wang, 
-    Alex Williamson, 
-    Thomas Winischhofer, 
-    David Woodhouse, 
+    Jonathan Adamczewski,
+    Dave Airlie,
+    Paul Anderson,
+    Eric Anholt,
+    Andrei Barbu,
+    Jesse Barnes,
+    Donnie Berkholz,
+    Alan Coopersmith,
+    Michel D&auml;nzer,
+    Alex Deucher,
+    Radek Doulik,
+    Egbert Eich,
+    Eduard Fuchs,
+    George Fufutos,
+    Alexander Gottwald,
+    Matthieu Herrb,
+    Ben Herrenschmidt,
+    Thomas Hellstr&ouml;m,
+    Fredrik H&ouml;glund,
+    Kristian H&oslash;gsberg,
+    Matthias Hopf,
+    Zephaniah E. Hull,
+    Alan Hourihane,
+    Valery Inozemtsev,
+    Adam Jackson,
+    Deron Johnson,
+    Nicholas Joly,
+    Jaymz Julian,
+    Lars Knoll,
+    Egmont Koblinger,
+    Felix K&uuml;hling,
+    Philip Langdale,
+    Kevin E. Martin,
+    Keith Packard,
+    Drew Parsons,
+    Hong Bo Peng,
+    Aaron Plattner,
+    Jeremy C. Reed,
+    David Reveman,
+    Ian Romanick,
+    Zack Rusin,
+    S&oslash;ren Sandmann,
+    Tilman Sauerbeck,
+    Roland Scheidegger,
+    Dag-Erling Sm&oslash;rgrav,
+    Daniel Stone,
+    Carl Switzky,
+    Luc Verhaegen,
+    Julio M. Merino Vidal,
+    Zhenyu Wang,
+    Alex Williamson,
+    Thomas Winischhofer,
+    David Woodhouse,
     </Para>
     </ListItem>
     </VarListEntry>
     </VariableList>
     </Para>
-    
+
     <Para>
-    The X Window System has been a collaborative effort from its inception. 
+    The X Window System has been a collaborative effort from its inception.
     Our apologies for anyone or organization inadvertently overlooked.
     Many individuals (including major contributors) who worked on X are
     represented by their employers in this list.  If you feel we have left anyone
     out, please let us know.
     </Para>
-    
+
     <Para>
     <VariableList>
-    
+
     <VarListEntry>
     <Term>This product includes software developed by: </Term>
     <ListItem>
@@ -1529,7 +1529,7 @@ The next section describes what is new in the latest version
     Andreas Luik,
     Torrey Lyons,
     Roland Mainz,
-    Kevin E. Martin, 
+    Kevin E. Martin,
     Takuma Murakami,
     Kensuke Matsuzaki,
     Keith Packard,
@@ -1540,339 +1540,339 @@ The next section describes what is new in the latest version
     Toshimitsu Tanaka,
     Nicholas Wourms.
     </Para>
-    
+
     <Para>
-    2d3d Inc., 
+    2d3d Inc.,
     3Dlabs Inc. Ltd.,
-    Aaron Plattner, 
-    Adam de Boor, 
-    Adam Jackson, 
-    Adobe Systems Inc., 
-    After X-TT Project, 
-    AGE Logic Inc., 
-    Alan Coopersmith, 
-    Alan Cox, 
-    Alan Hourihane, 
-    Alexander Gottwald, 
-    Alex Deucher, 
-    Anders Carlsson, 
-    Andreas Luik, 
-    Andreas Monitzer, 
+    Aaron Plattner,
+    Adam de Boor,
+    Adam Jackson,
+    Adobe Systems Inc.,
+    After X-TT Project,
+    AGE Logic Inc.,
+    Alan Coopersmith,
+    Alan Cox,
+    Alan Hourihane,
+    Alexander Gottwald,
+    Alex Deucher,
+    Anders Carlsson,
+    Andreas Luik,
+    Andreas Monitzer,
     Andreas Robinson,
-    Andrew C Aitchison, 
-    Andy Ritger, 
+    Andrew C Aitchison,
+    Andy Ritger,
     Angus Lees,
-    Ani Joshi, 
-    Anton Zioviev, 
-    Apollo Computer Inc., 
-    Apple Computer Inc., 
-    Ares Software Corp., 
-    AT&amp;T Inc., 
-    ATI Technologies Inc., 
+    Ani Joshi,
+    Anton Zioviev,
+    Apollo Computer Inc.,
+    Apple Computer Inc.,
+    Ares Software Corp.,
+    AT&amp;T Inc.,
+    ATI Technologies Inc.,
     BEAM Ltd.,
     Ben Skeggs,
     Benjamin Herrenschmidt,
-    Benjamin Rienfenstahl, 
-    Bigelow and Holmes, 
-    Bill Reynolds, 
-    Bitstream Inc., 
+    Benjamin Rienfenstahl,
+    Bigelow and Holmes,
+    Bill Reynolds,
+    Bitstream Inc.,
     Bogdan Diaconescu,
     Branden Robinson,
-    Brian Fundakowski Feldman, 
-    Brian Goines, 
-    Brian Paul, 
-    Bruno Haible, 
-    Bryan Stine, 
+    Brian Fundakowski Feldman,
+    Brian Goines,
+    Brian Paul,
+    Bruno Haible,
+    Bryan Stine,
     Catharon Productions Inc.,
-    Charles Murcko, 
-    Chen Xiangyang, 
-    Chisato Yamauchi, 
-    Chris Constello, 
-    Christian Zietz, 
-    Cognition Corp., 
-    Compaq Computer Corporation, 
-    Concurrent Computer Corporation, 
-    Conectiva S.A., 
-    Corin Anderson, 
-    Craig Struble, 
-    Daewoo Electronics Co. Ltd., 
-    Dale Schumacher, 
-    Damien Miller, 
-    Daniel Berrange, 
+    Charles Murcko,
+    Chen Xiangyang,
+    Chisato Yamauchi,
+    Chris Constello,
+    Christian Zietz,
+    Cognition Corp.,
+    Compaq Computer Corporation,
+    Concurrent Computer Corporation,
+    Conectiva S.A.,
+    Corin Anderson,
+    Craig Struble,
+    Daewoo Electronics Co. Ltd.,
+    Dale Schumacher,
+    Damien Miller,
+    Daniel Berrange,
     Daniel Borca,
-    Daniel Stone, 
-    Daniver Limited, 
-    Daryll Strauss, 
-    Data General Corporation, 
+    Daniel Stone,
+    Daniver Limited,
+    Daryll Strauss,
+    Data General Corporation,
     Dave Airlie,
-    David Bateman, 
-    David Dawes, 
-    David E. Wexelblat, 
-    David Holland, 
-    David J. McKay, 
-    David McCullough, 
-    David Mosberger-Tang, 
-    David S. Miller, 
-    Davor Matic, 
-    Deron Johnson, 
+    David Bateman,
+    David Dawes,
+    David E. Wexelblat,
+    David Holland,
+    David J. McKay,
+    David McCullough,
+    David Mosberger-Tang,
+    David S. Miller,
+    Davor Matic,
+    Deron Johnson,
     Digeo Inc.,
-    Digital Equipment Corporation, 
-    Dirk Hohndel, 
-    Doug Anson, 
+    Digital Equipment Corporation,
+    Dirk Hohndel,
+    Doug Anson,
     Dmitry Golubev,
-    Earle F. Philhower III, 
-    Edouard TISSERANT, 
-    Eduardo Horvath, 
-    Egbert Eich, 
-    Elliot Lee, 
-    Eric Anholt, 
-    Eric Fortune, 
-    Eric Sunshine, 
-    Erik Fortune, 
-    Erik Nygren, 
-    Evans &#38; Sutherland Computer Corporation, 
+    Earle F. Philhower III,
+    Edouard TISSERANT,
+    Eduardo Horvath,
+    Egbert Eich,
+    Elliot Lee,
+    Eric Anholt,
+    Eric Fortune,
+    Eric Sunshine,
+    Erik Fortune,
+    Erik Nygren,
+    Evans &#38; Sutherland Computer Corporation,
     Fabio Massimo Di Nitto,
-    Fabrizio Gennari, 
+    Fabrizio Gennari,
     Felix Kuehling,
     Finn Thoegersen,
-    Francesco Zappa Nardelli, 
+    Francesco Zappa Nardelli,
     Frank C. Earl,
-    Frederic Lepied, 
-    Free Software Foundation Inc., 
-    Fujitsu Limited, 
-    Fujitsu Open Systems Solutions Inc., 
-    Fuji Xerox Co. Ltd., 
-    Geert Uytterhoeven, 
-    Gerrit Jan Akkerman, 
-    Gerry Toll, 
-    Glenn G. Lai, 
-    GNOME Foundation, 
-    Go Watanabe, 
+    Frederic Lepied,
+    Free Software Foundation Inc.,
+    Fujitsu Limited,
+    Fujitsu Open Systems Solutions Inc.,
+    Fuji Xerox Co. Ltd.,
+    Geert Uytterhoeven,
+    Gerrit Jan Akkerman,
+    Gerry Toll,
+    Glenn G. Lai,
+    GNOME Foundation,
+    Go Watanabe,
     Greg Kroah-Hartman,
-    Greg Parker, 
-    Gregory Mokhin, 
-    GROUPE BULL, 
-    Guy Martin, 
-    Hans Oey, 
-    Harald Koenig, 
-    Harm Hanemaayer, 
-    Harold L Hunt II, 
-    Harry Langenbacher, 
-    Henry A. Worth, 
-    Hewlett-Packard Company, 
-    Hitachi Ltd, 
-    Holger Veit, 
-    Howard Greenwell, 
-    Hummingbird Communications Ltd., 
-    IBM Corporation, 
-    Intel Corporation, 
-    INTERACTIVE Systems Corporation, 
-    International Business Machines Corp., 
-    Itai Nahshon, 
-    Ivan Kokshaysky, 
-    Ivan Pascal, 
-    Jakub Jelinek, 
-    James Tsillas, 
-    Jason Bacon, 
-    Jean-loup Gailly, 
+    Greg Parker,
+    Gregory Mokhin,
+    GROUPE BULL,
+    Guy Martin,
+    Hans Oey,
+    Harald Koenig,
+    Harm Hanemaayer,
+    Harold L Hunt II,
+    Harry Langenbacher,
+    Henry A. Worth,
+    Hewlett-Packard Company,
+    Hitachi Ltd,
+    Holger Veit,
+    Howard Greenwell,
+    Hummingbird Communications Ltd.,
+    IBM Corporation,
+    Intel Corporation,
+    INTERACTIVE Systems Corporation,
+    International Business Machines Corp.,
+    Itai Nahshon,
+    Ivan Kokshaysky,
+    Ivan Pascal,
+    Jakub Jelinek,
+    James Tsillas,
+    Jason Bacon,
+    Jean-loup Gailly,
     Jeff Hartmann,
-    Jeff Kirk, 
-    Jeffrey Hsu, 
-    Jehan Bing, 
-    Jeremy Katz, 
+    Jeff Kirk,
+    Jeffrey Hsu,
+    Jehan Bing,
+    Jeremy Katz,
     Jerome Glisse,
-    Jim Gettys, 
-    Jim Tsillas, 
-    John Dennis, 
-    John Harper, 
-    John Heasley, 
-    Jon Block, 
+    Jim Gettys,
+    Jim Tsillas,
+    John Dennis,
+    John Harper,
+    John Heasley,
+    Jon Block,
     Jon Smirl,
-    Jon Tombs, 
-    Jorge Delgado, 
+    Jon Tombs,
+    Jorge Delgado,
     Jos辿 Fonseca,
-    Joseph Friedman, 
-    Joseph V. Moss, 
-    Juliusz Chroboczek, 
-    Jyunji Takagi, 
-    Kaleb Keithley, 
-    Kazushi (Jam) Marukawa, 
-    Kazuyuki (ikko-) Okamoto, 
-    Kean Johnston, 
-    Keith Packard, 
-    Keith Whitwell, 
-    Kensuke Matsuzaki, 
-    Kristian H&oslash;gsberg, 
-    Larry Wall, 
-    Lawrence Berkeley Laboratory, 
+    Joseph Friedman,
+    Joseph V. Moss,
+    Juliusz Chroboczek,
+    Jyunji Takagi,
+    Kaleb Keithley,
+    Kazushi (Jam) Marukawa,
+    Kazuyuki (ikko-) Okamoto,
+    Kean Johnston,
+    Keith Packard,
+    Keith Whitwell,
+    Kensuke Matsuzaki,
+    Kristian H&oslash;gsberg,
+    Larry Wall,
+    Lawrence Berkeley Laboratory,
     Leif Delgass,
-    Lennart Augustsson, 
-    Leon Shiman, 
-    Lexmark International Inc., 
-    Linus Torvalds, 
-    Luc Verhaegen, 
-    Machine Vision Holdings Inc., 
-    Manfred Brands, 
-    Marc Aurele La France Mark Adler, 
-    Mark J. Kilgard, 
-    Mark Leisher, 
-    Mark Smulders, 
-    Mark Vojkovich, 
+    Lennart Augustsson,
+    Leon Shiman,
+    Lexmark International Inc.,
+    Linus Torvalds,
+    Luc Verhaegen,
+    Machine Vision Holdings Inc.,
+    Manfred Brands,
+    Marc Aurele La France Mark Adler,
+    Mark J. Kilgard,
+    Mark Leisher,
+    Mark Smulders,
+    Mark Vojkovich,
     Marvin Solomon,
-    Massachusetts Institute Of Technology, 
-    Matrox Graphics, 
-    Matthew Grossman, 
-    Matthieu Herrb, 
-    Metro Link Inc., 
-    Michael Bax, 
-    Michael H. Schimek, 
-    Michael P. Marking, 
-    Michael Schimek, 
-    Michael Smith, 
-    Michel Daenzer, 
-    Mike A. Harris, 
-    Ming Yu, 
-    MIPS Computer Systems Inc., 
-    National Semiconductor, 
-    NCR Corporation Inc., 
-    Netscape Communications Corporation, 
-    Network Computing Devices Inc., 
+    Massachusetts Institute Of Technology,
+    Matrox Graphics,
+    Matthew Grossman,
+    Matthieu Herrb,
+    Metro Link Inc.,
+    Michael Bax,
+    Michael H. Schimek,
+    Michael P. Marking,
+    Michael Schimek,
+    Michael Smith,
+    Michel Daenzer,
+    Mike A. Harris,
+    Ming Yu,
+    MIPS Computer Systems Inc.,
+    National Semiconductor,
+    NCR Corporation Inc.,
+    Netscape Communications Corporation,
+    Network Computing Devices Inc.,
     Nicholas Miell,
-    Nicholas Wourms, 
+    Nicholas Wourms,
     Nicolai Haehnle,
-    Noah Levitt, 
-    Nolan Leake, 
-    Novell Inc., 
-    Nozomi YTOW, 
-    NTT Software Corporation, 
-    Number Nine Computer Corp., 
-    Number Nine Visual Technologies, 
-    NVIDIA Corp., 
-    Oivier Danet, 
-    Oki Technosystems Laboratory Inc., 
-    OMRON Corporation, 
-    Open Software Foundation, 
-    Orest Zborowski, 
-    Owen Taylor, 
-    Pablo Saratxaga, 
-    Panacea Inc., 
-    Panagiotis Tsirigotis, 
-    Paolo Severini, 
-    Pascal Haible, 
-    Patrick Lecoanet, 
-    Patrick Lerda, 
-    Paul Anderson, 
-    Paul Elliott, 
+    Noah Levitt,
+    Nolan Leake,
+    Novell Inc.,
+    Nozomi YTOW,
+    NTT Software Corporation,
+    Number Nine Computer Corp.,
+    Number Nine Visual Technologies,
+    NVIDIA Corp.,
+    Oivier Danet,
+    Oki Technosystems Laboratory Inc.,
+    OMRON Corporation,
+    Open Software Foundation,
+    Orest Zborowski,
+    Owen Taylor,
+    Pablo Saratxaga,
+    Panacea Inc.,
+    Panagiotis Tsirigotis,
+    Paolo Severini,
+    Pascal Haible,
+    Patrick Lecoanet,
+    Patrick Lerda,
+    Paul Anderson,
+    Paul Elliott,
     Paul Mackerras,
-    Peter Breitenlohner, 
-    Peter Kunzmann, 
-    Peter Trattler, 
-    Philip Homburg, 
-    Precision Insight Inc., 
-    Prentice Hall, 
-    Quarterdeck Office Systems, 
-    Ralf Habacker Randy Hendry, 
-    Ranier Keller, 
-    Red Hat Inc., 
-    Regents of the University of California, 
-    Regis Cridlig, 
-    Rene Cougnenc, 
-    Richard A. Hecker, 
-    Richard Burdick, 
-    Rich Murphey, 
-    Rickard E. Faith, 
-    Rik Faith, 
-    Robert Chesler, 
+    Peter Breitenlohner,
+    Peter Kunzmann,
+    Peter Trattler,
+    Philip Homburg,
+    Precision Insight Inc.,
+    Prentice Hall,
+    Quarterdeck Office Systems,
+    Ralf Habacker Randy Hendry,
+    Ranier Keller,
+    Red Hat Inc.,
+    Regents of the University of California,
+    Regis Cridlig,
+    Rene Cougnenc,
+    Richard A. Hecker,
+    Richard Burdick,
+    Rich Murphey,
+    Rickard E. Faith,
+    Rik Faith,
+    Robert Chesler,
     Robert Millan,
-    Robert V. Baron, 
-    Robin Cutshaw, 
-    Roland Mainz, 
-    Ronny Vindenes, 
-    Russ Blaine, 
-    Ryan Breen, 
-    Ryan Lortie, 
-    Ryan Underwood, 
-    S3 Graphics Inc., 
-    Sam Leffler, 
-    SciTech Software, 
-    Scott Laird, 
-    Sebastien Marineau, 
-    Shigehiro Nomura, 
-    ShoGraphics Inc., 
-    Shunsuke Akiyama, 
-    Silicon Graphics Computer Systems Inc., 
-    Silicon Integrated Systems Corp Inc., 
-    Silicon Motion Inc., 
-    Simon P. Cooper, 
-    Snitily Graphics Consulting Services, 
-    Sony Corporation, 
-    S&oslash;ren Sandmann, 
-    SRI, 
-    Stanislav Brabec, 
-    Stefan Dirsch, 
-    Stephan Lang, 
+    Robert V. Baron,
+    Robin Cutshaw,
+    Roland Mainz,
+    Ronny Vindenes,
+    Russ Blaine,
+    Ryan Breen,
+    Ryan Lortie,
+    Ryan Underwood,
+    S3 Graphics Inc.,
+    Sam Leffler,
+    SciTech Software,
+    Scott Laird,
+    Sebastien Marineau,
+    Shigehiro Nomura,
+    ShoGraphics Inc.,
+    Shunsuke Akiyama,
+    Silicon Graphics Computer Systems Inc.,
+    Silicon Integrated Systems Corp Inc.,
+    Silicon Motion Inc.,
+    Simon P. Cooper,
+    Snitily Graphics Consulting Services,
+    Sony Corporation,
+    S&oslash;ren Sandmann,
+    SRI,
+    Stanislav Brabec,
+    Stefan Dirsch,
+    Stephan Lang,
     Stephane Marchesin,
-    Steven Lang, 
-    Stuart Kreitman, 
-    Sun Microsystems Inc., 
-    SunSoft Inc., 
-    SuSE Inc, 
-    Sven Luther, 
+    Steven Lang,
+    Stuart Kreitman,
+    Sun Microsystems Inc.,
+    SunSoft Inc.,
+    SuSE Inc,
+    Sven Luther,
     T. A. Phelps,
-    Takis Psarogiannakopoulos, 
-    Takuma Murakami, 
-    Takuya SHIOZAKI, 
-    Tektronix Inc., 
-    The DOS-EMU-Development-Team, 
-    The Institute of Software Academia Sinica, 
-    The NetBSD Foundation, 
-    Theo de Raadt, 
-    Theodore Ts'o, 
-    The Open Group, 
-    The Open Software Foundation, 
-    The Regents of the University of California, 
-    The Santa Cruz Operation Inc., 
-    The Weather Channel Inc., 
-    The X Consortium, 
-    The XFree86 Project Inc., 
-    Thomas E. Dickey, 
-    Thomas G. Lane, 
-    Thomas Hellstr&ouml;m, 
-    Thomas Mueller, 
-    Thomas Roell, 
-    Thomas Thanner, 
-    Thomas Winischhofer, 
-    Thomas Wolfram, 
-    Thorsten.Ohl, 
-    Tiago Gons, 
-    Todd C. Miller, 
-    Tomohiro KUBOTA, 
-    Torrey Lyons, 
-    Torrey T. Lyons, 
-    TOSHIBA Corp., 
-    Toshimitsu Tanaka, 
-    Travis Tilley, 
+    Takis Psarogiannakopoulos,
+    Takuma Murakami,
+    Takuya SHIOZAKI,
+    Tektronix Inc.,
+    The DOS-EMU-Development-Team,
+    The Institute of Software Academia Sinica,
+    The NetBSD Foundation,
+    Theo de Raadt,
+    Theodore Ts'o,
+    The Open Group,
+    The Open Software Foundation,
+    The Regents of the University of California,
+    The Santa Cruz Operation Inc.,
+    The Weather Channel Inc.,
+    The X Consortium,
+    The XFree86 Project Inc.,
+    Thomas E. Dickey,
+    Thomas G. Lane,
+    Thomas Hellstr&ouml;m,
+    Thomas Mueller,
+    Thomas Roell,
+    Thomas Thanner,
+    Thomas Winischhofer,
+    Thomas Wolfram,
+    Thorsten.Ohl,
+    Tiago Gons,
+    Todd C. Miller,
+    Tomohiro KUBOTA,
+    Torrey Lyons,
+    Torrey T. Lyons,
+    TOSHIBA Corp.,
+    Toshimitsu Tanaka,
+    Travis Tilley,
     Trolltech AS,
-    Tungsten Graphics Inc., 
+    Tungsten Graphics Inc.,
     Tuomas J. Lukka,
-    Ty Sarna, 
-    UCHIYAMA Yasushi, 
-    Unicode Inc., 
-    UniSoft Group Limited, 
-    University of Utah, 
-    University of Wisconsin, 
-    UNIX System Laboratories Inc., 
-    URW++ GmbH, 
-    VA Linux Systems, 
-    VIA Technologies Inc., 
-    Video Electronics Standard, 
-    VMware Inc., 
-    Vrije Universiteit, 
-    Wittawat Yamwong, 
-    Wyse Technology Inc., 
-    X Consortium, 
-    Xi Graphics Inc., 
-    X-Oz Technologies, 
+    Ty Sarna,
+    UCHIYAMA Yasushi,
+    Unicode Inc.,
+    UniSoft Group Limited,
+    University of Utah,
+    University of Wisconsin,
+    UNIX System Laboratories Inc.,
+    URW++ GmbH,
+    VA Linux Systems,
+    VIA Technologies Inc.,
+    Video Electronics Standard,
+    VMware Inc.,
+    Vrije Universiteit,
+    Wittawat Yamwong,
+    Wyse Technology Inc.,
+    X Consortium,
+    Xi Graphics Inc.,
+    X-Oz Technologies,
     X-TrueType Server Project and their contributors,
     Yu Shao.
     </Para>
diff --git a/sgml/core/Xserver-spec.sgml b/sgml/core/Xserver-spec.sgml
index 5dcd056..23f7fc6 100644
--- a/sgml/core/Xserver-spec.sgml
+++ b/sgml/core/Xserver-spec.sgml
@@ -121,7 +121,7 @@
 <!-- Original authorship information:
 
 .OF 'Porting Layer Definition'- % -'October 27, 2004'
-Definition of the Porting Layer 
+Definition of the Porting Layer
 for the X v11 Sample Server
 Susan Angebranndt
 Raymond Drewry
@@ -165,7 +165,7 @@ In practice, monochrome displays are now almost unheard of, with 4 bit
 gray scale displays being the low end.
 </para>
 <para>
-X is designed for a networking environment where 
+X is designed for a networking environment where
 users can run applications on machines other than their own workstations.
 Sometimes, the connection is over an Ethernet network with a protocol such as TCP/IP;
 but, any "reliable" byte stream is allowable.
@@ -210,9 +210,9 @@ The server code is organized into four major pieces:
 <para>
 The "porting layer" consists of the OS and DDX layers; these are
 actually parallel and neither one is on top of the other.
-The DIX layer is intended to be portable 
+The DIX layer is intended to be portable
 without change to target systems and is not
-detailed here, although several routines 
+detailed here, although several routines
 in DIX that are called by DDX are
 documented.
 Extensions incorporate new functionality into the server; and require
@@ -233,7 +233,7 @@ Section 6 describes the functions which exist for the extension writer.
 <para>
 The DIX layer is the machine and device independent part of X.
 The source should be common to all operating systems and devices.
-The port process should not include changes to this part, therefore internal interfaces to DIX 
+The port process should not include changes to this part, therefore internal interfaces to DIX
 modules are not discussed, except for public interfaces to the DDX and the OS layers.
 The functions described in this section are available for extension writers to use.
 </para>
@@ -261,9 +261,9 @@ Most of these operations are performed by OS and DDX routines that you must supp
   <title>Server Resource System</title>
 <para>
 X resources are C structs inside the server.
-Client applications create and manipulate these objects 
+Client applications create and manipulate these objects
 according to the rules of the X byte stream protocol.
-Client applications refer to resources with resource IDs, 
+Client applications refer to resources with resource IDs,
 which are 32-bit integers that are sent over the network.
 Within the server, of course, they are just C structs, and we refer to them
 by pointers.
@@ -284,8 +284,8 @@ The DDX layer has several kinds of resources:
 </itemizedlist>
 </para>
 <para>
-The type names of the more 
-important server 
+The type names of the more
+important server
 structs usually end in "Rec," such as "DeviceRec;"
 the pointer types usually end in "Ptr," such as "DevicePtr."
 </para>
@@ -295,7 +295,7 @@ important defined constants are declared
 in .h files that have names that suggest the name of the object.
 For instance, there are two .h files for windows,
 window.h and windowstr.h.
-window.h defines only what needs to be defined in order to use windows 
+window.h defines only what needs to be defined in order to use windows
 without peeking inside of them;
 windowstr.h defines the structs with all of their components in great detail
 for those who need it.
@@ -339,7 +339,7 @@ as opposed to a free routine, not in a data structure:
 </blockquote>
 </para>
 <para>
-The attribute fields are mostly set by DIX; DDX should not modify them 
+The attribute fields are mostly set by DIX; DDX should not modify them
 unless noted otherwise.
 </para>
 </section>
@@ -370,7 +370,7 @@ type.  To allocate a new class bit, call
 </programlisting></blockquote>
 </para>
 <para>
-There are two ways of looking up resources, by type or 
+There are two ways of looking up resources, by type or
 by class.  Classes are non-exclusive subsets of the space of
 all resources, so you can lookup the union of multiple classes.
 (RC_ANY is the union of all classes).</para>
@@ -507,7 +507,7 @@ successful.</para>
 	    CallbackListPtr *pcbl;
 	    CallbackProcPtr callback;
 	    pointer         subscriber_data;
- 
+
 </programlisting></blockquote>
 Adds the (callback, subscriber_data) pair to the given callback list.  Creates the callback
 list if it doesn't exist.  Returns TRUE if successful.</para>
@@ -556,11 +556,11 @@ should be called by InitExtensions.
 		MainProc, SwappedMainProc, CloseDownProc, MinorOpcodeProc)
 
 		char *name;  /*Null terminate string; case matters*/
-		int NumEvents;                
-		int NumErrors;                
+		int NumEvents;
+		int NumErrors;
 		int (* MainProc)(ClientPtr);/*Called if client matches server order*/
 		int (* SwappedMainProc)(ClientPtr);/*Called if client differs from server*/
-		void (* CloseDownProc)(ExtensionEntry *);  
+		void (* CloseDownProc)(ExtensionEntry *);
 		unsigned short (*MinorOpcodeProc)(ClientPtr);
 
 </programlisting></blockquote>
@@ -591,10 +591,10 @@ LengthRestL, SwapRestS, SwapRestL, swapl, swaps, cpswapl, and cpswaps.</para>
 <section>
   <title>OS Layer</title>
 <para>
-This part of the source consists of a few routines that you have to rewrite 
+This part of the source consists of a few routines that you have to rewrite
 for each operating system.
-These OS functions maintain the client connections and schedule work 
-to be done for clients.  
+These OS functions maintain the client connections and schedule work
+to be done for clients.
 They also provide an interface to font files,
 font name to file name translation, and
 low level memory management.
@@ -608,7 +608,7 @@ The sample server implementation is in Xserver/os/osinit.c.
 <section>
   <title>Scheduling and Request Delivery</title>
 <para>
-The main dispatch loop in DIX creates the illusion of multitasking between 
+The main dispatch loop in DIX creates the illusion of multitasking between
 different windows, while the server is itself but a single process.
 The dispatch loop breaks up the work for each client into small digestible parts.
 Some parts are requests from a client, such as individual graphic commands.
@@ -628,7 +628,7 @@ You must supply some of the pieces for proper scheduling between clients.
 </para>
 <para>
 WaitForSomething is the scheduler procedure you must write that will
-suspend your server process until something needs to be done.   
+suspend your server process until something needs to be done.
 This call should
 make the server suspend until one or more of the following occurs:
 <itemizedlist>
@@ -638,7 +638,7 @@ make the server suspend until one or more of the following occurs:
 </itemizedlist>
 </para>
 <para>
-Before WaitForSomething() computes the masks to pass to select, poll or 
+Before WaitForSomething() computes the masks to pass to select, poll or
 similar operating system interface, it needs to
 see if there is anything to do on the work queue; if so, it must call a DIX
 routine called ProcessWorkQueue.
@@ -814,7 +814,7 @@ returned as the result value of the call.
 These are not clients that have full requests ready, but any clients who have
 any data ready to be read or processed.
 The DIX dispatcher
-will process requests from each client in turn by calling 
+will process requests from each client in turn by calling
 ReadRequestFromClient(), below.
 </para>
 <para>
@@ -828,8 +828,8 @@ by calling the DIX routine:
 </programlisting></blockquote>
 This routine returns NULL if a new client cannot be allocated (e.g. maximum
 number of clients reached).  The ospriv argument will be stored into the OS
-private field (pClient->osPrivate), to store OS private information about the 
-client.  In the sample server, the osPrivate field contains the 
+private field (pClient->osPrivate), to store OS private information about the
+client.  In the sample server, the osPrivate field contains the
 number of the socket for this client. See also "New Client Connections."
 NextAvailableClient() will call InsertFakeRequest(), so you must be
 prepared for this.
@@ -864,11 +864,11 @@ and RemoveEnabledDevice are in Xserver/os/connection.c.
 <section>
   <title>Timer Facilities</title>
 <para>
-Similarly, the X server or an extension may need to wait for some timeout. 
+Similarly, the X server or an extension may need to wait for some timeout.
 Early X releases implemented this functionality using block and wakeup handlers,
 but this has been rewritten to use a general timer facilty, and the
 internal screen saver facilties reimplemented to use Timers.
-These functions are TimerInit, TimerForce, TimerSet, TimerCheck, TimerCancel, 
+These functions are TimerInit, TimerForce, TimerSet, TimerCheck, TimerCancel,
 and TimerFree, as defined in Xserver/include/os.h. A callback function will be called
 when the timer fires, along with the current time, and a user provided argument.
 <blockquote><programlisting>
@@ -920,7 +920,7 @@ Calling TimerCheck will force the server to see if any timer callbacks should be
 <section>
   <title>New Client Connections</title>
 <para>
-The process whereby a new client-server connection starts up is 
+The process whereby a new client-server connection starts up is
 very dependent upon what your byte stream mechanism.
 This section describes byte stream initiation using examples from the TCP/IP
 implementation on the sample server.
@@ -929,25 +929,25 @@ implementation on the sample server.
 The first thing that happens is a client initiates a connection with the server.
 How a client knows to do this depends upon your network facilities and the
 Xlib implementation.
-In a typical scenario, a user named Fred 
+In a typical scenario, a user named Fred
 on his X workstation is logged onto a Cray
 supercomputer running a command shell in an X window.  Fred can type shell
 commands and have the Cray respond as though the X server were a dumb terminal.
 Fred types in a command to run an X client application that was linked with Xlib.
-Xlib looks at the shell environment variable DISPLAY, which has the 
+Xlib looks at the shell environment variable DISPLAY, which has the
 value "fredsbittube:0.0."
-The host name of Fred's workstation is "fredsbittube," and the 0s are 
+The host name of Fred's workstation is "fredsbittube," and the 0s are
 for multiple screens and multiple X server processes.
-(Precisely what 
+(Precisely what
 happens on your system depends upon how X and Xlib are implemented.)
 </para>
 <para>
-The client application calls a TCP routine on the 
+The client application calls a TCP routine on the
 Cray to open a TCP connection for X
 to communicate with the network node "fredsbittube."
 The TCP software on the Cray does this by looking up the TCP
 address of "fredsbittube" and sending an open request to TCP port 6000
-on fredsbittube.  
+on fredsbittube.
 </para>
 <para>
 All X servers on TCP listen for new clients on port 6000 by default;
@@ -964,7 +964,7 @@ This is the byte stream that all X communications will go over.
 Actually, it is a bit more complicated than that.
 Each X server process running on the host machine is called a "display."
 Each display can have more than one screen that it manages.
-"corporatehydra:3.2" represents screen 2 on display 3 on 
+"corporatehydra:3.2" represents screen 2 on display 3 on
 the multi-screened network node corporatehydra.
 The open request would be sent on well-known port number 6003.
 </para>
@@ -972,11 +972,11 @@ The open request would be sent on well-known port number 6003.
 Once the byte stream is set up, what goes on does not depend very much
 upon whether or not it is TCP.
 The client sends an xConnClientPrefix struct (see Xproto.h) that has the
-version numbers for the version of Xlib it is running, some byte-ordering information, 
+version numbers for the version of Xlib it is running, some byte-ordering information,
 and two character strings used for authorization.
 If the server does not like the authorization strings
 or the version numbers do not match within the rules,
-or if anything else is wrong, it sends a failure 
+or if anything else is wrong, it sends a failure
 response with a reason string.
 </para>
 <para>
@@ -1033,7 +1033,7 @@ routine is called from the main loop:
 
 	void ResetWellKnownSockets()
 </programlisting></blockquote>
-Sample implementations of both of these routines are found in 
+Sample implementations of both of these routines are found in
 Xserver/os/connection.c.
 </para>
 <para>
@@ -1058,22 +1058,22 @@ It is the responsibility of the following routine to break it up into request bl
 You must write
 the routine ReadRequestFromClient() to get one request from the byte stream
 belonging to client "who."
-You must swap the third and fourth bytes (the second 16-bit word) according to the 
+You must swap the third and fourth bytes (the second 16-bit word) according to the
 byte-swap rules of
 the protocol to determine the length of the
-request.  
-This length is measured in 32-bit words, not in bytes.  Therefore, the 
+request.
+This length is measured in 32-bit words, not in bytes.  Therefore, the
 theoretical maximum request is 256K.
 (However, the maximum length allowed is dependent upon the server's input
-buffer.  This size is sent to the client upon connection.  The maximum 
+buffer.  This size is sent to the client upon connection.  The maximum
 size is the constant MAX_REQUEST_SIZE in Xserver/include/os.h)
 The rest of the request you return is
-assumed NOT to be correctly swapped for internal 
+assumed NOT to be correctly swapped for internal
 use, because that is the responsibility of DIX.
 </para>
 <para>
 The 'who' argument is the ClientPtr returned from WaitForSomething.
-The return value indicating status should be set to the (positive) byte count if the read is successful, 
+The return value indicating status should be set to the (positive) byte count if the read is successful,
 0 if the read was blocked, or a negative error code if an error happened.
 </para>
 <para>
@@ -1081,7 +1081,7 @@ You must then store a pointer to
 the bytes of the request in the client request buffer field;
 who->requestBuffer.  This can simply be a pointer into your buffer;
 DIX may modify it in place but will not otherwise cause damage.
-Of course, the request must be contiguous; you must 
+Of course, the request must be contiguous; you must
 shuffle it around in your buffers if not.
 </para>
 <para>
@@ -1127,7 +1127,7 @@ request.  ResetCurrentRequest() should always cause a yield (isItTimeToYield).
 		int n;
 		char *buf;
 </programlisting></blockquote>
-WriteToClient should write n bytes starting at buf to the 
+WriteToClient should write n bytes starting at buf to the
 ClientPtr "who".
 It returns the number of bytes written, but for simplicity,
 the number returned must be either the same value as the number
@@ -1236,7 +1236,7 @@ first client.
 <blockquote><programlisting>
 	Bool isItTimeToYield;
 </programlisting></blockquote>
-isItTimeToYield is a global variable you can set 
+isItTimeToYield is a global variable you can set
 if you want to tell
 DIX to end the client's "time slice" and start paying attention to the next client.
 After the current request is finished, DIX will move to the next client.
@@ -1249,18 +1249,18 @@ server, ReadRequestFromClient() sets isItTimeToYield after
 <para>
 This scheduling algorithm can have a serious effect upon performance when two
 clients are drawing into their windows simultaneously.
-If it allows one client to run until its request 
+If it allows one client to run until its request
 queue is empty by ignoring isItTimeToYield, the client's queue may
 in fact never empty and other clients will be blocked out.
 On the other hand, if it switchs between different clients too quickly,
 performance may suffer due to too much switching between contexts.
 For example, if a graphics processor needs to be set up with drawing modes
 before drawing, and two different clients are drawing with
-different modes into two different windows, you may 
+different modes into two different windows, you may
 switch your graphics processor modes so often that performance is impacted.
 </para>
 <para>
-See the Strategies document for 
+See the Strategies document for
 heuristics on setting isItTimeToYield.
 </para>
 <para>
@@ -1433,7 +1433,7 @@ The rest are for user input from input devices.
 <section>
   <title>Input</title>
 <para>
-In this document "input" refers to input from the user, 
+In this document "input" refers to input from the user,
 such as mouse, keyboard, and
 bar code readers.
 X input devices are of several types: keyboard, pointing device, and
@@ -1483,8 +1483,8 @@ The main DDX input interface is the following routine:
 	void ProcessInputEvents()
 </programlisting></blockquote>
 You must write this routine to deliver input events from the user.
-DIX calls it when input is pending (see next section), and possibly 
-even when it is not.  
+DIX calls it when input is pending (see next section), and possibly
+even when it is not.
 You should write it to get events from each device and deliver
 the events to DIX.
 To deliver the events to DIX, DDX should call the following
@@ -1497,7 +1497,7 @@ routine:
 		    int count;
 </programlisting></blockquote>
 This is the "input proc" for the device, a DIX procedure.
-DIX will fill in this procedure pointer to one of its own routines by 
+DIX will fill in this procedure pointer to one of its own routines by
 the time ProcessInputEvents() is called the first time.
 Call this input proc routine as many times as needed to
 deliver as many events as should be delivered.
@@ -1525,9 +1525,9 @@ For keyboard and pointing devices the xEvent variant should be keyButtonPointer.
 Fill in the following fields in the xEvent record:
 <itemizedlist>
 
-<listitem><para>type - is one of the following: KeyPress, KeyRelease, ButtonPress, 
+<listitem><para>type - is one of the following: KeyPress, KeyRelease, ButtonPress,
 					ButtonRelease, or MotionNotify</para></listitem>
-<listitem><para>detail - for KeyPress or KeyRelease fields, this should be the 
+<listitem><para>detail - for KeyPress or KeyRelease fields, this should be the
 					key number (not the ASCII code); otherwise unused</para></listitem>
 <listitem><para>time - is the time that the event happened (32-bits, in milliseconds, arbitrary origin)</para></listitem>
 <listitem><para>rootX - is the x coordinate of cursor</para></listitem>
@@ -1537,7 +1537,7 @@ Fill in the following fields in the xEvent record:
 The rest of the fields are filled in by DIX.
 </para>
 <para>
-The time stamp is maintained by your code in the DDX layer, and it is your responsibility to 
+The time stamp is maintained by your code in the DDX layer, and it is your responsibility to
 stamp all events correctly.
 </para>
 <para>
@@ -1546,7 +1546,7 @@ including keyboard events.
 </para>
 <para>
 The pointing device must report all button press and release events.
-In addition, it should report a MotionNotify event every time it gets called 
+In addition, it should report a MotionNotify event every time it gets called
 if the pointing device has moved since the last notify.
 Intermediate pointing device moves are stored in a special GetMotionEvents buffer,
 because most client programs are not interested in them.
@@ -1560,14 +1560,14 @@ one for each supported device.
 <title>Telling DIX When Input is Pending</title>
 <para>
 In the server's dispatch loop, DIX checks to see
-if there is any device input pending whenever WaitForSomething() returns.  
+if there is any device input pending whenever WaitForSomething() returns.
 If the check says that input is pending, DIX calls the
 DDX routine ProcessInputEvents().
 </para>
 <para>
 This check for pending input must be very quick; a procedure call
 is too slow.
-The code that does the check is a hardwired IF 
+The code that does the check is a hardwired IF
 statement in DIX code that simply compares the values
 pointed to by two pointers.
 If the values are different, then it assumes that input is pending and
@@ -1584,8 +1584,8 @@ is used to set these pointers:
 </programlisting></blockquote>
 You should call it sometime during initialization to indicate to DIX the
 correct locations to check.
-You should 
-pay special attention to the size of what they actually point to, 
+You should
+pay special attention to the size of what they actually point to,
 because the locations are assumed to be longs.
 </para>
 <para>
@@ -1594,13 +1594,13 @@ to point to arbitrary values that
 are different.
 In other words, if you forget to call this routine during initialization,
 the worst thing that will happen is that
-ProcessInputEvents will be called when 
+ProcessInputEvents will be called when
 there are no events to process.
 </para>
 <para>
 p1 and p2 might
 point at the head and tail of some shared
-memory queue. 
+memory queue.
 Another use would be to have one point at a constant 0, with the
 other pointing at some mask containing 1s
 for each input device that has
@@ -1627,9 +1627,9 @@ the this time in milliseconds.
 <section>
   <title>Controlling Input Devices</title>
 <para>
-You must write four routines to do various device-specific 
+You must write four routines to do various device-specific
 things with the keyboard and pointing device.
-They can have any name you wish because 
+They can have any name you wish because
 you pass the procedure pointers to DIX routines.
 </para>
 <para>
@@ -1669,7 +1669,7 @@ events be delivered to it through the GetMotionProc routine.
 		pointer ctrl;
 		int class;
 </programlisting></blockquote>
-You need to write this routine to ring the bell on the keyboard. 
+You need to write this routine to ring the bell on the keyboard.
 loud is a number from 0 to 100, with 100 being the loudest.
 Class is either BellFeedbackClass or KbdFeedbackClass (from XI.h).
 </para>
@@ -1693,7 +1693,7 @@ See input.h for the ctrl structures.
   <title>Input Initialization</title>
 <para>
 Input initialization is a bit complicated.
-It all starts with InitInput(), a routine that you write to call 
+It all starts with InitInput(), a routine that you write to call
 AddInputDevice() twice
 (once for pointing device and once for keyboard.)
 You also want to call RegisterKeyboardDevice() and RegisterPointerDevice()
@@ -1714,7 +1714,7 @@ the pointer is the pointer.
 	    int argc;
 	    char **argv;
 </programlisting></blockquote>
-InitInput is a DDX routine you must write to initialize the 
+InitInput is a DDX routine you must write to initialize the
 input subsystem in DDX.
 It must call AddInputDevice() for each device that might generate events.
 In addition, you must register the main keyboard and pointing devices by
@@ -1730,14 +1730,14 @@ calling RegisterPointerDevice() and RegisterKeyboardDevice().
 AddInputDevice is a DIX routine you call to create a device object.
 deviceProc is a DDX routine that is called by DIX to do various operations.
 AutoStart should be TRUE for devices that need to be turned on at
-initialization time with a special call, as opposed to waiting for some 
+initialization time with a special call, as opposed to waiting for some
 client application to
 turn them on.
 This routine returns NULL if sufficient memory cannot be allocated to
 install the device.
 </para>
 <para>
-Note also that except for the main keyboard and pointing device, 
+Note also that except for the main keyboard and pointing device,
 an extension is needed to provide for a client interface to a device.
 </para>
 <para>
@@ -1747,7 +1747,7 @@ an extension is needed to provide for a client interface to a device.
 		DevicePtr device;
 </programlisting></blockquote>
 RegisterPointerDevice is a DIX routine that your DDX code calls that
-makes that device the main pointing device.  
+makes that device the main pointing device.
 This routine is called once upon initialization and cannot be called again.
 </para>
 <para>
@@ -1794,20 +1794,20 @@ it will be one of  these defined constants  (defined in input.h):
 <listitem><para>
 DEVICE_INIT -
 At DEVICE_INIT time, the device should initialize itself by calling
-InitPointerDeviceStruct(), InitKeyboardDeviceStruct(), or a similar 
+InitPointerDeviceStruct(), InitKeyboardDeviceStruct(), or a similar
 routine (see below)
 and "opening" the device if necessary.
 If you return a non-zero (i.e., != Success) value from the DEVICE_INIT
 call, that device will be considered unavailable. If either the main keyboard
-or main pointing device cannot be initialized, the DIX code will refuse 
+or main pointing device cannot be initialized, the DIX code will refuse
 to continue booting up.</para></listitem>
 <listitem><para>
-DEVICE_ON - If the DeviceProc is called with DEVICE_ON, then it is 
+DEVICE_ON - If the DeviceProc is called with DEVICE_ON, then it is
 allowed to start
 putting events into the client stream by calling through the ProcessInputProc
 in the device.</para></listitem>
 <listitem><para>
-DEVICE_OFF - If the DeviceProc is called with DEVICE_OFF, no further 
+DEVICE_OFF - If the DeviceProc is called with DEVICE_OFF, no further
 events from that
 device should be given to the DIX layer.
 The device will appear to be dead to the user.</para></listitem>
@@ -1830,7 +1830,7 @@ be totally closed down.</para></listitem>
 </programlisting></blockquote>
 InitPointerDeviceStruct is a DIX routine you call at DEVICE_INIT time to declare
 some operating routines and data structures for a pointing device.
-map and mapLength are as described in the X Window 
+map and mapLength are as described in the X Window
 System protocol specification.
 ControlProc and GetMotionEvents are DDX routines, see above.
 </para>
@@ -1838,7 +1838,7 @@ ControlProc and GetMotionEvents are DDX routines, see above.
 numMotionEvents is for the motion-buffer-size for the GetMotionEvents
 request.
 A typical length for a motion buffer would be 100 events.
-A server that does not implement this capability should set 
+A server that does not implement this capability should set
 numMotionEvents to zero.
 </para>
 <para>
@@ -1847,17 +1847,17 @@ numMotionEvents to zero.
 	void InitKeyboardDeviceStruct(device, pKeySyms, pModifiers, Bell, ControlProc)
 		DevicePtr device;
 		KeySymsPtr pKeySyms;
-		CARD8 *pModifiers;   
+		CARD8 *pModifiers;
 		BellProcPtr Bell;
 		KbdCtrlProcPtr ControlProc;
 
 </programlisting></blockquote>
-You call this DIX routine when a keyboard device is initialized and 
+You call this DIX routine when a keyboard device is initialized and
 its device procedure is called with
 DEVICE_INIT.
-The formats of the keysyms and modifier maps are defined in 
-Xserver/include/input.h. 
-They describe the layout of keys on the keyboards, and the glyphs 
+The formats of the keysyms and modifier maps are defined in
+Xserver/include/input.h.
+They describe the layout of keys on the keyboards, and the glyphs
 associated with them.  ( See the next section for information on
 setting up the modifier map and the keysym map.)
 ControlProc and Bell are DDX routines, see above.
@@ -1879,8 +1879,8 @@ The keycode mapping information that you set up consists of the following:
 <listitem><para>
 A minimum and maximum keycode number</para></listitem>
 <listitem><para>
-An array of sets of keysyms for each key, that is of length 
-maxkeycode - minkeycode + 1.  
+An array of sets of keysyms for each key, that is of length
+maxkeycode - minkeycode + 1.
 Each element of this array is a list of codes for symbols that are on that key.
 There is no limit to the number of symbols that can be on a key.</para></listitem>
 </itemizedlist>
@@ -1892,7 +1892,7 @@ The X protocol defines standard names to indicate the symbol(s)
 printed on each keycap. (See X11/keysym.h)
 </para>
 <para>
-Legal modifier keys must generate both up and down transitions.  When 
+Legal modifier keys must generate both up and down transitions.  When
 a client tries to change a modifier key (for instance, to make "A" the
 "Control" key), DIX calls the following routine, which should retuurn
 TRUE if the key can be used as a modifier on the given device:
@@ -1909,12 +1909,12 @@ TRUE if the key can be used as a modifier on the given device:
 <title>Screens</title>
 <para>
 Different computer graphics
-displays have different capabilities.  
+displays have different capabilities.
 Some are simple monochrome
 frame buffers that are just lying
 there in memory, waiting to be written into.
 Others are color displays with many bits per pixel using some color lookup table.
-Still others have high-speed graphic processors that prefer to do all of the work 
+Still others have high-speed graphic processors that prefer to do all of the work
 themselves,
 including maintaining their own high-level, graphic data structures.
 </para>
@@ -1925,14 +1925,14 @@ The only requirement on screens is that you be able to both read
 and write locations in the frame buffer.
 All screens must have a depth of 32 or less (unless you use
 an X extension to allow a greater depth).
-All screens must fit into one of the classes listed in the section 
+All screens must fit into one of the classes listed in the section
 in this document on Visuals and Depths.
 </para>
 <para>
 X uses the pixel as its fundamental unit of distance on the screen.
 Therefore, most programs will measure everything in pixels.</para>
 <para>
-The sample server assumes square pixels.  
+The sample server assumes square pixels.
 Serious WYSIWYG (what you see is what you get) applications for
 publishing and drawing programs will adjust for
 different screen resolutions automatically.
@@ -1945,9 +1945,9 @@ code for the sample server but quite a bit in the client applications).</para>
 <para>
 X supports multiple screens that are connected to the same
 server.  Therefore, all the per-screen information is bundled into one data
-structure of attributes and procedures, which is the ScreenRec (see 
-Xserver/include/scrnintstr.h).  
-The procedure entry points in a ScreenRec operate on 
+structure of attributes and procedures, which is the ScreenRec (see
+Xserver/include/scrnintstr.h).
+The procedure entry points in a ScreenRec operate on
 regions, colormaps, cursors, and fonts, because these resources
 can differ in format from one screen to another.</para>
 <para>
@@ -1975,7 +1975,7 @@ All screens in a given server must agree on a set of pixmap image
 formats (PixmapFormat) to support (depth, number of bits per pixel,
 etc.).</para>
 <para>
-There is no color interpretation of bits in the pixmap.  Pixmaps 
+There is no color interpretation of bits in the pixmap.  Pixmaps
 do not contain pixel values.  The interpretation is made only when
 the bits are transferred onto the screen.</para>
 <para>
@@ -2136,7 +2136,7 @@ allocation overhead for the region structure itself.
 	macro: Bool REGION_COPY(pScreen, dstrgn, srcrgn)
 
 </programlisting></blockquote>
-RegionCopy copies the description of one region, srcrgn, to another 
+RegionCopy copies the description of one region, srcrgn, to another
 already-created region,
 dstrgn; returning TRUE if the copy succeeded, and FALSE otherwise.</para>
 <para>
@@ -2225,7 +2225,7 @@ one rectangle and reallocates it to a size of one rectangle, if applicable.</par
 	macro: REGION_TRANSLATE(pScreen, pRegion, x, y)
 
 </programlisting></blockquote>
-TranslateRegion simply moves a region +x in the x direction and +y in the y 
+TranslateRegion simply moves a region +x in the x direction and +y in the y
 direction.</para>
 <para>
 <blockquote><programlisting>
@@ -2329,7 +2329,7 @@ regions overlap; FALSE otherwise.</para>
 	RegionPtr pScreen->BitmapToRegion (pPixmap)
 		PixmapPtr pPixmap;
 
-	macro: RegionPtr BITMAP_TO_REGION(pScreen, pPixmap) 
+	macro: RegionPtr BITMAP_TO_REGION(pScreen, pPixmap)
 
 </programlisting></blockquote>
 Given a depth-1 pixmap, this routine must create a valid region which
@@ -2464,7 +2464,7 @@ RecolorCursor notifies DDX that the colors in pCurs have changed and
 indicates whether this is the cursor currently being displayed.  If it
 is, the cursor hardware state may have to be updated.  Whether
 displayed or not, state created at RealizeCursor time may have to be
-updated.  A generic version, miRecolorCursor, may be used that 
+updated.  A generic version, miRecolorCursor, may be used that
 does an unrealize, a realize, and possibly a display (in micursor.c);
 however this constrains UnrealizeCursor and RealizeCursor to always return
 TRUE as no error indication is returned here.</para>
@@ -2590,49 +2590,49 @@ The class of a display describes how this translation takes place.
 There are three ways to do the translation.
 <itemizedlist>
 <listitem><para>
-Pseudo - The pixel value, as a whole, is looked up 
+Pseudo - The pixel value, as a whole, is looked up
 in a table of length map_entries to
 determine the color to display.</para></listitem>
 <listitem><para>
-True - The 
-pixel value is broken up into red, green, and blue fields, each of which 
-are looked up in separate red, green, and blue lookup tables, 
+True - The
+pixel value is broken up into red, green, and blue fields, each of which
+are looked up in separate red, green, and blue lookup tables,
 each of length map_entries.</para></listitem>
 <listitem><para>
-Gray - The pixel value is looked up in a table of length map_entries to 
+Gray - The pixel value is looked up in a table of length map_entries to
 determine a gray level to display.</para></listitem>
 </itemizedlist>
 </para>
 <para>
-In addition, the lookup table can be static (resulting colors are fixed for each 
+In addition, the lookup table can be static (resulting colors are fixed for each
 pixel value)
 or dynamic (lookup entries are under control of the client program).
 This leads to a total of six classes:
 <itemizedlist>
 <listitem><para>
-Static Gray - The pixel value (of however many bits) determines directly the 
+Static Gray - The pixel value (of however many bits) determines directly the
 level of gray
 that the pixel assumes.</para></listitem>
 <listitem><para>
-Gray Scale - The pixel value is fed through a lookup table to arrive at the level 
+Gray Scale - The pixel value is fed through a lookup table to arrive at the level
 of gray to display
 for the given pixel.</para></listitem>
 <listitem><para>
-Static Color - The pixel value is fed through a fixed lookup table that yields the 
+Static Color - The pixel value is fed through a fixed lookup table that yields the
 color to display
 for that pixel.</para></listitem>
 <listitem><para>
-PseudoColor - The whole pixel value is fed through a programmable lookup 
+PseudoColor - The whole pixel value is fed through a programmable lookup
 table that has one
 color (including red, green, and blue intensities) for each possible pixel value,
 and that color is displayed.</para></listitem>
 <listitem><para>
 True Color - Each pixel value consists of one or more bits
-that directly determine each primary color intensity after being fed through 
+that directly determine each primary color intensity after being fed through
 a fixed table.</para></listitem>
 <listitem><para>
 Direct Color - Each pixel value consists of one or more bits for each primary color.
-Each primary color value is individually looked up in a table for that primary 
+Each primary color value is individually looked up in a table for that primary
 color, yielding
 an intensity for that primary color.
 For each pixel, the red value is looked up in the
@@ -2649,7 +2649,7 @@ A simple monochrome 1 bit per pixel display is Static Gray.</para></listitem>
 A display that has 2 bits per pixel for a choice
 between the colors of black, white, green and violet is Static Color.</para></listitem>
 <listitem><para>
-A display that has three bits per pixel, where 
+A display that has three bits per pixel, where
 each bit turns on or off one of the red, green or
 blue guns, is in the True Color class.</para></listitem>
 <listitem><para>
@@ -2666,16 +2666,16 @@ This is a pseudocolor display.
 The client application gets to fill the lookup table in this class of display.</para>
 <para>
 Imagine the same hardware from the last example.
-Your server software allows the user, on the 
+Your server software allows the user, on the
 command line that starts up the server
-program, 
+program,
 to fill the lookup table to his liking once and for all.
 From then on, the server software would not change the lookup table
 until it exits.
-For instance, the default might be a lookup table with a reasonable sample of 
+For instance, the default might be a lookup table with a reasonable sample of
 colors from throughout the color space.
 But the user could specify that the table be filled with 256 steps of gray scale
-because he knew ahead of time he would be manipulating a lot of black-and-white 
+because he knew ahead of time he would be manipulating a lot of black-and-white
 scanned photographs
 and not very many color things.
 Clients would be presented with this unchangeable lookup table.
@@ -2683,9 +2683,9 @@ Although the hardware qualifies as a PseudoColor display,
 the facade presented to the X client is that this is a Static Color display.</para>
 <para>
 You have to decide what kind of display you have or want
-to pretend you have.  
+to pretend you have.
 When you initialize the screen(s), this class value must be set in the
-VisualRec data structure along with other display characteristics like the 
+VisualRec data structure along with other display characteristics like the
 depth and other numbers.</para>
 <para>
 The allowable DepthRec's and VisualRec's are pointed to by fields in the ScreenRec.
@@ -2704,11 +2704,11 @@ At any given time, the most recently installed
 colormap(s) will be in use in the server
 so that its (their) windows' colors will be guaranteed to be correct.
 Other windows may be off-color.
-Although this may seem to be chaotic, in practice most clients 
+Although this may seem to be chaotic, in practice most clients
 use the default colormap for the screen.</para>
 <para>
 The default colormap for a screen is initialized when the screen is initialized.
-It always remains in existence and is not owned by any regular client.  It 
+It always remains in existence and is not owned by any regular client.  It
 is owned by client 0 (the server itself).
 Many clients will simply use this default colormap for their drawing.
 Depending upon the class of the screen, the entries in this colormap may
@@ -2756,7 +2756,7 @@ It is the DDX layer's chance to free any data it added to the colormap.</para>
 		ColormapPtr pColormap;
 
 </programlisting></blockquote>
-InstallColormap should 
+InstallColormap should
 fill a lookup table on the screen with which the colormap is associated with
 the colors in pColormap.
 If there is only one hardware lookup table for the screen, then all colors on
@@ -2774,16 +2774,16 @@ See the note, below, about uninstalling maps.</para>
 		ColormapPtr pColormap;
 
 </programlisting></blockquote>
-UninstallColormap should 
-remove pColormap from screen pColormap->pScreen.  
+UninstallColormap should
+remove pColormap from screen pColormap->pScreen.
 Some other map, such as the default map if possible,
 should be installed in place of pColormap if applicable.
 If
 pColormap is the default map, do nothing.
-If any client has requested ColormapNotify events, the DDX layer must notify the client.  
-(The routine WalkTree() is 
-be used to find such windows.  The DIX routines TellNoMap(), 
-TellNewMap()  and TellGainedMap() are provided to be used as 
+If any client has requested ColormapNotify events, the DDX layer must notify the client.
+(The routine WalkTree() is
+be used to find such windows.  The DIX routines TellNoMap(),
+TellNewMap()  and TellGainedMap() are provided to be used as
 the procedure parameter to WalkTree.  These procedures are in
 Xserver/dix/colormap.c.)</para>
 <para>
@@ -2813,12 +2813,12 @@ The number of entries to change are ndef, and pdefs points to the information
 describing what to change.
 Note that partial changes of entries in the colormap are allowed.
 Only the colors
-indicated in the flags field of each xColorItem need to be changed.  
+indicated in the flags field of each xColorItem need to be changed.
 However, all three color fields will be sent with the proper value for the
 benefit of screens that may not be able to set part of a colormap value.
 If the screen is a static class, this routine does nothing.
-The structure of colormap entries is nontrivial; see colormapst.h 
-and the definition of xColorItem in Xproto.h for 
+The structure of colormap entries is nontrivial; see colormapst.h
+and the definition of xColorItem in Xproto.h for
 more details.</para>
 <para>
 <blockquote><programlisting>
@@ -2855,7 +2855,7 @@ will not look white on an 8-bit display).</para>
 When a client requests a new colormap and when the server creates the default
 colormap, the procedure CreateColormap in the DIX layer is invoked.
 That procedure allocates memory for the colormap and related storage such as
-the lists of which client owns which pixels.  
+the lists of which client owns which pixels.
 It then sets a bit, BeingCreated, in the flags field of the ColormapRec
 and calls the DDX layer's CreateColormap routine.
 This is your chance to initialize the colormap.
@@ -2867,7 +2867,7 @@ at the IsDefault bit in the flags field, you should allocate BlackPixel
 and WhitePixel to match the values you set in the pScreen structure.
 (Of course, you picked those values to begin with.)</para>
 <para>
-You can also wait and use AllocColor() to allocate blackPixel 
+You can also wait and use AllocColor() to allocate blackPixel
 and whitePixel after the default colormap has been created.
 If the default colormap is static and you initialized it in
 pScreen->CreateColormap, then use can use AllocColor afterwards
@@ -2968,7 +2968,7 @@ font compiler is found in fonts/tools/bdftopcf.</para>
 <para>
 Each screen configured into the server
 has an opportunity at font-load time
-to "realize" a font into some internal format if necessary. 
+to "realize" a font into some internal format if necessary.
 This happens every time the font is loaded into memory.</para>
 <para>
 A font (FontRec in Xserver/include/dixfontstr.h) is
@@ -2989,9 +2989,9 @@ in the devPrivate storage.</para>
 		FontPtr pFont;
 
 </programlisting></blockquote>
-RealizeFont and UnrealizeFont should calculate and allocate these extra data structures and 
+RealizeFont and UnrealizeFont should calculate and allocate these extra data structures and
 dispose of them when no longer needed.
-These are called in response to OpenFont and CloseFont requests from 
+These are called in response to OpenFont and CloseFont requests from
 the client.
 The sample server implementation is in fbscreen.c (which does very little).</para>
 </section>
@@ -2999,7 +2999,7 @@ The sample server implementation is in fbscreen.c (which does very little).</par
 <section>
   <title>Other Screen Routines</title>
 <para>
-You must supply several other screen-specific routines for 
+You must supply several other screen-specific routines for
 your X server implementation.
 Some of these are described in other sections:
 <itemizedlist>
@@ -3008,7 +3008,7 @@ GetImage() is described in the Drawing Primitives section.</para></listitem>
 <listitem><para>
 GetSpans() is described in the Pixblit routine section.</para></listitem>
 <listitem><para>
-Several window and pixmap manipulation procedures are 
+Several window and pixmap manipulation procedures are
 described in the Window section under Drawables.</para></listitem>
 <listitem><para>
 The CreateGC() routine is described under Graphics Contexts.</para></listitem>
@@ -3027,7 +3027,7 @@ QueryBestSize() returns the best sizes for cursors, tiles, and stipples
 in response to client requests.
 kind is one of the defined constants CursorShape, TileShape, or StippleShape
 (defined in X.h).
-For CursorShape, return the maximum width and 
+For CursorShape, return the maximum width and
 height for cursors that you can handle.
 For TileShape and StippleShape, start with the suggested values in pWidth
 and pHeight and modify them in place to be optimal values that are
@@ -3079,7 +3079,7 @@ server initialization/reset after all modules have had a chance to
 request private space on all structures that support them (see
 <xref linkend="wrappers_and_privates"/> below).  You may create resources
 in this function instead of in the
-screen init function passed to AddScreen in order to guarantee that 
+screen init function passed to AddScreen in order to guarantee that
 all pre-allocated space requests have been registered first.  With the
 new devPrivates mechanism, this is not strictly necessary, however.
 This routine returns TRUE if successful.</para>
@@ -3161,7 +3161,7 @@ A bitmap is a pixmap that is one bit deep.</para>
 
 </programlisting></blockquote>
 This ScreenRec procedure must create a pixmap of the size
-requested.  
+requested.
 It must allocate a PixmapRec and fill in all of the fields.
 The reference count field must be set to 1.
 If width or height are zero, no space should be allocated
@@ -3178,15 +3178,15 @@ See Xserver/fb/fbpixmap.c for the sample server implementation.</para>
 
 </programlisting></blockquote>
 This ScreenRec procedure must "destroy" a pixmap.
-It should decrement the reference count and, if zero, it 
+It should decrement the reference count and, if zero, it
 must deallocate the PixmapRec and all attached devPrivate blocks.
-If successful, it returns TRUE. 
+If successful, it returns TRUE.
 See Xserver/fb/fbpixmap.c for the sample server implementation.</para>
 <para>
 <blockquote><programlisting>
 
 	Bool
-	pScreen->ModifyPixmapHeader(pPixmap, width, height, depth, bitsPerPixel, devKind, pPixData) 
+	pScreen->ModifyPixmapHeader(pPixmap, width, height, depth, bitsPerPixel, devKind, pPixData)
 		PixmapPtr   pPixmap;
 		int	    width;
 		int	    height;
@@ -3252,7 +3252,7 @@ be drawn.  The contents of the window is drawn by the client through
 requests to the server.</para>
 <para>
 Window painting is orchestrated through an expose event system.
-When a region is exposed, 
+When a region is exposed,
 DIX generates an expose event, telling the client to repaint the window and
 passing the region that is the minimal area needed to be repainted.</para>
 <para>
@@ -3277,7 +3277,7 @@ all graphics drawn to hidden areas must be intercepted and redirected
 to the off-screen window sections.
 Not only can this be complicated for the server programmer,
 but it can also impact window painting performance.
-The backing store implementation can choose, at any time, to 
+The backing store implementation can choose, at any time, to
 forget pieces of backing that are written into, relying instead upon
 expose events to repaint for simplicity.</para>
 <para>
@@ -3328,7 +3328,7 @@ that overlap this window.  To get the list with the
 children included (subwindow-mode is IncludeInferiors),
 the routine NotClippedByChildren(pWin) returns the unclipped region.</para></listitem>
 <listitem><para>
-borderClip is the region used by CopyWindow and 
+borderClip is the region used by CopyWindow and
 includes the area of the window, its children, and the border, but with the
 overlapping areas of sibling children removed.</para></listitem>
 </itemizedlist>
@@ -3457,9 +3457,9 @@ The WindowExposures() routine
 paints the border and generates exposure events for the window.
 pRegion is an unoccluded region of the window, and pBSRegion is an
 occluded region that has backing store.
-Since exposure events include a rectangle describing what was exposed, 
+Since exposure events include a rectangle describing what was exposed,
 this routine may have to send back a series of exposure events, one for
-each rectangle of the region.  
+each rectangle of the region.
 The count field in the expose event is a hint to the
 client as to the number of
 regions that are after this one.
@@ -3483,7 +3483,7 @@ values.  dx,dy are the distance that the window has been moved (if at all).</par
 <para>
 In addition to the procedures listed above, there are two routines which
 manipulate the actual window image directly.
-In the sample server, mi implementations will work for 
+In the sample server, mi implementations will work for
 most purposes and fb routines speed up situations, such
 as solid backgrounds/borders or tiles that are 8, 16 or 32 pixels square.</para>
 <para>
@@ -3508,7 +3508,7 @@ and all of its child windows.</para>
 <para>
 If generateExposures is false, the client is trying to simply erase part
 of the window to the background fill style.
-ClearToBackground should write the background color or tile to the 
+ClearToBackground should write the background color or tile to the
 rectangle in question (probably using PaintWindowBackground).
 If w or h is zero, it clears all the way to the right or lower edge of the window.</para>
 <para>
@@ -3585,7 +3585,7 @@ single-layered framebuffer case, pLayerWin == pWin.</para>
 	WindowPtr firstChild;
 
 </programlisting></blockquote>
-The dix functions ChangeSaveUnder and CheckSaveUnder have moved to ddx and 
+The dix functions ChangeSaveUnder and CheckSaveUnder have moved to ddx and
 are accessed via this screen function.  pLayerWin should be the window
 returned in the ppLayerWin parameter of MarkOverlappedWindows.  The function
 may turn on backing store for windows that might be covered, and may partially
@@ -3614,8 +3614,8 @@ backing store that was started by ChangeSaveUnder.</para>
 
 </programlisting></blockquote>
 The formerly dix function MoveWindow has moved to ddx and is accessed via
-this screen function.  The new position of the window is given by 
-x,y.  kind is VTMove if the window is only moving, or VTOther if 
+this screen function.  The new position of the window is given by
+x,y.  kind is VTMove if the window is only moving, or VTOther if
 the border is also changing.</para>
 <para>
 <blockquote><programlisting>
@@ -3739,7 +3739,7 @@ the hardware draw characters, or a variable-width procedure that carefully
 lays out glyphs by hand in software, depending upon the new font that is
 selected.</para>
 <para>
-A definition of these structures can be found in the file 
+A definition of these structures can be found in the file
 Xserver/include/gcstruct.h.</para>
 <para>
 Also included in each GC is support for dynamic devPrivates, which the
@@ -3748,7 +3748,7 @@ DDX can use for any purpose (see <xref linkend="wrappers_and_privates"/> below).
 The DIX routines available for manipulating GCs are
 CreateGC, ChangeGC, CopyGC, SetClipRects, SetDashes, and FreeGC.
 <blockquote><programlisting>
-	
+
 	GCPtr CreateGC(pDrawable, mask, pval, pStatus)
 	    DrawablePtr pDrawable;
 	    BITS32 mask;
@@ -3785,7 +3785,7 @@ CreateGC, ChangeGC, CopyGC, SetClipRects, SetDashes, and FreeGC.
 </programlisting></blockquote>
 </para>
 <para>
-As a convenience, each Screen structure contains an array of 
+As a convenience, each Screen structure contains an array of
 GCs that are preallocated, one at each depth the screen supports.
 These are particularly useful in the mi code.  Two DIX routines
 must be used to get these GCs:
@@ -3921,7 +3921,7 @@ Some kinds of extension software may cause this routine to be called
 more than originally intended; you should not rely on algorithms that
 will break under such circumstances.</para>
 <para>
-See the Strategies document for more information on creatively using 
+See the Strategies document for more information on creatively using
 this routine.</para>
 <para>
 <blockquote><programlisting>
@@ -4015,7 +4015,7 @@ by this routine after destroying the region, so that other software
 This routine makes a copy of the clipMask and clipType from pgcSrc
 into pgcDst.  It is responsible for destroying any previous clipMask
 in pgcDst.  The clip mask in the source can be the same as the
-clip mask in the dst (clients do the strangest things), so care must 
+clip mask in the dst (clients do the strangest things), so care must
 be taken when destroying things.  This call is required because dix
 does not know how to copy the clip mask from pgcSrc.</para>
 </section>
@@ -4027,7 +4027,7 @@ The X protocol (rules for the byte stream that goes between client and server)
 does all graphics using primitive
 operations, which are called Drawing Primitives.
 These include line drawing, area filling, arcs, and text drawing.
-Your implementation must supply 16 routines 
+Your implementation must supply 16 routines
 to perform these on your hardware.
 (The number 16 is arbitrary.)</para>
 <para>
@@ -4067,8 +4067,8 @@ for more details.</para>
 <para>
 ALL of these routines MUST CLIP to the
 appropriate regions in the drawable.
-Since there are many regions to clip to simultaneously, 
-your ValidateGC routine should combine these into a unified 
+Since there are many regions to clip to simultaneously,
+your ValidateGC routine should combine these into a unified
 clip region to which your drawing routines can quickly refer.
 This is exactly what the fb routines supplied with the sample server
 do.
@@ -4110,7 +4110,7 @@ algorithm, because client software assumes that every jag on every
 line at an angle will come at the same place.
 Two lines that should have
 one pixel in the space between them
-(because of their distance apart and their widths) should have such a one-pixel line 
+(because of their distance apart and their widths) should have such a one-pixel line
 of space between them if drawn, regardless of angle.</para>
 <para>
 The solid area fill routines (FillPolygon, PolyFillRect, PolyFillArc)
@@ -4192,7 +4192,7 @@ different depths, except for copying bitmaps to pixmaps and applying
 foreground and background colors to it.  All other conditions of
 CopyArea apply to CopyPlane too.</para>
 <para>
-An example implementation is fbCopyPlane() in 
+An example implementation is fbCopyPlane() in
 Xserver/fb/fbcopy.c.</para>
 <para>
 <blockquote><programlisting>
@@ -4211,7 +4211,7 @@ mode is one of the defined constants Origin (absolute coordinates) or Previous
 (each coordinate is relative to the last).
 Note that this does not use the background color or any tiles or stipples.</para>
 <para>
-Example implementations are fbPolyPoint() in Xserver/fb/fbpoint.c and 
+Example implementations are fbPolyPoint() in Xserver/fb/fbpoint.c and
 miPolyPoint in Xserver/mi/mipolypnt.c.</para>
 <para>
 <blockquote><programlisting>
@@ -4225,7 +4225,7 @@ miPolyPoint in Xserver/mi/mipolypnt.c.</para>
 
 </programlisting></blockquote>
 Similar to PolyPoint, Polylines draws lines between the locations given in the array.
-Zero-width lines are NOT meant to be really zero width; this is the client's way of 
+Zero-width lines are NOT meant to be really zero width; this is the client's way of
 telling you that you can maximally optimize line drawing with little regard to
 the end caps and joins.
 mode is one of the defined constants Previous or Origin, depending upon
@@ -4312,7 +4312,7 @@ An example implementation is miFillPolygon() in Xserver/mi/mipoly.c.</para>
 </programlisting></blockquote>
 PolyFillRect fills multiple rectangles.</para>
 <para>
-Example implementations are fbPolyFillRect() in Xserver/fb/fbfillrect.c and 
+Example implementations are fbPolyFillRect() in Xserver/fb/fbfillrect.c and
 miPolyFillRect() in Xserver/mi/mifillrct.c.</para>
 <para>
 <blockquote><programlisting>
@@ -4404,7 +4404,7 @@ An example implementation is miImageText8() in Xserver/mi/mipolytext.c.</para>
 
 </programlisting></blockquote>
 PolyText8 works like ImageText8, except it draws with
-the current fill style for special effects such as 
+the current fill style for special effects such as
 shaded text.
 See the X protocol specification for more details.</para>
 <para>
@@ -4428,7 +4428,7 @@ An example implementation is miPolyText8() in Xserver/mi/mipolytext.c.</para>
 
 </programlisting></blockquote>
 These two routines are the same as the "8" versions,
-except that they are for 16-bit character codes (useful 
+except that they are for 16-bit character codes (useful
 for oriental writing systems).</para>
 <para>
 The primary difference is in the way the character information is
@@ -4444,7 +4444,7 @@ of the character code constitute the row and column in a square matrix
 of CharInfo structs.  Each font has row and column minimum and maximum
 values; the CharInfo structures form a two-dimensional matrix.</para>
 <para>
-Example implementations are miPolyText16() and 
+Example implementations are miPolyText16() and
 miImageText16() in Xserver/mi/mipolytext.c.</para>
 <para>
 See the X protocol specification for more details on these graphic operations.</para>
@@ -4462,7 +4462,7 @@ The Drawing Primitive functions must be defined for your server.
 One possible way to do this is to use the mi routines from the sample server.
 If you choose to use the mi routines (even part of them!) you must implement
 these Pixblit routines.
-These routines read and write pixel values 
+These routines read and write pixel values
 and deal directly with the image data.</para>
 <para>
 The Pixblit routines for the sample server are part of the "fb"
@@ -4703,7 +4703,7 @@ for WYSIWYG word processing and similar systems.</para>
 <para>
 Both of these routines must clip themselves to the overall clipping region.</para>
 <para>
-Example implementations in mi are miPolyGlyphBlt() and 
+Example implementations in mi are miPolyGlyphBlt() and
 miImageGlyphBlt() in Xserver/mi/miglblt.c.</para>
 </section>
 <section>
@@ -4825,7 +4825,7 @@ argument is the value to store.</para>
 <para>
 If private data with the given key is already associated with the object, <function>dixSetPrivate</function> will
 overwrite the old value with the new one.  Otherwise, new space will be allocated to hold the pointer value.
-The function returns <literal>TRUE</literal> unless memory allocation fails, but note that since memory allocation only 
+The function returns <literal>TRUE</literal> unless memory allocation fails, but note that since memory allocation only
 occurs on the first reference to the private data, all subsequent calls are guaranteed to succeed.</para>
 
 <para>
@@ -4947,7 +4947,7 @@ pointers, and op wrappers may change the GC op pointers but not the funcs.</para
 <para>
 Thus, the rule for GC wrappings is: wrap the funcs from CreateGC and, in each
 func wrapper, unwrap the ops and funcs, call down, and re-wrap.  In each op
-wrapper, unwrap the ops, call down, and rewrap afterwards.  Note that in 
+wrapper, unwrap the ops, call down, and rewrap afterwards.  Note that in
 re-wrapping you must save out the pointer you're replacing again.  This way the
 chain will be maintained when wrappers adjust the funcs/ops tables they use.</para>
 </section>
@@ -4980,7 +4980,7 @@ Neither client nor closure are actually used inside the work queue routines.</pa
 <para>
 This is a summary of the routines discussed in this document.
 The procedure names are in alphabetical order.
-The Struct is the structure it is attached to; if blank, this 
+The Struct is the structure it is attached to; if blank, this
 procedure is not attached to a struct and must be named as shown.
 The sample server provides implementations in the following
 categories.  Notice that many of the graphics routines have both
diff --git a/sgml/fonts/fonts.sgml b/sgml/fonts/fonts.sgml
index 852d6e9..6b6cf2e 100644
--- a/sgml/fonts/fonts.sgml
+++ b/sgml/fonts/fonts.sgml
@@ -19,7 +19,7 @@
 
 <Para>
 This document describes the support for fonts in X11R.
-<XRef LinkEnd="sec-installing"> is aimed at the 
+<XRef LinkEnd="sec-installing"> is aimed at the
 casual user wishing to install fonts in X11R the rest of the
 document describes the font support in more detail.
 </Para>
@@ -294,7 +294,7 @@ BDF format and the somewhat more efficient binary PCF format.
 Bitmap fonts are normally distributed in the BDF format.  Before
 installing such fonts, it is desirable (but not absolutely necessary)
 to convert the font files to the PCF format.  This is done by using the
-command `<Literal remap="tt">bdftopcf</Literal>', <Emphasis remap="it">e.g.</Emphasis> 
+command `<Literal remap="tt">bdftopcf</Literal>', <Emphasis remap="it">e.g.</Emphasis>
 
 <Screen>
 $ bdftopcf courier12.bdf
@@ -525,7 +525,7 @@ $ xset fp+ /usr/local/fonts/bitmap
 <Para>
 Conversely, an element may be removed from the front of the font path
 with `<Literal remap="tt">xset -fp</Literal>', and removed from the end with `<Literal remap="tt">xset fp-</Literal>'.
-You may reset the font path to its default value with 
+You may reset the font path to its default value with
 `<Literal remap="tt">xset fp default</Literal>'.
 </Para>
 
@@ -729,19 +729,19 @@ Unicode text.  Together, the fonts contain approximately 7500 glyphs.
 The main ClearlyU font has the XLFD
 
 <Screen>
--mutt-clearlyu-medium-r-normal--17-120-100-100-p-101-iso10646-1 
+-mutt-clearlyu-medium-r-normal--17-120-100-100-p-101-iso10646-1
 </Screen>
 
 and resides in the font file
 
 <Screen>
-/usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz 
+/usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz
 </Screen>
 
 Additional ClearlyU fonts include
 
 <Screen>
--mutt-clearlyu alternate glyphs-medium-r-normal--17-120-100-100-p-91-iso10646-1 
+-mutt-clearlyu alternate glyphs-medium-r-normal--17-120-100-100-p-91-iso10646-1
 -mutt-clearlyu pua-medium-r-normal--17-120-100-100-p-111-iso10646-1
 -mutt-clearlyu arabic extra-medium-r-normal--17-120-100-100-p-103-fontspecific-0
 -mutt-clearlyu ligature-medium-r-normal--17-120-100-100-p-141-fontspecific-0
@@ -879,15 +879,15 @@ Standard encoding.
 </Para>
 
 <Para>
-The Luxi fonts are original designs by Kris Holmes and Charles 
-Bigelow.  Luxi fonts include seriffed, sans serif, and monospaced 
-styles, in roman and oblique, and normal and bold weights. The fonts 
-share stem weight, x-height, capital height, ascent and descent, for 
+The Luxi fonts are original designs by Kris Holmes and Charles
+Bigelow.  Luxi fonts include seriffed, sans serif, and monospaced
+styles, in roman and oblique, and normal and bold weights. The fonts
+share stem weight, x-height, capital height, ascent and descent, for
 graphical harmony.
 </Para>
 
 <Para>
-The character width metrics of Luxi roman and bold fonts match those 
+The character width metrics of Luxi roman and bold fonts match those
 of core fonts bundled with popular operating and window systems.
 </Para>
 
@@ -900,13 +900,13 @@ URL="LICENSE.html"
 </Para>
 
 <Para>
-Charles Bigelow and Kris Holmes from Bigelow and Holmes Inc. 
+Charles Bigelow and Kris Holmes from Bigelow and Holmes Inc.
 developed the Luxi typeface designs in Ikarus digital format.
 </Para>
 
 <Para>
-URW++ Design and Development GmbH converted the Ikarus format fonts 
-to TrueType and Type1 font programs and implemented the grid-fitting 
+URW++ Design and Development GmbH converted the Ikarus format fonts
+to TrueType and Type1 font programs and implemented the grid-fitting
 "hints" and kerning tables in the Luxi fonts.
 </Para>
 
@@ -914,10 +914,10 @@ to TrueType and Type1 font programs and implemented the grid-fitting
 For more information, please contact
 <EMAIL
 >design@bigelowandholmes.com</EMAIL
-> or 
+> or
 <EMAIL
 >info@urwpp.de</EMAIL
->, or consult 
+>, or consult
 <ULink
 URL="http://www.urwpp.de"
 >the URW++ web site</ULink
@@ -954,7 +954,7 @@ XLFD in `<Literal remap="tt">fonts.dir</Literal>'.  For example, a `<Literal rem
 contain entries for the Type&nbsp;1 Courier font such as
 
 <Screen>
-cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 
+cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
 cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2
 </Screen>
 
@@ -1555,7 +1555,7 @@ remap them to their proper names.
 
 <Para>
 This is done by writing a `<Literal remap="tt">fonts.alias</Literal>' file. The format of this file
-is very simple: it consists of a series of lines each mapping an alias 
+is very simple: it consists of a series of lines each mapping an alias
 name to a font name.  A `<Literal remap="tt">fonts.alias</Literal>' file might look as follows:
 
 <Screen>
@@ -1994,7 +1994,7 @@ Font Description document, by Jim Flowers, which is provided in the file
 The <ULink
 URL="http://www.faqs.org/faqs/by-newsgroup/comp/comp.fonts.html"
 >comp.fonts FAQ</ULink
->, 
+>,
 which is unfortunately no longer being maintained, contains a wealth
 of information about digital fonts.
 </Para>
@@ -2008,7 +2008,7 @@ URL="http://www.fontconfig.org"
 </Para>
 
 <Para>
-The 
+The
 <ULink
 URL="http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/"
 >xfsft home page</ULink
@@ -2018,7 +2018,7 @@ however still find some of the information that it contains useful.
 <ULink
 URL="http://www.joerg-pommnitz.de/TrueType/xfsft.html"
 >Joerg Pommnitz' xfsft page</ULink
-> 
+>
 is the canonical source for the `<Literal remap="tt">ttmkfdir</Literal>' utility, which is the
 ancestor of <Literal remap="tt">mkfontscale</Literal>.
 </Para>
@@ -2040,11 +2040,11 @@ URL="http://x-tt.sourceforge.jp/"
 </Para>
 
 <Para>
-A number of East-Asian CIDFonts are available from 
+A number of East-Asian CIDFonts are available from
 <ULink
 URL="ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/"
 >O'Reilly's FTP site</ULink
->. 
+>.
 </Para>
 
 <Para>
diff --git a/sgml/graphics/dps.sgml b/sgml/graphics/dps.sgml
index 48745e9..b005d8c 100644
--- a/sgml/graphics/dps.sgml
+++ b/sgml/graphics/dps.sgml
@@ -341,7 +341,7 @@ URL="http://dps.sourceforge.net"
 </Para>
 
 <Para>
-&lsqb;PLRM2] PostScript language reference manual. Adobe Systems, 2nd ed. Addison-Wesley, 1990. ISBN 0-201-18127-4. 
+&lsqb;PLRM2] PostScript language reference manual. Adobe Systems, 2nd ed. Addison-Wesley, 1990. ISBN 0-201-18127-4.
 </Para>
 
 <Para>
diff --git a/sgml/input/XKB-Config.sgml b/sgml/input/XKB-Config.sgml
index 06d4cdd..ca7e271 100644
--- a/sgml/input/XKB-Config.sgml
+++ b/sgml/input/XKB-Config.sgml
@@ -43,8 +43,8 @@ need to touch any of the xkb configuration files.
 
 <Para>
 The easiest and the most natural way to specify a keyboard mapping is to use
-the <Literal remap="tt">rules</Literal> component. As its name suggests it describes a number of 
-general rules to combine all bits and pieces into a valid and useful keyboard 
+the <Literal remap="tt">rules</Literal> component. As its name suggests it describes a number of
+general rules to combine all bits and pieces into a valid and useful keyboard
 mapping. All you need to do is to select a suitable rules file and then to
 feed it with a few parameters that will adjust the keyboard behaviour to
 fulfill your needs.
@@ -57,7 +57,7 @@ The parameters are:
 <ListItem>
 
 <Para>
-<Literal remap="tt">XkbRules </Literal>- files of rules to be used for keyboard mapping 
+<Literal remap="tt">XkbRules </Literal>- files of rules to be used for keyboard mapping
 composition
 </Para>
 </ListItem>
@@ -93,8 +93,8 @@ composition
 <Para>
 The proper rules file depends on your vendor. In reality, the commonest
 file of rules is <Literal remap="tt">xorg</Literal>. For each rules file there is a description
-file named <Literal remap="tt">&lt;vendor-rules&gt;.lst</Literal>, for instance <Literal remap="tt">xorg.lst</Literal> 
-which is located in the xkb configuration subdirectory <Literal remap="tt">rules</Literal> 
+file named <Literal remap="tt">&lt;vendor-rules&gt;.lst</Literal>, for instance <Literal remap="tt">xorg.lst</Literal>
+which is located in the xkb configuration subdirectory <Literal remap="tt">rules</Literal>
 (for example <Literal remap="tt">/etc/X11/xkb/rules</Literal>).
 </Para>
 
@@ -118,9 +118,9 @@ Section "InputDevice"
 EndSection
 </Screen>
 
-The values of <Literal remap="tt">XkbModel</Literal> and <Literal remap="tt">XkbLayout</Literal> are really 
-not surprising. The <Literal remap="tt">XkbOptions</Literal> has been explicitly set to 
-the empty set of parameters. The <Literal remap="tt">XkbVariant</Literal> option has been left out. 
+The values of <Literal remap="tt">XkbModel</Literal> and <Literal remap="tt">XkbLayout</Literal> are really
+not surprising. The <Literal remap="tt">XkbOptions</Literal> has been explicitly set to
+the empty set of parameters. The <Literal remap="tt">XkbVariant</Literal> option has been left out.
 That means the default variant named <Literal remap="tt">basic</Literal> is loaded.
 </Para>
 
@@ -133,7 +133,7 @@ setxkbmap -rules xorg -model pc104 -layout us -option ""
 </Screen>
 
 The configuration and the shell command would be very analogous
-for most other layouts (internationalized mappings). 
+for most other layouts (internationalized mappings).
 </Para>
 
 </Sect2>
@@ -205,8 +205,8 @@ EndSection
 
 That seems tricky but it is not. The logic for settings of variants
 is the same as for layouts, that means the first and the third variant
-settings are left out (set to <Literal remap="tt">basic</Literal>), the second is set to 
-<Literal remap="tt">bksl</Literal> (a special variant with an enhanced definition of the backslash 
+settings are left out (set to <Literal remap="tt">basic</Literal>), the second is set to
+<Literal remap="tt">bksl</Literal> (a special variant with an enhanced definition of the backslash
 key).
 </Para>
 
@@ -229,7 +229,7 @@ setxkbmap -rules xorg -model logicordless -layout "us,cz,de" \
 See rules/*.lst files.
 </Para>
 
-<!-- 
+<!--
   TODO: More detailed descriptions of options. Users often get confused.
 -->
 
@@ -244,7 +244,7 @@ See rules/*.lst files.
 Generally, you can directly prescribe what configuration of each of basic
 xkb components should be used to form the resulting keyboard mapping.
 This method is rather "brute force". You precisely need to know the structure
-and the meaning of all of used configuration components. 
+and the meaning of all of used configuration components.
 </Para>
 
 <Para>
@@ -263,15 +263,15 @@ There are five basic components used to form a keyboard mapping:
 <ListItem>
 
 <Para>
-<Emphasis>key codes</Emphasis> - a translation of the scan codes produced by the 
+<Emphasis>key codes</Emphasis> - a translation of the scan codes produced by the
 keyboard into a suitable symbolic form
-              
+
 </Para>
 </ListItem>
 <ListItem>
 
 <Para>
-<Emphasis>types</Emphasis> - a specification of what various combinations of 
+<Emphasis>types</Emphasis> - a specification of what various combinations of
 modifiers produce
 
 </Para>
@@ -279,7 +279,7 @@ modifiers produce
 <ListItem>
 
 <Para>
-<Emphasis>key symbols</Emphasis> - a translation of symbolic key codes into actual 
+<Emphasis>key symbols</Emphasis> - a translation of symbolic key codes into actual
 symbols
 
 </Para>
diff --git a/sgml/input/XKB-Enhancing.sgml b/sgml/input/XKB-Enhancing.sgml
index bd83083..4aec2e6 100644
--- a/sgml/input/XKB-Enhancing.sgml
+++ b/sgml/input/XKB-Enhancing.sgml
@@ -35,7 +35,7 @@ URL="http://www.x-docs.org/XKB/XKBproto.pdf"
 >) at least
 to clarify for himself some xkb-specific terms used in this document
 and elsewhere in xkb configuration. Also it shows wise to understand
-how the X server and a client digest their keyboard inputs 
+how the X server and a client digest their keyboard inputs
 (with and without xkb).
 </Para>
 
@@ -43,7 +43,7 @@ how the X server and a client digest their keyboard inputs
 A useful source is also <ULink
 URL="http://www.tsu.ru/~pascal/en/xkb"
 >Ivan  Pascal's text about xkb configuration</ULink
-> often referenced throughout this 
+> often referenced throughout this
 document.
 </Para>
 
@@ -65,10 +65,10 @@ file.
 
 <Para>
 This compiled configuration file is prepared by the program <Literal remap="tt">xkbcomp</Literal>
-which behaves altogether as an ordinary compiler (see <Literal remap="tt">man xkbcomp</Literal>). 
+which behaves altogether as an ordinary compiler (see <Literal remap="tt">man xkbcomp</Literal>).
 Its input are human readable xkb configuration files which are verified and
 then composed into a useful xkb configuration. Users don't need to mess with
-<Literal remap="tt">xkbcomp</Literal> themselves, for them it is invisible. Usually, it is started 
+<Literal remap="tt">xkbcomp</Literal> themselves, for them it is invisible. Usually, it is started
 upon X server startup.
 </Para>
 
@@ -83,25 +83,25 @@ main modules:
 <Para>
 Tables that defines translation from keyboard scan codes into reasonable
 symbolic names, maximum, minimum legal keycodes, symbolic aliases and
-description of physically present LED-indicators. The primary sence of 
-this component is to allow definitions of maps of symbols (see below) 
-to be independent of physical keyboard scancodes. There are two main 
-naming conventions for symbolic names (always four bytes long): 
+description of physically present LED-indicators. The primary sence of
+this component is to allow definitions of maps of symbols (see below)
+to be independent of physical keyboard scancodes. There are two main
+naming conventions for symbolic names (always four bytes long):
 
 <ItemizedList>
 <ListItem>
 
 <Para>
- names which express some traditional meaning like 
-<Literal remap="tt">&lt;SPCE&gt;</Literal> (stands for space bar) or 
+ names which express some traditional meaning like
+<Literal remap="tt">&lt;SPCE&gt;</Literal> (stands for space bar) or
 </Para>
 </ListItem>
 <ListItem>
 
 <Para>
- names which express some relative positioning on a keyboard, for 
-example <Literal remap="tt">&lt;AE01&gt;</Literal> (an exclamation mark on US keyboards), on 
-the right there are keys <Literal remap="tt">&lt;AE02&gt;</Literal>, <Literal remap="tt">&lt;AE03&gt;</Literal> 
+ names which express some relative positioning on a keyboard, for
+example <Literal remap="tt">&lt;AE01&gt;</Literal> (an exclamation mark on US keyboards), on
+the right there are keys <Literal remap="tt">&lt;AE02&gt;</Literal>, <Literal remap="tt">&lt;AE03&gt;</Literal>
 etc.
 </Para>
 </ListItem>
@@ -208,7 +208,7 @@ concepts and used tricks.
 <Title>Levels And Groups</Title>
 
 <Para>
-Since XFree86 4.3.0 and X11R6.7.0 you can use <Emphasis remap="bf">multi-layout</Emphasis> concept of xkb 
+Since XFree86 4.3.0 and X11R6.7.0 you can use <Emphasis remap="bf">multi-layout</Emphasis> concept of xkb
 configuration.
 Though it is still in boundaries of xkb protocol and general ideas, the
 keymap designer must obey new rules when creating new maps. In exchange
@@ -235,7 +235,7 @@ modifiers so it its row has only one column defined.
 
 <Para>
 Note that in XKB there is no prior assumption that certain modifiers are bound
-to certain columns. By editing proper files (see <XRef LinkEnd="keytypes">) this 
+to certain columns. By editing proper files (see <XRef LinkEnd="keytypes">) this
 mapping can be changed as well.
 </Para>
 
@@ -248,8 +248,8 @@ for? The group is not very useful unless you intend to use more than one
 logically different set of symbols (like more than one alphabet) defined in a
 single mapping table. But then, the group has a natural meaning - each symbol
 set has its own group and changing it means selecting a different one.
-XKB approach allows up to four different groups. The columns inside each group 
-are called (shift) levels. The X server knows the current group and reports it 
+XKB approach allows up to four different groups. The columns inside each group
+are called (shift) levels. The X server knows the current group and reports it
 together with modifier set and with a keycode in key events.
 </Para>
 
@@ -270,8 +270,8 @@ tables - groups (logically different symbol sets)
 <ListItem>
 
 <Para>
- for each group of a keycode XKB keyboard map contains some columns 
-- shift levels (values reached by combinations of Shift, Ctrl, Alt, ... 
+ for each group of a keycode XKB keyboard map contains some columns
+- shift levels (values reached by combinations of Shift, Ctrl, Alt, ...
 modifiers)
 </Para>
 </ListItem>
@@ -290,7 +290,7 @@ modifiers)
 <ListItem>
 
 <Para>
- the current group number is tracked by X server 
+ the current group number is tracked by X server
 </Para>
 </ListItem>
 
@@ -306,7 +306,7 @@ four different symbol sets where each of them would reside in its own group.
 
 <Para>
 The multi-layout concept provides a facility to manipulate xkb groups
-and symbol definitions in a way that allows almost arbitrary composition of 
+and symbol definitions in a way that allows almost arbitrary composition of
 predefined symbol tables. To keep it fully functional you have to:
 
 <ItemizedList>
@@ -335,7 +335,7 @@ behaviour
 <Sect1>
 <Title>Defining New Layouts</Title>
 
-<!-- 
+<!--
   TODO: It may be better to merge IP01 docs and this guide.
 -->
 
@@ -351,7 +351,7 @@ addressed by XKB extension.
 See <ULink
 URL="http://www.tsu.ru/~pascal/en/xkb/gram-common.html"
 >Common  notes about XKB configuration files language</ULink
-> for more precise explanation of 
+> for more precise explanation of
 syntax of xkb configuration files.
 </Para>
 
@@ -371,7 +371,7 @@ want to use on of four predefined latin alphabet layouts.
 
 <Para>
 Okay, let's assume you want extend an existing keymap and you want to override
-a few keys. Let's take a simple U.K. keyboard as an example (defined in 
+a few keys. Let's take a simple U.K. keyboard as an example (defined in
 <Literal remap="tt">pc/gb</Literal>):
 </Para>
 
@@ -399,24 +399,24 @@ xkb_symbols "basic" {
 </Para>
 
 <!--
-    TODO: ref IP01 file syntax TODO: some words about symbolic names like 
+    TODO: ref IP01 file syntax TODO: some words about symbolic names like
     'sterling' and also about
      TODO: unicode characters (for non-latin alphabets),
      TODO: ref to compatibility symbolic names vs. unicode
 -->
 
 <Para>
-It defines a new layout in <Literal remap="tt">basic</Literal> variant as an extension of common 
+It defines a new layout in <Literal remap="tt">basic</Literal> variant as an extension of common
 latin alphabet layout. The layout (symbol set) name is set to "Great Britain".
-Then there are redefinitions of a few keycodes and a modifiers binding. As you 
-can see the number of shift levels is the same for <Literal remap="tt">&lt;AE02&gt;</Literal>, 
-<Literal remap="tt">&lt;AE03&gt;</Literal>, <Literal remap="tt">&lt;AC11&gt;</Literal>, <Literal remap="tt">&lt;TLDE&gt;</Literal> and 
-<Literal remap="tt">&lt;BKSL&gt;</Literal> keys but it differs from number of shift levels of 
+Then there are redefinitions of a few keycodes and a modifiers binding. As you
+can see the number of shift levels is the same for <Literal remap="tt">&lt;AE02&gt;</Literal>,
+<Literal remap="tt">&lt;AE03&gt;</Literal>, <Literal remap="tt">&lt;AC11&gt;</Literal>, <Literal remap="tt">&lt;TLDE&gt;</Literal> and
+<Literal remap="tt">&lt;BKSL&gt;</Literal> keys but it differs from number of shift levels of
 <Literal remap="tt">&lt;RALT&gt;</Literal>.
 </Para>
 
 <Para>
-Note that the <Literal remap="tt">&lt;RALT&gt;</Literal> key itself is a binding key for Mod5 and 
+Note that the <Literal remap="tt">&lt;RALT&gt;</Literal> key itself is a binding key for Mod5 and
 that it
 serves like a shift modifier for LevelThree, together with Shift
 as a multi-key. It is a good habit to respect this rule in a new similar
@@ -425,7 +425,7 @@ layout.
 
 <Para>
 Okay, you could now define more variants of your new layout besides
-<Literal remap="tt">basic</Literal> simply by including (augmenting/overriding/...) the basic 
+<Literal remap="tt">basic</Literal> simply by including (augmenting/overriding/...) the basic
 definition and altering what may be needed.
 </Para>
 
@@ -435,19 +435,19 @@ definition and altering what may be needed.
 <Title>Key Types</Title>
 
 <Para>
-The differences in the number of columns (shift levels) are caused by 
-a different types of keys (see the types definition in section basics).  Most 
-keycodes have implicitly set the keytype in the included 
-<quote><Literal remap="tt">pc/latin</Literal></quote> file to 
-<quote><Literal remap="tt">FOUR&lowbar;LEVEL&lowbar;ALPHABETIC</Literal></quote>. The only exception is 
-<Literal remap="tt">&lt;RALT&gt;</Literal> keycode which is explicitly set 
+The differences in the number of columns (shift levels) are caused by
+a different types of keys (see the types definition in section basics).  Most
+keycodes have implicitly set the keytype in the included
+<quote><Literal remap="tt">pc/latin</Literal></quote> file to
+<quote><Literal remap="tt">FOUR&lowbar;LEVEL&lowbar;ALPHABETIC</Literal></quote>. The only exception is
+<Literal remap="tt">&lt;RALT&gt;</Literal> keycode which is explicitly set
 <quote><Literal remap="tt">TWO&lowbar;LEVEL</Literal></quote> keytype.
 </Para>
 
 <Para>
 All those names refer to pre-defined shift level schemes. Usually you can
 choose a suitable shift level scheme from <Literal remap="tt">default</Literal> types scheme list
-in proper xkb component's subdirectory. 
+in proper xkb component's subdirectory.
 </Para>
 
 <Para>
@@ -531,7 +531,7 @@ and no capitalization rules are applied.
 <Para>
 As the name suggest this scheme is primarily used for numeric keypads.
 The scheme considers two modifiers - Shift and NumLock. If none
-of modifiers applies the symbol from the first level is taken. If either 
+of modifiers applies the symbol from the first level is taken. If either
 Shift or NumLock modifiers apply the symbol from the second level is taken.
 If both Shift+NumLock modifiers apply the symbol from the first level
 is taken. Again, shift-cancels-caps variant.
@@ -571,7 +571,7 @@ is chosen by Control rather than by Shift.
 <Term>PC&lowbar;SYSRQ</Term>
 <ListItem>
 <Para>
-It is similar to TWO&lowbar;LEVEL scheme but it considers the Alt modifier rather 
+It is similar to TWO&lowbar;LEVEL scheme but it considers the Alt modifier rather
 than Shift. That means, the symbol from the second level
 is chosen by Alt rather than by Shift.
 </Para>
@@ -603,8 +603,8 @@ the symbol from the second level is chosen.
 </Para>
 
 <Para>
-If needed, special <Literal remap="tt">caps</Literal> schemes may be used. They redefine the 
-standard behaviour of all <Literal remap="tt">*ALPHABETIC</Literal> types. The layouts (maps of 
+If needed, special <Literal remap="tt">caps</Literal> schemes may be used. They redefine the
+standard behaviour of all <Literal remap="tt">*ALPHABETIC</Literal> types. The layouts (maps of
 symbols) with keys defined in respective types then automatically change
 their behaviour accordingly. Possible redefinitions are:
 
@@ -637,7 +637,7 @@ shift&lowbar;nocancel
 </ItemizedList>
 
 None of these schemes should be used directly. They are defined merely
-for <Literal remap="tt">'caps:'</Literal> xkb options (used to globally change the layouts 
+for <Literal remap="tt">'caps:'</Literal> xkb options (used to globally change the layouts
 behaviour).
 </Para>
 
@@ -651,11 +651,11 @@ create a new one.
 
 <Para>
 When the XKB software deals with a separate type description it gets
-a complete list of modifiers that should be taken into account from the 
+a complete list of modifiers that should be taken into account from the
 <Literal remap="tt">'modifiers=&lt;list of modifiers&gt;'</Literal> list and expects that a set
 of <Literal remap="tt">'map[&lt;combination of modifiers&gt;]=&lt;list of modifiers&gt;'</Literal>
-instructions that contain the mapping for each combination of modifiers 
-mentioned in that list. Modifiers that are not explicitly listed are NOT taken 
+instructions that contain the mapping for each combination of modifiers
+mentioned in that list. Modifiers that are not explicitly listed are NOT taken
 into account
 when the resulting shift level is computed.
 If some combination is omitted the program (subroutine) should choose the first
@@ -673,9 +673,9 @@ type "..." {
 };
 </Screen>
 
-In this case the map statements for <Literal remap="tt">ModTwo</Literal> only and 
-<Literal remap="tt">ModOne+ModTwo</Literal> are omitted.  It means that if the <Literal remap="tt">ModTwo</Literal> is 
-active the subroutine can't found explicit mapping for such combination an will 
+In this case the map statements for <Literal remap="tt">ModTwo</Literal> only and
+<Literal remap="tt">ModOne+ModTwo</Literal> are omitted.  It means that if the <Literal remap="tt">ModTwo</Literal> is
+active the subroutine can't found explicit mapping for such combination an will
 use the <Emphasis>default level</Emphasis> i.e. Level1.
 </Para>
 
@@ -690,23 +690,23 @@ type "..." {
 };
 </Screen>
 
-the ModTwo will not be taken into account and the resulting level depends on 
-the ModOne state only. That means, ModTwo alone produces the Level1 but the 
+the ModTwo will not be taken into account and the resulting level depends on
+the ModOne state only. That means, ModTwo alone produces the Level1 but the
 combination ModOne+ModTwo produces the Level2 as well as ModOne alone.
 </Para>
 
 <Para>
 What does it mean if the second modifier is the Lock? It means that in
-the first case (the Lock itself is included in the list of modifiers but 
-combinations with this modifier aren't mentioned in the map statements) 
-the internal capitalization rules will be applied to the symbol from the first 
+the first case (the Lock itself is included in the list of modifiers but
+combinations with this modifier aren't mentioned in the map statements)
+the internal capitalization rules will be applied to the symbol from the first
 level. But in the second case the capitalization will be applied to the symbol
 chosen accordingly to he first modifier - and this can be the symbol from the
 first as well as from the second level.
 </Para>
 
 <Para>
-Usually, all modifiers introduced in <Literal remap="tt">'modifiers=&lt;list of modifiers&gt;'</Literal> list are used for shift level calculation and then 
+Usually, all modifiers introduced in <Literal remap="tt">'modifiers=&lt;list of modifiers&gt;'</Literal> list are used for shift level calculation and then
 discarded. Sometimes this is not desirable. If you want to use a modifier
 for shift level calculation but you don't want to discard it, you may
 list in '<Literal remap="tt">preserve[&lt;combination of modifiers&gt;]=&lt;list of modifiers&gt;'</Literal>. That means, for a given combination all listed modifiers
@@ -716,8 +716,8 @@ it has been used for a shift level calculation or not.
 </Para>
 
 <Para>
-Any key type description can use both real and virtual modifiers. Since real 
-modifiers always have standard names it is not necessary to explicitly declare  
+Any key type description can use both real and virtual modifiers. Since real
+modifiers always have standard names it is not necessary to explicitly declare
 them. Virtual modifiers can have arbitrary names and can be declared (prior
 using them) directly in key type definition:
 
@@ -725,7 +725,7 @@ using them) directly in key type definition:
 virtual_modifiers &lt;comma-separated list of modifiers&gt;  ;
 </Screen>
 
-as seen in for example <Literal remap="tt">basic</Literal>, <Literal remap="tt">pc</Literal> or <Literal remap="tt">mousekeys</Literal> key 
+as seen in for example <Literal remap="tt">basic</Literal>, <Literal remap="tt">pc</Literal> or <Literal remap="tt">mousekeys</Literal> key
 type definitions.
 </Para>
 
@@ -751,7 +751,7 @@ into predefined templates.
 </Para>
 
 <Para>
-A pattern in a rules file (often located in 
+A pattern in a rules file (often located in
 <Literal remap="tt">/usr/lib/X11/xkb/rules</Literal>) can be parameterized with four other arguments:
 <Literal remap="tt">Model</Literal>, <Literal remap="tt">Layout</Literal>, <Literal remap="tt">Variant</Literal> and <Literal remap="tt">Options</Literal>.
 For most cases parameters <Literal remap="tt">model</Literal> and <Literal remap="tt">layout</Literal> should
@@ -759,8 +759,8 @@ be sufficient for choosing a functional keyboard mapping.
 </Para>
 
 <Para>
-The rules file itself is composed of pattern lines and lines with rules. The pattern line starts with an exclamation mark ('<Literal remap="tt">!</Literal>') 
-and describes how will the xkb interpret the following lines (rules). A sample 
+The rules file itself is composed of pattern lines and lines with rules. The pattern line starts with an exclamation mark ('<Literal remap="tt">!</Literal>')
+and describes how will the xkb interpret the following lines (rules). A sample
 rules file looks like this:
 
 <Screen>
@@ -768,7 +768,7 @@ rules file looks like this:
   macintosh_old	                =	macintosh
   ...
   *		                =	xorg
-  
+
 ! model		                =	symbols
   hp		                =	+inet(&percnt;m)
   microsoftpro	                =	+inet(&percnt;m)
@@ -777,11 +777,11 @@ rules file looks like this:
 ! model	    layout[1]	        =	symbols
   macintosh	us	        =	macintosh/us&percnt;(v[1])
   *             *               =       pc/pc(&percnt;m)+pc/&percnt;l[1]&percnt;(v[1])
-  
+
 ! model     layout[2]	        =	symbols
   macintosh     us              =	+macintosh/us[2]&percnt;(v[2]):2
   *		*               =	+pc/&percnt;l[2]&percnt;(v[2]):2
-  
+
 ! option			=	types
   caps:internal			=	+caps(internal)
   caps:internal_nocancel	=	+caps(internal_nocancel)
@@ -791,36 +791,36 @@ rules file looks like this:
 
 <Para>
 Each rule defines what certain combination of values on the left side
-of equal sign ('<Literal remap="tt">=</Literal>') results in. For example a (keyboard) model 
+of equal sign ('<Literal remap="tt">=</Literal>') results in. For example a (keyboard) model
 <Literal remap="tt">macintosh&lowbar;old</Literal> instructs xkb to take definitions of keycodes
 from file <Literal remap="tt">keycodes/macintosh</Literal> while the rest of models
 (represented by a wild card '<Literal remap="tt">*</Literal>') instructs it to take them from
 file <Literal remap="tt">keycodes/xorg</Literal>. The wild card represents all possible
 values on the left side which were not found in any of the previous rules.
-The more specialized (more complete) rules have higher precedence than general 
+The more specialized (more complete) rules have higher precedence than general
 ones, i.e. the more general rules supply reasonable default values.
 </Para>
 
 <Para>
-As you can see some lines contain substitution parameters - the parameters 
-preceded by the percent sign ('<Literal remap="tt">&percnt;</Literal>'). The first alphabetical character 
-after the percent sign expands to the value which has been found on the left 
-side. For example <Literal remap="tt">+&percnt;l&percnt;(v)</Literal> expands into <Literal remap="tt">+cz(bksl)</Literal> if the 
-respective values on the left side were <Literal remap="tt">cz</Literal> layout in its <Literal remap="tt">bksl</Literal> 
-variant. More, if the layout resp. variant  parameter is followed by a pair of 
-brackets ('<Literal remap="tt">[</Literal>', '<Literal remap="tt">]</Literal>') it means that xkb should <Emphasis>place the 
+As you can see some lines contain substitution parameters - the parameters
+preceded by the percent sign ('<Literal remap="tt">&percnt;</Literal>'). The first alphabetical character
+after the percent sign expands to the value which has been found on the left
+side. For example <Literal remap="tt">+&percnt;l&percnt;(v)</Literal> expands into <Literal remap="tt">+cz(bksl)</Literal> if the
+respective values on the left side were <Literal remap="tt">cz</Literal> layout in its <Literal remap="tt">bksl</Literal>
+variant. More, if the layout resp. variant  parameter is followed by a pair of
+brackets ('<Literal remap="tt">[</Literal>', '<Literal remap="tt">]</Literal>') it means that xkb should <Emphasis>place the
 layout resp. variant into specified xkb group</Emphasis>. If the brackets are omitted
 the first group is the default value.
 </Para>
 
 <Para>
-So the second block of rules enhances symbol definitions for some particular 
-keyboard models with extra keys (for internet, multimedia, ...) . Other models 
+So the second block of rules enhances symbol definitions for some particular
+keyboard models with extra keys (for internet, multimedia, ...) . Other models
 are left intact. Similarly, the last block overrides some key type definitions,
-so the common global behaviour ''shift cancels caps'' or ''shift doesn't cancel 
-caps'' can be selected. The rest of rules produces special symbols for each 
-variant <Literal remap="tt">us</Literal> layout of <Literal remap="tt">macintosh</Literal> keyboard and standard pc 
-symbols in appropriate variants as a default. 
+so the common global behaviour ''shift cancels caps'' or ''shift doesn't cancel
+caps'' can be selected. The rest of rules produces special symbols for each
+variant <Literal remap="tt">us</Literal> layout of <Literal remap="tt">macintosh</Literal> keyboard and standard pc
+symbols in appropriate variants as a default.
 </Para>
 
 </Sect2>
@@ -838,12 +838,12 @@ symbols in appropriate variants as a default.
 <Title>Descriptive Files of Rules</Title>
 
 <Para>
-Now you just need to add a detailed description to <Literal remap="tt">&lt;rules&gt;.xml</Literal> 
-description file so the other users (and external programs which often parse 
+Now you just need to add a detailed description to <Literal remap="tt">&lt;rules&gt;.xml</Literal>
+description file so the other users (and external programs which often parse
 this file) know what is your work about.
 </Para>
 
-<!-- 
+<!--
     TODO: format and semantics
 -->
 
@@ -853,14 +853,14 @@ this file) know what is your work about.
 <Para>
 The formerly used descriptive files were named <Literal remap="tt">&lt;rules&gt;.lst</Literal>
 Its structure is very simple and quite self descriptive but such simplicity
-had also some cavities, for example there was no way how to describe local 
-variants of layouts and there were problems with the localization of 
+had also some cavities, for example there was no way how to describe local
+variants of layouts and there were problems with the localization of
 descriptions. To preserve compatibility with some older programs,
 new XML descriptive files can be converted to old format '.lst'.
 </Para>
 
 <Para>
-For each parameter of rules file should be described its meaning. For the rules 
+For each parameter of rules file should be described its meaning. For the rules
 file described above the <Literal remap="tt">.lst</Literal> file could look like:
 
 <Screen>
@@ -879,8 +879,8 @@ file described above the <Literal remap="tt">.lst</Literal> file could look like
 
 ! option
   caps:internal		 uses internal capitalization. Shift cancels Caps
-  caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps  
-  
+  caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps
+
 </Screen>
 
 </Para>
diff --git a/sgml/platforms/Darwin.sgml b/sgml/platforms/Darwin.sgml
index 290b784..63fc3fe 100644
--- a/sgml/platforms/Darwin.sgml
+++ b/sgml/platforms/Darwin.sgml
@@ -18,8 +18,8 @@
 <para>
 <ulink
 url="http://www.freedesktop.org/Software/xorg">Xorg</ulink>, a freely
-redistributable open-source implementation of the 
-<ulink url="http://www.x.org/">X Window System</ulink>, 
+redistributable open-source implementation of the
+<ulink url="http://www.x.org/">X Window System</ulink>,
 has been ported to <ulink url="http://www.opensource.apple.com/projects/darwin/"
 >Darwin</ulink>
 and <ulink
@@ -173,7 +173,7 @@ cd sandbox
 cvs checkout xc
 </screen>
 
-Wait for all the files to complete downloading. 
+Wait for all the files to complete downloading.
 
 </para>
 </listitem>
@@ -189,7 +189,7 @@ Wait for all the files to complete downloading.
 
 <para>
 Once you have everything ready it is easy to build and install
-X11R&relvers;. From the command line: 
+X11R&relvers;. From the command line:
 </para>
 
 <para>
@@ -218,7 +218,7 @@ sudo make install.man &#62;&#38; man.log
 
 <para>
 You need to add the X Window System executables to your path. Your path
-is the list of directories to be searched for executable commands. 
+is the list of directories to be searched for executable commands.
 The X11 commands are located in <literal remap="tt">/usr/X11R6/bin</literal>, which needs to be
 added to your path. In Quartz mode, the XDarwin application does this for
 you automatically. It can also be configured to add additional directories
@@ -263,7 +263,7 @@ From the text console you can start the X Window System by typing
 When you are ready to quit X11R&relvers; type ``exit'' in the main
 terminal window or quit with the window manager if you have one
 running. Unfortunately in IOKit mode, the X server does not shutdown
-correctly and if you did not start with ``exec startx'', you 
+correctly and if you did not start with ``exec startx'', you
 will get an apparently frozen screen with only a spinning beachball
 cursor on it. Nothing you type shows up on the screen, but in fact
 your keystrokes are being received by the console. Type
@@ -334,7 +334,7 @@ look, how the windows are moved, resized, etc. You will likely want to
 get a fancier window manager than twm, which is included with
 X11R&relvers;. The <Literal remap="tt">.xinitrc</Literal> file in your home directory controls what
 programs are run when you start the X Window System. You can find a sample
-<Literal remap="tt">.xinitrc</Literal> file in <Literal remap="tt">/etc/X11/xinit/xinitrc</Literal>.  
+<Literal remap="tt">.xinitrc</Literal> file in <Literal remap="tt">/etc/X11/xinit/xinitrc</Literal>.
 </Para>
 
 <Para>
diff --git a/sgml/platforms/LynxOS.sgml b/sgml/platforms/LynxOS.sgml
index 284f194..7be637f 100644
--- a/sgml/platforms/LynxOS.sgml
+++ b/sgml/platforms/LynxOS.sgml
@@ -17,7 +17,7 @@
 
 <Para>
 X11R&relvers; is a port of X11R6.4 that supports several versions of
-Intel-based Unix.  It is derived from XFree86 4.4 rc2 which was 
+Intel-based Unix.  It is derived from XFree86 4.4 rc2 which was
 derived from X386 1.2, which was the X server
 distributed with X11R5.  This release consists of many new features
 and performance improvements as well as many bug fixes.
@@ -64,15 +64,15 @@ environment variable.
 
 <Para>
 Refer to the next section <XRef LinkEnd="running"> for
-further information on necessary configuration steps before running 
-X11R&relvers; on LynxOS. 
+further information on necessary configuration steps before running
+X11R&relvers; on LynxOS.
 </Para>
 
 <Sect2>
 <Title>Accessing X11R&relvers; manual pages</Title>
 
 <Para>
-Include <Literal remap="tt">/usr/X11R6/man</Literal> in the MANPATH environment variable or add 
+Include <Literal remap="tt">/usr/X11R6/man</Literal> in the MANPATH environment variable or add
 the directory <Literal remap="tt">/usr/X11R6/man</Literal> to <Literal remap="tt">/usr/Lib/man.config</Literal>
 </Para>
 
@@ -84,12 +84,12 @@ the directory <Literal remap="tt">/usr/X11R6/man</Literal> to <Literal remap="tt
 <Title>Running X11R&relvers;</Title>
 
 <Para>
-This section describes the changes to the LynxOS environment 
+This section describes the changes to the LynxOS environment
 which may be necessary to successfully run X11R&relvers;.
 </Para>
 
 <!--
-Read <htmlurl url="QuickStart.html" name="Quick-Start Guide 
+Read <htmlurl url="QuickStart.html" name="Quick-Start Guide
 to X11R&relvers; Setup"> to learn more about how to configure X11R&relvers;
 for
 your hardware.
@@ -194,7 +194,7 @@ now:
      # cd /sys/lynx.os
      # make install
      # reboot -N
-  
+
 </Screen>
 
 </Para>
@@ -223,7 +223,7 @@ LynxOS.
 <Para>
 LynxOS x86 comes with a PS/2 mouse driver. If it is not currently
 installed on your system, install it with
-<Literal remap="tt">/usr/bin/Install.ps2mouse</Literal>. 
+<Literal remap="tt">/usr/bin/Install.ps2mouse</Literal>.
 </Para>
 
 <!--
@@ -255,7 +255,7 @@ mouse driver as follows:
    #ifdef DEBUG
           kkprintf("Mouse: write %d %x\n", count, buff[0] &#38; 0x0FF);
    #endif
-  
+
 </Screen>
 
 </Para>
@@ -272,7 +272,7 @@ Then rebuild both the mouse driver and the kernel:
      # cd /sys/lynx.os
      # make install
      # reboot
-  
+
 </Screen>
 
 </Para>
@@ -300,11 +300,11 @@ terminals in <Literal remap="tt">/etc/ttys</Literal>, e.g. <Literal remap="tt">/
 <Screen>
 change
        /dev/atc3:1:default:vt100at:/bin/login
-  
+
 to
        /dev/atc3:0:default:vt100at:/bin/login
                  ^
-  
+
 </Screen>
 
 </Para>
@@ -340,7 +340,7 @@ be inconsistent with what one would expect (i.e. random).
 
 <sect2>Copy Motif files<p>
 
-  You must create symbolic links for the Motif libraries and 
+  You must create symbolic links for the Motif libraries and
   utilities in the <tt>/usr/X11R6</tt> directory tree.
   <tscreen><verb>
       ln -s /usr/bin/X11/uil /usr/X11R6/bin
@@ -364,8 +364,8 @@ be inconsistent with what one would expect (i.e. random).
 
   The X11R&relvers; libraries are compiled with the -mposix compiler option
   while the Motif libraries shipped with LynxOS AT 2.3.0 are not. This
-  incompatibility will cause Motif <tt>XmFileSelection</tt> widgets to be linked 
-  with the wrong (i.e. POSIX) directory routines. To circumvent this 
+  incompatibility will cause Motif <tt>XmFileSelection</tt> widgets to be linked
+  with the wrong (i.e. POSIX) directory routines. To circumvent this
   problem apply the following patch to the library:
   <tscreen><verb>
       cp /usr/lib/libXm.a /usr/X11R6/lib
@@ -375,7 +375,7 @@ be inconsistent with what one would expect (i.e. random).
       mv x.o Xmos.o
       ar r /usr/X11R6/lib/libXm.a Xmos.o
   </verb></tscreen>
-  
+
   This patch is not necessary for LynxOS revisions after 2.3.0.
 
 </sect2>
@@ -528,7 +528,7 @@ If you have the MTRR device driver installed, add a line
 
 <Screen>
     #define HasMTRRSupport YES
-  
+
 </Screen>
 
 </Para>
@@ -545,7 +545,7 @@ You may then issue a
 
 <Screen>
      make World
-  
+
 </Screen>
 
 </Para>
@@ -559,7 +559,7 @@ build of the X11R&relvers; system) you can install the software using
 
 <Screen>
      make install
-  
+
 </Screen>
 
 </Para>
@@ -598,7 +598,7 @@ X11R&relvers; manual pages may be installed using
 
 <Screen>
      make install.man
-  
+
 </Screen>
 
 </Para>
@@ -621,7 +621,7 @@ operation to remove duplicate entries:
      done
      sort /usr/X11R6/man/whatis | uniq &#62; /tmp/tmpfile
      mv /tmp/tmpfile /usr/X11R6/man/whatis
-  
+
 </Screen>
 
 </Para>
@@ -633,20 +633,20 @@ operation to remove duplicate entries:
 
   X11R&relvers; 3.3 compiles on LynxOS microSPARC and on LynxOS PPC as well. On the
   microSPARC there is X server support for the colour frame buffers CG3 and CG6
-  while on the PPC there is no X server available at this time. Before you 
+  while on the PPC there is no X server available at this time. Before you
   start the build (on versions earlier than 2.5.0) you must create a symbolic
-  link from the CYGNUS gcc to a file named <tt>cc</tt> somewhere in a 
+  link from the CYGNUS gcc to a file named <tt>cc</tt> somewhere in a
   directory included in your PATH environment variable.
 
 <sect1>Console driver patch for microSPARC<p>
 
   Before building on the microSPARC you should install the patch for the console
   driver supplied in <tt>xc/programs/Xserver/hw/sunLynx/patch.Console</tt>.
-  (<tt>xc/programs/Xserver/hw/sunLynx/patch.Console-2.4.0</tt> for LynxOS 
+  (<tt>xc/programs/Xserver/hw/sunLynx/patch.Console-2.4.0</tt> for LynxOS
   revisions earlier than 2.5.0).
-  The patch fixes minor problems in the original LynxOS driver and adds 
+  The patch fixes minor problems in the original LynxOS driver and adds
   functionalities to detect the keyboard type and control the key click.
-  To create a backup of the original driver and install the patch issue 
+  To create a backup of the original driver and install the patch issue
   the commands
 <tscreen><verb>
  # cd /
@@ -675,8 +675,8 @@ operation to remove duplicate entries:
 
   On the first start of the X server on the microSPARC you will notice that
   the pointer follows mouse movements with a certain delay (especially if
-  you're moving the mouse real fast). You will also notice that moving 
-  windows with certain window managers (eg mwm) is not working correctly. 
+  you're moving the mouse real fast). You will also notice that moving
+  windows with certain window managers (eg mwm) is not working correctly.
   These effects should go away on the next server start.
 
   The server for monochrome cards builds properly if you enable it in
diff --git a/sgml/platforms/NetBSD.sgml b/sgml/platforms/NetBSD.sgml
index e953d18..0892602 100644
--- a/sgml/platforms/NetBSD.sgml
+++ b/sgml/platforms/NetBSD.sgml
@@ -89,7 +89,7 @@ Support for in-kernel MTRR and AGP support in NetBSD 1.5Y
 <ListItem>
 
 <Para>
-Enable wide characters support in NetBSD 1.5P and later. 
+Enable wide characters support in NetBSD 1.5P and later.
 </Para>
 </ListItem>
 
@@ -197,8 +197,8 @@ Preliminary APM support.
 <ListItem>
 
 <Para>
-Soft-booting secondary cards through the int10 BIOS interface is 
-now possible using the x86emu real mode emulator. 
+Soft-booting secondary cards through the int10 BIOS interface is
+now possible using the x86emu real mode emulator.
 </Para>
 </ListItem>
 
@@ -224,7 +224,7 @@ been added.
 <ListItem>
 
 <Para>
-A new version of the Aperture driver which provides MTRR 
+A new version of the Aperture driver which provides MTRR
 support is included.
 </Para>
 </ListItem>
@@ -252,7 +252,7 @@ for detailed installation instructions.
 
 <Para>
 The <Literal remap="tt">/etc/X11/xorg.conf</Literal> file tells the X server what kind of
-monitor, 
+monitor,
 video card and mouse you have.  You <Emphasis>must</Emphasis> create it to tell the
 server what specific hardware you have.
 </Para>
@@ -291,7 +291,7 @@ For details about the <Literal remap="tt">xorg.conf</Literal> file format, refer
 
 <Para>
 Once you've set up a xorg.conf file, you can fine tune the video
-modes with the <Literal remap="tt">xvidtune</Literal> utility. 
+modes with the <Literal remap="tt">xvidtune</Literal> utility.
 </Para>
 
 <Sect2>
@@ -300,7 +300,7 @@ modes with the <Literal remap="tt">xvidtune</Literal> utility.
 <Para>
 X11R&relvers; has support for the mouse driver included in
 the <Emphasis remap="bf">wscons</Emphasis> console driver introduced by NetBSD 1.4. Specify
-``<Literal remap="tt">wsmouse</Literal>'' as the protocol and ``<Literal remap="tt">/dev/wsmouse0</Literal>'' as the 
+``<Literal remap="tt">wsmouse</Literal>'' as the protocol and ``<Literal remap="tt">/dev/wsmouse0</Literal>'' as the
 device in <Literal remap="tt">/etc/X11/xorg.conf</Literal> if you're using NetBSD 1.4 or later
 with a PS/2 mouse.
 </Para>
@@ -316,7 +316,7 @@ mouse with NetBSD 1.3 or former releases.
 Only standard PS/2 mice are supported by this driver. Newest PS/2
 mice that send more than three bytes at a time (especially
 Intellimouse, or MouseMan+ with a wheel) are not supported by NetBSD
-1.3 and former releases. 
+1.3 and former releases.
 </Para>
 
 <Para>
@@ -332,12 +332,12 @@ instruction on mouse configuration.
 <Title>Running X</Title>
 
 <Para>
-The easiest way for new users to start X windows is to type: 
+The easiest way for new users to start X windows is to type:
 
 <Screen>
 startx &#62;&#38; startx.log
 </Screen>
- 
+
 Error messages are lost unless you redirect them
 because the server takes over the screen.
 </Para>
@@ -358,7 +358,7 @@ To start the display manager, log in as root on the console and type:
 </Para>
 
 <Para>
-You can start xdm automatically on bootup by changing the line 
+You can start xdm automatically on bootup by changing the line
 
 <Screen>
 xdm=NO			xdm_flags=""            # x11 display manager
@@ -370,7 +370,7 @@ to:
 xdm=YES			xdm_flags=""            # x11 display manager
 </Screen>
 
-in <Literal remap="tt">/etc/rc.conf</Literal>. 
+in <Literal remap="tt">/etc/rc.conf</Literal>.
 </Para>
 
 <Para>
@@ -383,7 +383,7 @@ these steps:
 
 <Para>
 Make sure the device file exists. If not, ``<Literal remap="tt">cd /dev ;
-./MAKEDEV wscons</Literal>''. 
+./MAKEDEV wscons</Literal>''.
 </Para>
 </ListItem>
 <ListItem>
@@ -449,7 +449,7 @@ options XSERVER, UCONSOLE
 <Para>
 The server supports the standard NetBSD/i386
 console drivers: pccons, pcvt and wscons (in pcvt compatibility
-mode). They are detected at runtime and no 
+mode). They are detected at runtime and no
 configuration of the server itself is required.
 </Para>
 
@@ -501,7 +501,7 @@ options         WSDISPLAY_COMPAT_USL		# VT handling
 options         WSDISPLAY_COMPAT_RAWKBD         # can get raw scancodes
 </Screen>
 
-in your kernel configuration file if you're using wscons. Refer to the 
+in your kernel configuration file if you're using wscons. Refer to the
 <Emphasis>wscons(4)</Emphasis> and <Emphasis>wsmouse(4)</Emphasis> manual pages for
 informations on how to configure wscons into the kernel.
 </Para>
@@ -514,7 +514,7 @@ informations on how to configure wscons into the kernel.
 <Para>
 By default NetBSD include the BSD 4.4 kernel security
 feature that disable access to the <Literal remap="tt">/dev/mem</Literal> device when in
-multi-users mode. But X.Org Foundation X servers can take advantage 
+multi-users mode. But X.Org Foundation X servers can take advantage
 (or require)
 linear access to the display memory.
 </Para>
@@ -533,7 +533,7 @@ kernel.
 <Para>
 The second way is to install the aperture driver, included in source form in
 <Literal remap="tt">xc/programs/Xserver/hw/xfree86/etc/apNetBSD.shar</Literal> in the
-X11R&relvers; source distribution. Unpack it in a new directory of your 
+X11R&relvers; source distribution. Unpack it in a new directory of your
 choice by running:
 
 <Screen>
@@ -541,18 +541,18 @@ choice by running:
 </Screen>
 
 By default the aperture driver will be installed in
-<Literal remap="tt">/usr/local/aperture</Literal>. You can change this default directory by 
-editing <Literal remap="tt">Makefile.inc</Literal> before building it. 
+<Literal remap="tt">/usr/local/aperture</Literal>. You can change this default directory by
+editing <Literal remap="tt">Makefile.inc</Literal> before building it.
 </Para>
 
 <Para>
-Then run ``<Literal remap="tt">make build</Literal>'' as root to install it. To enable it, 
+Then run ``<Literal remap="tt">make build</Literal>'' as root to install it. To enable it,
 add the following line to  <Literal remap="tt">/etc/lkm.conf</Literal>:
 
 <Screen>
 /usr/local/aperture/lkm/xf86.o  -  - /usr/local/aperture/lkm/xf86_mod_install - -
 </Screen>
- 
+
 and set ``<Literal remap="tt">lkm=YES</Literal>'' in <Literal remap="tt">/etc/rc.conf</Literal>
 </Para>
 
@@ -578,7 +578,7 @@ Use ``option INSECURE'' if you need more that one X server at a time.
 <Para>
 Starting with XFree86 3.9.17, the XFree86 aperture driver
 also supports MTRR write combining on Pentiums II
-and AMD K6 class processors. 
+and AMD K6 class processors.
 </Para>
 
 </Sect2>
@@ -631,18 +631,18 @@ sources, invoke ``<Literal remap="tt">make World</Literal>'' in the xc directory
 <Para>
 Starting with XFree86 4.0.2, perl is needed to build the fonts in
 XFree86. Since perl is not included with standard NetBSD installation,
-fonts that need perl are not built by default. 
+fonts that need perl are not built by default.
 </Para>
 
 <Para>
 If you have installed perl (from the NetBSD packages, for instance),
-add the line  
+add the line
 
 <Screen>
 #define HasPerl YES
 </Screen>
 
-in <Literal remap="tt">xc/config/cf/host.def</Literal> before rebuilding X. 
+in <Literal remap="tt">xc/config/cf/host.def</Literal> before rebuilding X.
 </Para>
 
 </Sect2>
@@ -652,7 +652,7 @@ in <Literal remap="tt">xc/config/cf/host.def</Literal> before rebuilding X.
 
 <Para>
 To build the X server with the Aperture driver enabled, you
-should unpack <Literal remap="tt">apNetBSD.shar</Literal> and install it first. 
+should unpack <Literal remap="tt">apNetBSD.shar</Literal> and install it first.
 </Para>
 
 <Para>
@@ -712,8 +712,8 @@ by adding:
  #define XFree86ConsoleDefines -DWSCONS_SUPPORT
 </Screen>
 
-to <Literal remap="tt">xc/config/host.def</Literal> before rebuilding the server. 
-This has not been thoroughly tested, except on the macppc. 
+to <Literal remap="tt">xc/config/host.def</Literal> before rebuilding the server.
+This has not been thoroughly tested, except on the macppc.
 </Para>
 
 <Para>
@@ -732,11 +732,11 @@ to use the pcvt compatibility mode of wscons:
 <Title>Building on other architectures</Title>
 
 <Para>
- 
+
 Note that the NetBSD project has now its own source tree, based on the
 X source tree, with some local modifications. You may want to
-start with this tree to rebuild from sources. 
-The NetBSD xsrc source tree is available at: 
+start with this tree to rebuild from sources.
+The NetBSD xsrc source tree is available at:
 <ULink
 URL="ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/xsrc/"
 >ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/xsrc/</ULink>
@@ -769,7 +769,7 @@ later releases can use:
 <Para>
 
 <Screen>
-                   
+
 &num;if (BSD &#62;= 199103)
 </Screen>
 
@@ -802,7 +802,7 @@ Many thanks to all people who contributed to make XFree86 work on
 <Emphasis remap="bf">Todd Fries</Emphasis>,
 <Emphasis remap="bf">Rod Grimes</Emphasis>,
 <Emphasis remap="bf">Charles Hannum</Emphasis>,
-<Emphasis remap="bf">Amancio Hasty</Emphasis>, 
+<Emphasis remap="bf">Amancio Hasty</Emphasis>,
 <Emphasis remap="bf">Christoph Robitschko</Emphasis>,
 <Emphasis remap="bf">Matthias Scheler</Emphasis>,
 <Emphasis remap="bf">Michael Smith</Emphasis>,
diff --git a/sgml/platforms/OS2Notes.sgml b/sgml/platforms/OS2Notes.sgml
index d8fc288..8dc9891 100644
--- a/sgml/platforms/OS2Notes.sgml
+++ b/sgml/platforms/OS2Notes.sgml
@@ -37,7 +37,7 @@ information, and set at least the environment variables described there.
 
 <Para>
 At the current time, the most recent version available is X11R&relvers;
-This is a full and unrestricted version which comes with complete source 
+This is a full and unrestricted version which comes with complete source
 code. 4.0 is a highly experimental release, so many features that might
 have worked in earlier versions, may now no longer work, or work differently.
 Be aware that for OS/2, X11R&relvers; is considered to be alpha software.
@@ -168,8 +168,8 @@ which might still be available from some archives is NOT compatible.
 </Para>
 
 <Para>
-Furthermore, you need the X11R&relvers; sources. These are available from 
-the common X.Org repositories. Look into a directory which is 
+Furthermore, you need the X11R&relvers; sources. These are available from
+the common X.Org repositories. Look into a directory which is
 often named /pub/R7.1.
 </Para>
 
@@ -203,7 +203,7 @@ put everything below this tree. I found that a clean tree occupies
 less than the half space of the disk, this gives me the opportunity to
 rename this tree to <Literal remap="tt">&bsol;x11old</Literal> and copy a new version to the
 same disk to produce diffs. Last time the complete tree was
-arranged under the root directory <Literal remap="tt">xc</Literal>, this would become 
+arranged under the root directory <Literal remap="tt">xc</Literal>, this would become
 <Literal remap="tt">&bsol;x11&bsol;xc</Literal> then.
 </Para>
 </ListItem>
@@ -215,7 +215,7 @@ To unpack the files you would usually execute the command
 <Screen>
 gzip -dc file.tar.gz | tar xvf -
 </Screen>
- 
+
 in the <Literal remap="tt">&bsol;x11</Literal> directory. At the end you will usually see the
 irritating, but non-fatal message "gzip: stdout Broken pipe". Ignore it.
 </Para>
@@ -228,9 +228,9 @@ the X.Org Foundation. Before you do this, enter
 
 <Screen>
       chmod -R a+rw &bsol;x11&bsol;xc
-      
+
 </Screen>
- 
+
 to make certain files in the tree writable.
 </Para>
 </ListItem>
@@ -241,7 +241,7 @@ There should be a file <Literal remap="tt">added-XXX</Literal> accompanying the
 which lists the files that are newly created. The patch program has
 a problem with creating new directories, so we need to create them
 on advance. For each <Literal remap="tt">added-XXX</Literal> file you find, execute from
-<Literal remap="tt">&bsol;x11</Literal> 
+<Literal remap="tt">&bsol;x11</Literal>
 <Screen>
 xc&bsol;config&bsol;util&bsol;added added-XXX
 </Screen>
@@ -251,7 +251,7 @@ the following instructions:
 
 <Screen>
       grep "&bsol;*&bsol;*&bsol;* xc/" patchfile &#62;added-file
-      
+
 </Screen>
 
 Edit <Literal remap="tt">added-file</Literal> with a text editor and remove the <Literal remap="tt">*** </Literal> at
@@ -268,7 +268,7 @@ is done by a command
 
 <Screen>
       patch -p -E &#60;patchfile 2&#62;&#38;1 | tee patchlog
-      
+
 </Screen>
 
 from the <Literal remap="tt">&bsol;x11</Literal> directory. Be aware to use the right
@@ -277,9 +277,9 @@ Don't use the recommended <Literal remap="tt">-s</Literal> option, this makes <L
 and you won't see problems in the patchlog file. Use
 
 <Screen>
-      find &bsol;x11 -name *.rej -print 
+      find &bsol;x11 -name *.rej -print
       find &bsol;x11 -name *# -print
-      
+
 </Screen>
 
 to find any rejects and unapplied patches (attention: yet another OS/2
@@ -289,7 +289,7 @@ remove the original files with
 
 <Screen>
       find &bsol;x11 -name *.orig -print -exec rm {} ;
-      
+
 </Screen>
 
 </Para>
@@ -321,7 +321,7 @@ Both options are not yet supported.
 
 <Para>
 Tcl* and Tk* don't need to be set explicitly. Reasonable defaults
-are in the other config files, provided you have a complete 
+are in the other config files, provided you have a complete
 X11R&relvers;/OS2 binary tree with the tcl/tk runtime support installed.
 </Para>
 </ListItem>
@@ -340,8 +340,8 @@ This does not work.
 <ListItem>
 
 <Para>
-Go to the directory <Literal remap="tt">xc&bsol;util&bsol;compress</Literal> and 
-<Literal remap="tt">make compress.exe</Literal> there. Install the program produced 
+Go to the directory <Literal remap="tt">xc&bsol;util&bsol;compress</Literal> and
+<Literal remap="tt">make compress.exe</Literal> there. Install the program produced
 there in your path. I stumbled more than once on half-ported
 compress programs on OS/2 ftp servers that are defective w.r.t.
 reading and writing stdin/stdout. In some stage (font compression)
@@ -407,7 +407,7 @@ Finally, from the <Literal remap="tt">xc</Literal> dir, execute
 <Screen>
       xmake install
       xmake install.man
-      
+
 </Screen>
 
 </Para>
@@ -431,7 +431,7 @@ This is no problem and has no effect on the rest of the system.
 The imake.exe which is installed in <Literal remap="tt">&bsol;X11R&relvers;&bsol;bin</Literal> is usually defective.
 The one which was built initially and installed in the root directory
 of the drive where you have the source tree is okay. So simply copy
-this <Literal remap="tt">&bsol;imake.exe</Literal> to the <Literal remap="tt">&bsol;X11R&relvers;&bsol;bin</Literal> directory 
+this <Literal remap="tt">&bsol;imake.exe</Literal> to the <Literal remap="tt">&bsol;X11R&relvers;&bsol;bin</Literal> directory
 manually. Some day this might be fixed.
 </Para>
 </ListItem>
diff --git a/sgml/platforms/OpenBSD.sgml b/sgml/platforms/OpenBSD.sgml
index 99abeb1..577cab1 100644
--- a/sgml/platforms/OpenBSD.sgml
+++ b/sgml/platforms/OpenBSD.sgml
@@ -20,7 +20,7 @@
 <Title>What and Where is X11R7&relvers;?</Title>
 
 <Para>
-The X.Org Foundation X11R7&relvers; is an Open Source version of 
+The X.Org Foundation X11R7&relvers; is an Open Source version of
 the X Window System that supports
 several UNIX(R) and UNIX-like operating systems (such as Linux, the BSDs
 and Solaris x86) on Intel and other platforms.
@@ -34,7 +34,7 @@ URL="COPYRIGHT.html"
 </Para>
 
 <Para>
-The sources for X11R7&relvers; are available from 
+The sources for X11R7&relvers; are available from
 <ULink
 URL="http://wiki.x.org"
 >http://wiki.x.org</ULink
@@ -55,7 +55,7 @@ X11R7&relvers; builds on most architectures supported by OpenBSD. See section
 Use the X.Org Bugzilla at <ULink
 URL="http://bugs.freedesktop.org"
 >http://bugs.freedesktop.org</ULink
-> 
+>
 to submit comments or suggestions about this file, using the xorg product.
 </Para>
 
@@ -118,7 +118,7 @@ Server support for OpenBSD/amd64.
 
 <Para>
 The <Literal remap="tt">/etc/X11/xorg.conf</Literal> file tells the X server what kind of
-monitor, 
+monitor,
 video card and mouse you have.  You <Emphasis>must</Emphasis> create it to tell the
 server what specific hardware you have.
 </Para>
@@ -168,7 +168,7 @@ URL="xorg.conf.5.html"
 
 <Para>
 Once you've set up a xorg.conf file, you can fine tune the video
-modes with the <Literal remap="tt">xvidtune</Literal> utility. 
+modes with the <Literal remap="tt">xvidtune</Literal> utility.
 </Para>
 
 <Sect2>
@@ -176,7 +176,7 @@ modes with the <Literal remap="tt">xvidtune</Literal> utility.
 
 <Para>
 X11R7&relvers; has support for the mouse driver included in
-the new <Emphasis remap="bf">wscons</Emphasis> console driver. 
+the new <Emphasis remap="bf">wscons</Emphasis> console driver.
 Specify ``<Literal remap="tt">wsmouse</Literal>'' as the protocol and
 ``<Literal remap="tt">/dev/wsmouse</Literal>'' as the  device in <Literal remap="tt">/etc/X11/xorg.conf</Literal>
 with a PS/2 or USB mouse.
@@ -212,7 +212,7 @@ You can start xdm automatically on bootup by adding the line:
 xdm_flags=""            # for normal use: xdm_flags=""
 </Screen>
 
-in <Literal remap="tt">/etc/rc.conf.local</Literal>. 
+in <Literal remap="tt">/etc/rc.conf.local</Literal>.
 </Para>
 
 </Sect2>
@@ -248,7 +248,7 @@ OpenBSD's GENERIC kernels have all support for running X enabled.
 <Title>Console drivers</Title>
 
 <Para>
-The server supports wscons, the standard OpenBSD/i386 console driver. 
+The server supports wscons, the standard OpenBSD/i386 console driver.
 </Para>
 
 </Sect2>
@@ -273,7 +273,7 @@ I/O ports of the video boards.
 To enable the aperture driver, once included in the kernel, set
 
 <Screen>
-machdep.allowaperture=2     
+machdep.allowaperture=2
 </Screen>
 
 in <Literal remap="tt">/etc/sysctl.conf</Literal>.  See the
@@ -281,12 +281,12 @@ in <Literal remap="tt">/etc/sysctl.conf</Literal>.  See the
 URL="http://www.openbsd.org/cgi-bin/man.cgi?query=xf86&#38;apropos=0&#38;sektion=4&#38;manpath=OpenBSD+Current&#38;arch=i386&#38;format=html"
 >xf86(4)</ULink
 >
-manual page for details. 
+manual page for details.
 </Para>
 
 <Para>
 Another (less recommended) way to enable linear memory and I/O ports
-access is to disable the kernel security feature by 
+access is to disable the kernel security feature by
 initializing <Literal remap="tt">securelevel</Literal> to -1 in <Literal remap="tt">/etc/rc.securelevel</Literal>.
 </Para>
 
@@ -322,8 +322,8 @@ You should configure the distribution by editing
 sources, invoke ``<Literal remap="tt">make World</Literal>'' in the xc directory.</Title>
 
 <Para>
- 
-Note that OpenBSD project now has its own source tree, 
+
+Note that OpenBSD project now has its own source tree,
 with some local modifications. You may want
 to start with this tree to rebuild from sources.  The OpenBSD XF4
 source tree is available by anoncvs from all OpenBSD anoncvs
@@ -341,7 +341,7 @@ URL="http://www.openbsd.org/anoncvs.html"
 X11R7&relvers; compiles on most OpenBSD architectures. The X.Org
 X server builds and run on the following systems. On other
 architectures supported by OpenBSD, only client side libraries and
-applications are supported.  
+applications are supported.
 </Para>
 
 <Sect2>
@@ -349,7 +349,7 @@ applications are supported.
 
 <Para>
 The X server is known to work on some VGA cards in alpha
-machines that support BWX I/O, with OpenBSD 3.2 and higher. 
+machines that support BWX I/O, with OpenBSD 3.2 and higher.
 </Para>
 
 <Para>
@@ -359,7 +359,7 @@ The following cards have been successfully tested for now:
 <ListItem>
 
 <Para>
-3DLabs Permedia 2 (8, 15, 16 and 24 bits depth) 
+3DLabs Permedia 2 (8, 15, 16 and 24 bits depth)
 </Para>
 </ListItem>
 <ListItem>
@@ -394,7 +394,7 @@ Matrox MGA 2064 (8, 16 and 24 bits depth)
 <Para>
 Note that this version of doesn't work on TGA cards. The
 version shipped with OpenBSD 3.1 and higher includes an OS-specific
-driver <Emphasis>wsfb</Emphasis> that is used to support TGA cards. 
+driver <Emphasis>wsfb</Emphasis> that is used to support TGA cards.
 </Para>
 
 </Sect2>
@@ -409,8 +409,8 @@ Other machines are more or less untested.
 </Para>
 
 <Para>
-Use xorgconfig to build a /etc/X11/xorg.conf file before starting 
-the server for the first time. 
+Use xorgconfig to build a /etc/X11/xorg.conf file before starting
+the server for the first time.
 </Para>
 
 <Para>
@@ -435,7 +435,7 @@ Modeline "1152x768" 64.995 1152 1213 1349 1472  768 771 777 806 -HSync -VSync
 OpenBSD 3.2 on sparc switched to the wscons device driver and now uses
 the OS specific <Emphasis>wsfb</Emphasis> driver in the X server. This driver is
 not included in X11R7&relvers;. Please use the version shipped with
-OpenBSD instead. 
+OpenBSD instead.
 </Para>
 
 </Sect2>
@@ -444,9 +444,9 @@ OpenBSD instead.
 <Title>OpenBSD/sparc64</Title>
 
 <Para>
-This version only has support PCI based machines using ATI cards on 
+This version only has support PCI based machines using ATI cards on
 OpenBSD/sparc64. Note that the version shipped with OpenBSD has
-support for the X server on both SBus and UPA (unaccelerated) based cards. 
+support for the X server on both SBus and UPA (unaccelerated) based cards.
 </Para>
 
 </Sect2>
@@ -464,7 +464,7 @@ Many thanks to all people who contributed to make X11R7&relvers; work on
 <Emphasis remap="bf">Miodrag Vallat</Emphasis>,
 <Emphasis remap="bf">Rod Grimes</Emphasis>,
 <Emphasis remap="bf">Charles Hannum</Emphasis>,
-<Emphasis remap="bf">Amancio Hasty</Emphasis>, 
+<Emphasis remap="bf">Amancio Hasty</Emphasis>,
 <Emphasis remap="bf">Christoph Robitschko</Emphasis>,
 <Emphasis remap="bf">Matthias Scheler</Emphasis>,
 <Emphasis remap="bf">Michael Smith</Emphasis>,
diff --git a/sgml/platforms/SCO.sgml b/sgml/platforms/SCO.sgml
index 0d3a278..e6c59a0 100644
--- a/sgml/platforms/SCO.sgml
+++ b/sgml/platforms/SCO.sgml
@@ -154,7 +154,7 @@ Go to the top level of the source tree and execute the command
 <Literal remap="tt">CC=gcc make World BOOTSTRAPCFLAGS=-DSCO5 2&gt;&amp;1 &verbar; tee world.log</Literal>.
 This will do a full build, and send all of the build results to the
 file <Literal remap="tt">world.log</Literal>.
-    
+
 </Para>
 </ListItem>
 <ListItem>
@@ -194,11 +194,11 @@ in the R5 distribution.
 
 <Para>
 To use a Bus/Keyboard or PS2 mouse you should configure the mouse drivers
-using '<Literal remap="tt">mkdev mouse</Literal>'.  You may then use the 
+using '<Literal remap="tt">mkdev mouse</Literal>'.  You may then use the
 <Literal remap="tt">OsMouse</Literal> option in your <Literal remap="tt">xorg.conf</Literal> to specify that X
 should use the SCO mouse drivers.  To do this, set the <Literal remap="tt">Protocol</Literal> to
 "<Literal remap="tt">OsMouse</Literal>" in the <Literal remap="tt">Pointer</Literal> section of your
-<Literal remap="tt">xorg.conf</Literal> file.  You can also use "<Literal remap="tt">OsMouse</Literal>" for your 
+<Literal remap="tt">xorg.conf</Literal> file.  You can also use "<Literal remap="tt">OsMouse</Literal>" for your
 serial mouse, especially if you are having trouble getting your mouse to
 work using the X mouse drivers.
 </Para>
@@ -235,9 +235,9 @@ applications to terminate in an unpredictable way.  You can set the
 
 <Para>
 After compiling the tree, or after installing the binary distribution you
-can get <Literal remap="tt">man</Literal> to recognise the Xorg man pages by adding 
+can get <Literal remap="tt">man</Literal> to recognise the Xorg man pages by adding
 <Literal remap="tt">/usr/X11R6/man</Literal> to
-the <Literal remap="tt">MANPATH</Literal> in <Literal remap="tt">/etc/default/man</Literal>. The line should 
+the <Literal remap="tt">MANPATH</Literal> in <Literal remap="tt">/etc/default/man</Literal>. The line should
 look similar to:
 
 <Screen>
diff --git a/sgml/security/XACE-Spec.sgml b/sgml/security/XACE-Spec.sgml
index f47f596..663c59b 100644
--- a/sgml/security/XACE-Spec.sgml
+++ b/sgml/security/XACE-Spec.sgml
@@ -113,7 +113,7 @@
 	</itemizedlist>
       </section>
     </section>
-      
+
     <section>
       <title>Future Work</title>
       <section id="future_hooks">
@@ -140,7 +140,7 @@
 
     <section>
       <title>Using Hooks</title>
-      
+
       <section>
 	<title>Overview</title>
 	<para>XACE has two header files that security extension code may need to include.  Include <filename>Xext/xacestr.h</filename> if you need the structure definitions for the XACE hooks in your source file.  Otherwise, include <filename>Xext/xace.h</filename>, which contains everything else including constants and function declarations.</para>
@@ -291,8 +291,8 @@
 
 	<section id="core_dispatch_hook">
 	  <title>Core Dispatch</title>
-	  <para>This hook allows security extensions to examine all incoming core protocol requests before they are dispatched.  The hook argument is a pointer to a structure of type <type>XaceCoreDispatchRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type> 
+	  <para>This hook allows security extensions to examine all incoming core protocol requests before they are dispatched.  The hook argument is a pointer to a structure of type <type>XaceCoreDispatchRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client making the incoming request.  Note that the complete request is accessible via the <structfield>requestBuffer</structfield> member of the client structure.  The <function>REQUEST</function> family of macros, located in <filename>include/dix.h</filename>, are useful in verifying and reading from this member.</para>
 	  <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code.  In this event, the request will not be processed further and the error code will be returned to the client.</para>
@@ -300,10 +300,10 @@
 
 	<section id="ext_dispatch_hook">
 	  <title>Extension Dispatch</title>
-	  <para>This hook allows security extensions to examine all incoming extension protocol requests before they are dispatched.  The hook argument is a pointer to a structure of type <type>XaceExtAccessRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>ext</structfield> field of type <type>ExtensionEntry*</type>, 
-	  a <structfield>access_mode</structfield> field of type <type>Mask</type>, 
+	  <para>This hook allows security extensions to examine all incoming extension protocol requests before they are dispatched.  The hook argument is a pointer to a structure of type <type>XaceExtAccessRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>ext</structfield> field of type <type>ExtensionEntry*</type>,
+	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client making the incoming request.  Note that the complete request is accessible via the <structfield>requestBuffer</structfield> member of the client structure.  The <function>REQUEST</function> family of macros, located in <filename>include/dix.h</filename>, are useful in verifying and reading from this member.</para>
 	  <para>The <structfield>ext</structfield> field refers to the extension being accessed.  This is required information since extensions are not associated with any particular major number.</para>
@@ -313,13 +313,13 @@
 
 	<section id="resource_access_hook">
 	  <title>Resource Access</title>
-	  <para>This hook allows security extensions to monitor all resource lookups.  The hook argument is a pointer to a structure of type <type>XaceResourceAccessRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>id</structfield> field of type <type>XID</type>, 
-	  a <structfield>rtype</structfield> field of type <type>RESTYPE</type>, 
-	  a <structfield>res</structfield> field of type <type>pointer</type>, 
-	  a <structfield>ptype</structfield> field of type <type>RESTYPE</type>, 
-	  a <structfield>parent</structfield> field of type <type>pointer</type>, 
+	  <para>This hook allows security extensions to monitor all resource lookups.  The hook argument is a pointer to a structure of type <type>XaceResourceAccessRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>id</structfield> field of type <type>XID</type>,
+	  a <structfield>rtype</structfield> field of type <type>RESTYPE</type>,
+	  a <structfield>res</structfield> field of type <type>pointer</type>,
+	  a <structfield>ptype</structfield> field of type <type>RESTYPE</type>,
+	  a <structfield>parent</structfield> field of type <type>pointer</type>,
 	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client on whose behalf the lookup is being performed.  Note that this may be <varname>serverClient</varname> for server lookups.</para>
@@ -488,9 +488,9 @@
 
 	<section id="device_access_hook">
 	  <title>Device Access</title>
-	  <para>This hook allows security extensions to restrict client actions on input devices.  The hook argument is a pointer to a structure of type <type>XaceDeviceAccessRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>dev</structfield> field of type <type>DeviceIntPtr</type>, 
+	  <para>This hook allows security extensions to restrict client actions on input devices.  The hook argument is a pointer to a structure of type <type>XaceDeviceAccessRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>dev</structfield> field of type <type>DeviceIntPtr</type>,
 	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client attempting to access the device (keyboard).  Note that this may be <varname>serverClient</varname>.</para>
@@ -610,9 +610,9 @@
 
 	<section id="property_access_hook">
 	  <title>Property Access</title>
-	  <para>This hook allows security extensions to monitor all property accesses and additionally to support polyinstantiation if desired.  The hook argument is a pointer to a structure of type <type>XacePropertyAccessRec</type>.  This structure contains a 
-	    <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>, 
+	  <para>This hook allows security extensions to monitor all property accesses and additionally to support polyinstantiation if desired.  The hook argument is a pointer to a structure of type <type>XacePropertyAccessRec</type>.  This structure contains a
+	    <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>,
 	    a <structfield>ppProp</structfield> field of type <type>PropertyPtr*</type>,
 	    a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
@@ -685,12 +685,12 @@
 
 	<section id="send_access_hook">
 	  <title>Send Access</title>
-	  <para>This hook allows security extensions to prevent devices and clients from posting X events to a given window.  The hook argument is a pointer to a structure of type <type>XaceSendAccessRec</type>.  This structure contains 
-	    a <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	    a <structfield>dev</structfield> field of type <type>DeviceIntPtr</type>, 
-	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>, 
+	  <para>This hook allows security extensions to prevent devices and clients from posting X events to a given window.  The hook argument is a pointer to a structure of type <type>XaceSendAccessRec</type>.  This structure contains
+	    a <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	    a <structfield>dev</structfield> field of type <type>DeviceIntPtr</type>,
+	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>,
 	    a <structfield>events</structfield> field of type <type>events</type>,
-	    a <structfield>count</structfield> field of type <type>int</type>, 
+	    a <structfield>count</structfield> field of type <type>int</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client attempting a <literal>SendEvent</literal> request or other synthetic event generation to the given window.  This field may be NULL if the <structfield>dev</structfield> field is set.</para>
 	  <para>The <structfield>dev</structfield> field refers to the device attempting to post an event which would be delivered to the given window.  This field may be NULL if the <structfield>client</structfield> field is set.</para>
@@ -704,10 +704,10 @@
 	<section id="receive_access_hook">
 	  <title>Receive Access</title>
 	  <para>This hook allows security extensions to prevent a client from receiving X events that have been delivered to a given window.  The hook argument is a pointer to a structure of type <type>XaceReceiveAccessRec</type>.  This structure contains
-	    a <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>, 
+	    a <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	    a <structfield>pWin</structfield> field of type <type>WindowPtr</type>,
 	    a <structfield>events</structfield> field of type <type>events</type>,
-	    a <structfield>count</structfield> field of type <type>int</type>, 
+	    a <structfield>count</structfield> field of type <type>int</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client to which the event would be delivered.</para>
 	  <para>The <structfield>pWin</structfield> field refers to the window where the event has been sent.</para>
@@ -719,10 +719,10 @@
 
 	<section id="client_access_hook">
 	  <title>Client Access</title>
-	  <para>This hook allows security extensions to prevent clients from manipulating other clients directly.  This hook applies to a small set of protocol requests such as <literal>KillClient</literal>.  The hook argument is a pointer to a structure of type <type>XaceClientAccessRec</type>.  This structure contains 
-	  a <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>target</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>access_mode</structfield> field of type <type>Mask</type>, 
+	  <para>This hook allows security extensions to prevent clients from manipulating other clients directly.  This hook applies to a small set of protocol requests such as <literal>KillClient</literal>.  The hook argument is a pointer to a structure of type <type>XaceClientAccessRec</type>.  This structure contains
+	  a <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>target</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client making the request.</para>
 	  <para>The <structfield>target</structfield> field refers to the client being manipulated.</para>
@@ -766,10 +766,10 @@
 
 	<section id="ext_access_hook">
 	  <title>Extension Access</title>
-	  <para>This hook allows security extensions to approve or deny requests involving which extensions are supported by the server.  This allows control over which extensions are visible.  The hook argument is a pointer to a structure of type <type>XaceExtAccessRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>ext</structfield> field of type <type>ExtensionEntry*</type>, 
-	  a <structfield>access_mode</structfield> field of type <type>Mask</type>, 
+	  <para>This hook allows security extensions to approve or deny requests involving which extensions are supported by the server.  This allows control over which extensions are visible.  The hook argument is a pointer to a structure of type <type>XaceExtAccessRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>ext</structfield> field of type <type>ExtensionEntry*</type>,
+	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client making the incoming request, which is typically <literal>QueryExtension</literal> or <literal>ListExtensions</literal>.</para>
 	  <para>The <structfield>ext</structfield> field refers to the extension being accessed.  This is required information since extensions are not associated with any particular major number.</para>
@@ -780,9 +780,9 @@
 
 	<section id="server_access_hook">
 	  <title>Server Access</title>
-	  <para>This hook allows security extensions to approve or deny requests that affect the X server itself.  The hook argument is a pointer to a structure of type <type>XaceServerAccessRec</type>, which contains 
-	  a <structfield>client</structfield> field of type <type>ClientPtr</type>, 
-	  a <structfield>access_mode</structfield> field of type <type>Mask</type>, 
+	  <para>This hook allows security extensions to approve or deny requests that affect the X server itself.  The hook argument is a pointer to a structure of type <type>XaceServerAccessRec</type>, which contains
+	  a <structfield>client</structfield> field of type <type>ClientPtr</type>,
+	  a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	  and a <structfield>status</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the client making the request.</para>
 	  <para>The <structfield>access_mode</structfield> field encodes the type of action being performed.  The valid mode bits are described in the table below.</para>
@@ -835,8 +835,8 @@
 
 	<section id="selection_access_hook">
 	  <title>Selection Access</title>
-	  <para>This hook allows security extensions to monitor all selection accesses and additionally to support polyinstantiation if desired.  The hook argument is a pointer to a structure of type <type>XaceSelectionAccessRec</type>.  This structure contains a 
-	    <structfield>client</structfield> field of type <type>ClientPtr</type>, 
+	  <para>This hook allows security extensions to monitor all selection accesses and additionally to support polyinstantiation if desired.  The hook argument is a pointer to a structure of type <type>XaceSelectionAccessRec</type>.  This structure contains a
+	    <structfield>client</structfield> field of type <type>ClientPtr</type>,
 	    a <structfield>ppSel</structfield> field of type <type>Selection**</type>,
 	    a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
@@ -890,8 +890,8 @@
 
 	<section id="screen_access_hook">
 	  <title>Screen Access</title>
-	  <para>This hook allows security extensions to approve or deny requests that manipulate screen objects  The hook argument is a pointer to a structure of type <type>XaceScreenAccessRec</type>.  This structure contains a 
-	    <structfield>client</structfield> field of type <type>ClientPtr</type>, 
+	  <para>This hook allows security extensions to approve or deny requests that manipulate screen objects  The hook argument is a pointer to a structure of type <type>XaceScreenAccessRec</type>.  This structure contains a
+	    <structfield>client</structfield> field of type <type>ClientPtr</type>,
 	    a <structfield>screen</structfield> field of type <type>ScreenPtr</type>,
 	    a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
@@ -937,8 +937,8 @@
 
 	<section id="screensaver_access_hook">
 	  <title>Screen Saver Access</title>
-	  <para>This hook allows security extensions to approve or deny requests that manipulate the screensaver.   The hook argument is a pointer to a structure of type <type>XaceScreenAccessRec</type>.  This structure contains a 
-	    <structfield>client</structfield> field of type <type>ClientPtr</type>, 
+	  <para>This hook allows security extensions to approve or deny requests that manipulate the screensaver.   The hook argument is a pointer to a structure of type <type>XaceScreenAccessRec</type>.  This structure contains a
+	    <structfield>client</structfield> field of type <type>ClientPtr</type>,
 	    a <structfield>screen</structfield> field of type <type>ScreenPtr</type>,
 	    a <structfield>access_mode</structfield> field of type <type>Mask</type>,
 	    and a <structfield>status</structfield> field of type <type>int</type>.</para>
@@ -984,8 +984,8 @@
 
 	<section id="auth_avail_hook">
 	  <title>Authorization Availability Hook</title>
-	  <para>This hook allows security extensions to examine the authorization associated with a newly connected client.  This can be used to set up client security state depending on the authorization method that was used.  The hook argument is a pointer to a structure of type <type>XaceAuthAvailRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
+	  <para>This hook allows security extensions to examine the authorization associated with a newly connected client.  This can be used to set up client security state depending on the authorization method that was used.  The hook argument is a pointer to a structure of type <type>XaceAuthAvailRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
 	  and a <structfield>authId</structfield> field of type <type>XID</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to the newly connected client.</para>
 	  <para>The <structfield>authId</structfield> field is the resource ID of the client's authorization.</para>
@@ -995,11 +995,11 @@
 	    <para>This hook is a legacy of the APPGROUP Extension.  In the future, this hook may be phased out in favor of a new client state, <literal>ClientStateAuthenticated</literal>.</para>
 	  </note>
 	</section>
- 
+
 	<section id="key_avail_hook">
 	  <title>Keypress Availability Hook</title>
-	  <para>This hook allows security extensions to examine keypresses outside of the normal event mechanism.  This could be used to implement server-side hotkey support.  The hook argument is a pointer to a structure of type <type>XaceKeyAvailRec</type>.  This structure contains a 
-	  <structfield>event</structfield> field of type <type>xEventPtr</type>, 
+	  <para>This hook allows security extensions to examine keypresses outside of the normal event mechanism.  This could be used to implement server-side hotkey support.  The hook argument is a pointer to a structure of type <type>XaceKeyAvailRec</type>.  This structure contains a
+	  <structfield>event</structfield> field of type <type>xEventPtr</type>,
 	  a <structfield>keybd</structfield> field of type <type>DeviceIntPtr</type>,
 	  and a <structfield>count</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>event</structfield> field refers to the keyboard event, typically a <literal>KeyPress</literal> or <literal>KeyRelease</literal>.</para>
@@ -1007,21 +1007,21 @@
 	  <para>The <structfield>count</structfield> field is the number of repetitions of the event (not 100\% sure of this at present, however).</para>
 	  <para>This hook has no return value.</para>
 	</section>
- 
+
 	<section id="audit_avail_hook">
 	  <title>Auditing Hooks</title>
-	  <para>Two hooks provide basic auditing support.  The begin hook is called immediately before an incoming client request is dispatched and before the dispatch hook is called (refer to <xref linkend="core_dispatch_hook"/>).  The end hook is called immedately after the processing of the request has finished.  The hook argument is a pointer to a structure of type <type>XaceKeyAvailRec</type>.  This structure contains a 
-	  <structfield>client</structfield> field of type <type>ClientPtr</type>, 
+	  <para>Two hooks provide basic auditing support.  The begin hook is called immediately before an incoming client request is dispatched and before the dispatch hook is called (refer to <xref linkend="core_dispatch_hook"/>).  The end hook is called immedately after the processing of the request has finished.  The hook argument is a pointer to a structure of type <type>XaceKeyAvailRec</type>.  This structure contains a
+	  <structfield>client</structfield> field of type <type>ClientPtr</type>,
 	  and a <structfield>requestResult</structfield> field of type <type>int</type>.</para>
 	  <para>The <structfield>client</structfield> field refers to client making the request.</para>
 	  <para>The <structfield>requestResult</structfield> field contains the result of the request, either <literal>Success</literal> or one of the protocol error codes.  Note that this field is significant only in the end hook.</para>
 	  <para>These hooks have no return value.</para>
 	</section>
- 
+
      </section>
     </section>
   </section>
-  
+
   <section>
     <title>Protocol</title>
     <section>