Import manual pages from xorg-docs package

10 files changed, 3572 insertions, 0 deletions

diff --git a/doc/xorg-docs/man/Makefile.am b/doc/xorg-docs/man/Makefile.am
new file mode 100644
index 000000000..68eda4914
--- /dev/null
+++ b/doc/xorg-docs/man/Makefile.am
@@ -0,0 +1,23 @@
+#  Copyright 2005 Red Hat, Inc.
+# 
+#  Permission to use, copy, modify, distribute, and sell this software
+#  and its documentation for any purpose is hereby granted without fee,
+#  provided that the above copyright notice appear in all copies and
+#  that both that copyright notice and this permission notice appear in
+#  supporting documentation, and that the name of Red Hat not be used in
+#  advertising or publicity pertaining to distribution of the software
+#  without specific, written prior permission.  Red Hat makes no
+#  representations about the suitability of this software for any
+#  purpose.  It is provided "as is" without express or implied warranty.
+# 
+#  RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+#  INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
+#  NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+#  CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+#  OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+#  OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE
+#  USE OR PERFORMANCE OF THIS SOFTWARE.
+#
+#  Process this file with autoconf to create configure.
+
+SUBDIRS = general
diff --git a/doc/xorg-docs/man/general/Consortium.man b/doc/xorg-docs/man/general/Consortium.man
new file mode 100644
index 000000000..b7080199c
--- /dev/null
+++ b/doc/xorg-docs/man/general/Consortium.man
@@ -0,0 +1,238 @@
+.\" $TOG: Consortium.cpp /main/71 1997/10/13 14:55:16 kaleb $
+.\" Copyright (c) 1993, 1994, 1996  X Consortium
+.\" 
+.\" Permission is hereby granted, free of charge, to any person obtaining a
+.\" copy of this software and associated documentation files (the "Software"), 
+.\" to deal in the Software without restriction, including without limitation 
+.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 
+.\" and/or sell copies of the Software, and to permit persons to whom the 
+.\" Software furnished to do so, subject to the following conditions:
+.\" 
+.\" The above copyright notice and this permission notice shall be included in
+.\" all copies or substantial portions of the Software.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+.\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
+.\" THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
+.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 
+.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
+.\" SOFTWARE.
+.\" 
+.\" Except as contained in this notice, the name of the X Consortium shall not 
+.\" be used in advertising or otherwise to promote the sale, use or other 
+.\" dealing in this Software without prior written authorization from the 
+.\" X Consortium.
+.\"
+.\" $XFree86$
+.\"
+.TH XCONSORTIUM __miscmansuffix__ __xorgversion__
+.SH NAME
+XConsortium \- X Consortium information
+.SH SYNOPSIS
+Release 6.3 of X Version 11 was brought to you by X Consortium, Inc.
+.SH DESCRIPTION
+The X Consortium was an independent, not-for-profit Delaware membership
+corporation.  It was formed in 1993 as the successor to the MIT X Consortium.
+The purpose of the X Consortium was to foster the development, evolution, and
+maintenance of the X Window System, a comprehensive set of vendor-neutral,
+system-architecture neutral, network-transparent windowing and user interface
+standards.
+.PP
+The X Window System was created in the mid-1980s at the Massachusetts
+Institute of Technology.  In 1988, MIT formed a member-funded consortium to
+provide the technical and administrative leadership necessary to support
+further development of the X Window System.  In 1992, MIT and the membership
+decided it was in their best interests to move the consortium out of MIT and
+create an independent, stand-alone organization.  All rights to the
+X Window System were assigned by MIT to X Consortium, Inc. on January 1, 1994.
+X Consortium, Inc. closed its doors on December 31, 1996.  All rights to the
+X Window System have been assigned to the Open Software Foundation.
+.PP
+The X Consortium was financially self-supporting through membership fees.
+There are no license fees associated with the use of X Window System standards
+and code developed by the X Consortium.  Membership in the X Consortium was
+open to any organization willing to execute a membership agreement.
+.PP
+The X Consortium was a highly participative body.  Members were encouraged to
+actively cooperate with the staff and other members in the design and review
+of proposed specifications, and in the design, coding and testing of sample
+implementations of those specifications.
+.PP
+The X Consortium accomplished most of its work using electronic mail over the
+Internet, with individual mailing lists for working groups.  Internet
+electronic mail connectivity was viewed as a requirement for useful
+participation in X Consortium activities.  Meetings were held as necessary,
+often in conjunction with industry conferences and trade shows.
+.SH STAFF
+.nf
+President:
+Bob Scheifler
+
+Office Manager:
+Janet O'Halloran
+
+Director of Marketing:
+Paul Lavallee
+
+Director of Engineering:
+Jim Fournier
+
+Manager, X Window System:
+Matt Landau, emeritus
+
+Technical Director, X Window System:
+Ralph Swick
+
+Technical Staff, X Window System:
+
+Donna Converse, emeritus
+Stephen Gildea, emeritus
+Kaleb Keithley
+Arnaud Le Hors
+Ralph Mor, emeritus
+Ray Tice
+Dave Wiggins, emeritus
+
+Managers, CDE Development:
+Giora Guth
+Peter Bohnert, emeritus
+
+Manager, CDE Quality Engineering:
+David Brooks
+
+CDE Architects:
+Kevin Samborn
+Daniel Dardailler, emeritus
+
+Technical Staff, CDE Development:
+
+Art Barstow
+Pascale Dardailler
+David Kaelbling
+Mitch Greess
+Robert Seacord
+
+Technical Staff, CDE Quality Engineering:
+
+Chris Burleson
+Tom Cavin
+Sami Mohammed
+Mark Schuldenfrei
+
+Manager, Systems Administration:
+Kevin Ethier
+
+Technical Staff, Systems Administration:
+Mike Donati
+Amy Rich, emeritus
+Anne Salemme
+.fi
+
+.SH "BOARD OF DIRECTORS"
+The X Consortium's activities and affairs were managed under the direction and
+oversight of a Board of Directors, elected annually by the Members.  The Board
+was responsible for reviewing the achievements of the Consortium, approving
+planned work, appointing a President and other officers of the Consortium, and
+setting membership dues.  The last Directors were:
+
+.nf
+Robert W. Scheifler, President, X Consortium
+Dr. Forest Baskett, Senior VP of R&D, Silicon Graphics Computer Systems
+Harold D. Blair, Apogee International Corp.
+Roger S. Gourd, Gourd & Associates
+Dr. Robin Hillyard, Chairman and Chief Technical Officer, Novasoft Systems
+Don McGovern, General Operations Manager and Executive Dir., Hewlett Packard
+Peter J. Shaw, Senior VP, NetManage
+Michael Tobias, President, Tech-Source, Inc.
+.fi
+
+.SH "ADDRESS"
+To reach the X Consortium public Wide World Web server, use the URL:
+http://www.x.org/
+.PP
+To reach the X Consortium public ftp machine, use anonymous ftp to:
+ftp.x.org
+
+.SH "FULL MEMBERS"
+
+.nf
+Adobe Systems Inc.
+Cray Research, Inc.
+Digital Equipment Corp.
+Fujitsu Limited
+Hewlett-Packard Company
+Hitachi Ltd.
+IBM Corporation
+Megatek Corp.
+Motorola, Inc.
+NEC Corporation
+Novell, Inc.
+Oki Electric Industry Co., Ltd.
+OMRON Corporation
+SCO, Inc.
+Siemens Nixdorf Informationssysteme AG
+Silicon Graphics, Inc.
+Sony Corporation
+Sun Microsystems, Inc.
+Tektronix, Inc.
+.fi
+
+.SH "ASSOCIATE MEMBERS"
+
+.nf
+Boundless Technologies
+Hummingbird Communications Ltd.
+Insignia Solutions, Ltd.
+Mercury Interactive Corp.
+NetManage, Inc.
+Network Computing Devices
+VisiCom Laboratories, Inc.
+Walker Richer & Quinn, Inc.
+.fi
+
+.SH "END USERS"
+
+.nf
+Hughes Aircraft Company
+.fi
+
+.SH "AFFILIATE MEMBERS"
+
+.nf
+ASTEC, Inc.
+BARCO Chromatics, Inc.
+CenterLine Software, Inc.
+CliniComp, Intl.
+Component Integration Laboratories, Inc.
+Draper Laboratory.
+Electronic Book Technologies, Inc.
+Gallium Software, Inc.
+Georgia Institiute of Technology
+Human Designed Systems, Inc.
+INRIA \- Institut National de Recherche en Informatique et en Automatique
+Integrated Computer Solutions, Inc.
+Investment Management Services, Inc.
+Jupiter Systems
+KL Group Inc.
+Massachusetts Institute of Technology
+Metheus Corporation
+Metro Link, Inc.
+Object Management Group, Inc.
+Open Software Foundation
+Performance Awareness Corp.
+Peritek Corp.
+Petrotechnical Open Software Corp.
+Point Technologies, Inc.
+Shiman Associates, Inc.
+Smithsonian Astrophysical Observatory.
+Software Development Corp.
+SOUM Corporation
+Spectragraphics Corp.
+Tech-Source, Inc.
+TriTeal Corp.
+White Pine Software, Inc.
+World Wide Web Consortium.
+The XFree86 Project, Inc.
+X Inside, Inc.
+.fi
diff --git a/doc/xorg-docs/man/general/Makefile.am b/doc/xorg-docs/man/general/Makefile.am
new file mode 100644
index 000000000..35a65f870
--- /dev/null
+++ b/doc/xorg-docs/man/general/Makefile.am
@@ -0,0 +1,57 @@
+#  Copyright 2005 Red Hat, Inc.
+# 
+#  Permission to use, copy, modify, distribute, and sell this software
+#  and its documentation for any purpose is hereby granted without fee,
+#  provided that the above copyright notice appear in all copies and
+#  that both that copyright notice and this permission notice appear in
+#  supporting documentation, and that the name of Red Hat not be used in
+#  advertising or publicity pertaining to distribution of the software
+#  without specific, written prior permission.  Red Hat makes no
+#  representations about the suitability of this software for any
+#  purpose.  It is provided "as is" without express or implied warranty.
+# 
+#  RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+#  INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
+#  NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+#  CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+#  OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+#  OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE
+#  USE OR PERFORMANCE OF THIS SOFTWARE.
+#
+#  Process this file with autoconf to create configure.
+
+miscmandir = $(MISC_MAN_DIR)
+
+miscman_PRE = \
+	Consortium.man \
+	security.man \
+	Standards.man \
+	X.man \
+	XOrgFoundation.man \
+	Xprint.man \
+	XProjectTeam.man
+
+miscman_DATA = $(miscman_PRE:man=@MISC_MAN_SUFFIX@)
+
+CLEANFILES = $(miscman_DATA)
+
+SED = sed
+
+# Strings to replace in man pages
+XORGRELSTRING = @PACKAGE_STRING@
+  XORGMANNAME = X Version 11
+
+MAN_SUBSTS = \
+	-e 's|__vendorversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
+	-e 's|__xorgversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
+	-e 's|__projectroot__|$(prefix)|g' \
+	-e 's|__appmansuffix__|$(APP_MAN_SUFFIX)|g' \
+	-e 's|__libmansuffix__|$(APP_LIB_SUFFIX)|g' \
+	-e 's|__miscmansuffix__|$(MISC_MAN_SUFFIX)|g'
+
+SUFFIXES = .$(MISC_MAN_SUFFIX) .man
+
+.man.$(MISC_MAN_SUFFIX):
+	sed $(MAN_SUBSTS) < $< > $@
+
+EXTRA_DIST = $(miscman_PRE) Xprint.sgml
diff --git a/doc/xorg-docs/man/general/Standards.man b/doc/xorg-docs/man/general/Standards.man
new file mode 100644
index 000000000..d904efddb
--- /dev/null
+++ b/doc/xorg-docs/man/general/Standards.man
@@ -0,0 +1,435 @@
+.\" $Xorg: Standards.cpp,v 1.3 2000/08/17 19:42:04 cpqbld Exp $
+.\" $XdotOrg: xc/doc/man/general/Standards.man,v 1.3 2004/09/03 16:18:18 kem Exp $
+.\" Copyright (c) 1993, 1994, 1996, 2004 The Open Group
+.\"
+.\" All rights reserved.
+.\"
+.\" 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, and/or sell copies of the Software, and to permit persons
+.\" to whom the Software is furnished to do so, provided that the above
+.\" copyright notice(s) and this permission notice appear in all copies of
+.\" the Software and that both the above copyright notice(s) and this
+.\" permission notice appear in supporting documentation.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+.\" OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
+.\" HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
+.\" INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
+.\" FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+.\" NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
+.\" WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Except as contained in this notice, the name of a copyright holder
+.\" shall not be used in advertising or otherwise to promote the sale, use
+.\" or other dealings in this Software without prior written authorization
+.\" of the copyright holder.
+.\"
+.\" X Window System is a trademark of The Open Group.
+.\"
+.TH XSTANDARDS __miscmansuffix__ __xorgversion__
+.SH NAME
+XStandards \- X Window System Standards and Specifications
+.SH SYNOPSIS
+The major goal of the X Consortium was to promote cooperation within the
+computer industry in the creation of standard software interfaces at
+all layers in the X Window System environment.
+The X Consortium produced standards - documents which
+defined network protocols, programming interfaces, and
+other aspects of the X environment.  These standards
+continue to exist in the X.Org Foundation releases.
+The X.Org Foundation also produces specifications.
+Like X Window System Standards, these are documents
+which define network protocols, programming interfaces,
+and other aspects of the X environment.  Under the aegis
+of The Open Group, X Window System standards, X.Org Foundation
+specifications, and other specifications are the
+basis for portions of The Open Group's various CAE
+specifications.
+.PP
+The status of various standards, specifications, and
+the software in the X11R7.0 distribution, is explained below.
+.SH STANDARDS
+The following documents are X Window System standards:
+.nf
+
+X Window System Protocol
+X Version 11, Release 7.0
+Robert W. Scheifler
+
+Xlib \- C Language X Interface
+X Version 11, Release 7.0
+James Gettys, Robert W. Scheifler, Ron Newman
+
+X Toolkit Intrinsics \- C Language Interface
+X Version 11, Release 7.0
+Joel McCormack, Paul Asente, Ralph R. Swick, Donna Converse
+
+Bitmap Distribution Format
+Version 2.1
+X Version 11, Release 7.0
+
+Inter-Client Communication Conventions Manual
+Version 2.0
+X Version 11, Release 7.0
+David Rosenthal, Stuart W. Marks
+
+Compound Text Encoding
+Version 1.1
+X Version 11, Release 7.0
+Robert W. Scheifler
+
+X Logical Font Description Conventions
+Version 1.5
+X Version 11, Release 7.0
+Jim Flowers, Stephen Gildea
+
+X Display Manager Control Protocol
+Version 1.1
+X Version 11, Release 7.0
+Keith Packard
+
+X11 Nonrectangular Window Shape Extension
+Version 1.0.1
+X Version 11, Release 7.0
+Keith Packard
+
+X11 Input Extension Protocol Specification
+Version 1.0
+X Version 11, Release 7.0
+George Sachs, Mark Patrick
+
+X11 Input Extension Library Specification
+X Version 11, Release 7.0
+Mark Patrick, George Sachs
+
+The X Font Service Protocol
+Version 2.0
+X Version 11, Release 7.0
+Jim Fulton
+
+Inter-Client Exchange (ICE) Protocol
+Version 1.0
+X Version 11, Release 7.0
+Robert Scheifler, Jordan Brown
+
+Inter-Client Exchange (ICE) Library
+Version 1.0
+X Version 11, Release 7.0
+Ralph Mor
+
+X Session Management Protocol
+Version 1.0
+X Version 11, Release 7.0
+Mike Wexler
+
+X Session Management Library
+Version 1.0
+X Version 11, Release 7.0
+Ralph Mor
+
+The Input Method Protocol
+Version 1.0
+X Version 11, Release 7.0
+Masahiko Narita, Hideki Hiura
+
+X Synchronization Extension
+Version 3.0
+X Version 11, Release 7.0
+Tim Glauert, Dave Carver, Jim Gettys, David P. Wiggins
+
+XTEST Extension
+Version 2.2
+Kieron Drake
+
+Big Requests Extension
+Version 2.0
+X Version 11, Release 7.0
+Bob Scheifler
+
+XC-MISC Extension
+Version 1.1
+X Version 11, Release 7.0
+Bob Scheifler, Dave Wiggins
+
+Double Buffer Extension
+Version 1.0
+Ian Elliott, David P. Wiggins
+
+Record Extension Protocol
+Version 1.13
+Martha Zimet, Stephen Gildea
+
+Record Extension Library
+Version 1.13
+Martha Zimet, Stephen Gildea
+
+X Keyboard Extension Protocol
+X Version 11, Release 7.0
+Erik Fortune
+
+X Keyboard Extension Library
+X Version 11, Release 7.0
+Amber J. Benson, Gary Aitken, Erik Fortune, Donna Converse,
+George Sachs, and Will Walker
+
+X Print Extension Protocol
+X Version 11, Release 7.0
+
+X Print Extension Library
+X Version 11, Release 7.0
+
+X Application Group Extension Protocol and Library
+Version 1.0
+X Version 11, Release 7.0
+Kaleb Keithley
+
+X Security Extension Protocol and Library
+Version 4.0
+X Version 11, Release 7.0
+Dave Wiggins
+
+X Proxy Manager Protocol
+X Version 11, Release 7.0
+Ralph Swick
+
+LBX Extension Protocol and Library
+X Version 11, Release 7.0
+Keith Packard, Dave Lemke, Donna Converse, Ralph Mor, Ray Tice
+
+Remote Execution MIME Type
+Version 1.0
+X Version 11, Release 7.0
+Arnaud Le Hors
+.fi
+.SH SPECIFICATIONS
+The following documents are X Project Team specifications:
+.nf
+
+Colormap Utilization Policy and Extension
+Version 1.0
+Kaleb Keithley
+
+Extended Visual Information Extension
+Version 1.0
+Peter Daifuku
+
+X Display Power Management (DPMS) Extension Protocol and Library
+Version 1.0
+Rob Lembree
+
+.SH "INCLUDE FILES"
+The following include files are part of the Xlib standard.
+.PP
+.nf
+<X11/cursorfont.h>
+<X11/keysym.h>
+<X11/keysymdef.h>
+<X11/X.h>
+<X11/Xatom.h>
+<X11/Xcms.h>
+<X11/Xlib.h>
+<X11/Xlibint.h>
+<X11/Xproto.h>
+<X11/Xprotostr.h>
+<X11/Xresource.h>
+<X11/Xutil.h>
+<X11/X10.h>
+.fi
+.PP
+The following include files are part of the X Toolkit Intrinsics standard.
+.PP
+.nf
+<X11/Composite.h>
+<X11/CompositeP.h>
+<X11/Constraint.h>
+<X11/ConstrainP.h>
+<X11/Core.h>
+<X11/CoreP.h>
+<X11/Intrinsic.h>
+<X11/IntrinsicP.h>
+<X11/Object.h>
+<X11/ObjectP.h>
+<X11/RectObj.h>
+<X11/RectObjP.h>
+<X11/Shell.h>
+<X11/ShellP.h>
+<X11/StringDefs.h>
+<X11/Vendor.h>
+<X11/VendorP.h>
+.fi
+.PP
+The following include file is part of the
+Nonrectangular Window Shape Extension standard.
+.PP
+.nf
+<X11/extensions/shape.h>
+.fi
+.PP
+The following include files are part of the X Input Extension standard.
+.PP
+.nf
+<X11/extensions/XI.h>
+<X11/extensions/XInput.h>
+<X11/extensions/XIproto.h>
+.fi
+.PP
+The following include files are part of the ICElib standard.
+.PP
+.nf
+<X11/ICE/ICE.h>
+<X11/ICE/ICEconn.h>
+<X11/ICE/ICElib.h>
+<X11/ICE/ICEmsg.h>
+<X11/ICE/ICEproto.h>
+<X11/ICE/ICEutil.h>
+.fi
+.PP
+The following include files are part of the SMlib standard.
+.PP
+.nf
+<X11/SM/SM.h>
+<X11/SM/SMlib.h>
+<X11/SM/SMproto.h>
+.fi
+.PP
+The following include file is part of the Synchronization standard.
+.PP
+.nf
+<X11/extensions/sync.h>
+.fi
+.PP
+The following include file is part of the XTEST standard.
+.PP
+.nf
+<X11/extensions/XTest.h>
+.fi
+.PP
+The following include file is part of the Double Buffer Extension standard.
+.PP
+.nf
+<X11/extensions/Xdbe.h>
+.fi
+.PP
+The following include file is part of the Record Library standard.
+.PP
+.nf
+<X11/extensions/record.h>
+.fi
+.PP
+The following include files are part of the X Keyboard Extension Library
+standard.
+.PP
+.nf
+\" some subset of...
+<X11/XKBlib.h>
+<X11/extensions/XKB.h>
+<X11/extensions/XKBproto.h>
+<X11/extensions/XKBstr.h>
+<X11/extensions/XKBgeom.h>
+.fi
+.PP
+The following include files are part of the X Print Extension Library
+standard.
+.PP
+.nf
+<X11/extensions/Print.h>
+<X11/extensions/Printstr.h>
+.fi
+.PP
+The following include files are part of the X Application Group Extension
+Library standard.
+.PP
+.nf
+<X11/extensions/Xag.h>
+<X11/extensions/Xagstr.h>
+.fi
+.PP
+The following include files are part of the X Security Extension Library
+standard.
+.PP
+.nf
+<X11/extensions/security.h>
+<X11/extensions/securstr.h>
+.fi
+.PP
+The following include files are part of the LBX Extension library standard.
+.PP
+.nf
+\" some subset of...
+<X11/extensions/XLbx.h>
+<X11/extensions/lbxbuf.h>
+<X11/extensions/lbxbufstr.h>
+<X11/extensions/lbxdeltastr.h>
+<X11/extensions/lbximage.h>
+<X11/extensions/lbxopts.h>
+<X11/extensions/lbxstr.h>
+<X11/extensions/lbxzlib.h>
+.fi
+.PP
+The following include files are part of the Colormap Utilization
+Policy and Extension specification.
+.PP
+.nf
+<X11/extensions/Xcup.h>
+<X11/extensions/Xcupstr.h>
+.fi
+.PP
+The following include files are part of the Extended Visual
+Information specification.
+.PP
+.nf
+<X11/extensions/XEVI.h>
+<X11/extensions/XEVIstr.h>
+.fi
+.PP
+The following include files are part of the X Display Management
+Signaling Extension specification.
+.PP
+.nf
+<X11/extensions/dpms.h>
+<X11/extensions/dpmsstr.h>
+.fi
+
+.SH "NON STANDARDS"
+The X11R7.0 distribution contains \fIsample\fP implementations, not
+\fIreference\fP implementations.  Although much of the code is believed
+to be correct, the code should be assumed to be in error wherever it
+conflicts with the specification.
+.PP
+The only X Window System standards are the ones listed above.
+No other documents, include files, or software in X11R7.0 carry special
+status within the X Window System.  For example, none of the following
+are standards:
+internal interfaces of the sample server;
+the MIT-SHM extension;
+the Athena Widget Set;
+the Xmu library;
+the Xau library;
+the RGB database;
+the X Locale database;
+the fonts distributed with X11R7.0;
+the applications distributed with X11R7.0;
+the include files <X11/XWDFile.h>, <X11/Xfuncproto.h>, <X11/Xfuncs.h>,
+<X11/Xosdefs.h>, <X11/Xos.h>, <X11/Xos_r.h>, <X11/Xwinsock.h>, and
+<X11/Xthreads.h>;
+the bitmap files in <X11/bitmaps>.
+.PP
+The Multi-Buffering extension was a draft standard of the
+X Consortium but has been superseded by DBE as a standard.
+
+.SH "X REGISTRY"
+The X.Org Foundation maintains a registry of certain X-related items, to
+aid in avoiding conflicts and to aid in sharing of such items.
+.PP
+The registry is published as part of the X Window System software
+release.
+The latest version may also be found at
+.nf
+	ftp://ftp.x.org/pub/DOCS/registry
+.fi
+The X Registry and the names in it are not X Window System standards.
diff --git a/doc/xorg-docs/man/general/X.man b/doc/xorg-docs/man/general/X.man
new file mode 100644
index 000000000..128506b68
--- /dev/null
+++ b/doc/xorg-docs/man/general/X.man
@@ -0,0 +1,1334 @@
+.\" $Xorg: X.cpp,v 1.3 2000/08/17 19:42:04 cpqbld Exp $
+.\" $XdotOrg: xc/doc/man/general/X.man,v 1.6 2004/12/08 13:42:01 ago Exp $
+.\"
+.\" Copyright (c) 1994, 2004  The Open Group
+.\" Copyright \(co 2000  The XFree86 Project, Inc.
+.\" 
+.\" All rights reserved.
+.\"
+.\" 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, and/or sell copies of the Software, and to permit persons
+.\" to whom the Software is furnished to do so, provided that the above
+.\" copyright notice(s) and this permission notice appear in all copies of
+.\" the Software and that both the above copyright notice(s) and this
+.\" permission notice appear in supporting documentation.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+.\" OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
+.\" HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
+.\" INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
+.\" FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+.\" NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
+.\" WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Except as contained in this notice, the name of a copyright holder
+.\" shall not be used in advertising or otherwise to promote the sale, use
+.\" or other dealings in this Software without prior written authorization
+.\" of the copyright holder.
+.\"
+.\" X Window System is a trademark of The Open Group.
+.\"
+.\" $XFree86: xc/doc/man/general/X.man,v 1.7 2001/10/01 13:43:56 eich Exp $
+.\"
+.TH X __miscmansuffix__ __vendorversion__
+.SH NAME
+X \- a portable, network-transparent window system
+.SH SYNOPSIS
+.PP
+The X Window System is a network transparent window system which runs
+on a wide range of computing and graphics machines.  It should be
+relatively straightforward to build the X.Org Foundation software
+distribution on most ANSI C and POSIX compliant systems.  Commercial
+implementations are also available for a wide range of platforms.
+.PP
+The X.Org Foundation requests that the following names be used when
+referring to this software:
+.sp
+.ce 5
+X
+.br
+X Window System
+.br
+X Version 11
+.br
+X Window System, Version 11
+.br
+X11
+.PP
+.I "X Window System"
+is a trademark of The Open Group.
+.SH DESCRIPTION
+X Window System servers run on computers with bitmap displays.
+The server distributes user input to and accepts output requests from various
+client programs through a variety of different interprocess
+communication channels.  Although the most common case is for the client
+programs to be
+running on the same machine as the server, clients can be run transparently
+from other machines (including machines with different architectures and
+operating systems) as well.
+.PP
+X supports overlapping hierarchical subwindows and text and
+graphics operations, on both monochrome and color
+displays.
+For a full explanation of the functions that are available, see
+the \fIXlib - C Language X Interface\fP manual, 
+the \fIX Window System Protocol\fP specification,
+the \fIX Toolkit Intrinsics - C Language Interface\fP manual,
+and various toolkit documents.
+.PP
+The number of programs that use \fIX\fP is quite large.
+Programs provided in the core X.Org Foundation distribution include:
+a terminal emulator, \fIxterm\fP;
+a window manager, \fItwm\fP; 
+a display manager, \fIxdm\fP;
+a console redirect program, \fIxconsole\fP;
+a mail interface, \fIxmh\fP;
+a bitmap editor, \fIbitmap\fP;
+resource listing/manipulation tools, \fIappres\fP, \fIeditres\fP;
+access control programs, \fIxauth\fP, \fIxhost\fP, and \fIiceauth\fP;
+user preference setting programs, \fIxrdb\fP, \fIxcmsdb\fP,
+\fIxset\fP, \fIxsetroot\fP, \fIxstdcmap\fP, and \fIxmodmap\fP;
+clocks, \fIxclock\fP and \fIoclock\fP;
+a font displayer, (\fIxfd\fP;
+utilities for listing information about fonts, windows, and displays,
+\fIxlsfonts\fP, \fIxwininfo\fP, \fIxlsclients\fP,
+\fIxdpyinfo\fP, \fIxlsatoms\fP, and \fIxprop\fP;
+screen image manipulation utilities, \fIxwd\fP, \fIxwud\fP, and \fIxmag\fP;
+a performance measurement utility, \fIx11perf\fP;
+a font compiler, \fIbdftopcf\fP;
+a font server and related utilities, \fIxfs\fP, \fIfsinfo\fP, \fIfslsfonts\fP, \fIfstobdf\fP;
+a display server and related utilities, \fIXserver\fP, \fIrgb\fP, \fImkfontdir\fP;
+a print server and related utilities, \fIXprt\fP, \fIxplsprinters\fP, and \fIxprehashprinterlist\fP;
+remote execution utilities, \fIrstart\fP and \fIxon\fP;
+a clipboard manager, \fIxclipboard\fP;
+keyboard description compiler and related utilities, \fIxkbcomp\fP, \fIsetxkbmap\fP
+\fIxkbprint\fP, \fIxkbbell\fP, \fIxkbevd\fP, \fIxkbvleds\fP, and \fIxkbwatch\fP;
+a utility to terminate clients, \fIxkill\fP; 
+an optimized X protocol proxy, \fIlbxproxy\fP;
+a firewall security proxy, \fIxfwp\fP;
+a proxy manager to control them, \fIproxymngr\fP;
+a utility to find proxies, \fIxfindproxy\fP;
+web browser plug-ins, \fIlibxrx.so\fP and \fIlibxrxnest.so\fP;
+an RX MIME-type helper program, \fIxrx\fP;
+and a utility to cause part or all of the screen to be redrawn, \fIxrefresh\fP. 
+.PP
+Many other utilities, window managers, games, toolkits, etc. are included
+as user-contributed software in the X.Org Foundation distribution, or are
+available on the Internet.
+See your site administrator for details.
+.SH "STARTING UP"
+.PP 
+There are two main ways of getting the X server and an initial set of
+client applications started.  The particular method used depends on what
+operating system you are running and whether or not you use other window
+systems in addition to X.
+.TP 8
+.B "\fIxdm\fP (the X Display Manager)"
+If you want to always have X running on your display, your site administrator
+can set your machine up to use the X Display Manager \fIxdm\fP.  This program
+is typically started by the system at boot time and takes care of keeping the
+server running and getting users logged in.  If you are running
+\fIxdm\fP, you will see a window on the screen welcoming you to the system and
+asking for your username and password.  Simply type them in as you would at
+a normal terminal, pressing the Return key after each.  If you make a mistake,
+\fIxdm\fP will display an error message and ask you to try again.  After you
+have successfully logged in, \fIxdm\fP will start up your X environment.  By
+default, if you have an executable file named \fI.xsession\fP in your
+home directory,
+\fIxdm\fP will treat it as a program (or shell script) to run to start up 
+your initial clients (such as terminal emulators, clocks, a window manager,
+user settings for things like the background, the speed of the pointer, etc.).
+Your site administrator can provide details.
+.TP 8
+.B "\fIxinit\fP (run manually from the shell)"
+Sites that support more than one window system might choose to use the
+\fIxinit\fP program for starting X manually.  If this is true for your 
+machine, your site administrator will probably have provided a program 
+named "x11", "startx", or "xstart" that will do site-specific initialization
+(such as loading convenient default resources, running a window manager, 
+displaying a clock, and starting several terminal emulators) in a nice
+way.  If not, you can build such a script using the \fIxinit\fP program.
+This utility simply runs one user-specified program to start the server,
+runs another to start up any desired clients, and then waits for either to
+finish.  Since either or both of the user-specified programs may be a shell 
+script, this gives substantial flexibility at the expense of a
+nice interface.  For this reason, \fIxinit\fP is not intended for end users.
+.SH "DISPLAY NAMES"
+.PP
+From the user's perspective, every X server has a \fIdisplay name\fP of the
+form:
+.sp
+.ce 1
+\fIhostname:displaynumber.screennumber\fP
+.sp
+This information is used by the application to determine how it should
+connect to the server and which screen it should use by default
+(on displays with multiple monitors):
+.TP 8
+.I hostname
+The \fIhostname\fP specifies the name of the machine to which the display is
+physically connected.  If the hostname is not given, the most efficient way of 
+communicating to a server on the same machine will be used.
+.TP 8
+.I displaynumber
+The phrase "display" is usually used to refer to collection of monitors that
+share a common keyboard and pointer (mouse, tablet, etc.).  Most workstations
+tend to only have one keyboard, and therefore, only one display.  Larger, 
+multi-user
+systems, however, frequently have several displays so that more than
+one person can be doing graphics work at once.  To avoid confusion, each
+display on a machine is assigned a \fIdisplay number\fP (beginning at 0)
+when the X server for that display is started.  The display number must always
+be given in a display name.
+.TP 8
+.I screennumber
+Some displays share a single keyboard and pointer among two or more monitors.
+Since each monitor has its own set of windows, each screen is assigned a
+\fIscreen number\fP (beginning at 0) when the X server for that display is
+started.  If the screen number is not given, screen 0 will be used.
+.PP
+On POSIX systems, the default display name is stored 
+in your DISPLAY environment variable.  This variable is set automatically
+by the \fIxterm\fP terminal emulator.  However, when you log into another
+machine on a network, you will need to set DISPLAY by hand to point to your
+display.  For example,
+.sp
+.nf
+    % setenv DISPLAY myws:0
+    $ DISPLAY=myws:0; export DISPLAY
+.fi
+The \fIxon\fP script can be used to start an X program on a remote machine;
+it automatically sets the DISPLAY variable correctly.
+.PP
+Finally, most X programs accept a command line option of 
+\fB-display \fIdisplayname\fR to temporarily override the contents of
+DISPLAY.  This is most commonly used to pop windows on another person's
+screen or as part of a "remote shell" command to start an xterm pointing back 
+to your display.  For example,
+.sp
+.nf
+    % xeyes -display joesws:0 -geometry 1000x1000+0+0
+    % rsh big xterm -display myws:0 -ls </dev/null &
+.fi
+.PP
+X servers listen for connections on a variety of different 
+communications channels (network byte streams, shared memory, etc.).
+Since there can be more than one way of contacting a given server,
+The \fIhostname\fP part of the display name is used to determine the
+type of channel 
+(also called a transport layer) to be used.  X servers generally
+support the following types of connections:
+.TP 8
+.I "local"
+.br
+The hostname part of the display name should be the empty string.
+For example:  \fI:0\fP, \fI:1\fP, and \fI:0.1\fP.  The most efficient
+local transport will be chosen.
+.TP 8
+.I TCP\/IP
+.br
+The hostname part of the display name should be the server machine's
+IP address name.  Full Internet names, abbreviated names, and IP addresses
+are all allowed.  For example:  \fIx.org:0\fP, \fIexpo:0\fP,
+\fI198.112.45.11:0\fP, \fIbigmachine:1\fP, and \fIhydra:0.1\fP.
+.TP 8
+.I DECnet
+.br
+The hostname part of the display name should be the server machine's 
+nodename, followed by two colons instead of one.
+For example:  \fImyws::0\fP, \fIbig::1\fP, and \fIhydra::0.1\fP.
+.PP
+.SH "ACCESS CONTROL"
+An X server can use several types of access control.  Mechanisms provided
+in Release 6 are:
+.nf
+.br
+.ta 3.4i
+    Host Access	Simple host-based access control.
+    MIT-MAGIC-COOKIE-1	Shared plain-text "cookies".
+    XDM-AUTHORIZATION-1	Secure DES based private-keys.
+    SUN-DES-1	Based on Sun's secure rpc system.
+    MIT-KERBEROS-5	Kerberos Version 5 user-to-user.
+.fi
+.PP
+\fIXdm\fP initializes access control for the server and also places
+authorization information in a file accessible to the user.
+Normally, the list of hosts from
+which connections are always accepted should be empty, so that only clients
+with are explicitly authorized can connect to the display.  When you add
+entries to the host list (with \fIxhost\fP), the server no longer performs any
+authorization on connections from those machines.  Be careful with this.
+.PP
+The file from which \fIXlib\fP extracts authorization data can be
+specified with the environment variable \fBXAUTHORITY\fP, and defaults to
+the file \fB.Xauthority\fP in the home directory.  \fIXdm\fP uses
+\fB$HOME/.Xauthority\fP and will create it or merge in authorization records
+if it already exists when a user logs in.
+.PP
+If you use several machines and share a common home directory
+across all of the machines by means of a network file system,
+you never really have to worry about authorization files,
+the system should work correctly by default.
+Otherwise, as the authorization files are machine-independent,
+you can simply copy the files to share them.
+To manage authorization files, use \fIxauth\fP.
+This program allows you to extract
+records and insert them into other files.  Using this, you can send
+authorization to remote machines when you login,
+if the remote machine does not share a common home directory with
+your local machine.
+Note that authorization information transmitted
+``in the clear'' through a network file system or
+using \fIftp\fP or \fIrcp\fP can be ``stolen''
+by a network eavesdropper, and as such may enable unauthorized access.
+In many environments, this level of security is not a concern, but if it is,
+you need to know the exact semantics of the particular authorization
+data to know if this is actually a problem.
+.PP
+For more information on access control, see the \fIXsecurity\fP manual page.
+.SH "GEOMETRY SPECIFICATIONS"
+One of the advantages of using window systems instead of
+hardwired terminals is that 
+applications don't have to be restricted to a particular size or location
+on the screen.
+Although the layout of windows on a display is controlled
+by the window manager that the user is running (described below), 
+most X programs accept
+a command line argument of the form \fB-geometry \fIWIDTHxHEIGHT+XOFF+YOFF\fR
+(where \fIWIDTH\fP, \fIHEIGHT\fP, \fIXOFF\fP, and \fIYOFF\fP are numbers)
+for specifying a preferred size and location for this application's main
+window.
+.PP
+The \fIWIDTH\fP and \fIHEIGHT\fP parts of the geometry specification are
+usually measured in either pixels or characters, depending on the application.
+The \fIXOFF\fP and \fIYOFF\fP parts are measured in pixels and are used to
+specify the distance of the window from the left or right and top and bottom
+edges of the screen, respectively.  Both types of offsets are measured from the
+indicated edge of the screen to the corresponding edge of the window.  The X
+offset may be specified in the following ways:
+.TP 8
+.I +XOFF
+The left edge of the window is to be placed \fIXOFF\fP pixels in from the
+left edge of the screen (i.e., the X coordinate of the window's origin will be 
+\fIXOFF\fP).  \fIXOFF\fP may be negative, in which case the window's left edge 
+will be off the screen.
+.TP 8
+.I -XOFF
+The right edge of the window is to be placed \fIXOFF\fP pixels in from the
+right edge of the screen.  \fIXOFF\fP may be negative, in which case the 
+window's right edge will be off the screen.
+.PP
+The Y offset has similar meanings:
+.TP 8
+.I +YOFF
+The top edge of the window is to be \fIYOFF\fP pixels below the
+top edge of the screen (i.e., the Y coordinate of the window's origin will be
+\fIYOFF\fP).  \fIYOFF\fP may be negative, in which case the window's top edge 
+will be off the screen.
+.TP 8
+.I -YOFF
+The bottom edge of the window is to be \fIYOFF\fP pixels above the
+bottom edge of the screen.  \fIYOFF\fP may be negative, in which case 
+the window's bottom edge will be off the screen.
+.PP
+Offsets must be given as pairs; in other words, in order to specify either
+\fIXOFF\fP or \fIYOFF\fP both must be present.  Windows can be placed in the
+four corners of the screen using the following specifications:
+.TP 8
+.I +0+0
+upper left hand corner.
+.TP 8
+.I -0+0
+upper right hand corner.
+.TP 8
+.I -0-0
+lower right hand corner.
+.TP 8
+.I +0-0
+lower left hand corner.
+.PP
+In the following examples, a terminal emulator is placed in roughly
+the center of the screen and
+a load average monitor, mailbox, and clock are placed in the upper right 
+hand corner:
+.sp
+.nf
+    xterm -fn 6x10 -geometry 80x24+30+200 &
+    xclock -geometry 48x48-0+0 &
+    xload -geometry 48x48-96+0 &
+    xbiff -geometry 48x48-48+0 &
+.fi
+.PP
+.SH "WINDOW MANAGERS"
+The layout of windows on the screen is controlled by special programs called
+\fIwindow managers\fP.  Although many window managers will honor geometry
+specifications as given, others may choose to ignore them (requiring the user
+to explicitly draw the window's region on the screen with the pointer, for 
+example).
+.PP
+Since window managers are regular (albeit complex) client programs,
+a variety of different user interfaces can be built.  The X.Org Foundation distribution
+comes with a window manager named \fItwm\fP which supports overlapping windows,
+popup menus, point-and-click or click-to-type input models, title bars, nice
+icons (and an icon manager for those who don't like separate icon windows).
+.PP
+See the user-contributed software in the X.Org Foundation distribution for other
+popular window managers.
+.SH "FONT NAMES"
+Collections of characters for displaying text and symbols in X are known as
+\fIfonts\fP.  A font typically contains images that share a common appearance
+and look nice together (for example, a single size, boldness, slant, and
+character set).  Similarly, collections of fonts that are based on a common
+type face (the variations are usually called roman, bold, italic, bold italic, 
+oblique, and bold oblique) are called \fIfamilies\fP.  
+.PP
+Fonts come in various sizes.  The X server supports \fIscalable\fP fonts,
+meaning it is possible to create a font of arbitrary size from a single
+source for the font.  The server supports scaling from \fIoutline\fP
+fonts and \fIbitmap\fP fonts.  Scaling from outline fonts usually produces
+significantly better results than scaling from bitmap fonts.
+.PP
+An X server can obtain fonts from individual files stored in directories
+in the file system, or from one or more font servers,
+or from a mixtures of directories and font servers.
+The list of places the server looks when trying to find
+a font is controlled by its \fIfont path\fP.  Although most installations
+will choose to have the server start up with all of the commonly used font
+directories in the font path, the font path can be changed at any time
+with the \fIxset\fP program.
+However, it is important to remember that the directory names are
+on the \fBserver\fP's machine, not on the application's.
+.PP
+Bitmap font files are usually created by compiling a textual font description
+into binary form, using \fIbdftopcf\fP.
+Font databases are created by running the \fImkfontdir\fP program in the
+directory containing the source or compiled versions of the fonts.
+Whenever fonts are added to a directory, \fImkfontdir\fP should be rerun
+so that the server can find the new fonts.  To make the server reread the
+font database, reset the font path with the \fIxset\fP program.  For example,
+to add a font to a private directory, the following commands could be used:
+.sp
+.nf
+    % cp newfont.pcf ~/myfonts
+    % mkfontdir ~/myfonts
+    % xset fp rehash 
+.fi
+.PP
+The \fIxfontsel\fP and \fIxlsfonts\fP programs can be used to browse
+through the fonts available on a server.
+Font names tend to be fairly long as they contain all of the information
+needed to uniquely identify individual fonts.  However, the X server
+supports wildcarding of font names, so the full specification
+.sp
+.nf
+    \fI-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1\fP
+.fi
+.sp
+might be abbreviated as:
+.sp
+.nf
+    \fI-*-courier-medium-r-normal--*-100-*-*-*-*-iso8859-1\fP
+.fi
+.PP
+Because the shell also has special meanings for \fI*\fP and \fI?\fP,
+wildcarded font names should be quoted:
+.sp
+.nf
+    % xlsfonts -fn '-*-courier-medium-r-normal--*-100-*-*-*-*-*-*'
+.fi
+.PP
+The \fIxlsfonts\fP program can be used to list all of the fonts that
+match a given pattern.  With no arguments, it lists all available fonts.
+This will usually list the same font at many different sizes.  To see
+just the base scalable font names, try using one of the following patterns:
+.sp
+.nf
+    \fI-*-*-*-*-*-*-0-0-0-0-*-0-*-*\fP
+    \fI-*-*-*-*-*-*-0-0-75-75-*-0-*-*\fP
+    \fI-*-*-*-*-*-*-0-0-100-100-*-0-*-*\fP
+.fi
+.PP
+To convert one of the resulting names into a font at a specific size,
+replace one of the first two zeros with a nonzero value.
+The field containing the first zero is for the pixel size; replace it
+with a specific height in pixels to name a font at that size.
+Alternatively, the field containing the second zero is for the point size;
+replace it with a specific size in decipoints (there are 722.7 decipoints to
+the inch) to name a font at that size.
+The last zero is an average width field, measured in tenths of pixels;
+some servers will anamorphically scale if this value is specified.
+.SH "FONT SERVER NAMES"
+One of the following forms can be used to name a font server that
+accepts TCP connections:
+.sp
+.nf
+    tcp/\fIhostname\fP:\fIport\fP
+    tcp/\fIhostname\fP:\fIport\fP/\fIcataloguelist\fP
+.fi
+.PP
+The \fIhostname\fP specifies the name (or decimal numeric address)
+of the machine on which the font server is running.  The \fIport\fP
+is the decimal TCP port on which the font server is listening for connections.
+The \fIcataloguelist\fP specifies a list of catalogue names,
+with '+' as a separator.
+.PP
+Examples: \fItcp/x.org:7100\fP, \fItcp/198.112.45.11:7100/all\fP.
+.PP
+One of the following forms can be used to name a font server that
+accepts DECnet connections:
+.sp
+.nf
+    decnet/\fInodename\fP::font$\fIobjname\fP
+    decnet/\fInodename\fP::font$\fIobjname\fP/\fIcataloguelist\fP
+.fi
+.PP
+The \fInodename\fP specifies the name (or decimal numeric address)
+of the machine on which the font server is running.
+The \fIobjname\fP is a normal, case-insensitive DECnet object name.
+The \fIcataloguelist\fP specifies a list of catalogue names,
+with '+' as a separator.
+.PP
+Examples: \fIDECnet/SRVNOD::FONT$DEFAULT\fP, \fIdecnet/44.70::font$special/symbols\fP.
+.SH "COLOR NAMES"
+Most applications provide ways of tailoring (usually through resources or
+command line arguments) the colors of various elements
+in the text and graphics they display.
+A color can be specified either by an abstract color name,
+or by a numerical color specification.
+The numerical specification can identify a color in either
+device-dependent (RGB) or device-independent terms.
+Color strings are case-insensitive.
+.PP
+X supports the use of abstract color names, for example, "red", "blue".
+A value for this abstract name is obtained by searching one or more color
+name databases.
+\fIXlib\fP first searches zero or more client-side databases;
+the number, location, and content of these databases is
+implementation dependent.
+If the name is not found, the color is looked up in the
+X server's database.
+The text form of this database is commonly stored in the file
+\fI\__projectroot__/lib/X11/rgb.txt\fP.
+.PP
+A numerical color specification
+consists of a color space name and a set of values in the following syntax:
+.sp
+.nf
+    \fI<color_space_name>\fP:\fI<value>/.../<value>\fP
+.fi
+.PP
+An RGB Device specification is identified by
+the prefix "rgb:" and has the following syntax:
+.sp
+.nf
+    rgb:\fI<red>/<green>/<blue>\fP
+
+        \fI<red>\fP, \fI<green>\fP, \fI<blue>\fP := \fIh\fP | \fIhh\fP | \fIhhh\fP | \fIhhhh\fP
+        \fIh\fP := single hexadecimal digits
+.fi
+Note that \fIh\fP indicates the value scaled in 4 bits, 
+\fIhh\fP the value scaled in 8 bits,
+\fIhhh\fP the value scaled in 12 bits,
+and \fIhhhh\fP the value scaled in 16 bits, respectively.
+These values are passed directly to the X server,
+and are assumed to be gamma corrected.
+.PP
+The eight primary colors can be represented as:
+.sp
+.ta 2.5i
+.nf
+    black	rgb:0/0/0
+    red	rgb:ffff/0/0
+    green	rgb:0/ffff/0
+    blue	rgb:0/0/ffff
+    yellow	rgb:ffff/ffff/0
+    magenta	rgb:ffff/0/ffff
+    cyan	rgb:0/ffff/ffff
+    white	rgb:ffff/ffff/ffff
+.fi
+.PP
+For backward compatibility, an older syntax for RGB Device is
+supported, but its continued use is not encouraged.
+The syntax is an initial sharp sign character followed by
+a numeric specification, in one of the following formats:
+.sp
+.ta 3i
+.nf
+\&    #RGB	(4 bits each)
+\&    #RRGGBB	(8 bits each)
+\&    #RRRGGGBBB	(12 bits each)
+\&    #RRRRGGGGBBBB	(16 bits each)
+.fi
+.PP
+The R, G, and B represent single hexadecimal digits.
+When fewer than 16 bits each are specified, 
+they represent the most-significant bits of the value
+(unlike the "rgb:" syntax, in which values are scaled).
+For example, #3a7 is the same as #3000a0007000.
+.PP
+An RGB intensity specification is identified
+by the prefix "rgbi:" and has the following syntax:
+.sp
+.nf
+    rgbi:\fI<red>/<green>/<blue>\fP
+.fi
+.PP
+The red, green, and blue are floating point values
+between 0.0 and 1.0, inclusive.
+They represent linear intensity values, with
+1.0 indicating full intensity, 0.5 half intensity, and so on.
+These values will be gamma corrected by \fIXlib\fP
+before being sent to the X server.
+The input format for these values is an optional sign,
+a string of numbers possibly containing a decimal point,
+and an optional exponent field containing an E or e 
+followed by a possibly signed integer string.
+.PP
+The standard device-independent string specifications have
+the following syntax:
+.sp
+.ta 3.5i
+.nf
+    CIEXYZ:\fI<X>/<Y>/<Z>\fP	(\fInone\fP, 1, \fInone\fP)
+    CIEuvY:\fI<u>/<v>/<Y>\fP	(~.6, ~.6, 1)
+    CIExyY:\fI<x>/<y>/<Y>\fP	(~.75, ~.85, 1)
+    CIELab:\fI<L>/<a>/<b>\fP	(100, \fInone\fP, \fInone\fP)
+    CIELuv:\fI<L>/<u>/<v>\fP	(100, \fInone\fP, \fInone\fP)
+    TekHVC:\fI<H>/<V>/<C>\fP	(360, 100, 100)
+.fi
+.PP
+All of the values (C, H, V, X, Y, Z, a, b, u, v, y, x) are
+floating point values.  Some of the values are constrained to
+be between zero and some upper bound; the upper bounds are
+given in parentheses above.
+The syntax for these values is an optional '+' or '-' sign,
+a string of digits possibly containing a decimal point,
+and an optional exponent field consisting of an 'E' or 'e'
+followed by an optional '+' or '-' followed by a string of digits.
+.PP
+For more information on device independent color,
+see the \fIXlib\fP reference manual.
+.SH KEYBOARDS
+.PP
+The X keyboard model is broken into two layers:  server-specific codes
+(called \fIkeycodes\fP) which represent the physical keys, and 
+server-independent symbols (called \fIkeysyms\fP) which
+represent the letters or words that appear on the keys.  
+Two tables are kept in the server for converting keycodes to keysyms:
+.TP 8
+.I "modifier list"
+Some keys (such as Shift, Control, and Caps Lock) are known as \fImodifier\fP
+and are used to select different symbols that are attached to a single key
+(such as Shift-a generates a capital A, and Control-l generates a control
+character ^L).  The server keeps a list of keycodes corresponding to the
+various modifier keys.  Whenever a key is pressed or released, the server 
+generates an \fIevent\fP that contains the keycode of the indicated key as 
+well as a mask that specifies which of the modifier keys are currently pressed.
+Most servers set up this list to initially contain
+the various shift, control, and shift lock keys on the keyboard.  
+.TP 8
+.I "keymap table"
+Applications translate event keycodes and modifier masks into keysyms
+using a \fIkeysym table\fP which contains one row for each keycode and one
+column for various modifier states.  This table is initialized by the server
+to correspond to normal typewriter conventions.  The exact semantics of
+how the table is interpreted to produce keysyms depends on the particular
+program, libraries, and language input method used, but the following
+conventions for the first four keysyms in each row are generally adhered to:
+.PP
+The first four elements of the list are split into two groups of keysyms.
+Group 1 contains the first and second keysyms;
+Group 2 contains the third and fourth keysyms.
+Within each group,
+if the first element is alphabetic and the
+the second element is the special keysym \fINoSymbol\fP,
+then the group is treated as equivalent to a group in which
+the first element is the lowercase letter and the second element
+is the uppercase letter.
+.PP
+Switching between groups is controlled by the keysym named MODE SWITCH,
+by attaching that keysym to some key and attaching
+that key to any one of the modifiers Mod1 through Mod5.
+This modifier is called the ``group modifier.''
+Group 1 is used when the group modifier is off,
+and Group 2 is used when the group modifier is on.
+.PP
+Within a group,
+the modifier state determines which keysym to use.
+The first keysym is used when the Shift and Lock modifiers are off.
+The second keysym is used when the Shift modifier is on,
+when the Lock modifier is on and the second keysym is uppercase alphabetic,
+or when the Lock modifier is on and is interpreted as ShiftLock.
+Otherwise, when the Lock modifier is on and is interpreted as CapsLock,
+the state of the Shift modifier is applied first to select a keysym;
+but if that keysym is lowercase alphabetic,
+then the corresponding uppercase keysym is used instead.
+.SH OPTIONS
+Most X programs attempt to use the same names for command line options and
+arguments.  All applications written with the X Toolkit Intrinsics
+automatically accept the following options:
+.TP 8
+.B \-display \fIdisplay\fP
+This option specifies the name of the X server to use.
+.TP 8
+.B \-geometry \fIgeometry\fP
+This option specifies the initial size and location of the window.
+.TP 8
+.B \-bg \fIcolor\fP, \fB\-background \fIcolor\fP
+Either option specifies the color to use for the window background.
+.TP 8
+.B \-bd \fIcolor\fP, \fB\-bordercolor \fIcolor\fP
+Either option specifies the color to use for the window border.
+.TP 8
+.B \-bw \fInumber\fP, \fB\-borderwidth \fInumber\fP
+Either option specifies the width in pixels of the window border.
+.TP 8
+.B \-fg \fIcolor\fP, \fB\-foreground \fIcolor\fP
+Either option specifies the color to use for text or graphics.
+.TP 8
+.B \-fn \fIfont\fP, \fB-font \fIfont\fP
+Either option specifies the font to use for displaying text.
+.TP 8
+.B \-iconic
+.br
+This option indicates that the user would prefer that the application's
+windows initially not be visible as if the windows had be immediately 
+iconified by the user.  Window managers may choose not to honor the
+application's request.  
+.TP 8
+.B \-name
+.br
+This option specifies the name under which resources for the
+application should be found.  This option is useful in shell
+aliases to distinguish between invocations of an application,
+without resorting to creating links to alter the executable file name.
+.TP 8
+.B \-rv\fP, \fB\-reverse\fP
+Either option indicates that the program should simulate reverse video if 
+possible, often by swapping the foreground and background colors.  Not all
+programs honor this or implement it correctly.  It is usually only used on
+monochrome displays.
+.TP 8
+.B \+rv
+.br
+This option indicates that the program should not simulate reverse video.  
+This is used to
+override any defaults since reverse video doesn't always work properly.
+.TP 8
+.B \-selectionTimeout
+This option specifies the timeout in milliseconds within which two
+communicating applications must respond to one another for a selection
+request.
+.TP 8
+.B \-synchronous
+This option indicates that requests to the X server should be sent 
+synchronously, instead of asynchronously.  Since 
+.I Xlib
+normally buffers requests to the server, errors do not necessarily get reported
+immediately after they occur.  This option turns off the buffering so that
+the application can be debugged.  It should never be used with a working 
+program.
+.TP 8
+.B \-title \fIstring\fP
+This option specifies the title to be used for this window.  This information 
+is sometimes
+used by a window manager to provide some sort of header identifying the window.
+.TP 8
+.B \-xnllanguage \fIlanguage[_territory][.codeset]\fP
+This option specifies the language, territory, and codeset for use in
+resolving resource and other filenames.
+.TP 8
+.B \-xrm \fIresourcestring\fP
+This option specifies a resource name and value to override any defaults.  It 
+is also very useful for setting resources that don't have explicit command 
+line arguments.
+.SH RESOURCES
+To make the tailoring of applications to personal preferences easier, X 
+provides a mechanism for storing default values for program resources
+(e.g. background color, window title, etc.)
+Resources are specified as strings
+that are read in from various places when an application is run.
+Program components are named in a hierarchical fashion,
+with each node in the hierarchy identified by a class and an instance name.
+At the top level is the class and instance name of the application itself.
+By convention, the class name of the application is the same as the program
+name, but with  the first letter capitalized (e.g. \fIBitmap\fP or \fIEmacs\fP)
+although some programs that begin with the letter ``x'' also capitalize the
+second letter for historical reasons.
+.PP
+The precise syntax for resources is:
+.PP
+.nf
+.ta 1.8i 2.0i
+ResourceLine	=	Comment | IncludeFile | ResourceSpec | <empty line>
+Comment	=	"!" {<any character except null or newline>}
+IncludeFile	=	"#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
+FileName	=	<valid filename for operating system>
+ResourceSpec	=	WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
+ResourceName	=	[Binding] {Component Binding} ComponentName
+Binding	=	"\&." | "*"
+WhiteSpace	=	{<space> | <horizontal tab>}
+Component	=	"?" | ComponentName
+ComponentName	=	NameChar {NameChar}
+NameChar	=	"a"\-"z" | "A"\-"Z" | "0"\-"9" | "_" | "-"
+Value	=	{<any character except null or unescaped newline>}
+.fi
+.PP
+Elements separated by vertical bar (|) are alternatives.
+Curly braces ({\&.\&.\&.}) indicate zero or more repetitions
+of the enclosed elements.
+Square brackets ([\&.\&.\&.]) indicate that the enclosed element is optional.
+Quotes ("\&.\&.\&.") are used around literal characters.
+.PP
+IncludeFile lines are interpreted by replacing the line with the
+contents of the specified file.  The word "include" must be in lowercase.
+The filename is interpreted relative to the directory of the file in
+which the line occurs (for example, if the filename contains no
+directory or contains a relative directory specification).
+.PP
+If a ResourceName contains a contiguous sequence of two or more Binding
+characters, the sequence will be replaced with single "\&." character
+if the sequence contains only "\&." characters,
+otherwise the sequence will be replaced with a single "*" character.
+.PP
+A resource database never contains more than one entry for a given
+ResourceName.  If a resource file contains multiple lines with the
+same ResourceName, the last line in the file is used.
+.PP
+Any whitespace character before or after the name or colon in a ResourceSpec
+are ignored.
+To allow a Value to begin with whitespace,
+the two-character sequence ``\\\^\fIspace\fP'' (backslash followed by space)
+is recognized and replaced by a space character,
+and the two-character sequence ``\\\^\fItab\fP''
+(backslash followed by horizontal tab)
+is recognized and replaced by a horizontal tab character.
+To allow a Value to contain embedded newline characters,
+the two-character sequence ``\\\^n'' is recognized and replaced by a
+newline character.
+To allow a Value to be broken across multiple lines in a text file,
+the two-character sequence ``\\\^\fInewline\fP''
+(backslash followed by newline) is
+recognized and removed from the value.
+To allow a Value to contain arbitrary character codes,
+the four-character sequence ``\\\^\fInnn\fP'',
+where each \fIn\fP is a digit character in the range of ``0''\-``7'',
+is recognized and replaced with a single byte that contains
+the octal value specified by the sequence.
+Finally, the two-character sequence ``\\\\'' is recognized
+and replaced with a single backslash.
+.PP
+When an application looks for the value of a resource, it specifies
+a complete path in the hierarchy, with both class and instance names.
+However, resource values are usually given with only partially specified
+names and classes, using pattern matching constructs.
+An asterisk (*) is a loose binding and is used to represent any number
+of intervening components, including none.
+A period (.) is a tight binding and is used to separate immediately
+adjacent components.
+A question mark (?) is used to match any single component name or class.
+A database entry cannot end in a loose binding;
+the final component (which cannot be "?") must be specified.
+The lookup algorithm searches the resource database for the entry that most
+closely matches (is most specific for) the full name and class being queried.
+When more than one database entry matches the full name and class,
+precedence rules are used to select just one.
+.LP
+The full name and class are scanned from left to right (from highest
+level in the hierarchy to lowest), one component at a time.
+At each level, the corresponding component and/or binding of each
+matching entry is determined, and these matching components and
+bindings are compared according to precedence rules.
+Each of the rules is applied at each level,
+before moving to the next level,
+until a rule selects a single entry over all others.
+The rules (in order of precedence) are:
+.IP 1. 5
+An entry that contains a matching component (whether name, class, or "?")
+takes precedence over entries that elide the level (that is, entries
+that match the level in a loose binding).
+.IP 2. 5
+An entry with a matching name takes precedence over both
+entries with a matching class and entries that match using "?".
+An entry with a matching class takes precedence over
+entries that match using "?".
+.IP 3. 5
+An entry preceded by a tight binding takes precedence over entries
+preceded by a loose binding.
+.PP
+Programs based on the X Tookit Intrinsics
+obtain resources from the following sources
+(other programs usually support some subset of these sources):
+.TP 8
+.B "RESOURCE_MANAGER root window property"
+Any global resources that should be available to clients on all machines 
+should be stored in the RESOURCE_MANAGER property on the
+root window of the first screen using the \fIxrdb\fP program.
+This is frequently taken care
+of when the user starts up X through the display manager or \fIxinit\fP.
+.TP 8
+.B "SCREEN_RESOURCES root window property"
+Any resources specific to a given screen (e.g. colors)
+that should be available to clients on all machines 
+should be stored in the SCREEN_RESOURCES property on the
+root window of that screen.
+The \fIxrdb\fP program will sort resources automatically and place them
+in RESOURCE_MANAGER or SCREEN_RESOURCES, as appropriate.
+.TP 8
+.B "application-specific files"
+Directories named by the environment variable XUSERFILESEARCHPATH
+or the environment variable XAPPLRESDIR (which names a single
+directory and should end with a '/' on POSIX systems), plus directories in a
+standard place (usually under __projectroot__/lib/X11/,
+but this can be overridden with the XFILESEARCHPATH environment variable)
+are searched for for application-specific resources.
+For example, application default resources are usually kept in
+__projectroot__/lib/X11/app-defaults/.
+See the \fIX Toolkit Intrinsics - C Language Interface\fP manual for
+details.
+.TP 8
+.B XENVIRONMENT
+Any user- and machine-specific resources may be specified by setting
+the XENVIRONMENT environment variable to the name of a resource file
+to be loaded by all applications.  If this variable is not defined,
+a file named \fI$HOME\fP/.Xdefaults-\fIhostname\fP is looked for instead,
+where \fIhostname\fP is the name of the host where the application
+is executing.
+.TP 8
+.B \-xrm \fIresourcestring\fP
+Resources can also be specified from the 
+command line.  The \fIresourcestring\fP is a single resource name and value as
+shown above.  Note that if the string contains characters interpreted by
+the shell (e.g., asterisk), they must be quoted.
+Any number of \fB\-xrm\fP arguments may be given on the
+command line.
+.PP
+Program resources are organized into groups called \fIclasses\fP, so that 
+collections of individual resources (each of which are 
+called \fIinstances\fP)
+can be set all at once.  By convention, the instance name of a resource
+begins with a lowercase letter and class name with an upper case letter.
+Multiple word resources are concatenated with the first letter of the 
+succeeding words capitalized.  Applications written with the X Toolkit
+Intrinsics will have at least the following resources:
+.PP
+.TP 8
+.B background (\fPclass\fB Background)
+This resource specifies the color to use for the window background.
+.PP
+.TP 8
+.B borderWidth (\fPclass\fB BorderWidth)
+This resource specifies the width in pixels of the window border.
+.PP
+.TP 8
+.B borderColor (\fPclass\fB BorderColor)
+This resource specifies the color to use for the window border.
+.PP
+Most applications using the X Toolkit Intrinsics also have the resource
+\fBforeground\fP
+(class \fBForeground\fP), specifying the color to use for text
+and graphics within the window.
+.PP
+By combining class and instance specifications, application preferences 
+can be set quickly and easily.  Users of color displays will frequently
+want to set Background and Foreground classes to particular defaults.
+Specific color instances such as text cursors can then be overridden
+without having to define all of the related resources.  For example,
+.sp
+.nf
+    bitmap*Dashed:  off
+    XTerm*cursorColor:  gold
+    XTerm*multiScroll:  on
+    XTerm*jumpScroll:  on
+    XTerm*reverseWrap:  on
+    XTerm*curses:  on
+    XTerm*Font:  6x10
+    XTerm*scrollBar: on
+    XTerm*scrollbar*thickness: 5
+    XTerm*multiClickTime: 500
+    XTerm*charClass:  33:48,37:48,45-47:48,64:48
+    XTerm*cutNewline: off
+    XTerm*cutToBeginningOfLine: off
+    XTerm*titeInhibit:  on
+    XTerm*ttyModes:  intr ^c erase ^? kill ^u
+    XLoad*Background: gold
+    XLoad*Foreground: red
+    XLoad*highlight: black
+    XLoad*borderWidth: 0
+    emacs*Geometry:  80x65-0-0
+    emacs*Background:  rgb:5b/76/86
+    emacs*Foreground:  white
+    emacs*Cursor:  white
+    emacs*BorderColor:  white
+    emacs*Font:  6x10
+    xmag*geometry: -0-0
+    xmag*borderColor:  white
+.fi
+.PP
+If these resources were stored in a file called \fI.Xresources\fP in your home
+directory, they could be added to any existing resources in the server with
+the following command:
+.sp
+.nf
+    % xrdb -merge $HOME/.Xresources
+.fi
+.sp
+This is frequently how user-friendly startup scripts merge user-specific 
+defaults
+into any site-wide defaults.  All sites are encouraged to set up convenient
+ways of automatically loading resources. See the \fIXlib\fP 
+manual section \fIResource Manager Functions\fP for more information.
+.SH ENVIRONMENT
+.TP
+.SM
+.B DISPLAY
+This is the only mandatory environment variable. It must point to an
+X server. See section "Display Names" above.
+.TP
+.SM
+.B XAUTHORITY
+This must point to a file that contains authorization data. The default
+is \fI$HOME/.Xauthority\fP. See
+.BR Xsecurity (__miscmansuffix__),
+.BR xauth (1),
+.BR xdm (1),
+.BR Xau (3).
+.TP
+.SM
+.B ICEAUTHORITY
+This must point to a file that contains authorization data. The default
+is \fI$HOME/.ICEauthority\fP.
+.TP
+.SM
+.BR LC_ALL ", " LC_CTYPE ", " LANG
+The first non-empty value among these three determines the current
+locale's facet for character handling, and in particular the default
+text encoding. See
+.BR locale (__miscmansuffix__),
+.BR setlocale (3),
+.BR locale (1).
+.TP
+.SM
+.B XMODIFIERS
+This variable can be set to contain additional information important
+for the current locale setting. Typically set to \fI@im=<input-method>\fP
+to enable a particular input method. See
+.BR XSetLocaleModifiers (3).
+.TP
+.SM
+.B XLOCALEDIR
+This must point to a directory containing the locale.alias file and
+Compose and XLC_LOCALE file hierarchies for all locales. The default value
+is\fI __projectroot__/lib/X11/locale\fP.
+.TP
+.SM
+.B XENVIRONMENT
+This must point to a file containing X resources. The default is
+\fI$HOME/.Xdefaults-<hostname>\fP. Unlike\fI __projectroot__/lib/X11/Xresources\fP,
+it is consulted each time an X application starts.
+.TP
+.SM
+.B XFILESEARCHPATH
+This must contain a colon separated list of path templates, where libXt
+will search for resource files. The default value consists of
+.sp
+.nf
+    __projectroot__/lib/X11/%L/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%l/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%L/%T/%N%S:\\
+    __projectroot__/lib/X11/%l/%T/%N%S:\\
+    __projectroot__/lib/X11/%T/%N%S
+.fi
+.sp
+A path template is transformed to a pathname by substituting:
+.sp
+.nf
+    %N => name (basename) being searched for
+    %T => type (dirname) being searched for
+    %S => suffix being searched for
+    %C => value of the resource "customization"
+          (class "Customization")
+    %L => the locale name
+    %l => the locale's language (part before '_')
+    %t => the locale's territory (part after '_` but before '.')
+    %c => the locale's encoding (part after '.')
+.fi
+.TP
+.SM
+.B XUSERFILESEARCHPATH
+This must contain a colon separated list of path templates,
+where libXt will search for user dependent resource files. The default
+value is:
+.sp
+.nf
+    $XAPPLRESDIR/%L/%N%C:\\
+    $XAPPLRESDIR/%l/%N%C:\\
+    $XAPPLRESDIR/%N%C:\\
+    $HOME/%N%C:\\
+    $XAPPLRESDIR/%L/%N:\\
+    $XAPPLRESDIR/%l/%N:\\
+    $XAPPLRESDIR/%N:\\
+    $HOME/%N
+.fi
+.sp
+$XAPPLRESDIR defaults to \fI$HOME\fP, see below.
+.sp
+A path template is transformed to a pathname by substituting:
+.sp
+.nf
+    %N => name (basename) being searched for
+    %T => type (dirname) being searched for
+    %S => suffix being searched for
+    %C => value of the resource "customization"
+          (class "Customization")
+    %L => the locale name
+    %l => the locale's language (part before '_')
+    %t => the locale's territory (part after '_` but before '.')
+    %c => the locale's encoding (part after '.')
+.fi
+.TP
+.SM
+.B XAPPLRESDIR
+This must point to a base directory where the user stores his application
+dependent resource files. The default value is \fI$HOME\fP. Only used if
+XUSERFILESEARCHPATH is not set.
+.TP
+.SM
+.B XKEYSYMDB
+This must point to a file containing nonstandard keysym definitions.
+The default value is\fI __projectroot__/lib/X11/XKeysymDB\fP.
+.TP
+.SM
+.B XCMSDB
+This must point to a color name database file. The default value is
+\fI\__projectroot__/lib/X11/Xcms.txt\fP.
+.TP
+.SM
+.B XFT_CONFIG
+This must point to a configuration file for the Xft library. The default
+value is\fI __projectroot__/lib/X11/XftConfig\fP.
+.TP
+.SM
+.B RESOURCE_NAME
+This serves as main identifier for resources belonging to the program
+being executed. It defaults to the basename of pathname of the program.
+.TP
+.SM
+.B SESSION_MANAGER
+Denotes the session manager the application should connect. See
+.BR xsm (1),
+.BR rstart (1).
+.TP
+.SM
+.B XF86BIGFONT_DISABLE
+Setting this variable to a non-empty value disables the XFree86-Bigfont
+extension. This extension is a mechanism to reduce the memory consumption
+of big fonts by use of shared memory.
+.LP
+.B XKB_FORCE
+.br
+.B XKB_DISABLE
+.br
+.B XKB_DEBUG
+.br
+.B _XKB_CHARSET
+.br
+.B _XKB_LOCALE_CHARSETS
+.br
+.B _XKB_OPTIONS_ENABLE
+.br
+.B _XKB_LATIN1_LOOKUP
+.br
+.B _XKB_CONSUME_LOOKUP_MODS
+.br
+.B _XKB_CONSUME_SHIFT_AND_LOCK
+.br
+.B _XKB_IGNORE_NEW_KEYBOARDS
+.br
+.B _XKB_CONTROL_FALLBACK
+.br
+.B _XKB_COMP_LED
+.B _XKB_COMP_FAIL_BEEP
+.TP
+.SM
+.I ""
+These variables influence the X Keyboard Extension.
+.SH EXAMPLES
+The following is a collection of sample command lines for some of the 
+more frequently used commands.  For more information on a particular command,
+please refer to that command's manual page.
+.sp
+.nf
+    %  xrdb $HOME/.Xresources
+    %  xmodmap -e "keysym BackSpace = Delete"
+    %  mkfontdir /usr/local/lib/X11/otherfonts
+    %  xset fp+ /usr/local/lib/X11/otherfonts
+    %  xmodmap $HOME/.keymap.km
+    %  xsetroot -solid 'rgbi:.8/.8/.8' 
+    %  xset b 100 400 c 50 s 1800 r on
+    %  xset q
+    %  twm
+    %  xmag
+    %  xclock -geometry 48x48-0+0 -bg blue -fg white
+    %  xeyes -geometry 48x48-48+0
+    %  xbiff -update 20 
+    %  xlsfonts '*helvetica*'
+    %  xwininfo -root
+    %  xdpyinfo -display joesworkstation:0
+    %  xhost -joesworkstation
+    %  xrefresh
+    %  xwd | xwud
+    %  bitmap companylogo.bm 32x32
+    %  xcalc -bg blue -fg magenta
+    %  xterm -geometry 80x66-0-0 -name myxterm $*
+    %  xon filesysmachine xload
+.fi
+.SH DIAGNOSTICS
+A wide variety of error messages are generated from various programs.
+The default error handler in \fIXlib\fP (also used by many toolkits) uses
+standard resources to construct diagnostic messages when errors occur.  The
+defaults for these messages are usually stored in
+\fI\__projectroot__/lib/X11/XErrorDB\fP.  If this file is not present,
+error messages will be rather terse and cryptic.
+.PP
+When the X Toolkit Intrinsics encounter errors converting resource strings to
+the
+appropriate internal format, no error messages are usually printed.  This is
+convenient when it is desirable to have one set of resources across a variety
+of displays (e.g. color vs. monochrome, lots of fonts vs. very few, etc.),
+although it can pose problems for trying to determine why an application might
+be failing.  This behavior can be overridden by the setting the
+\fIStringConversionsWarning\fP resource.
+.PP
+To force the X Toolkit Intrinsics to always print string conversion error
+messages,
+the following resource should be placed in the file that gets
+loaded onto the RESOURCE_MANAGER property
+using the \fIxrdb\fP program (frequently called \fI.Xresources\fP
+or \fI.Xres\fP in the user's home directory):
+.sp
+.nf
+    *StringConversionWarnings: on
+.fi
+.sp
+To have conversion messages printed for just a particular application,
+the appropriate instance name can be placed before the asterisk:
+.sp
+.nf
+    xterm*StringConversionWarnings: on
+.fi
+.SH "SEE ALSO"
+.PP
+.\" introductions
+.BR XOrgFoundation (__miscmansuffix__),
+.BR XStandards (__miscmansuffix__),
+.BR Xsecurity (__miscmansuffix__),
+.BR Xprint (__miscmansuffix__),
+.\" clients, utilities, and demos
+.BR appres (1),
+.BR bdftopcf (1),
+.BR bitmap (1),
+.BR editres (1),
+.BR fsinfo (1),
+.BR fslsfonts (1),
+.BR fstobdf (1),
+.BR iceauth (1),
+.BR imake (1),
+.BR lbxproxy (1),
+.BR kbd_mode (1),
+.BR makedepend (1),
+.BR mkfontdir (1),
+.BR oclock (1),
+.BR proxymngr (1),
+.BR rgb (1), 
+.BR resize (1),
+.BR rstart (1),
+.BR smproxy (1),
+.BR twm (1),
+.BR x11perf (1),
+.BR x11perfcomp (1), 
+.BR xauth (1),
+.BR xclipboard (1),
+.BR xclock (1),
+.BR xcmsdb (1),
+.BR xconsole (1),
+.BR xdm (1),
+.BR xdpyinfo (1),
+.BR xfd (1),
+.BR xfindproxy (1),
+.BR xfs (1),
+.BR xfwp (1),
+.BR xhost (1),
+.BR xinit (1),
+.BR xkbbell (1),
+.BR xkbcomp (1),
+.BR xkbevd (1),
+.BR xkbprint (1),
+.BR xkbvleds (1),
+.BR xkbwatch (1),
+.BR xkill (1),
+.BR xlogo (1),
+.BR xlsatoms (1),
+.BR xlsclients (1),
+.BR xlsfonts (1),
+.BR xmag (1),
+.BR xmh (1),
+.BR xmodmap (1),
+.BR xon (1),
+.BR xplsprinters (1),
+.BR xprop (1),
+.BR xrdb (1),
+.BR xrefresh (1),
+.BR xrx (1),
+.BR xset (1),
+.BR xsetroot (1),
+.BR xsm (1),
+.BR xstdcmap (1),
+.BR xterm (1),
+.BR xwd (1),
+.BR xwininfo (1),
+.BR xwud (1).
+.\" servers
+.BR Xserver (1),
+.BR Xdec (1),
+.BR Xdmx (1),
+.BR XmacII (1),
+.BR Xsun (1),
+.BR Xnest (1),
+.BR Xvfb (1),
+.BR Xorg (1),
+.BR XDarwin (1),
+.BR Xprt (1).
+.\" specifications
+.I "Xlib \- C Language X Interface\fR,\fP"
+and
+.I "X Toolkit Intrinsics \- C Language Interface"
+.SH TRADEMARKS
+.PP
+X Window System is a trademark of The Open Group.
+.SH AUTHORS
+.PP
+A cast of thousands, literally.  Releases 6.7 and later are 
+brought to you by the X.Org Foundation, LLC. The names of all people who 
+made it a reality will be found in the individual documents and 
+source files.
+.PP
+Releases 6.6 and 6.5 were done by The X.Org Group.  Release 6.4 was done by
+The X Project Team.  The Release 6.3 distribution was from The X Consortium,
+Inc.  The staff members at the X Consortium responsible for that release
+were: Donna Converse (emeritus), Stephen Gildea (emeritus), Kaleb Keithley,
+Matt Landau (emeritus), Ralph Mor (emeritus), Janet O'Halloran, Bob
+Scheifler, Ralph Swick, Dave Wiggins (emeritus), and Reed Augliere.
+.PP
+The X Window System standard was originally developed at the
+Laboratory for Computer Science at the Massachusetts Institute 
+of Technology, and all rights thereto were assigned to the X Consortium 
+on January 1, 1994.
+X Consortium, Inc. closed its doors on December 31, 1996.  All rights to the
+X Window System have been assigned to The Open Group.
diff --git a/doc/xorg-docs/man/general/XOrgFoundation.man b/doc/xorg-docs/man/general/XOrgFoundation.man
new file mode 100644
index 000000000..4d9946d82
--- /dev/null
+++ b/doc/xorg-docs/man/general/XOrgFoundation.man
@@ -0,0 +1,56 @@
+.\"
+.\" Copyright 2004, 2005 X.Org Foundation, LLC
+.\" Copyright (c) 1993, 1994, 1996  X Consortium
+.\" 
+.\" Permission is hereby granted, free of charge, to any person obtaining a
+.\" copy of this software and associated documentation files (the "Software"), 
+.\" to deal in the Software without restriction, including without limitation 
+.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 
+.\" and/or sell copies of the Software, and to permit persons to whom the 
+.\" Software furnished to do so, subject to the following conditions:
+.\" 
+.\" The above copyright notice and this permission notice shall be included in
+.\" all copies or substantial portions of the Software.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+.\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
+.\" THE X.ORG FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
+.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 
+.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
+.\" SOFTWARE.
+.\"
+.TH XORGFOUNDATION __miscmansuffix__ __xorgversion__
+.SH NAME
+XOrgFoundation \- X.Org Foundation information
+.SH SYNOPSIS
+Release 7.0 of X Version 11 is brought to you by the X.Org Foundation, LLC.
+.SH DESCRIPTION
+The X.Org Foundation is an independent, not-for-profit 501(c)(3) charity
+corporation.  It was formed in 2004 as the successor to the X.Org Group at
+The Open Group. The purpose of the X.Org Foundation is to foster the 
+development, evolution, and maintenance of the X Window System, a 
+comprehensive set of vendor-neutral, system-architecture neutral, 
+network-transparent windowing and user interface standards. Membership
+in the X.Org Foundation is free and open to anyone. The X.Org Foundation
+hosts a public CVS repository of the source code on Freedesktop.Org.
+.PP
+The X Window System was created in the mid-1980s at the Massachusetts
+Institute of Technology.  In 1988, MIT formed a member-funded consortium to
+provide the technical and administrative leadership necessary to support
+further development of the X Window System.  In 1992, MIT and the membership
+decided it was in their best interests to move the consortium out of MIT and
+create an independent, stand-alone organization.  All rights to the X Window 
+System were assigned by MIT to X Consortium, Inc. on January 1, 1994. On 
+December 31, 1996 the X Consortium, Inc. closed its doors and all rights 
+to the X Window System were assigned to The Open Group (then known as the
+Open Software Foundation.)
+.PP
+.SH "ADDRESSES"
+The X.Org Foundation's web site is http://www.x.org/
+.PP
+The X.Org Foundation's public ftp site is ftp://ftp.x.org/
+.PP
+Information about the X.Org Foundation CVS repository is on the 
+Freedesktop.Org web site at http://www.freedesktop.org/Software/xorg
+.fi
diff --git a/doc/xorg-docs/man/general/XProjectTeam.man b/doc/xorg-docs/man/general/XProjectTeam.man
new file mode 100644
index 000000000..d7673dad5
--- /dev/null
+++ b/doc/xorg-docs/man/general/XProjectTeam.man
@@ -0,0 +1,91 @@
+.\" $Xorg: XProjectTeam.cpp,v 1.6 2001/01/29 17:44:41 coskrey Exp $
+.\" Copyright (c) 1993, 1994, 1996  X Consortium
+.\" Copyright (c) 1996, 2000 The Open Group
+.\" 
+.\" Permission is hereby granted, free of charge, to any person obtaining a
+.\" copy of this software and associated documentation files (the "Software"), 
+.\" to deal in the Software without restriction, including without limitation 
+.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 
+.\" and/or sell copies of the Software, and to permit persons to whom the 
+.\" Software furnished to do so, subject to the following conditions:
+.\" 
+.\" The above copyright notice and this permission notice shall be included in
+.\" all copies or substantial portions of the Software.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+.\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
+.\" THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
+.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 
+.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
+.\" SOFTWARE.
+.\" 
+.\" Except as contained in this notice, the name of the X Consortium shall not 
+.\" be used in advertising or otherwise to promote the sale, use or other 
+.\" dealing in this Software without prior written authorization from the 
+.\" X Consortium.
+.\"
+.\" $XFree86: xc/doc/man/general/XProjectTeam.man,v 1.2 2001/01/27 18:20:38 dawes Exp $
+.\"
+.TH XORG __miscmansuffix__ __xorgversion__
+.SH NAME
+X.Org, XProjectTeam \- X.Org Group information
+.SH SYNOPSIS
+Release 6.5 and 6.6 of X Version 11 was brought to you by The X.Org Group.
+Release 6.4 of X Version 11 was brought to you by The X Project Team.
+.SH DESCRIPTION
+The Open Group's X Project Team was created as the successor 
+to the X Consortium, Inc., after the X Consortium ceased operations and
+transferred ownership of X11 to The Open Group. The X.Org Group 
+(hereinafter called "X.Org") was created as the successor to The X Project 
+Team after the The Open Group ceased operating The X Project Team. The 
+purpose of X.Org was to foster development, evolution, and maintenance of 
+the X Window System.  X.Org operates under the corporate umbrella of The 
+Open Group.
+.PP
+The X Consortium was an independent, not-for-profit Delaware membership
+corporation.  It was formed in 1993 as the successor to the MIT X 
+Consortium.
+.PP
+The X Window System was created in the mid-1980s at the Massachusetts
+Institute of Technology.  In 1988, MIT formed a member-funded consortium 
+to provide the technical and administrative leadership necessary to 
+support further development of the X Window System.  In 1992, MIT and 
+the membership decided it was in their best interests to move the 
+consortium out of MIT and create an independent, stand-alone organization.  
+All rights to the X Window System were assigned by MIT to X Consortium, 
+Inc. on January 1, 1994.  On December 31, 1996 the X Consortium, Inc. 
+closed its doors and all rights to the X Window System were assigned to 
+The Open Group.
+.PP
+.SH "ADDRESS"
+To reach The Open Group public World Wide Web server, use
+http://www.opengroup.org/.
+.PP
+To reach The X.Org public World Wide Web server, use
+http://www.x.org/.
+.PP
+To reach The X.Org public ftp machine, use anonymous ftp at
+ftp://ftp.x.org/
+
+.SH "FULL MEMBERS"
+
+.nf
+Attachmate
+Barco
+Compaq
+Hewlett-Packard
+Hummingbird
+IBM
+ICS
+Metro Link
+MITRE
+Shiman Associates
+Silicon Graphics Incorporated
+Starnet Communications
+Sun Microsystems
+The XFree86 Project
+US Navy
+WRQ
+Xi Graphics
+.fi
diff --git a/doc/xorg-docs/man/general/Xprint.man b/doc/xorg-docs/man/general/Xprint.man
new file mode 100644
index 000000000..39b0ccc70
--- /dev/null
+++ b/doc/xorg-docs/man/general/Xprint.man
@@ -0,0 +1,421 @@
+.\" -*- coding: us-ascii -*-
+.TH Xprint __miscmansuffix__ "8 October 2004"  
+.SH NAME
+Xprint \- The "X print service" - a portable, network-transparent printing system based on the X11 protocol
+.SH SYNOPSIS
+Xprint is a very flexible, extensible, scaleable, client/server
+print system based on ISO 10175 (and some other specs) and the X11 
+rendering protocol. 
+Using Xprint an application can search, query and use devices like 
+printers, FAX machines or create documents in formats like PDF. 
+In particular, an application can seek a printer, query supported 
+attributes (like paper size, trays, fonts etc.), configure the printer 
+device to match it\(cqs needs and print on it like on any other X device 
+reusing parts of the code which is used for the video card Xserver. 
+.SH OVERVIEW
+The "X Print Service" technology allows X rendering to devices such as
+printers and fax. Most of the service is available in the X11
+technology stack as Xp, with the remainder in single toolkit stacks (e.g. DtPrint for CDE).
+Modifications have also been made to the LessTif/Motif/Qt technology
+stacks to support Xprint.
+.PP
+The Xp portion consists of:
+.TP 0.2i
+\(bu
+Xp Extension for the X-Server (included in the X-Server Xprt)
+.TP 0.2i
+\(bu
+Xp Extension API for the client side (libXp/libXprintUtils)
+.TP 0.2i
+\(bu
+PCL ddx driver that converts core X to native PCL
+.TP 0.2i
+\(bu
+PDF ddx driver that converts core X to native PDF
+.TP 0.2i
+\(bu
+PostScript ddx driver that converts core X to native PostScript
+.TP 0.2i
+\(bu
+Raster ddx driver that generates xwd rasters which can be converted to PCL, PDF or PostScript rasters
+.PP
+.PP
+From an X clients perspective, it can attach to one of two nearly
+identical X-Servers, a "Video" X-Server, and a "Print" X-Server
+which has the additional Xp capability but otherwise looks and
+behaves the same. 
+.SH "HOW THE X PRINT SERVICE WORKS"
+The X Print Service expands on the traditional X-Server and Xlib world
+in four ways.
+.TP 0.4i
+1.
+Most obvious is the use of "print ddx drivers" instead of
+"video ddx drivers". While a video ddx driver modifies pixels
+in a video frame buffer, a print ddx driver generates "page
+description language (PDL)" output (such as PCL, PDF or PostScript)
+or sends the print rendering instructions to a platform-specific
+print API (like Win32/GDI).
+
+Once a print ddx driver generates PDL output, it can be sent to
+a spooler such as \fBlp\fR(1)
+or retrieved by the client (to implement functionality like "print-to-file").
+
+Though not currently done, a single X-Server can support both
+print and video ddx drivers.
+.TP 0.4i
+2.
+Since printers support "paged" output, unlike video, a portion
+of the Xp Extension supports APIs to delineate printed output.
+For example, XpStartPage and XpEndPage tell the X-Server where
+a physical page starts and ends in an otherwise continuous
+stream of X rendering primitives. Likewise, XpStartJob and
+XpEndJob determine when a collection of pages starts and ends.
+XpEndJob typically causes the generated PDL to be submitted to
+a spooler, such as \fBlp\fR(1).
+.TP 0.4i
+3.
+Since printers have extensive capabilities, another portion of
+the Xp Extension supports APIs to manipulate "print contexts".
+
+Once a printer is selected using the Xp Extension API, a print
+context to represent it can be created. A print context
+embodies the printer selected - it contains the printer's
+default capabilities, selectable range of capabilities,
+printer state, and generated output. Some "attributes" within
+the print context can be modified by the user, and the
+X-Server and print ddx driver will react accordingly. For
+example, the attribute "content-orientation" can be set to
+"landscape" or "portrait" (if the printer supports these 
+values - which can be queried using the Xprint API as well).
+.TP 0.4i
+4.
+Since printers can have "built in" fonts, the Xp Extension in
+the X-Server works with the print ddx drivers to make
+available (for printing only) additional fonts on a per print
+context basis.
+
+When a print context is created and set for a given printer,
+the X font calls may be able to access additional printer
+fonts. To do this (typically), the X-Server must have access
+to "printer metric files" (.pmf) that describe at minimum the
+metrics of the built in fonts.
+.PP
+.SH USAGE
+There are three tasks to start the X Print Service:
+.TP 0.4i
+1.
+configuring the X Print Server,
+.TP 0.4i
+2.
+starting the X Print Service
+.TP 0.4i
+3.
+configuring the user session so that clients can find the running X Print Service
+.PP
+.PP
+The tasks are described in detail below.
+.SH "SERVER CONFIGURATION"
+The X Print Server (Xprt) can read a number of configuration files which
+control its behavior and support for printers. Each vendor platform has
+a default location for this information. Xprt can also read the
+environment variable \fBXPCONFIGDIR\fR to locate alternate configuration
+directories. Common settings include:
+
+export XPCONFIGDIR=/X11/lib/X11/XpConfig/
+.PP
+export XPCONFIGDIR=/proj/x11/xc/programs/Xserver/XpConfig/
+
+.PP
+Xprt has many built-in defaults, and lacking any configuration files,
+will immediately try to support all printers visible via \fBlpstat\fR(1).
+.PP
+In order of importance for configuration by a system administrator, the
+configuration files for a "C" locale are as follows (see \fBXprt\fR(__appmansuffix__) for more
+details (including support for non-"C" locales)):
+.TP 
+\fB${XPCONFIGDIR}/C/print/Xprinters\fR
+\&'Xprinters' is the top most configuration file. It tells
+Xprt which specific printer names (e.g. mylaser) should
+be supported, and whether \fBlpstat\fR(1) or other commands
+should be used to automatically supplement the list of
+printers.
+.TP 
+\fB${XPCONFIGDIR}/C/print/attributes/printer\fR
+The 'printer' file maps printer names to model
+configurations (see 'model-config' below). For example,
+"mylaser" could be mapped to a "HPDJ1600C", and all other
+arbitrary printers could be mapped to a default, such as
+"HPLJ4SI". When depending on \fBlpstat\fR(1) in the Xprinters
+file, setting up defaults in 'printer' becomes all the
+more important.
+.TP 
+\fB${XPCONFIGDIR}/C/print/attributes/document\fR
+The 'document' file specifies the initial document values
+for any print jobs. For example, which paper tray to
+use, what default resolution, etc.
+.TP 
+\fB${XPCONFIGDIR}/C/print/attributes/job\fR
+The 'job' file specifies the initial job values for any
+print jobs. For example, "notification-profile" can be
+set so that when a print job is successfully sent to a
+printer, e-mail is sent to the user.
+.TP 
+\fB${XPCONFIGDIR}/C/print/models/PSdefault/model\-config\fR, \fB${XPCONFIGDIR}/C/print/models/PSdefault/fonts/fonts.dir\fR, \fB${XPCONFIGDIR}/C/print/models/PSdefault/fonts/9nb00051.pmf\fR, \fB${XPCONFIGDIR}/C/print/models/PSdefault/fonts/9nb00093.pmf\fR
+The 'model-config' file has attributes that describe the
+printer model\(cqs capabilities and default settings.
+Printer model fonts may also be present. The model-config
+file also identifies the print ddx driver to be used.
+For each printer model supported, a complete hierarchy of
+files should exist. In most cases, these files do not
+need to be modified.
+.TP 
+\fB${XPCONFIGDIR}/C/print/ddx\-config/raster/pcl\fR, \fB${XPCONFIGDIR}/C/print/ddx\-config/raster/pdf\fR, \fB${XPCONFIGDIR}/C/print/ddx\-config/raster/postscript\fR
+The print ddx drivers can have highly specific
+configuration files to control their behavior. In most
+cases, these files do not need to be modified.
+.PP
+More information in how to configure and customize the X print server can be found in the
+\fBXprt\fR(__appmansuffix__)
+manual page.
+.SH "STARTING UP"
+The summary checklist for starting the X Print Service is as follows:
+.TP 0.4i
+1.
+Choose an execution model for the X Print Service. The X
+Print Service can be run on a per-user session basis, per
+machine basis, or can be run on a few machines globally
+available to a number of users.
+.TP 0.4i
+2.
+If print jobs are to be submitted to a spooler (almost always
+the case), make sure all needed printers are available to the
+spooler subsystem (most often \fBlp\fR(1))
+on the same machine running the X Print Service.
+.TP 0.4i
+3.
+Configure the X Print Server. See ``X Print Server
+Configuration''.
+.TP 0.4i
+4.
+Depending on #1, start the X Print Server process "Xprt", and
+then the toolkit-specific Print Dialog Manager Daemon process
+(such as CDEnext's "dtpdmd") at the appropriate times.
+Note that libXprintUtils-based applications/toolkits do not need
+a Print Dialog Manager Daemon process to use Xprint.
+.PP
+The details are described below.
+.PP
+Because the X Print Service is based on X, it can be easily distributed.
+The most significant factors in which execution model to choose will be
+driven by:
+.TP 0.2i
+\(bu
+how many printers will be accessable through the printer
+subsystem on any given machine. A system administrator may
+choose to cluster printers on a few given machines, or
+scatter them across an organization and possibly make
+extensive use of remote spoolers to make them globally
+available.
+.TP 0.2i
+\(bu
+how many machines will need a copy of the X Print Server
+configuration files. The files have been architected so
+that one super-set version of them can be maintained and
+distributed (e.g. via NFS), and a per-machine or per-user
+version of the `Xprinters' is all that is needed to have the
+appropriate information in them utilized or ignored.
+.TP 0.2i
+\(bu
+how many users can demand services from a given X Print
+Service.
+.PP
+With the above in mind, some obvious execution models include:
+.TP 0.2i
+\(bu
+Global - in this model, the system administrator is choosing
+to run the X Print Service on a *few* select machines with
+appropriate printers configured, and allow clients access to
+the global resource. This can centralize the administration
+of printers and configuration files, but may have to be
+monitored for performance loading.
+
+Startup would likely be done by boot-up scripts (such as \fB/etc/init.d/xprint\fR).
+.TP 0.2i
+\(bu
+Per-machine - every machine with potential X Print Service
+users would run the service. Printer and configuration file
+administration is decentralized, and usage would be limited
+to the users on the machine.
+
+Startup would likely be done by boot-up scripts (such as \fB/etc/init.d/xprint\fR).
+.TP 0.2i
+\(bu
+Per-user session - every user would run an entire X Print
+Service for themselves. In the future, the Video X Server
+normally started may contain Print X Server capability, so
+this model becomes very natural.
+
+Startup would likely be done at session login or by
+launching actions or processes manually once the user
+logs in. Note: Deamons like "dtpdmd" must be started after Xprt.
+.PP
+.PP
+Starting of the processes is straight forward. In strict order (example is for manually starting the X print server for CDEnext usage):
+.TP 0.4i
+1.
+
+.nf
+[machineA] % Xprt [\-XpFile <Xprinters file>] [:dispNum] &
+.fi
+
+
+Note that Xprt will look for configuration files in either
+a default location or where \fBXPCONFIGDIR\fR points.
+
+\fB\-XpFile\fR specifies an alternate `Xprinters' file, rather
+than the default one or `\fB${XPCONFIGDIR}/C/print/Xprinters\fR'.
+.TP 0.4i
+2.
+
+.nf
+[machineA] % dtpdmd \-d machineA[:dispNum] [\-l /tmp/dtpdmd.log] &
+.fi
+
+
+The dtpdmd will maintain an X-Selection on the X-Server,
+and will start dtpdm's as required to service requests.
+.PP
+.PP
+In all but the per-user session model, the machine running the dtpdmd
+(thus dtpdm's) will need display authorization to the users video
+display.
+.SH "CLIENT CONFIGURATION"
+Once a X Print Server and dtpdmd have been started -- many of them
+in some cases -- clients will need to find and use them. There are
+two mechanisms that allow clients to discover X Print Servers and
+printers.
+.TP 0.2i
+\(bu
+"X Print Specifier" - assuming usage of the DtPrint/XprintUtils-based print
+applications, the following notation is understood:
+
+
+.nf
+printer_name@machine[:dispNum]
+.fi
+
+
+For example:
+
+
+.nf
+colorlj7@printhub:2
+.fi
+
+
+In the above example, the X Print Server running at `printhub:2'
+is assumed to support the printer named `colorlj7'.
+.TP 0.2i
+\(bu
+\fB${XPSERVERLIST}\fR - assuming usage of the DtPrint print dialogs,
+the environment variable \fB${XPSERVERLIST}\fR can contain a list
+of X Print Servers. For example:
+
+
+.nf
+XPSERVERLIST="printhub:2 printhub:3 otherdept:0"
+.fi
+
+
+Then in the dialogs, only a printer name needs to be entered.
+The dialog will then search the X Print Servers in \fB${XPSERVERLIST}\fR
+for a server than supports the printer, and then establish
+contact.
+.PP
+.SH "END-USER SEQUENCE"
+From most CDEnext applications, printing is accomplished by bringing
+down the <File> menu and selecting <Print...>. This will result in
+the DtPrintSetupBox dialog, which will request the name of a printer,
+and offer limited capability to configure print options (e.g. number
+of copies). If the user wishes, they can select <Setup...>, which
+will start a dtpdm capable of modifying additional print options.
+Finally, the user should select <Print>.
+.SH ENVIRONMENT
+.TP 
+\fB${XPCONFIGDIR}\fR
+This environment variable points to the root
+of the Xprint server configuration directory hierarchy.
+If the variable is not defined, the default
+path is be assumed. The default path may be
+\fB/usr/X11R6/lib/X11/xserver/\fR, 
+\fB/usr/lib/X11/xserver/\fR,
+\fB/usr/share/Xprint/xserver/\fR or
+\fB/usr/openwin/server/etc/XpConfig\fR, depending on the
+system, and may be configured in \fB/etc/init.d/xprint\fR.
+.TP 
+\fB${LANG}\fR
+This environment variable selects the locale settings used by the Xprint server.
+Xprt allows language-specific settings (stored in \fB${XPCONFIGDIR}/${LANG}/print/\fR)
+which will override the default settings (stored in \fB${XPCONFIGDIR}/C/print/\fR).
+If \fB${LANG}\fR is not set "C" is assumed.
+.TP 
+\fB${XPSERVERLIST}\fR
+The environment variable \fB${XPSERVERLIST}\fR contains a list
+of display identifiers (separated by whitespace) which tell an
+application where it can find the Xprint servers. Usually
+\fB${XPSERVERLIST}\fR is set by the profile startup scripts (e.g.
+\fB/etc/profile\fR or \fB/etc/profile.d/xprint.sh\fR) using the output of
+\fB/etc/init.d/xprint get_xpserverlist\fR.
+
+Example: 
+
+.nf
+
+		export XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist`"
+.fi
+
+
+Alternatively \fB${XPSERVERLIST}\fR can be set
+manually. Example:
+
+.nf
+
+		export XPSERVERLIST="littlecat:80 bitdog:72"
+.fi
+
+instructs an application to find an Xprint server at display
+80 on the machine "littlecat" and at display 72 on the
+machine bigdog.
+.TP 
+\fB${XPRINTER}\fR 
+The environment variable \fB${XPRINTER}\fR
+defines the default printer used by print
+applications. The syntax is either
+\fIprintername\fR or
+\fIprintername\fR@\fIdisplay\fR.
+
+Examples:
+.RS 
+.TP 
+\fBXPRINTER=ps003\fR
+tells an application to look for the
+first printer named "ps003" on all Xprint
+servers.
+.TP 
+\fBXPRINTER=hplaser19@littlecat:80\fR
+tells an application to use the printer "hplaser19"
+on the Xprint server at display 
+"littlecat:80".
+.RE
+
+
+If \fB${XPRINTER}\fR is not set the applications
+will examine the values of the \fB${PDPRINTER}\fR,
+\fB${LPDEST}\fR, and 
+\fB${PRINTER}\fR environment variables (in that order). 
+.SH "SEE ALSO"
+\fBX11\fR(__miscmansuffix__), \fBxplsprinters\fR(__appmansuffix__), \fBxprehashprinterlist\fR(__appmansuffix__), \fBxphelloworld\fR(__appmansuffix__), \fBxpxmhelloworld\fR(__appmansuffix__), \fBxpawhelloworld\fR(__appmansuffix__), \fBxpxthelloworld\fR(__appmansuffix__), \fBxpsimplehelloworld\fR(__appmansuffix__), \fBXserver\fR(__appmansuffix__), \fBXprt\fR(__appmansuffix__), \fBlibXp\fR(__libmansuffix__), \fBlibXprintUtils\fR(__libmansuffix__), \fBlibXprintAppUtils\fR(__libmansuffix__), \fBXmPrintShell\fR(__libmansuffix__), \fBXawPrintShell\fR(__libmansuffix__), Xprint FAQ (http://xprint.mozdev.org/docs/Xprint_FAQ.html), Xprint main site (http://xprint.mozdev.org/)
+.SH AUTHORS
+This manual page was written by 
+Roland Mainz <roland.mainz@nrubsig.org> based on the original X11R6.6
+\fBxc/programs/Xserver/XpConfig/README\fR.
diff --git a/doc/xorg-docs/man/general/Xprint.sgml b/doc/xorg-docs/man/general/Xprint.sgml
new file mode 100644
index 000000000..1f7e0a75e
--- /dev/null
+++ b/doc/xorg-docs/man/general/Xprint.sgml
@@ -0,0 +1,627 @@
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.2//EN" 'http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd'>
+
+<!-- Process this file with docbook-to-man to generate an nroff manual
+     page: 'docbook-to-man manpage.sgml > manpage.1'.  You may view
+     the manual page with: 'docbook-to-man manpage.sgml | nroff -man | less'. 
+     A typical entry in a Makefile or Makefile.am is:
+
+manpage.1: manpage.sgml
+	docbook-to-man $< > $@
+
+HTML generation can be done like this:
+% xsltproc ==docbook /usr/share/sgml/docbook/docbook-xsl-stylesheets-1.60.1/html/docbook.xsl Xprint.sgml >Xprint.html
+  -->
+
+<refentry id="Xprint">
+  <refmeta>
+    <refentrytitle>Xprint</refentrytitle>
+    <manvolnum>__miscmansuffix__</manvolnum>
+  </refmeta>
+  <refnamediv>
+    <refname>Xprint</refname>
+
+    <refpurpose>The "X print service" - a portable, network-transparent printing system based on the X11 protocol</refpurpose>
+  </refnamediv>
+  <refsynopsisdiv>
+    <para>Xprint is a very flexible, extensible, scaleable, client/server
+     print system based on ISO 10175 (and some other specs) and the X11        
+     rendering protocol.                                                       
+     Using Xprint an application can search, query and use devices like        
+     printers, FAX machines or create documents in formats like PDF.           
+     In particular, an application can seek a printer, query supported         
+     attributes (like paper size, trays, fonts etc.), configure the printer    
+     device to match it&rsquo;s needs and print on it like on any other X device     
+     reusing parts of the code which is used for the video card Xserver.    
+    </para>
+  </refsynopsisdiv>
+  
+  <refsect1>
+    <title>OVERVIEW</title>
+    <para>
+      The "X Print Service" technology allows X rendering to devices such as
+      printers and fax.  Most of the service is available in the X11
+      technology stack as Xp, with the remainder in single toolkit stacks (e.g. DtPrint for CDE).
+      Modifications have also been made to the LessTif/Motif/Qt technology
+      stacks to support Xprint.
+    </para>
+    <para>
+      The Xp portion consists of:
+      <itemizedlist>
+        <listitem><para>Xp Extension for the X-Server (included in the X-Server Xprt)</para></listitem>
+        <listitem><para>Xp Extension API for the client side (libXp/libXprintUtils)</para></listitem>
+        <listitem><para>PCL ddx driver that converts core X to native PCL</para></listitem>
+        <listitem><para>PDF ddx driver that converts core X to native PDF</para></listitem>
+        <listitem><para>PostScript ddx driver that converts core X to native PostScript</para></listitem>
+        <listitem><para>Raster ddx driver that generates xwd rasters which can be converted to PCL, PDF or PostScript rasters</para></listitem>
+      </itemizedlist>
+    </para>
+    <para>
+      From an X clients perspective, it can attach to one of two nearly
+      identical X-Servers, a "Video" X-Server, and a "Print" X-Server
+      which has the additional Xp capability but otherwise looks and
+      behaves the same.   
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>HOW THE X PRINT SERVICE WORKS</title>
+    <para>    
+      The X Print Service expands on the traditional X-Server and Xlib world
+      in four ways.
+
+      <orderedlist>
+        <listitem>
+          <para>
+            Most obvious is the use of "print ddx drivers" instead of
+            "video ddx drivers".  While a video ddx driver modifies pixels
+            in a video frame buffer, a print ddx driver generates "page
+            description language (PDL)" output (such as PCL, PDF or PostScript)
+            or sends the print rendering instructions to a platform-specific
+            print API (like Win32/GDI).
+          </para>
+          <para>
+            Once a print ddx driver generates PDL output, it can be sent to
+            a spooler such as <citerefentry><refentrytitle>lp</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+            or retrieved by the client (to implement functionality like "print-to-file").
+          </para>
+          <para>
+            Though not currently done, a single X-Server can support both
+            print and video ddx drivers.
+            <!-- FIXME: IBM/AIX people have integrated Xprt into their main Xserver (currently experimental) ... -->
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            Since printers support "paged" output, unlike video, a portion
+            of the Xp Extension supports APIs to delineate printed output.
+            For example, <function>XpStartPage</function> and <function>XpEndPage</function> tell the X-Server where
+            a physical page starts and ends in an otherwise continuous
+            stream of X rendering primitives.  Likewise, <function>XpStartJob</function> and
+            <function>XpEndJob</function> determine when a collection of pages starts and ends.
+            <function>XpEndJob</function> typically causes the generated PDL to be submitted to
+            a spooler, such as <citerefentry><refentrytitle>lp</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            Since printers have extensive capabilities, another portion of
+            the Xp Extension supports APIs to manipulate "print contexts".
+          </para>
+          <para>
+            Once a printer is selected using the Xp Extension API, a print
+            context to represent it can be created.  A print context
+            embodies the printer selected - it contains the printer's
+            default capabilities, selectable range of capabilities,
+            printer state, and generated output.  Some "attributes" within
+            the print context can be modified by the user, and the
+            X-Server and print ddx driver will react accordingly.  For
+            example, the attribute "content-orientation" can be set to
+            "landscape" or "portrait" (if the printer supports these 
+            values - which can be queried using the Xprint API as well).
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            Since printers can have "built in" fonts, the Xp Extension in
+            the X-Server works with the print ddx drivers to make
+            available (for printing only) additional fonts on a per print
+            context basis.
+          </para>
+          <para>
+            When a print context is created and set for a given printer,
+            the X font calls may be able to access additional printer
+            fonts.  To do this (typically), the X-Server must have access
+            to "printer metric files" (.pmf) that describe at minimum the
+            metrics of the built in fonts.
+          </para>
+        </listitem>
+      </orderedlist>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>USAGE</title>
+    <para>    
+      There are three tasks to start the X Print Service:
+      <orderedlist>
+        <listitem><para>configuring the X Print Server,</para></listitem>
+        <listitem><para>starting the X Print Service</para></listitem>
+        <listitem><para>configuring the user session so that clients can find the running X Print Service</para></listitem>
+      </orderedlist>
+    </para>
+    <para>
+      The tasks are described in detail below.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>SERVER CONFIGURATION</title>
+    <para>
+      The X Print Server (Xprt) can read a number of configuration files which
+      control its behavior and support for printers.  Each vendor platform has
+      a default location for this information.  Xprt can also read the
+      environment variable <envar>XPCONFIGDIR</envar> to locate alternate configuration
+      directories.  Common settings include:
+
+      <simplelist type="vert">
+        <member>export XPCONFIGDIR=/X11/lib/X11/XpConfig/</member>
+        <member>export XPCONFIGDIR=/proj/x11/xc/programs/Xserver/XpConfig/</member>
+      </simplelist>
+    </para>
+    <para>
+      Xprt has many built-in defaults, and lacking any configuration files,
+      will immediately try to support all printers visible via <citerefentry><refentrytitle>lpstat</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    </para>
+    <para>
+      In order of importance for configuration by a system administrator, the
+      configuration files for a "C" locale are as follows (see <citerefentry><refentrytitle>Xprt</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry> for more
+      details (including support for non-"C" locales)):
+      <variablelist>
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/Xprinters</filename></term>
+          <listitem>
+            <para>
+              'Xprinters' is the top most configuration file.  It tells
+              Xprt which specific printer names (e.g.  mylaser) should
+              be supported, and whether <citerefentry><refentrytitle>lpstat</refentrytitle><manvolnum>1</manvolnum></citerefentry> or other commands
+              should be used to automatically supplement the list of
+              printers.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/attributes/printer</filename></term>
+          <listitem>
+            <para>
+              The 'printer' file maps printer names to model
+              configurations (see 'model-config' below).  For example,
+              "mylaser" could be mapped to a "HPDJ1600C", and all other
+              arbitrary printers could be mapped to a default, such as
+              "HPLJ4SI".  When depending on <citerefentry><refentrytitle>lpstat</refentrytitle><manvolnum>1</manvolnum></citerefentry> in the Xprinters
+              file, setting up defaults in 'printer' becomes all the
+              more important.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/attributes/document</filename></term>
+          <listitem>
+            <para>
+              The 'document' file specifies the initial document values
+              for any print jobs.  For example, which paper tray to
+              use, what default resolution, etc.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/attributes/job</filename></term>
+          <listitem>
+            <para>
+              The 'job' file specifies the initial job values for any
+              print jobs.  For example, "notification-profile" can be
+              set so that when a print job is successfully sent to a
+              printer, e-mail is sent to the user.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/models/PSdefault/model-config</filename></term>
+          <term><filename>${XPCONFIGDIR}/C/print/models/PSdefault/fonts/fonts.dir</filename></term>
+          <term><filename>${XPCONFIGDIR}/C/print/models/PSdefault/fonts/9nb00051.pmf</filename></term>
+          <term><filename>${XPCONFIGDIR}/C/print/models/PSdefault/fonts/9nb00093.pmf</filename></term>
+
+          <listitem>
+            <para>
+              The 'model-config' file has attributes that describe the
+              printer model&rsquo;s capabilities and default settings.
+              Printer model fonts may also be present.  The model-config
+              file also identifies the print ddx driver to be used.
+
+              For each printer model supported, a complete hierarchy of
+              files should exist.  In most cases, these files do not
+              need to be modified.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>${XPCONFIGDIR}/C/print/ddx-config/raster/pcl</filename></term>
+          <term><filename>${XPCONFIGDIR}/C/print/ddx-config/raster/pdf</filename></term>
+          <term><filename>${XPCONFIGDIR}/C/print/ddx-config/raster/postscript</filename></term>
+
+          <listitem>
+            <para>
+              The print ddx drivers can have highly specific
+              configuration files to control their behavior.  In most
+              cases, these files do not need to be modified.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+      
+      More information in how to configure and customize the X print server can be found in the
+      <citerefentry><refentrytitle>Xprt</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry>
+      manual page.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>STARTING UP</title>
+    <para>
+      The summary checklist for starting the X Print Service is as follows:
+      
+      <orderedlist>
+        <listitem>
+          <para>
+            Choose an execution model for the X Print Service.  The X
+            Print Service can be run on a per-user session basis, per
+            machine basis, or can be run on a few machines globally
+            available to a number of users.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            If print jobs are to be submitted to a spooler (almost always
+            the case), make sure all needed printers are available to the
+            spooler subsystem (most often <citerefentry><refentrytitle>lp</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+            on the same machine running the X Print Service.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            Configure the X Print Server.  See ``X Print Server
+            Configuration''.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            Depending on #1, start the X Print Server process "Xprt", and
+            then the toolkit-specific Print Dialog Manager Daemon process
+            (such as CDEnext's "dtpdmd") at the appropriate times.
+            Note that libXprintUtils-based applications/toolkits do not need
+            a Print Dialog Manager Daemon process to use Xprint.
+          </para>
+        </listitem>
+      </orderedlist>     
+      The details are described below.
+    </para>
+    <para>
+      Because the X Print Service is based on X, it can be easily distributed.
+      The most significant factors in which execution model to choose will be
+      driven by:
+      <itemizedlist>
+        <listitem>
+          <para>
+            how many printers will be accessable through the printer
+            subsystem on any given machine.  A system administrator may
+            choose to cluster printers on a few given machines, or
+            scatter them across an organization and possibly make
+            extensive use of remote spoolers to make them globally
+            available.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            how many machines will need a copy of the X Print Server
+            configuration files.  The files have been architected so
+            that one super-set version of them can be maintained and
+            distributed (e.g.  via NFS), and a per-machine or per-user
+            version of the `Xprinters' is all that is needed to have the
+            appropriate information in them utilized or ignored.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            how many users can demand services from a given X Print
+            Service.
+          </para>
+        </listitem>
+      </itemizedlist>
+
+      With the above in mind, some obvious execution models include:
+      <itemizedlist>
+        <listitem>
+          <para>
+            Global - in this model, the system administrator is choosing
+            to run the X Print Service on a *few* select machines with
+            appropriate printers configured, and allow clients access to
+            the global resource.  This can centralize the administration
+            of printers and configuration files, but may have to be
+            monitored for performance loading.
+          </para>
+          <para>
+            Startup would likely be done by boot-up scripts (such as <filename>/etc/init.d/xprint</filename>).
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Per-machine - every machine with potential X Print Service
+            users would run the service.  Printer and configuration file
+            administration is decentralized, and usage would be limited
+            to the users on the machine.
+          </para>
+          <para>
+            Startup would likely be done by boot-up scripts (such as <filename>/etc/init.d/xprint</filename>).
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Per-user session - every user would run an entire X Print
+            Service for themselves.  In the future, the Video X Server
+            normally started may contain Print X Server capability, so
+            this model becomes very natural.
+          </para>
+          <para>
+            Startup would likely be done at session login or by
+            launching actions or processes manually once the user
+            logs in.  Note: Deamons like "dtpdmd" must be started after Xprt.
+          </para>
+        </listitem>
+      </itemizedlist>
+     </para>
+     <para>
+       Starting of the processes is straight forward.  In strict order (example is for manually starting the X print server for CDEnext usage):
+       <orderedlist>
+         <listitem>
+           <para>
+             <programlisting>[machineA] % Xprt [-XpFile &lt;Xprinters file&gt;] [:dispNum] &amp;</programlisting>
+           </para>
+           <para>
+             Note that Xprt will look for configuration files in either
+             a default location or where <envar>XPCONFIGDIR</envar> points.
+           </para>
+           <para>
+             <option>-XpFile</option> specifies an alternate `Xprinters' file, rather
+             than the default one or `<filename>${XPCONFIGDIR}/C/print/Xprinters</filename>'.
+           </para>
+         </listitem>
+         <listitem>
+           <para>
+             <programlisting>[machineA] % dtpdmd -d machineA[:dispNum] [-l /tmp/dtpdmd.log] &amp;</programlisting>
+           </para>
+           <para>
+            The dtpdmd will maintain an X-Selection on the X-Server,
+            and will start dtpdm's as required to service requests.
+           </para>
+         </listitem>
+       </orderedlist>
+     </para>
+     <para>
+       In all but the per-user session model, the machine running the dtpdmd
+       (thus dtpdm's) will need display authorization to the users video
+       display.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>CLIENT CONFIGURATION</title>
+    <para>
+      Once a X Print Server and dtpdmd have been started -- many of them
+      in some cases -- clients will need to find and use them.  There are
+      two mechanisms that allow clients to discover X Print Servers and
+      printers.
+
+      <itemizedlist>
+        <listitem>
+          <para>
+            "X Print Specifier" - assuming usage of the DtPrint/XprintUtils-based print
+            applications, the following notation is understood:
+          </para>
+          <para>
+            <programlisting>printer_name@machine[:dispNum]</programlisting>
+          </para>
+          <para>
+            For example:
+          </para>
+          <para>
+            <programlisting>colorlj7@printhub:2</programlisting>
+          </para>
+          <para>
+           In the above example, the X Print Server running at `printhub:2'
+           is assumed to support the printer named `colorlj7'.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <envar>${XPSERVERLIST}</envar> - assuming usage of the DtPrint print dialogs,
+            the environment variable <envar>${XPSERVERLIST}</envar> can contain a list
+            of X Print Servers.  For example:
+          </para>
+          <para>
+            <programlisting>XPSERVERLIST="printhub:2 printhub:3 otherdept:0"</programlisting>
+          </para>
+          <para>
+            Then in the dialogs, only a printer name needs to be entered.
+            The dialog will then search the X Print Servers in <envar>${XPSERVERLIST}</envar>
+            for a server than supports the printer, and then establish
+            contact.
+          </para>
+        </listitem>
+      </itemizedlist>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>END-USER SEQUENCE</title>
+    <para>
+      From most CDEnext applications, printing is accomplished by bringing
+      down the &lt;File&gt; menu and selecting &lt;Print...&gt;.  This will result in
+      the DtPrintSetupBox dialog, which will request the name of a printer,
+      and offer limited capability to configure print options (e.g. number
+      of copies).  If the user wishes, they can select &lt;Setup...&gt;, which
+      will start a dtpdm capable of modifying additional print options.
+      Finally, the user should select &lt;Print&gt;.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>ENVIRONMENT</title>
+    <variablelist>
+      <varlistentry>
+        <term><envar>${XPCONFIGDIR}</envar></term>
+        <listitem>
+          <para> This environment variable points to the  root
+	    of  the Xprint server configuration directory hierarchy.
+	    If the variable is not defined,  the  default
+	    path  is be assumed.  The default path may be
+            <filename>/usr/X11R6/lib/X11/xserver/</filename>, 
+            <filename>/usr/lib/X11/xserver/</filename>,
+            <filename>/usr/share/Xprint/xserver/</filename> or
+            <filename>/usr/openwin/server/etc/XpConfig</filename>, depending on the
+	    system, and may be configured in <filename>/etc/init.d/xprint</filename>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><envar>${LANG}</envar></term>
+        <listitem>
+          <para>
+            This environment variable selects the locale settings used by the Xprint server.
+            Xprt allows language-specific settings (stored in <filename>${XPCONFIGDIR}/${LANG}/print/</filename>)
+            which will override the default settings (stored in <filename>${XPCONFIGDIR}/C/print/</filename>).
+            If <envar>${LANG}</envar> is not set "C" is assumed.
+          </para>
+        </listitem>
+      </varlistentry>
+      
+      <varlistentry>
+        <term><envar>${XPSERVERLIST}</envar></term>
+        <listitem>
+	    <para>The environment variable <envar>${XPSERVERLIST}</envar> contains a list
+	    of display identifiers (separated by whitespace) which tell an
+	    application where it can find the Xprint servers.  Usually
+	    <envar>${XPSERVERLIST}</envar> is set by the profile startup scripts (e.g.
+	    <filename>/etc/profile</filename> or <filename>/etc/profile.d/xprint.sh</filename>) using the output of
+	    <userinput>/etc/init.d/xprint get_xpserverlist</userinput>.</para>
+	  <para>Example: 
+	    <informalexample>
+	      <programlisting>
+		export XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist`"</programlisting>
+	    </informalexample>
+	  </para>
+	  <para>Alternatively <envar>${XPSERVERLIST}</envar> can be set
+	    manually. Example:</para>
+	    <informalexample>
+	      <programlisting>
+		export XPSERVERLIST="littlecat:80 bitdog:72"</programlisting>
+	    </informalexample>
+	  <para>
+	    instructs an application to find an Xprint server at display
+	    80 on the machine "littlecat" and at display 72 on the
+	    machine bigdog.
+	  </para>
+	</listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><envar>${XPRINTER}</envar>
+        </term>
+        <listitem>
+          <para>The environment variable <envar>${XPRINTER}</envar>
+	    defines the default printer used by print
+	    applications. The syntax is either
+	    <replaceable>printername</replaceable> or
+	    <replaceable>printername</replaceable>@<replaceable>display</replaceable>.</para>
+	    <para>Examples:
+	    <variablelist>
+	      <varlistentry>
+		<term><userinput>XPRINTER=ps003</userinput></term>
+		<listitem><para>
+		  tells an application to look for the
+		  first printer named "ps003" on all Xprint
+		  servers.</para>
+		</listitem>
+	      </varlistentry>
+	
+	      <varlistentry>
+		<!-- brain dead <term> does not permit quote marks
+		(in XPRINTER="hplaser19@littlecat:80"), so omit them -->
+		<term><userinput>XPRINTER=hplaser19@littlecat:80</userinput></term>
+		<listitem><para>
+		  tells an application to use the printer "hplaser19"
+		on the Xprint server at display 
+		  "littlecat:80".</para>
+	      </listitem>
+	      </varlistentry>
+
+	    </variablelist>
+	  </para>
+	  <para>If <envar>${XPRINTER}</envar> is not set the applications
+	    will examine the values of the <envar>${PDPRINTER}</envar>,
+	    <envar>${LPDEST}</envar>, and 
+	    <envar>${PRINTER}</envar> environment variables (in that order).  
+	  </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>SEE ALSO</title>
+    <para>
+      <simplelist type="inline">
+        <!-- specific references -->
+        <!-- none -->
+        
+        <!-- Xprint general references -->
+<!--
+        <member><citerefentry><refentrytitle>Xprint</refentrytitle><manvolnum>__miscmansuffix__</manvolnum></citerefentry></member>
+-->
+        <member><citerefentry><refentrytitle>X11</refentrytitle><manvolnum>__miscmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xplsprinters</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xprehashprinterlist</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xphelloworld</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xpxmhelloworld</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xpawhelloworld</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xpxthelloworld</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>xpsimplehelloworld</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>Xserver</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>Xprt</refentrytitle><manvolnum>__appmansuffix__</manvolnum></citerefentry></member>
+        <!-- ToDO: Add manual pages for the single Xprint DDX implementations (PostScript/PDF/PCL/PCL-MONO/Raster/etc.) -->
+        <member><citerefentry><refentrytitle>libXp</refentrytitle><manvolnum>__libmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>libXprintUtils</refentrytitle><manvolnum>__libmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>libXprintAppUtils</refentrytitle><manvolnum>__libmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>XmPrintShell</refentrytitle><manvolnum>__libmansuffix__</manvolnum></citerefentry></member>
+        <member><citerefentry><refentrytitle>XawPrintShell</refentrytitle><manvolnum>__libmansuffix__</manvolnum></citerefentry></member>
+        <member>Xprint FAQ (<ulink url="http://xprint.mozdev.org/docs/Xprint_FAQ.html">http://xprint.mozdev.org/docs/Xprint_FAQ.html</ulink>)</member>
+        <member>Xprint main site (<ulink url="http://xprint.mozdev.org/">http://xprint.mozdev.org/</ulink>)</member>
+      </simplelist>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>AUTHORS</title>
+    <para>
+      This manual page was written by 
+      Roland Mainz <email>roland.mainz@nrubsig.org</email> based on the original X11R6.6
+      <filename>xc/programs/Xserver/XpConfig/README</filename>.
+    </para>
+  </refsect1>
+</refentry>
+
diff --git a/doc/xorg-docs/man/general/security.man b/doc/xorg-docs/man/general/security.man
new file mode 100644
index 000000000..c2be69256
--- /dev/null
+++ b/doc/xorg-docs/man/general/security.man
@@ -0,0 +1,290 @@
+.\" $Xorg: security.cpp,v 1.3 2000/08/17 19:42:05 cpqbld Exp $
+.\" $XdotOrg: $
+.\" Copyright (c) 1993, 1994  X Consortium
+.\" Copyright 2004 Sun Microsystems, Inc.
+.\" 
+.\" 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, and/or sell copies of the Software, and to permit persons
+.\" to whom the Software is furnished to do so, provided that the above
+.\" copyright notice(s) and this permission notice appear in all copies of
+.\" the Software and that both the above copyright notice(s) and this
+.\" permission notice appear in supporting documentation.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+.\" OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
+.\" HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
+.\" INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
+.\" FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+.\" NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
+.\" WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\" 
+.\" Except as contained in this notice, the name of a copyright holder
+.\" shall not be used in advertising or otherwise to promote the sale, use
+.\" or other dealings in this Software without prior written authorization
+.\" of the copyright holder.
+.\" 
+.\" X Window System is a trademark of The Open Group.
+.\"
+.\" $XFree86: xc/doc/man/general/security.man,v 1.4tsi Exp $
+.\"
+.nr )S 12
+.TH XSECURITY __miscmansuffix__ __xorgversion__
+.SH NAME
+Xsecurity \- X display access control
+.SH SYNOPSIS
+.PP
+X provides mechanism for implementing many access control systems.
+The sample implementation includes six mechanisms:
+.nf
+.br
+.ta 3.4i
+    Host Access	Simple host-based access control.
+    MIT-MAGIC-COOKIE-1	Shared plain-text "cookies".
+    XDM-AUTHORIZATION-1	Secure DES based private-keys.
+    SUN-DES-1	Based on Sun's secure rpc system.
+    MIT-KERBEROS-5	Kerberos Version 5 user-to-user.
+    Server Interpreted	Server-dependent methods of access control
+.fi
+Not all of these are available in all builds or implementations.
+.SH "ACCESS SYSTEM DESCRIPTIONS"
+.IP "Host Access"
+Any client on a host in the host access control list is allowed access to
+the X server.  This system can work reasonably well in an environment
+where everyone trusts everyone, or when only a single person can log in
+to a given machine, and is easy to use when the list of hosts used is small.
+This system does not work well when multiple people can log in to a single
+machine and mutual trust does not exist.
+The list of allowed hosts is stored in the X server and can be changed with
+the \fIxhost\fP command.   The list is stored in the server by network 
+address, not host names, so is not automatically updated if a host changes
+address while the server is running.
+When using the more secure mechanisms listed below, the host list is
+normally configured to be the empty list, so that only authorized
+programs can connect to the display.   See the GRANTING ACCESS section of
+the \fIXserver\fP man page for details on how this list is initialized at
+server startup.
+.IP "MIT-MAGIC-COOKIE-1"
+When using MIT-MAGIC-COOKIE-1,
+the client sends a 128 bit "cookie"
+along with the connection setup information.
+If the cookie presented by the client matches one
+that the X server has, the connection is allowed access.
+The cookie is chosen so that it is hard to guess;
+\fIxdm\fP generates such cookies automatically when this form of
+access control is used.
+The user's copy of
+the cookie is usually stored in the \fI.Xauthority\fP file in the home
+directory, although the environment variable \fBXAUTHORITY\fP can be used
+to specify an alternate location.
+\fIXdm\fP automatically passes a cookie to the server for each new
+login session, and stores the cookie in the user file at login.
+.IP
+The cookie is transmitted on the network without encryption, so
+there is nothing to prevent a network snooper from obtaining the data
+and using it to gain access to the X server.  This system is useful in an
+environment where many users are running applications on the same machine
+and want to avoid interference from each other, with the caveat that this
+control is only as good as the access control to the physical network.
+In environments where network-level snooping is difficult, this system
+can work reasonably well.
+.IP "XDM-AUTHORIZATION-1"
+Sites who compile with DES support can use a DES-based access control
+mechanism called XDM-AUTHORIZATION-1.
+It is similar in usage to MIT-MAGIC-COOKIE-1 in that a key is
+stored in the \fI.Xauthority\fP file and is shared with the X server.
+However,
+this key consists of two parts - a 56 bit DES encryption key and 64 bits of
+random data used as the authenticator.
+.IP
+When connecting to the X server, the application generates 192 bits of data
+by combining the current time in seconds (since 00:00 1/1/1970 GMT) along
+with 48 bits of "identifier".  For TCP/IPv4 connections, the identifier is
+the address plus port number; for local connections it is the process ID
+and 32 bits to form a unique id (in case multiple connections to the same
+server are made from a single process).  This 192 bit packet is then
+encrypted using the DES key and sent to the X server, which is able to
+verify if the requestor is authorized to connect by decrypting with the
+same DES key and validating the authenticator and additional data.
+This system is useful in many environments where host-based access control
+is inappropriate and where network security cannot be ensured.
+.IP "SUN-DES-1"
+Recent versions of SunOS (and some other systems) have included a
+secure public key remote procedure call system.  This system is based
+on the notion of a network principal; a user name and NIS domain pair.
+Using this system, the X server can securely discover the actual user
+name of the requesting process.  It involves encrypting data with the
+X server's public key, and so the identity of the user who started the
+X server is needed for this; this identity is stored in the \fI.Xauthority\fP
+file.  By extending the semantics of "host address" to include this notion of
+network principal, this form of access control is very easy to use.
+.IP
+To allow access by a new user, use \fIxhost\fP.  For example,
+.nf
+    xhost keith@ ruth@mit.edu
+.fi
+adds "keith" from the NIS domain of the local machine, and "ruth" in
+the "mit.edu" NIS domain.  For keith or ruth to successfully connect
+to the display, they must add the principal who started the server to
+their \fI.Xauthority\fP file.  For example:
+.nf
+    xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
+.fi
+This system only works on machines which support Secure RPC, and only for
+users which have set up the appropriate public/private key pairs on their
+system.  See the Secure RPC documentation for details.
+To access the display from a remote host, you may have to do a
+\fIkeylogin\fP on the remote host first.
+.IP MIT-KERBEROS-5
+Kerberos is a network-based authentication scheme developed by MIT for
+Project Athena.  It allows mutually suspicious principals to
+authenticate each other as long as each trusts a third party,
+Kerberos.  Each principal has a secret key known only to it and
+Kerberos.  Principals includes servers, such as an FTP server or X
+server, and human users, whose key is their password.  Users gain
+access to services by getting Kerberos tickets for those services from
+a Kerberos server.  Since the X server has no place to store a secret
+key, it shares keys with the user who logs in.  X authentication thus
+uses the user-to-user scheme of Kerberos version 5.
+.IP
+When you log in via \fIxdm\fP, \fIxdm\fP will use your password to
+obtain the initial Kerberos tickets.  \fIxdm\fP stores the tickets in
+a credentials cache file and sets the environment variable
+\fIKRB5CCNAME\fP to point to the file.  The credentials cache is
+destroyed when the session ends to reduce the chance of the tickets
+being stolen before they expire.
+.IP
+Since Kerberos is a user-based authorization protocol, like the
+SUN-DES-1 protocol, the owner of a display can enable
+and disable specific users, or Kerberos principals.
+The \fIxhost\fP client is used to enable or disable authorization.
+For example,
+.nf
+    xhost krb5:judy krb5:gildea@x.org
+.fi
+adds "judy" from the Kerberos realm of the local machine, and "gildea"
+from the "x.org" realm.
+.IP "Server Interpreted"
+The Server Interpreted method provides two strings to the X server for
+entry in the access control list.  The first string represents the type 
+of entry, and the second string contains the value of the entry.  These
+strings are interpreted by the server and different implementations and
+builds may support different types of entries.  The types supported in
+the sample implementation are defined in the SERVER INTERPRETED ACCESS
+TYPES section below.   Entries of this type can be manipulated via
+\fIxhost\fP.  For example to add a Server Interpreted entry of type
+localuser with a value of root, the command is \fBxhost +si:localuser:root\fP.
+.SH "THE AUTHORIZATION FILE"
+.PP
+Except for Host Access control and Server Interpreted Access Control, each of 
+these systems uses data stored in
+the \fI.Xauthority\fP file to generate the correct authorization information
+to pass along to the X server at connection setup.  MIT-MAGIC-COOKIE-1 and
+XDM-AUTHORIZATION-1 store secret data in the file; so anyone who can read
+the file can gain access to the X server.  SUN-DES-1 stores only the
+identity of the principal who started the server
+(unix.\fIhostname\fP@\fIdomain\fP when the server is started by \fIxdm\fP),
+and so it is not useful to anyone not authorized to connect to the server.
+.PP
+Each entry in the \fI.Xauthority\fP file matches a certain connection family
+(TCP/IP, DECnet or local connections) and X display name (hostname plus display
+number).  This allows multiple authorization entries for different displays
+to share the same data file.  A special connection family (FamilyWild, value
+65535) causes an entry to match every display, allowing the entry to be used
+for all connections.  Each entry additionally contains the authorization
+name and whatever private authorization data is needed by that authorization
+type to generate the correct information at connection setup time.
+.PP
+The \fIxauth\fP program manipulates the \fI.Xauthority\fP file format.
+It understands the semantics of the connection families and address formats,
+displaying them in an easy to understand format.  It also understands that
+SUN-DES-1 and MIT-KERBEROS-5 use
+string values for the authorization data, and displays
+them appropriately.
+.PP
+The X server (when running on a workstation) reads authorization
+information from a file name passed on the command line with the \fI\-auth\fP
+option (see the \fIXserver\fP manual page).  The authorization entries in
+the file are used to control access to the server.  In each of the
+authorization schemes listed above, the data needed by the server to initialize
+an authorization scheme is identical to the data needed by the client to
+generate the appropriate authorization information, so the same file can be
+used by both processes.  This is especially useful when \fIxinit\fP is used.
+.IP "MIT-MAGIC-COOKIE-1"
+This system uses 128 bits of data shared between the user and the X server.
+Any collection of bits can be used.  \fIXdm\fP generates these keys using a
+cryptographically secure pseudo random number generator, and so the key to
+the next session cannot be computed from the current session key.
+.IP "XDM-AUTHORIZATION-1"
+This system uses two pieces of information.  First, 64 bits of random data,
+second a 56 bit DES encryption key (again, random data) stored
+in 8 bytes, the last byte of which is ignored.  \fIXdm\fP generates these keys
+using the same random number generator as is used for MIT-MAGIC-COOKIE-1.
+.IP "SUN-DES-1"
+This system needs a string representation of the principal which identifies
+the associated X server.
+This information is used to encrypt the client's authority information
+when it is sent to the X server.
+When \fIxdm\fP starts the X server, it uses the root
+principal for the machine on which it is running
+(unix.\fIhostname\fP@\fIdomain\fP, e.g.,
+"unix.expire.lcs.mit.edu@our.domain.edu").  Putting the correct principal
+name in the \fI.Xauthority\fP file causes Xlib to generate the appropriate
+authorization information using the secure RPC library.
+.IP "MIT-KERBEROS-5"
+Kerberos reads tickets from the cache pointed to by the
+\fIKRB5CCNAME\fP environment variable, so does not use any data from
+the \fI.Xauthority\fP file.  An entry with no data must still exist to tell
+clients that MIT-KERBEROS-5 is available.
+.IP
+Unlike the \fI.Xauthority\fP file for clients, the authority file
+passed by xdm to 
+a local X server (with ``\fB\-auth\fP \fIfilename\fP'', see xdm(1))
+does contain the name of the credentials cache, since 
+the X server will not have the 
+\fIKRB5CCNAME\fP environment variable set.
+The data of the MIT-KERBEROS-5 entry is the credentials cache name and
+has the form ``UU:FILE:\fIfilename\fP'', where \fIfilename\fP is the
+name of the credentials cache file created by xdm.  Note again that
+this form is \fInot\fP used by clients.
+.SH "SERVER INTERPRETED ACCESS TYPES"
+The sample implementation includes several Server Interpreted mechanisms:
+.nf
+.br
+.ta 3.4i
+    IPv6	IPv6 literal addresses
+    hostname	Network host name
+    localuser	Local connection user id
+    localgroup	Local connection group id
+.fi
+.IP "IPv6"
+A literal IPv6 address as defined in IETF RFC 3513.
+.IP "hostname"
+The value must be a hostname as defined in IETF RFC 2396. Due to Mobile IP
+and dynamic DNS, the name service is consulted at connection
+authentication time, unlike the traditional host access control list
+which only contains numeric addresses and does not automatically update when
+a host's address changes.  Note that this definition of hostname does
+not allow use of literal IP addresses.
+.IP "localuser & localgroup"
+On systems which can determine in a secure fashion the credentials of a client
+process, the "localuser" and "localgroup" authentication methods provide access
+based on those credentials.  The format of the values provided is platform
+specific.  For POSIX & UNIX platforms, if the value starts with the 
+character '#', the rest of the string is treated as a decimal uid or gid, 
+otherwise the string is defined as a user name or group name.
+.IP
+If your system supports this method and you use it, be warned that some
+programs that proxy connections and are setuid or setgid may get authenticated 
+as the uid or gid of the proxy process.  For instance, some versions of ssh
+will be authenticated as the user root, no matter what user is running the
+ssh client, so on systems with such software, adding access for localuser:root
+may allow wider access than intended to the X display.
+.SH FILES
+\&.Xauthority
+.SH "SEE ALSO"
+X(__miscmansuffix__), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)