Replace converted roff files with DocBook XML files

Gather the remaining DocBook XML files from www.osource.org/xorg/docbook.
Some will be build in this xorg-docs modules, other may be moved
closer to the module they document.

Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>

14 files changed, 16750 insertions, 10835 deletions

diff --git a/Makefile.am b/Makefile.am
index 1098fd3..cda473e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -34,9 +34,8 @@ EXTRA_DIST = \
 	specs/BDF/bdf.ms \
 	specs/BDF/fig1.ps \
 	specs/BDF/fig2.ps \
-	specs/CTEXT/ctext.tbl.ms \
-	specs/ICCCM/icccm.ms \
-	specs/ICCCM/indexmacros.t \
+	specs/CTEXT/ctext.xml \
+	specs/ICCCM/icccm.xml \
 	specs/RX/RX.mif \
 	specs/SIAddresses/hostname.txt \
 	specs/SIAddresses/IPv6.txt \
@@ -66,10 +65,10 @@ EXTRA_DIST = \
 	specs/XKB/XKBlib/fonts.fm5 \
 	specs/XKB/XKBlib/title.fm5 \
 	specs/XKB/XKBlib/XKBlib.book \
-	specs/XLFD/xlfd.tbl.ms \
-	specs/Xserver/analysis.tex \
-	specs/Xserver/appgroup.ms \
-	specs/Xserver/secint.tex \
+	specs/XLFD/xlfd.xml \
+	specs/Xserver/analysis.xml \
+	specs/Xserver/appgroup.xml \
+	specs/Xserver/secint.xml \
 	util/block.awk \
 	util/fixindex.awk \
 	util/indexmacros.t \
diff --git a/specs/CTEXT/ctext.tbl.ms b/specs/CTEXT/ctext.tbl.ms
deleted file mode 100644
index de9dc31..0000000
--- a/specs/CTEXT/ctext.tbl.ms
+++ /dev/null
@@ -1,450 +0,0 @@
-.\" $XdotOrg: xc/doc/specs/CTEXT/ctext.tbl.ms,v 1.2 2004/04/23 18:42:15 eich Exp $
-.\" Use tbl and -ms
-.sp 8
-.ce 5
-\s+2\fBCompound Text Encoding\fP\s-2
-.sp 6p
-Version 1.1
-X Consortium Standard
-X Version 11, Release 6.8
-Robert W. Scheifler
-.sp 2
-.LP
-Copyright \(co 1989 by X Consortium
-.LP
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the ``Software''), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-.LP
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-.LP
-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.
-.LP
-Except as contained in this notice, the name of the X Consortium shall not be
-used in advertising or otherwise to promote the sale, use or other dealings
-in this Software without prior written authorization from the X Consortium.
-.sp 2
-.NH 1
-Overview
-.LP
-Compound Text is a format for multiple character set data, such as
-multi-lingual text.  The format is based on ISO
-standards for encoding and combining character sets.  Compound Text is intended
-to be used in three main contexts: inter-client communication using selections,
-as defined in the \fIInter-Client Communication Conventions Manual\fP (ICCCM);
-window properties (e.g., window manager hints as defined in the ICCCM);
-and resources (e.g., as defined in Xlib and the Xt Intrinsics).
-.LP
-Compound Text is intended as an external representation, or interchange format,
-not as an internal representation.  It is expected (but not required) that
-clients will convert Compound Text to some internal representation for
-processing and rendering, and convert from that internal representation to
-Compound Text when providing textual data to another client.
-.NH 1
-Values
-.LP
-The name of this encoding is ``COMPOUND_TEXT''.  When text values are used in
-the ICCCM-compliant selection mechanism or are stored as window properties in
-the server, the type used should be the atom for ``COMPOUND_TEXT''.
-.LP
-Octet values are represented in this document as two decimal numbers in the
-form col/row.  This means the value (col * 16) + row.  For example, 02/01 means
-the value 33.
-.LP
-For our purposes, the octet encoding space is divided into four ranges:
-.RS
-.TS
-l l.
-C0	octets from 00/00 to 01/15
-GL	octets from 02/00 to 07/15
-C1	octets from 08/00 to 09/15
-GR	octets from 10/00 to 15/15
-.TE
-.RE
-.LP
-C0 and C1 are ``control character'' sets, while GL and GR are ``graphic
-character'' sets.  Only a subset of C0 and C1 octets are used in the encoding,
-and depending on the character set encoding defined as GL or GR, a subset of
-GL and GR octets may be used; see below for details.  All octets (00/00 to
-15/15) may appear inside the text of extended segments (defined below).
-.LP
-[For those familiar with ISO 2022, we will use only an 8-bit environment, and
-we will always use G0 for GL and G1 for GR.]
-.NH 1
-Control Characters
-.LP
-In C0, only the following values will be used:
-.RS
-.TS
-l l l.
-00/09	HT	HORIZONTAL TABULATION
-00/10	NL	NEW LINE
-01/11	ESC	(ESCAPE)
-.TE
-.RE
-.LP
-In C1, only the following value will be used:
-.RS
-.TS
-l l l.
-09/11	CSI	CONTROL SEQUENCE INTRODUCER
-.TE
-.RE
-.LP
-[The alternate 7-bit CSI encoding 01/11 05/11 is not used in Compound Text.]
-.LP
-No control sequences are defined in Compound Text for changing the C0 and C1
-sets.
-.LP
-A horizontal tab can be represented with the octet 00/09.  Specification of
-tabulation width settings is not part of Compound Text and must be obtained
-from context (in an unspecified manner).
-.LP
-[Inclusion of horizontal tab is for consistency with the STRING type currently
-defined in the ICCCM.]
-.LP
-A newline (line separator/terminator) can be represented with the octet 00/10.
-.LP
-[Note that 00/10 is normally LINEFEED, but is being interpreted as NEWLINE.
-This can be thought of as using the (deprecated) NEW LINE mode, E.1.3, in ISO
-6429.  Use of this value instead of 08/05 (NEL, NEXT LINE) is for consistency
-with the STRING type currently defined in the ICCCM.]
-.LP
-The remaining C0 and C1 values (01/11 and 09/11) are only used in the control
-sequences defined below.
-.NH 1
-Standard Character Set Encodings
-.LP
-The default GL and GR sets in Compound Text correspond to the left and right
-halves of ISO 8859-1 (Latin 1).  As such, any legal instance of a STRING type
-(as defined in the ICCCM) is also a legal instance of type COMPOUND_TEXT.
-.LP
-.nf
-[The implied initial state in ISO 2022 is defined with the sequence:
- 01/11 02/00 04/03  GO and G1 in an 8-bit environment only.  Designation also invokes.
- 01/11 02/00 04/07  In an 8-bit environment, C1 represented as 8-bits.
- 01/11 02/00 04/09  Graphic character sets can be 94 or 96.
- 01/11 02/00 04/11  8-bit code is used.
- 01/11 02/08 04/02  Designate ASCII into G0.
- 01/11 02/13 04/01  Designate right-hand part of ISO Latin-1 into G1.
-]
-.fi
-.LP
-To define one of the approved standard character set encodings to be
-the GL set, one of the following control sequences is used:
-.RS
-.TS
-l l.
-01/11 02/08 {I} F	94 character set
-01/11 02/04 02/08 {I} F	94\u\s-2N\s+2\d character set
-.TE
-.RE
-.LP
-To define one of the approved standard character set encodings to be
-the GR set, one of the following control sequences is used:
-.RS
-.TS
-l l.
-01/11 02/09 {I} F	94 character set
-01/11 02/13 {I} F	96 character set
-01/11 02/04 02/09 {I} F	94\u\s-2N\s+2\d character set
-.TE
-.RE
-.LP
-The ``F''in the control sequences above stands for ``Final character'', which
-is always in the range 04/00 to 07/14.  The ``{I}'' stands for zero or more
-``intermediate characters'', which are always in the range 02/00 to 02/15, with
-the first intermediate character always in the range 02/01 to 02/03.  The
-registration authority has defined an ``{I} F'' sequence for each registered
-character set encoding.
-.LP
-[Final characters for private encodings (in the range 03/00 to 03/15) are not
-permitted here in Compound Text.]
-.LP
-For GL, octet 02/00 is always defined as SPACE, and octet 07/15 (normally
-DELETE) is never used.  For a 94-character set defined as GR, octets 10/00 and
-15/15 are never used.
-.LP
-[This is consistent with ISO 2022.]
-.LP
-A 94\u\s-2N\s+2\d character set uses N octets (N > 1) for each character.
-The value of N is derived from the column value for F:
-.RS
-.TS
-l l.
-column 04 or 05	2 octets
-column 06	3 octets
-column 07	4 or more octets
-.TE
-.RE
-.LP
-In a 94\u\s-2N\s+2\d encoding, the octet values 02/00 and 07/15 (in GL) and
-10/00 and 15/15 (in GR) are never used.
-.LP
-[The column definitions come from ISO 2022.]
-.LP
-Once a GL or GR set has been defined, all further octets in that range (except
-within control sequences and extended segments) are interpreted with respect to
-that character set encoding, until the GL or GR set is redefined.  GL and GR
-sets can be defined independently, they do not have to be defined in pairs.
-.LP
-Note that when actually using a character set encoding as the GR set, you must
-force the most significant bit (08/00) of each octet to be a one, so that it
-falls in the range 10/00 to 15/15.
-.LP
-[Control sequences to specify character set encoding revisions (as in section
-6.3.13 of ISO 2022) are not used in Compound Text.  Revision indicators do not
-appear to provide useful information in the context of Compound Text.  The most
-recent revision can always be assumed, since revisions are upward compatible.]
-.NH 1
-Approved Standard Encodings
-.LP
-The following are the approved standard encodings to be used with Compound
-Text.  Note that none have Intermediate characters; however, a good parser will
-still deal with Intermediate characters in the event that additional encodings
-are later added to this list.
-.RS
-.TS
-l l l.
-_
-.sp 4p
-\fB{I} F\fP	\fB94/96\fP	\fBDescription\fP
-.sp 4p
-_
-.sp 6p
-4/02	94	7-bit ASCII graphics (ANSI X3.4-1968),
-		Left half of ISO 8859 sets
-04/09	94	Right half of JIS X0201-1976 (reaffirmed 1984),
-		8-Bit Alphanumeric-Katakana Code
-04/10	94	Left half of JIS X0201-1976 (reaffirmed 1984),
-		8-Bit Alphanumeric-Katakana Code
-.sp 6p
-04/01	96	Right half of ISO 8859-1, Latin alphabet No. 1
-04/02	96	Right half of ISO 8859-2, Latin alphabet No. 2
-04/03	96	Right half of ISO 8859-3, Latin alphabet No. 3
-04/04	96	Right half of ISO 8859-4, Latin alphabet No. 4
-04/06	96	Right half of ISO 8859-7, Latin/Greek alphabet
-04/07	96	Right half of ISO 8859-6, Latin/Arabic alphabet
-04/08	96	Right half of ISO 8859-8, Latin/Hebrew alphabet
-04/12	96	Right half of ISO 8859-5, Latin/Cyrillic alphabet
-04/13	96	Right half of ISO 8859-9, Latin alphabet No. 5
-.sp 6p
-04/01	94\u\s-22\s+2\d	GB2312-1980, China (PRC) Hanzi
-04/02	94\u\s-22\s+2\d	JIS X0208-1983, Japanese Graphic Character Set
-04/03	94\u\s-22\s+2\d	KS C5601-1987, Korean Graphic Character Set
-.sp 6p
-_
-.TE
-.RE
-.LP
-The sets listed as ``Left half of ...'' should always be defined as GL.  The
-sets listed as ``Right half of ...'' should always be defined as GR.  Other
-sets can be defined either as GL or GR.
-.NH 1
-Non-Standard Character Set Encodings
-.LP
-Character set encodings that are not in the list of approved standard
-encodings can be included
-using ``extended segments''.  An extended segment begins with one of the
-following sequences:
-.RS
-.TS
-l l.
-01/11 02/05 02/15 03/00 M L	variable number of octets per character
-01/11 02/05 02/15 03/01 M L	1 octet per character
-01/11 02/05 02/15 03/02 M L	2 octets per character
-01/11 02/05 02/15 03/03 M L	3 octets per character
-01/11 02/05 02/15 03/04 M L	4 octets per character
-.TE
-.RE
-[This uses the ``other coding system'' of ISO 2022, using private Final
-characters.]
-.LP
-The ``M'' and ``L'' octets represent a 14-bit unsigned value giving the number
-of octets that appear in the remainder of the segment.  The number is computed
-as ((M - 128) * 128) + (L - 128).  The most significant bit M and L are always
-set to one.  The remainder of the segment consists of two parts, the name of
-the character set encoding and the actual text.  The name of the encoding comes
-first and is separated from the text by the octet 00/02 (STX, START OF TEXT).
-Note that the length defined by M and L includes the encoding name and
-separator.
-.LP
-[The encoding of the length is chosen to avoid having zero octets in Compound
-Text when possible, because embedded NUL values are problematic in many C
-language routines.  The use of zero octets cannot be ruled out entirely
-however, since some octets in the actual text of the extended segment may have
-to be zero.]
-.LP
-The name of the encoding should be registered with the X Consortium to avoid
-conflicts and should when appropriate match the CharSet Registry and Encoding
-registration used in the X Logical Font Description.  The name itself should be
-encoded using ISO 8859-1 (Latin 1), should not use question mark (03/15) or
-asterisk (02/10), and should use hyphen (02/13) only in accordance with the X
-Logical Font Description.
-.LP
-Extended segments are not to be used for any character set encoding that can
-be constructed from a GL/GR pair of approved standard encodings. For
-example, it is incorrect to use an extended segment for any of the ISO 8859
-family of encodings.
-.LP
-It should be noted that the contents of an extended segment are arbitrary;
-for example,
-they may contain octets in the C0 and C1 ranges, including 00/00, and
-octets comprising a given character may differ in their most significant bit.
-.LP
-[ISO-registered ``other coding systems'' are not used in Compound Text;
-extended segments are the only mechanism for non-2022 encodings.]
-.NH 1
-Directionality
-.LP
-If desired, horizontal text direction can be indicated using the following
-control sequences:
-.RS
-.TS
-l l.
-09/11 03/01 05/13	begin left-to-right text
-09/11 03/02 05/13	begin right-to-left text
-09/11 05/13	end of string
-.TE
-.RE
-.LP
-[This is a subset of the SDS (START DIRECTED STRING) control in the Draft
-Bidirectional Addendum to ISO 6429.]
-.LP
-Directionality can be nested.  Logically, a stack of directions is maintained.
-Each of the first two control sequences pushes a new direction on the stack,
-and the third sequence (revert) pops a direction from the stack.  The stack
-starts out empty at the beginning of a Compound Text string.  When the stack is
-empty, the directionality of the text is unspecified.
-.LP
-Directionality applies to all subsequent text, whether in GL, GR, or an
-extended segment.  If the desired directionality of GL, GR, or extended
-segments differs, then directionality control sequences must be inserted when
-switching between them.
-.LP
-Note that definition of GL and GR sets is independent of directionality;
-defining a new GL or GR set does not change the current directionality, and
-pushing or popping a directionality does not change the current GL and GR
-definitions.
-.LP
-Specification of directionality is entirely optional; text direction should be
-clear from context in most cases.  However, it must be the case that either
-all characters in a Compound Text string have explicitly specified direction
-or that all characters have unspecified direction.  That is, if directionality
-control sequences are used, the first such control sequence must precede the
-first graphic character in a Compound Text string, and graphic characters are
-not permitted whenever the directionality stack is empty.
-.NH 1
-Resources
-.LP
-To use Compound Text in a resource, you can simply treat all octets as if they
-were ASCII/Latin-1 and just replace all ``\\'' octets (05/12) with the two
-octets ``\\\\'', all newline octets (00/10) with the two octets ``\\n'', and
-all zero octets with the four octets ``\\000''.
-It is up to the client making use of the resource to interpret the data as
-Compound Text; the policy by which this is ascertained is not constrained by
-the Compound Text specification.
-.NH 1
-Font Names
-.LP
-The following CharSet names for the standard character set encodings are
-registered for use in font names under the X Logical Font Description:
-.RS
-.TS
-l l l.
-_
-.sp 6p
-\fBName\fP	\fBEncoding Standard\fP	\fBDescription\fP
-.sp 6p
-_
-.sp 6p
-ISO8859-1	ISO 8859-1	Latin alphabet No. 1
-ISO8859-2	ISO 8859-2	Latin alphabet No. 2
-ISO8859-3	ISO 8859-3	Latin alphabet No. 3
-ISO8859-4	ISO 8859-4	Latin alphabet No. 4
-ISO8859-5	ISO 8859-5	Latin/Cyrillic alphabet
-ISO8859-6	ISO 8859-6	Latin/Arabic alphabet
-ISO8859-7	ISO 8859-7	Latin/Greek alphabet
-ISO8859-8	ISO 8859-8	Latin/Hebrew alphabet
-ISO8859-9	ISO 8859-9	Latin alphabet No. 5
-JISX0201.1976-0	JIS X0201-1976 (reaffirmed 1984)	8-bit Alphanumeric-Katakana Code
-GB2312.1980-0	GB2312-1980, GL encoding	China (PRC) Hanzi
-JISX0208.1983-0	JIS X0208-1983, GL encoding	Japanese Graphic Character Set
-KSC5601.1987-0	KS C5601-1987, GL encoding	Korean Graphic Character Set
-.sp 6p
-_
-.TE
-.RE
-.LP
-.NH 1
-Extensions
-.LP
-There is no absolute requirement for a parser to deal with anything but the
-particular encoding syntax defined in this specification.  However, it is
-possible that Compound Text may be extended in the future, and as such it may
-be desirable to construct the parser to handle 2022/6429 syntax more generally.
-.LP
-There are two general formats covering all control sequences that are expected
-to appear in extensions:
-.LP
-01/11 {I} F
-.IP
-For this format, I is always in the range 02/00 to 02/15, and F is always
-in the range 03/00 to 07/14.
-.LP
-09/11 {P} {I} F
-.IP
-For this format, P is always in the range 03/00 to 03/15, I is always in
-the range 02/00 to 02/15, and F is always in the range 04/00 to 07/14.
-.LP
-In addition, new (singleton) control characters (in the C0 and C1 ranges) might
-be defined in the future.
-.LP
-Finally, new kinds of ``segments'' might be defined in the future using syntax
-similar to extended segments:
-.LP
-01/11 02/05 02/15 F M L
-.IP
-For this format, F is in the range 03/05 to 3/15.  M and L are as defined
-in extended segments.  Such a segment will always be followed by the number
-of octets defined by M and L.  These octets can have arbitrary values and
-need not follow the internal structure defined for current extended
-segments.
-.LP
-If extensions to this specification are defined in the future, then any string
-incorporating instances of such extensions must start with one of the following
-control sequences:
-.RS
-.TS
-l l.
-01/11 02/03 V 03/00	ignoring extensions is OK
-01/11 02/03 V 03/01	ignoring extensions is not OK
-.TE
-.RE
-.LP
-In either case, V is in the range 02/00 to 02/15 and indicates the major
-version
-minus one of the specification being used.  These version control sequences are
-for use by clients that implement earlier versions, but have implemented a
-general parser.  The first control sequence indicates that it is acceptable to
-ignore all extension control sequences; no mandatory information will be lost
-in the process.  The second control sequence indicates that it is unacceptable
-to ignore any extension control sequences; mandatory information would be lost
-in the process.  In general, it will be up to the client generating the
-Compound Text to decide which control sequence to use.
-.NH 1
-Errors
-.LP
-If a Compound Text string does not match the specification here (e.g., uses
-undefined control characters, or undefined control sequences, or incorrectly
-formatted extended segments), it is best to treat the entire string as invalid,
-except as indicated by a version control sequence.
diff --git a/specs/CTEXT/ctext.xml b/specs/CTEXT/ctext.xml
new file mode 100644
index 0000000..6b534ae
--- /dev/null
+++ b/specs/CTEXT/ctext.xml
@@ -0,0 +1,879 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="ctext">
+
+<bookinfo>
+   <title>Compound Text Encoding</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.8</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>Robert</firstname><othername>W.</othername><surname>Scheifler</surname>
+      </author>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1989</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 1.1</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+
+<legalnotice>
+<para>
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+</para>
+
+<para>
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+Except as contained in this notice, the name of the X Consortium shall not be
+used in advertising or otherwise to promote the sale, use or other dealings
+in this Software without prior written authorization from the X Consortium.
+</para>
+</legalnotice>
+</bookinfo>
+<chapter id="title">
+<title>TITLE</title>
+<sect1 id="Overview">
+<title>Overview</title>
+
+<para>
+Compound Text is a format for multiple character set data, such as
+multi-lingual text.  The format is based on ISO
+standards for encoding and combining character sets.  Compound Text is intended
+to be used in three main contexts: inter-client communication using selections,
+as defined in the
+<emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis>
+(ICCCM); <!-- xref -->
+window properties (e.g., window manager hints as defined in the ICCCM);
+and resources (e.g., as defined in Xlib and the Xt Intrinsics).
+</para>
+
+<para>
+Compound Text is intended as an external representation, or interchange format,
+not as an internal representation.  It is expected (but not required) that
+clients will convert Compound Text to some internal representation for
+processing and rendering, and convert from that internal representation to
+Compound Text when providing textual data to another client.
+</para>
+</sect1>
+
+<sect1 id="Values">
+<title>Values</title>
+<para>
+<!-- .LP -->
+The name of this encoding is "COMPOUND_TEXT".  When text values are used in
+the ICCCM-compliant selection mechanism or are stored as window properties in
+the server, the type used should be the atom for "COMPOUND_TEXT".
+</para>
+
+<para>
+<!-- .LP -->
+Octet values are represented in this document as two decimal numbers in the
+form col/row.  This means the value (col * 16) + row.  For example, 02/01 means
+the value 33.
+</para>
+<para>
+For our purposes, the octet encoding space is divided into four ranges:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="9*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>C0</entry>
+      <entry>octets from 00/00 to 01/15</entry>
+    </row>
+    <row rowsep="0">
+      <entry>GL</entry>
+      <entry>octets from 02/00 to 07/15</entry>
+    </row>
+    <row rowsep="0">
+      <entry>C1</entry>
+      <entry>octets from 08/00 to 09/15</entry>
+    </row>
+    <row rowsep="0">
+      <entry>GR</entry>
+      <entry>octets from 10/00 to 15/15</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+C0 and C1 are "control character" sets, while GL and GR are "graphic
+character" sets.  Only a subset of C0 and C1 octets are used in the encoding,
+and depending on the character set encoding defined as GL or GR, a subset of
+GL and GR octets may be used; see below for details.  All octets (00/00 to
+15/15) may appear inside the text of extended segments (defined below).
+</para>
+<para>
+<!-- .LP -->
+[For those familiar with ISO 2022, we will use only an 8-bit environment, and
+we will always use G0 for GL and G1 for GR.]
+</para>
+</sect1>
+
+<sect1 id="Control_Characters">
+<title>Control Characters</title>
+<para>
+In C0, only the following values will be used:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="5*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>00/09</entry>
+      <entry>HT</entry>
+      <entry>HORIZONTAL TABULATION</entry>
+    </row>
+    <row rowsep="0">
+      <entry>00/10</entry>
+      <entry>NL</entry>
+      <entry>NEW LINE</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>ESC</entry>
+      <entry>(ESCAPE)</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+In C1, only the following value will be used:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="5*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>09/11</entry>
+      <entry>CSI</entry>
+      <entry>CONTROL SEQUENCE INTRODUCER</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+[The alternate 7-bit CSI encoding 01/11 05/11 is not used in Compound Text.]
+</para>
+<para>
+<!-- .LP -->
+No control sequences are defined in Compound Text for changing the C0 and C1
+sets.
+</para>
+<para>
+<!-- .LP -->
+A horizontal tab can be represented with the octet 00/09.  Specification of
+tabulation width settings is not part of Compound Text and must be obtained
+from context (in an unspecified manner).
+</para>
+<para>
+<!-- .LP -->
+[Inclusion of horizontal tab is for consistency with the STRING type currently
+defined in the ICCCM.]
+</para>
+<para>
+<!-- .LP -->
+A newline (line separator/terminator) can be represented with the octet 00/10.
+</para>
+<para>
+<!-- .LP -->
+[Note that 00/10 is normally LINEFEED, but is being interpreted as NEWLINE.
+This can be thought of as using the (deprecated) NEW LINE mode, E.1.3, in ISO
+6429.  Use of this value instead of 08/05 (NEL, NEXT LINE) is for consistency
+with the STRING type currently defined in the ICCCM.]
+</para>
+<para>
+<!-- .LP -->
+The remaining C0 and C1 values (01/11 and 09/11) are only used in the control
+sequences defined below.
+</para>
+</sect1>
+
+<sect1 id="Standard_Character_Set_Encodings">
+<title>Standard Character Set Encodings</title>
+<para>
+<!-- .LP -->
+The default GL and GR sets in Compound Text correspond to the left and right
+halves of ISO 8859-1 (Latin 1).  As such, any legal instance of a STRING type
+(as defined in the ICCCM) is also a legal instance of type COMPOUND_TEXT.
+</para>
+<para>
+[The implied initial state in ISO 2022 is defined with the sequence:
+ 01/11 02/00 04/03  GO and G1 in an 8-bit environment only.  Designation also invokes.
+ 01/11 02/00 04/07  In an 8-bit environment, C1 represented as 8-bits.
+ 01/11 02/00 04/09  Graphic character sets can be 94 or 96.
+ 01/11 02/00 04/11  8-bit code is used.
+ 01/11 02/08 04/02  Designate ASCII into G0.
+ 01/11 02/13 04/01  Designate right-hand part of ISO Latin-1 into G1.
+]
+</para>
+
+<para>
+To define one of the approved standard character set encodings to be
+the GL set, one of the following control sequences is used:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="2*"/>
+  <colspec colname='c4' colsep="0" colwidth="8*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>02/08</entry>
+      <entry>{I} F</entry>
+      <entry>94 character set</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>02/04</entry>
+      <entry>02/08{I} F</entry>
+      <entry>94<superscript>N</superscript> character set</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+To define one of the approved standard character set encodings to be
+the GR set, one of the following control sequences is used:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="2*"/>
+  <colspec colname='c4' colsep="0" colwidth="8*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>02/09</entry>
+      <entry>{I} F</entry>
+      <entry>94 character set</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>02/13</entry>
+      <entry>{I} F</entry>
+      <entry>96 character set</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11</entry>
+      <entry>02/04</entry>
+      <entry>02/09 {I} F</entry>
+      <entry>94<superscript>N</superscript> character set</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+The "F"in the control sequences above stands for "Final character", which
+is always in the range 04/00 to 07/14.  The "{I}" stands for zero or more
+"intermediate characters", which are always in the range 02/00 to 02/15, with
+the first intermediate character always in the range 02/01 to 02/03.  The
+registration authority has defined an "{I} F" sequence for each registered
+character set encoding.
+</para>
+
+<para>
+<!-- .LP -->
+[Final characters for private encodings (in the range 03/00 to 03/15) are not
+permitted here in Compound Text.]
+</para>
+<para>
+<!-- .LP -->
+For GL, octet 02/00 is always defined as SPACE, and octet 07/15 (normally
+DELETE) is never used.  For a 94-character set defined as GR, octets 10/00 and
+15/15 are never used.
+</para>
+<para>
+<!-- .LP -->
+[This is consistent with ISO 2022.]
+</para>
+<para>
+<!-- .LP -->
+A 94<superscript>N</superscript> character set uses N octets (N &gt; 1) for each character.
+The value of N is derived from the column value for F:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="3*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>column 04 or 05</entry>
+      <entry>2 octets</entry>
+    </row>
+    <row rowsep="0">
+      <entry>column 06</entry>
+      <entry>3 octets</entry>
+    </row>
+    <row rowsep="0">
+      <entry>column 07</entry>
+      <entry>4 or more octets</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<para>
+<!-- .LP -->
+In a 94<superscript>N</superscript> encoding, the octet values 02/00 and 07/15 (in GL) and
+10/00 and 15/15 (in GR) are never used.
+</para>
+<para>
+<!-- .LP -->
+[The column definitions come from ISO 2022.]
+</para>
+<para>
+<!-- .LP -->
+Once a GL or GR set has been defined, all further octets in that range (except
+within control sequences and extended segments) are interpreted with respect to
+that character set encoding, until the GL or GR set is redefined.  GL and GR
+sets can be defined independently, they do not have to be defined in pairs.
+</para>
+<para>
+<!-- .LP -->
+Note that when actually using a character set encoding as the GR set, you must
+force the most significant bit (08/00) of each octet to be a one, so that it
+falls in the range 10/00 to 15/15.
+</para>
+<para>
+<!-- xref -->
+[Control sequences to specify character set encoding revisions (as in section
+6.3.13 of ISO 2022) are not used in Compound Text.  Revision indicators do not
+appear to provide useful information in the context of Compound Text.  The most
+recent revision can always be assumed, since revisions are upward compatible.]
+</para>
+</sect1>
+
+<sect1 id="Approved_Standard_Encodings">
+<title>Approved Standard Encodings</title>
+<para>
+The following are the approved standard encodings to be used with Compound
+Text.  Note that none have Intermediate characters; however, a good parser will
+still deal with Intermediate characters in the event that additional encodings
+are later added to this list.
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="5*"/>
+  <thead>
+    <row>
+      <entry>{I} F</entry>
+      <entry>94/96</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>4/02</entry>
+      <entry>94</entry>
+      <entry>
+7-bit ASCII graphics (ANSI X3.4-1968), Left half of ISO 8859 sets
+      </entry>
+    </row>
+    <row>
+      <entry>04/09</entry>
+      <entry>94</entry>
+      <entry>
+Right half of JIS X0201-1976 (reaffirmed 1984),
+8-Bit Alphanumeric-Katakana Code
+      </entry>
+    </row>
+    <row>
+      <entry>04/10</entry>
+      <entry>94</entry>
+      <entry>
+Left half of JIS X0201-1976 (reaffirmed 1984),
+8-Bit Alphanumeric-Katakana Code
+      </entry>
+    </row>
+    <row>
+      <entry>04/01</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-1, Latin alphabet No. 1</entry>
+    </row>
+    <row>
+      <entry>04/02</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-2, Latin alphabet No. 2</entry>
+    </row>
+    <row>
+      <entry>04/03</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-3, Latin alphabet No. 3</entry>
+    </row>
+    <row>
+      <entry>04/04</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-4, Latin alphabet No. 4</entry>
+    </row>
+    <row>
+      <entry>04/06</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-7, Latin/Greek alphabet</entry>
+    </row>
+    <row>
+      <entry>04/07</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-6, Latin/Arabic alphabet</entry>
+    </row>
+    <row>
+      <entry>04/08</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-8, Latin/Hebrew alphabet</entry>
+    </row>
+    <row>
+      <entry>04/12</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-5, Latin/Cyrillic alphabet</entry>
+    </row>
+    <row>
+      <entry>04/13</entry>
+      <entry>96</entry>
+      <entry>Right half of ISO 8859-9, Latin alphabet No. 5</entry>
+    </row>
+    <row>
+      <entry>04/01</entry>
+      <entry>942</entry>
+      <entry>GB2312-1980, China (PRC) Hanzi</entry>
+    </row>
+    <row>
+      <entry>04/02</entry>
+      <entry>942</entry>
+      <entry>JIS X0208-1983, Japanese Graphic Character Set</entry>
+    </row>
+    <row>
+      <entry>04/03</entry>
+      <entry>942</entry>
+      <entry>KS C5601-1987, Korean Graphic Character Set</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+The sets listed as "Left half of ..." should always be defined as GL.  The
+sets listed as "Right half of ..." should always be defined as GR.  Other
+sets can be defined either as GL or GR.
+</para>
+</sect1>
+
+<sect1 id="Non_Standard_Character_Set_Encodings">
+<title>Non-Standard Character Set Encodings</title>
+<para>
+Character set encodings that are not in the list of approved standard
+encodings can be included
+using "extended segments".  An extended segment begins with one of the
+following sequences:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="2*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>01/11 2/05 02/15 03/00 M L</entry>
+      <entry>variable number of octets per character</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11 2/05 02/15 03/01 M L</entry>
+      <entry>1 octet per character</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11 2/05 02/15 03/02 M L</entry>
+      <entry>2 octet per character</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11 2/05 02/15 03/03 M L</entry>
+      <entry>3 octet per character</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11 2/05 02/15 03/04 M L</entry>
+      <entry>4 octet per character</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+[This uses the "other coding system" of ISO 2022, using private Final
+characters.]
+</para>
+<para>
+<!-- .LP -->
+The "M" and "L" octets represent a 14-bit unsigned value giving the number
+of octets that appear in the remainder of the segment.  The number is computed
+as ((M - 128) * 128) + (L - 128).  The most significant bit M and L are always
+set to one.  The remainder of the segment consists of two parts, the name of
+the character set encoding and the actual text.  The name of the encoding comes
+first and is separated from the text by the octet 00/02 (STX, START OF TEXT).
+Note that the length defined by M and L includes the encoding name and
+separator.
+</para>
+<para>
+<!-- .LP -->
+[The encoding of the length is chosen to avoid having zero octets in Compound
+Text when possible, because embedded NUL values are problematic in many C
+language routines.  The use of zero octets cannot be ruled out entirely
+however, since some octets in the actual text of the extended segment may have
+to be zero.]
+</para>
+<para>
+<!-- .LP -->
+The name of the encoding should be registered with the X Consortium to avoid
+conflicts and should when appropriate match the CharSet Registry and Encoding
+registration used in the X Logical Font Description.  The name itself should be
+encoded using ISO 8859-1 (Latin 1), should not use question mark (03/15) or
+asterisk (02/10), and should use hyphen (02/13) only in accordance with the X
+Logical Font Description.
+</para>
+<para>
+<!-- .LP -->
+Extended segments are not to be used for any character set encoding that can
+be constructed from a GL/GR pair of approved standard encodings. For
+example, it is incorrect to use an extended segment for any of the ISO 8859
+family of encodings.
+</para>
+<para>
+<!-- .LP -->
+It should be noted that the contents of an extended segment are arbitrary;
+for example,
+they may contain octets in the C0 and C1 ranges, including 00/00, and
+octets comprising a given character may differ in their most significant bit.
+</para>
+<para>
+<!-- .LP -->
+[ISO-registered "other coding systems" are not used in Compound Text;
+extended segments are the only mechanism for non-2022 encodings.]
+</para>
+</sect1>
+
+<sect1 id="Directionality">
+<title>Directionality</title>
+<para>
+<!-- .LP -->
+If desired, horizontal text direction can be indicated using the following
+control sequences:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="2*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>09/11 03/01 05/13</entry>
+      <entry>begin left-to-right text</entry>
+    </row>
+    <row rowsep="0">
+      <entry>09/11 03/02 05/13</entry>
+      <entry>begin right-to-left text</entry>
+    </row>
+    <row rowsep="0">
+      <entry>09/11 05/13</entry>
+      <entry>end of string</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+[This is a subset of the SDS (START DIRECTED STRING) control in the Draft
+Bidirectional Addendum to ISO 6429.]
+</para>
+<para>
+<!-- .LP -->
+Directionality can be nested.  Logically, a stack of directions is maintained.
+Each of the first two control sequences pushes a new direction on the stack,
+and the third sequence (revert) pops a direction from the stack.  The stack
+starts out empty at the beginning of a Compound Text string.  When the stack is
+empty, the directionality of the text is unspecified.
+</para>
+<para>
+<!-- .LP -->
+Directionality applies to all subsequent text, whether in GL, GR, or an
+extended segment.  If the desired directionality of GL, GR, or extended
+segments differs, then directionality control sequences must be inserted when
+switching between them.
+</para>
+<para>
+<!-- .LP -->
+Note that definition of GL and GR sets is independent of directionality;
+defining a new GL or GR set does not change the current directionality, and
+pushing or popping a directionality does not change the current GL and GR
+definitions.
+</para>
+<para>
+<!-- .LP -->
+Specification of directionality is entirely optional; text direction should be
+clear from context in most cases.  However, it must be the case that either
+all characters in a Compound Text string have explicitly specified direction
+or that all characters have unspecified direction.  That is, if directionality
+control sequences are used, the first such control sequence must precede the
+first graphic character in a Compound Text string, and graphic characters are
+not permitted whenever the directionality stack is empty.
+</para>
+</sect1>
+
+<sect1 id="Resources">
+<title>Resources</title>
+<para>
+<!-- .LP -->
+To use Compound Text in a resource, you can simply treat all octets as if they
+were ASCII/Latin-1 and just replace all "\" octets (05/12) with the two
+octets "\\", all newline octets (00/10) with the two octets "\n", and
+all zero octets with the four octets "\000".
+It is up to the client making use of the resource to interpret the data as
+Compound Text; the policy by which this is ascertained is not constrained by
+the Compound Text specification.
+</para>
+</sect1>
+
+<sect1 id="Font_Names">
+<title>Font Names</title>
+
+<para>
+The following CharSet names for the standard character set encodings are
+registered for use in font names under the X Logical Font Description:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="1*"/>
+  <colspec colname='c3' colsep="0" colwidth="2*"/>
+  <thead>
+    <row>
+      <entry>Name</entry>
+      <entry>Encoding Standard</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>ISO8859-1</entry>
+      <entry>ISO8859-1</entry>
+      <entry>Latinalphabet No. 1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-2</entry>
+      <entry>ISO8859-2</entry>
+      <entry>Latinalphabet No. 2</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-3</entry>
+      <entry>ISO8859-3</entry>
+      <entry>Latinalphabet No. 3</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-4</entry>
+      <entry>ISO8859-4</entry>
+      <entry>Latinalphabet No. 4</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-5</entry>
+      <entry>ISO 8859-5</entry>
+      <entry>Latin/Cyrillic alphabet</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-6</entry>
+      <entry>ISO 8859-6</entry>
+      <entry>Latin/Arabic alphabet</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-7</entry>
+      <entry>ISO8859-7</entry>
+      <entry>Latin/Greekalphabet</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-8</entry>
+      <entry>ISO8859-8</entry>
+      <entry>Latin/Hebrew alphabet</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ISO8859-9</entry>
+      <entry>ISO8859-9</entry>
+      <entry>Latinalphabet No. 5</entry>
+    </row>
+    <row rowsep="0">
+      <entry>JISX0201.1976-0</entry>
+      <entry>JIS X0201-1976 (reafŒrmed 1984)</entry>
+      <entry>8-bit Alphanumeric-Katakana Code</entry>
+    </row>
+    <row rowsep="0">
+      <entry>GB2312.1980-0</entry>
+      <entry>GB2312-1980, GL encoding</entry>
+      <entry>China (PRC) Hanzi</entry>
+    </row>
+    <row rowsep="0">
+      <entry>JISX0208.1983-0</entry>
+      <entry>JIS X0208-1983, GL encoding</entry>
+      <entry>Japanese Graphic Character Set</entry>
+    </row>
+    <row rowsep="0">
+      <entry>KSC5601.1987-0</entry>
+      <entry>KS C5601-1987, GL encoding</entry>
+      <entry>Korean Graphic Character Set</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+</sect1>
+<sect1 id="Extensions">
+<title>Extensions</title>
+<para>
+<!-- .LP -->
+There is no absolute requirement for a parser to deal with anything but the
+particular encoding syntax defined in this specification.  However, it is
+possible that Compound Text may be extended in the future, and as such it may
+be desirable to construct the parser to handle 2022/6429 syntax more generally.
+</para>
+<para>
+<!-- .LP -->
+There are two general formats covering all control sequences that are expected
+to appear in extensions:
+</para>
+
+<para>
+01/11 {I} F
+</para>
+
+<para>
+For this format, I is always in the range 02/00 to 02/15, and F is always
+in the range 03/00 to 07/14.
+</para>
+
+<para>
+09/11 {P} {I} F
+</para>
+
+<para>
+For this format, P is always in the range 03/00 to 03/15, I is always in
+the range 02/00 to 02/15, and F is always in the range 04/00 to 07/14.
+</para>
+
+<para>
+<!-- .LP -->
+In addition, new (singleton) control characters (in the C0 and C1 ranges) might
+be defined in the future.
+</para>
+
+<para>
+<!-- .LP -->
+Finally, new kinds of "segments" might be defined in the future using syntax
+similar to extended segments:
+</para>
+
+<para>
+01/11 02/05 02/15 F M L
+</para>
+
+<para>
+For this format, F is in the range 03/05 to 3/15.  M and L are as defined
+in extended segments.  Such a segment will always be followed by the number
+of octets defined by M and L.  These octets can have arbitrary values and
+need not follow the internal structure defined for current extended
+segments.
+</para>
+
+<para>
+<!-- .LP -->
+If extensions to this specification are defined in the future, then any string
+incorporating instances of such extensions must start with one of the following
+control sequences:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0" colwidth="1*"/>
+  <colspec colname='c2' colsep="0" colwidth="2*"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>01/11 02/03 V 03/00</entry>
+      <entry>ignoring extensions is OK</entry>
+    </row>
+    <row rowsep="0">
+      <entry>01/11 02/03 V 03/01</entry>
+      <entry>ignoring extensions is not OK</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+In either case, V is in the range 02/00 to 02/15 and indicates the major
+version
+minus one of the specification being used.  These version control sequences are
+for use by clients that implement earlier versions, but have implemented a
+general parser.  The first control sequence indicates that it is acceptable to
+ignore all extension control sequences; no mandatory information will be lost
+in the process.  The second control sequence indicates that it is unacceptable
+to ignore any extension control sequences; mandatory information would be lost
+in the process.  In general, it will be up to the client generating the
+Compound Text to decide which control sequence to use.
+</para>
+</sect1>
+
+<sect1 id="Errors">
+<title>Errors</title>
+<para>
+<!-- .LP -->
+If a Compound Text string does not match the specification here (e.g., uses
+undefined control characters, or undefined control sequences, or incorrectly
+formatted extended segments), it is best to treat the entire string as invalid,
+except as indicated by a version control sequence.
+</para>
+</sect1>
+</chapter>
+</book>
diff --git a/specs/ICCCM/icccm.ms b/specs/ICCCM/icccm.ms
deleted file mode 100644
index e62d78f..0000000
--- a/specs/ICCCM/icccm.ms
+++ /dev/null
@@ -1,5721 +0,0 @@
-.\" $Xorg: icccm.ms,v 1.3 2000/08/17 19:42:08 cpqbld Exp $
-.\" $XdotOrg: xc/doc/specs/ICCCM/icccm.ms,v 1.2 2004/04/23 18:42:15 eich Exp $
-.\" Use tbl, eqn, -ms, and macros.t
-.\" @(#)icccm.ms	1.50	16 Apr 1994	14:13:55
-.EH ''''
-.OH ''''
-.EF ''''
-.OF ''''
-.ps 11
-.nr PS 11
-.hw time-stamp
-.\"
-.\" --- bP --- bulleted paragraph macro
-.\"
-.de bP
-.IP \(bu 4
-..
-.\"
-.\" --- cT --- centered title; centers $1, adds TOC entry unless $2 is "no"
-.\"
-.de cT
-\\&		\" filler so that the following .sp really leaves a space
-.sp 1
-.ce 1
-\\s+1\\fB\\$1\\fP\\s-1
-.sp 1
-.if !'\\$2'no' \{\
-.XS \\n(PN
-\\$1
-.XE
-\}
-..
-.\"
-.\" --- dA --- double arrow string
-.\"
-.ds dA "\o'\(<-\(->'
-\&
-.sp 8
-.ce 9999
-.B
-\s+2Inter-Client Communication Conventions Manual\s0
-
-Version 2.0
-
-X Consortium Standard
-
-X Version 11, Release 6.8
-.R
-.ce 0
-.sp 6
-.ce 9999
-\s+1David Rosenthal\s0
-.sp 6p
-\s+1Sun Microsystems, Inc.\s0
-.sp 2
-\s+1Version 2 edited by Stuart W. Marks\s0
-.sp 6p
-\s+1SunSoft, Inc.\s0
-.ce 0
-.bp
-\&
-.ps 9
-.nr PS 9
-.sp 8
-.LP
-X Window System is a trademark of The Open Group
-.LP             
-.LP
-Copyright \(co 1988, 1991, 1993, 1994
-X Consortium
-.LP
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-.LP
-The above copyright notice and this permission notice shall be included
-in all copies or substantial portions of the Software.
-.LP
-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.
-.LP
-Except as contained in this notice, the name of the X Consortium shall
-not be used in advertising or otherwise to promote the sale, use or
-other dealings in this Software without prior written authorization
-from the X Consortium.
-.LP
-.sp 2
-Copyright \(co 1987, 1988, 1989, 1993, 1994
-Sun Microsystems, Inc.
-.LP 
-Permission to use, copy, modify, and distribute this documentation 
-for any purpose and without fee is hereby granted, provided 
-that the above copyright notice and this permission 
-notice appear in all copies.
-Sun Microsystems makes no representations about the 
-suitability for any purpose of the information in this document. 
-This documentation is provided as is without express or implied warranty. 
-.ps 11
-.nr PS 11
-.af PN i
-.EF ''\\\\n(PN''
-.OF ''\\\\n(PN''
-.bp +4		\" the TOC is three pages long
-.\" force preface onto odd page
-.if e \{\
-\&
-.bp
-\}
-.cT "Preface to Version 2.0"
-.LP
-The goal of the ICCCM Version 2.0 effort was to add new facilities, to fix
-problems with earlier drafts, and to improve readability and
-understandability, while maintaining compatibility with the earlier
-versions.  This document is the product of over two years of discussion among
-the members of the X Consortium's \fBwmtalk\fP working group.  The following
-people deserve thanks for their contributions:
-.LP
-.Ds
-.ta 3i
-Gabe Beged-Dov	Bill Janssen
-Chan Benson	Vania Joloboff
-Jordan Brown	Phil Karlton
-Larry Cable	Kaleb Keithley
-Ellis Cohen	Mark Manasse
-Donna Converse	Ralph Mor
-Brian Cripe	Todd Newman
-Susan Dahlberg	Bob Scheifler
-Peter Daifuku	Keith Taylor
-Andrew deBlois	Jim VanGilder
-Clive Feather	Mike Wexler
-Stephen Gildea	Michael Yee
-Christian Jacobi
-.De
-.LP
-It has been a privilege for me to work with this fine group of people.
-.sp
-Stuart W. Marks
-.br
-December 1993
-.br
-.bp
-.cT "Preface to Version 1.1"
-.LP
-David Rosenthal had overall architectural responsibility 
-for the conventions defined in this document;
-he wrote most of the text and edited the document, 
-but its development has been a communal effort.
-The details were thrashed out in meetings at the January 1988 MIT X Conference
-and at the 1988 Summer Usenix conference,
-and through months (and megabytes) of argument
-on the
-.PN wmtalk
-mail alias.
-Thanks are due to everyone who contributed,
-and especially to the following people.
-.LP
-For the Selection section:
-.LP
-.Ds
-Jerry Farrell
-Phil Karlton
-Loretta Guarino Reid
-Mark Manasse
-Bob Scheifler
-.De
-.LP
-For the Cut-Buffer section:
-.LP
-.Ds
-Andrew Palay
-.De
-.LP
-For the Window and Session Manager sections:
-.LP
-.Ds
-.ta 3i
-Todd Brunhoff	Matt Landau
-Ellis Cohen	Mark Manasse
-Jim Fulton	Bob Scheifler
-Hania Gajewska	Ralph Swick
-Jordan Hubbard	Mike Wexler
-Kerry Kimbrough	Glenn Widener
-Audrey Ishizaki	
-.De
-.LP
-For the Device Color Characterization section:
-.Ds
-Keith Packard
-.De
-.LP
-In addition, thanks are due to those who contributed to the public review:
-.LP
-.Ds
-.ta 3i
-Gary Combs	John Irwin
-Errol Crary	Vania Joloboff
-Nancy Cyprych	John Laporta
-John Diamant	Ken Lee
-Clive Feather	Stuart Marks
-Burns Fisher	Alan Mimms
-Richard Greco	Colas Nahaboo
-Tim Greenwood	Mark Patrick
-Kee Hinckley	Steve Pitschke
-Brian Holt	Brad Reed
-John Interrante	John Thomas
-.De
-.bp 1
-.af PN 1
-.EH '\fBInter-Client Communication Conventions\fP''\fBX11, Release 6.8\fP'
-.OH '\fBInter-Client Communication Conventions\fP''\fBX11, Release 6.8\fP'
-.EF ''\fB % \fP''
-.OF ''\fB % \fP''
-.nH 1 Introduction
-.LP
-It was an explicit design goal of X Version 11 to specify mechanism,
-not policy.
-As a result,  
-a client that converses with the server using the protocol defined 
-by the \fIX Window System Protocol\fP, \fIVersion 11\fP may operate correctly 
-in isolation but may not coexist properly with others sharing the same server.
-.LP
-Being a good citizen in the X Version 11 world involves adhering to
-conventions that govern inter-client communications in the following areas:
-.bP
-Selection mechanism
-.bP
-Cut buffers
-.bP
-Window manager
-.bP
-Session manager
-.bP
-Manipulation of shared resources
-.bP
-Device color characterization
-.LP
-This document proposes suitable conventions without attempting to enforce 
-any particular user interface.
-To permit clients written in different languages to communicate,
-these conventions are expressed solely in terms of protocol operations,
-not in terms of their associated Xlib interfaces,
-which are probably more familiar.
-The binding of these operations to the Xlib interface for C
-and to the equivalent interfaces for other languages
-is the subject of other documents.
-.nH 2 "Evolution of the Conventions"
-.LP
-In the interests of timely acceptance,
-the \fIInter-Client Communication Conventions Manual\fP (ICCCM)
-covers only a minimal set of required conventions.
-These conventions will be added to and updated as appropriate,
-based on the experiences of the X Consortium.
-.LP
-As far as possible,
-these conventions are upwardly compatible with those in the February 25, 1988,
-draft that was distributed with the X Version 11, Release 2, of the software.
-In some areas,
-semantic problems were discovered with those conventions,
-and, thus, complete upward compatibility could not be assured.
-These areas are noted in the text and are summarized in Appendix A.
-.LP
-In the course of developing these conventions,
-a number of minor changes to the protocol were identified as desirable.
-They also are identified in the text, are summarized in Appendix B,
-and are offered as input to a future protocol revision process.
-If and when a protocol revision incorporating these changes is undertaken,
-it is anticipated that the ICCCM will need to be revised.
-Because it is difficult to ensure that clients and servers are upgraded
-simultaneously, 
-clients using the revised conventions should examine the minor protocol 
-revision number and be prepared to use the older conventions 
-when communicating with an older server.
-.LP
-It is expected that these revisions will ensure that clients using 
-the conventions appropriate to protocol minor revision \fIn\fP 
-will interoperate correctly with those that use the conventions 
-appropriate to protocol minor revision \fIn\fP + 1 if the server supports both.
-.nH 2 Atoms
-.LP
-Many of the conventions use atoms.
-To assist the reader,
-the following sections attempt to amplify the description of atoms 
-that is provided in the protocol specification.
-.nH 3 "What Are Atoms?"
-.LP
-At the conceptual level, 
-atoms are unique names that clients can use to communicate information 
-to each other.
-They can be thought of as a bundle of octets,
-like a string but without an encoding being specified.
-The elements are not necessarily ASCII characters,
-and no case folding happens.\**
-.FS
-The comment in the protocol specification for 
-.PN InternAtom 
-that ISO Latin-1 encoding should be used is in the nature of a convention;
-the server treats the string as a byte sequence.
-.FE
-.LP
-The protocol designers felt that passing these
-sequences of bytes back and forth across the wire would be too costly.
-Further, they thought it important that events 
-as they appear on the wire have a fixed size (in fact, 32 bytes)
-and that because some events contain atoms, a fixed-size representation 
-for them was needed.
-.LP
-To allow a fixed-size representation,
-a protocol request 
-.Pn ( InternAtom )
-was provided to register a byte sequence with the server,
-which returns a 32-bit value (with the top three bits zero) 
-that maps to the byte sequence.
-The inverse operator is also available 
-.Pn ( GetAtomName ).
-.nH 3 "Predefined Atoms"
-.LP
-The protocol specifies a number of atoms as being predefined:
-.QP
-Predefined atoms are not strictly necessary
-and may not be useful in all environments,
-but they will eliminate many 
-.PN InternAtom
-requests in most applications.
-Note that they are predefined only in the sense of having numeric values, 
-not in the sense of having required semantics.
-.LP
-Predefined atoms are an implementation trick to avoid the cost of interning
-many of the atoms that are expected to be used during the startup phase 
-of all applications.
-The results of the 
-.PN Intern\%Atom 
-requests, which require a handshake, can be assumed \fIa priori\fP.
-.LP
-Language interfaces should probably cache the atom-name mappings 
-and get them only when required.
-The CLX interface, for instance, makes no distinction between predefined atoms
-and other atoms; all atoms are viewed as symbols at the interface.
-However, a CLX implementation will typically keep a symbol or atom cache 
-and will typically initialize this cache with the predefined atoms.
-.nH 3 "Naming Conventions"
-.LP
-The built-in atoms are composed of uppercase ASCII characters with the
-logical words separated by an underscore character (_), for example,  
-WM_ICON_NAME.
-The protocol specification recommends that atoms used 
-for private vendor-specific reasons should begin with an underscore.
-To prevent conflicts among organizations, 
-additional prefixes should be chosen 
-(for example,  _DEC_WM_DECORATION_GEOMETRY).
-.LP
-The names were chosen in this fashion to make it easy to use them in a
-natural way within LISP.
-Keyword constructors allow the programmer to specify the atoms as LISP atoms.
-If the atoms were not all uppercase,
-special quoting conventions would have to be used.
-.nH 3 Semantics
-.LP
-The core protocol imposes no semantics on atoms except as they are used in
-FONTPROP structures.
-For further information on FONTPROP semantics,
-see the \fIX Logical Font Description Conventions\fP.
-.nH 3 "Name Spaces"
-.LP
-The protocol defines six distinct spaces in which atoms are interpreted.
-Any particular atom may or may not have some valid interpretation
-with respect to each of these name spaces.
-.br
-.ne 6
-.TS H
-l l lw(3.6i).
-_
-.sp 6p
-.B
-Space	Briefly	Examples
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-Property name	Name	WM_HINTS, WM_NAME, RGB_BEST_MAP, .\^.\^.
-Property type	Type	WM_HINTS, CURSOR, RGB_COLOR_MAP, .\^.\^.
-Selection name	Selection	PRIMARY, SECONDARY, CLIPBOARD
-Selection target	Target	FILE_NAME, POSTSCRIPT, PIXMAP, .\^.\^.
-Font property		QUAD_WIDTH, POINT_SIZE, .\^.\^.
-T{
-.PN ClientMessage
-type
-T}	T{
-T}	T{
-WM_SAVE_YOURSELF, _DEC_SAVE_EDITS, \&.\^.\^.
-T}
-.sp 6p
-_
-.TE
-.nH 3 "Discriminated Names"
-.LP
-Sometimes a protocol requires an arbitrary number of similar
-objects that need unique names (usually because the objects are created
-dynamically, so that names cannot be invented in advance). For example, a
-colormap-generating program might use the selection mechanism to offer
-colormaps for each screen and so needs a selection name for each screen.
-Such names are called \*Qdiscriminated names\*U and are discriminated by
-some entity. This entity can be:
-.DS
-    A screen
-    An X resource (a window, a colormap, a visual, etc.)
-    A client
-.DE
-.LP
-If it is only necessary to generate a fixed set of names for each value
-of the discriminating entity, then the discriminated names are formed by
-suffixing an ordinary name according to the value of the entity.
-.LP
-If \fIname\fP is a descriptive portion for the name, \fId\fP is a decimal
-number with no leading zeroes, and \fIx\fP is a hexadecimal number with
-exactly 8 digits, and using uppercase letters, then such discriminated names
-shall have the form:
-.br
-.ne 6
-.TS
-lB lB lB
-l l l .
-_
-.sp 6p
-Name Discriminated by	Form	Example
-.sp 6p
-_
-.sp 6p
-screen number	\fIname\fP_S\fId\fP	WM_COMMS_S2
-X resource	\fIname\fP_R\fIx\fP	GROUP_LEADER_R1234ABCD
-.sp 6p
-_
-.TE
-.LP
-To discriminate a name by client, use an X resource ID created by that
-client.  This resource can be of any type.
-.LP
-Sometimes it is simply necessary to generate a unique set of names (for
-example, for the properties on a window used by a MULTIPLE selection).
-These names should have the form:
-.DS
-.ta 2i
-U\fId\fP	(e.g.,  U0  U1  U2  U3  .\^.\^.)
-.DE
-.LP
-if the names stand totally alone, and the form:
-.DS
-.ta 2i
-\fIname\fP_U\fId\fP	(e.g.,  FOO_U0  BAR_U0  FOO_U1  BAR_U1  .\^.\^.)
-.DE
-.LP
-if they come in sets (here there are two sets, named \*QFOO\*U and
-\*QBAR\*U).  The stand-alone U\fId\fP form should be used only if it is
-clear that the module using it has complete control over the relevant
-namespace or has the active cooperation of all other entities that might
-also use these names. (Naming properties on a window created specifically
-for a particular selection is such a use; naming properties on the root
-window is almost certainly not.)
-.LP
-In a particularly difficult case, it might be necessary to combine both
-forms of discrimination. If this happens, the U form should come after
-the other form, thus:
-.DS
-    FOO_R12345678_U23
-.DE
-.NT Rationale
-Existing protocols will not be changed to use these naming conventions,
-because doing so will cause too much disruption.  However, it is expected
-that future protocols \(em both standard and private \(em will use these
-conventions.
-.NE
-.nH 1 "Peer-to-Peer Communication by Means of Selections"
-.LP
-Selections are the primary mechanism that X Version 11 defines 
-for the exchange of information between clients,
-for example, by cutting and pasting between windows.
-Note that there can be an arbitrary number of selections
-(each named by an atom) and that they are global to the server.
-Section 2.6 discusses the choice of an atom.
-Each selection is owned by a client and is attached to a window.
-.LP
-Selections communicate between an owner and a requestor.
-The owner has the data representing the value of its selection,
-and the requestor receives it.
-A requestor wishing to obtain the value of a selection provides the following:
-.bP
-The name of the selection
-.bP
-The name of a property
-.bP
-A window
-.bP
-The atom representing the data type required
-.bP
-Optionally, some parameters for the request
-.LP
-If the selection is currently owned,
-the owner receives an event and is expected to do the following:
-.bP
-Convert the contents of the selection to the requested data type
-.bP
-Place this data in the named property on the named window
-.bP
-Send the requestor an event to let it know the property is available
-.LP
-Clients are strongly encouraged to use this mechanism.
-In particular,
-displaying text in a permanent window without providing the ability 
-to select and convert it into a string is definitely considered antisocial.
-.LP
-Note that all data transferred between an owner and a requestor must usually 
-go by means of the server in an X Version 11 environment.
-A client cannot assume that another client can open the same files
-or even communicate directly.
-The other client may be talking to the server by means of 
-a completely different networking mechanism (for example,  one client might
-be DECnet and the other TCP/IP).
-Thus, passing indirect references to data 
-(such as, file names, host names, and port numbers) 
-is permitted only if both clients specifically agree.
-.nH 2 "Acquiring Selection Ownership"
-.LP
-A client wishing to acquire ownership of a particular selection
-should call 
-.PN SetSelectionOwner,
-which is defined as follows:
-.LP
-.sM
-.IN "SetSelectionOwner" "" "@DEF@"
-.PN SetSelectionOwner
-.IP "" .2i
-\fIselection\fP\^: ATOM
-.br
-\fIowner\fP\^: WINDOW or
-.PN None
-.br
-\fItime\fP\^: TIMESTAMP or
-.PN CurrentTime
-.LP
-.eM
-.LP
-The client should set the specified selection to the atom that represents 
-the selection,
-set the specified owner to some window that the client created,
-and set the specified time to some time between the current last-change time 
-of the selection concerned and the current server time.
-This time value usually will be obtained from the timestamp of the event 
-that triggers the acquisition of the selection.
-Clients should not set the time
-value to 
-.PN CurrentTime ,
-because if they do so, they have no way of finding
-when they gained ownership of the selection.
-Clients must use a window they created so that requestors
-can route events to the owner of the selection.\**
-.FS
-At present, no part of the protocol requires requestors
-to send events to the owner of a selection.
-This restriction is imposed to prepare for possible future extensions.
-.FE
-.NT Convention
-Clients attempting to acquire a selection must set the time value of the 
-.PN Set\%Selection\%Owner 
-request to the timestamp of the event triggering the acquisition attempt, 
-not to 
-.PN CurrentTime .
-A zero-length append to a property is a way to obtain a timestamp for
-this purpose;
-the timestamp is in the corresponding 
-.PN Property\%Notify
-event.
-.NE
-.LP
-If the time in the 
-.PN SetSelectionOwner 
-request is in the future relative to the server's current time 
-or is in the past relative to the last time the specified selection 
-changed hands, the 
-.PN SetSelectionOwner
-request appears to the client to succeed,
-but ownership is not actually transferred.
-.LP
-Because clients cannot name other clients directly,
-the specified owner window is used to refer to the owning client
-in the replies to 
-.PN GetSelectionOwner ,
-in 
-.PN SelectionRequest 
-and
-.PN SelectionClear
-events, and possibly as a place to put properties describing the selection
-in question.
-To discover the owner of a particular selection,
-a client should invoke
-.PN GetSelectionOwner ,
-which is defined as follows:
-.LP
-.sM
-.IN "GetSelectionOwner" "" "@DEF@"
-.PN GetSelectionOwner
-.IP "" .2i
-\fIselection\fP\^: ATOM
-.LP
-\(->
-.IP "" .2i
-owner: WINDOW or
-.PN None
-.LP
-.eM
-.NT Convention
-Clients are expected to provide some visible confirmation
-of selection ownership.
-To make this feedback reliable,
-a client must perform a sequence like the following:
-.sp
-.Ds 0
-SetSelectionOwner(selection=PRIMARY, owner=Window, time=timestamp)
-owner = GetSelectionOwner(selection=PRIMARY)
-if (owner != Window) Failure
-.De
-.NE
-.LP
-If the 
-.PN SetSelectionOwner
-request succeeds (not merely appears to succeed),
-the client that issues it is recorded by the server as being the owner 
-of the selection for the time period starting at the specified time.
-.nH 2 "Responsibilities of the Selection Owner"
-.LP
-When a requestor wants the value of a selection,
-the owner receives a 
-.PN SelectionRequest
-event, which is defined as follows:
-.LP
-.sM
-.IN "SelectionRequest" "" "@DEF@"
-.PN SelectionRequest
-.IP "" .2i
-\fIowner\fP\^: WINDOW
-.br
-\fIselection\fP\^: ATOM
-.br
-\fItarget\fP\^: ATOM
-.br
-\fIproperty\fP\^: ATOM or
-.PN None
-.br
-\fIrequestor\fP\^: WINDOW
-.br
-\fItime\fP\^: TIMESTAMP or
-.PN CurrentTime
-.LP
-.eM
-.LP
-The specified owner and selection will be the values that were specified in
-the
-.PN SetSelection\%Owner 
-request.
-The owner should compare the timestamp with the period 
-it has owned the selection and, if the time is outside,
-refuse the 
-.PN SelectionRequest 
-by sending the requestor window a 
-.PN SelectionNotify 
-event with the property set to 
-.PN None 
-(by means of a
-.PN SendEvent
-request with an empty event mask).
-.LP
-More advanced selection owners are free to maintain a history
-of the value of the selection and to respond to requests for the
-value of the selection during periods they owned it
-even though they do not own it now.
-.LP
-If the specified property is 
-.PN None ,
-the requestor is an obsolete client.
-Owners are encouraged to support these clients by using the specified target
-atom as the property name to be used for the reply.
-.LP
-Otherwise,
-the owner should use the target to decide the form into which the selection
-should be converted.
-Some targets may be defined such that requestors can pass parameters
-along with the request.  The owner will find these parameters in the
-property named in the selection request.  The type, format, and
-contents of this property are dependent upon the definition of the
-target.  If the target is not defined to have parameters, the owner
-should ignore the property if it is present.
-If the selection cannot be converted
-into a form based on the target (and parameters, if any),
-the owner should refuse the 
-.PN Selection\%Request
-as previously described.
-.LP
-If the specified property is not 
-.PN None ,
-the owner should place the data resulting from converting the selection 
-into the specified property on the requestor window
-and should set the property's type to some appropriate value,
-which need not be the same as the specified target.
-.NT Convention
-All properties used to reply to 
-.PN SelectionRequest
-events must be placed on the requestor window.
-.NE
-.LP
-In either case, 
-if the data comprising the selection cannot be stored on the requestor window 
-(for example, because the server cannot provide sufficient memory),
-the owner must refuse the 
-.PN SelectionRequest ,
-as previously described.
-See also section 2.5.
-.LP
-If the property is successfully stored,
-the owner should acknowledge the successful conversion
-by sending the requestor window a 
-.PN SelectionNotify 
-event (by means of a
-.PN SendEvent
-request with an empty mask).
-.PN SelectionNotify
-is defined as follows:
-.LP
-.sM
-.IN "SelectionNotify" "" "@DEF@"
-.PN SelectionNotify
-.IP "" .2i
-\fIrequestor\fP\^: WINDOW
-.br
-\fIselection\fP, \fItarget\fP\^: ATOM
-.br
-\fIproperty\fP\^: ATOM or
-.PN None
-.br
-\fItime\fP\^: TIMESTAMP or
-.PN CurrentTime
-.LP
-.eM
-.LP
-The owner should set the specified selection, target, time, 
-and property arguments to the values received in the 
-.PN SelectionRequest 
-event.
-(Note that setting the property argument to 
-.PN None 
-indicates that the conversion requested could not be made.)
-.NT Convention
-The selection, target, time, and property arguments in the 
-.PN SelectionNotify 
-event should be set to the values received in the 
-.PN SelectionRequest 
-event.
-.NE
-.LP
-If the owner receives more than one
-.PN Selection\%Request
-event with the same requestor, selection, target, and timestamp it must
-respond to them in the same order in which they were received.
-.NT Rationale
-It is possible for a requestor to have multiple outstanding requests that
-use the same requestor window, selection, target, and timestamp, and that
-differ only in the property.  If this occurs, and one of the conversion
-requests fails, the resulting
-.PN Selection\%Notify
-event will have its property argument set to 
-.PN None .
-This may make it impossible for the requestor to determine which conversion
-request had failed, unless the requests are responded to in order.
-.NE
-.LP
-The data stored in the property must eventually be deleted.
-A convention is needed to assign the responsibility for doing so.
-.NT Convention
-Selection requestors are responsible for deleting properties whose
-names they receive in 
-.PN SelectionNotify 
-events (see section 2.4) or in properties with type MULTIPLE.
-.NE
-.LP
-A selection owner will often need confirmation that the data comprising the
-selection has actually been transferred.
-(For example, 
-if the operation has side effects on the owner's internal data structures, 
-these should not take place until the requestor has indicated 
-that it has successfully received the data.)
-Owners should express interest in 
-.PN PropertyNotify 
-events for the specified requestor window 
-and wait until the property in the 
-.PN SelectionNotify 
-event has been deleted before assuming that the selection data has been
-transferred.  For the MULTIPLE request, if the different conversions require
-separate confirmation, the selection owner can also watch for the deletion
-of the individual properties named in the property in the
-.PN Selection\%Notify
-event.
-.LP
-When some other client acquires a selection,
-the previous owner receives a 
-.PN SelectionClear 
-event, which is defined as follows:
-.LP
-.sM
-.IN "SelectionClear" "" "@DEF@"
-.PN SelectionClear
-.IP "" .2i
-\fIowner\fP\^: WINDOW
-.br
-\fIselection\fP\^: ATOM
-.br
-\fItime\fP\^: TIMESTAMP
-.LP
-.eM
-.LP
-The timestamp argument is the time at which the ownership changed hands,
-and the owner argument is the window the previous owner specified in its
-.PN SetSelectionOwner 
-request.
-.LP
-If an owner loses ownership while it has a transfer in progress (that is,
-before it receives notification that the requestor has received all the data),
-it must continue to service the ongoing transfer until it is complete.
-.LP
-If the selection value completely changes, but the owner happens
-to be the same client (for example, selecting a totally different
-piece of text in the same \fBxterm\fP as before), then the client should
-reacquire the selection ownership as if it were not the owner,
-providing a new timestamp. If the selection value is modified, but
-can still reasonably be viewed as the same selected object,\** the
-owner should take no action.
-.FS
-The division between these two cases is a matter of judgment
-on the part of the software developer.
-.FE
-.nH 2 "Giving Up Selection Ownership"
-.LP
-Clients may either give up selection ownership voluntarily 
-or lose it forcibly as the result of some other client's actions.
-.nH 3 "Voluntarily Giving Up Selection Ownership"
-.LP
-To relinquish ownership of a selection voluntarily,
-a client should execute a 
-.PN SetSelection\%Owner
-request for that selection atom, with owner specified as 
-.PN None
-and the time specified as the timestamp that was used to acquire the selection.
-.LP
-Alternatively,
-the client may destroy the window used as the owner value of the 
-.PN SetSelection\%Owner
-request, or the client may terminate.
-In both cases,
-the ownership of the selection involved will revert to 
-.PN None .
-.nH 3 "Forcibly Giving Up Selection Ownership"
-.LP
-If a client gives up ownership of a selection
-or if some other client executes a 
-.PN SetSelection\%Owner 
-for it and thus reassigns it forcibly,
-the previous owner will receive a 
-.PN Selection\%Clear 
-event. For the definition of a 
-.PN Selection\%Clear
-event, see section 2.2.
-.LP
-The timestamp is the time the selection changed hands.
-The specified owner is the window that was specified by the current owner 
-in its 
-.PN SetSelectionOwner
-request.
-.nH 2 "Requesting a Selection"
-.LP
-A client that wishes to obtain the value of a selection in a particular
-form (the requestor) issues a 
-.PN ConvertSelection 
-request, which is defined as follows:
-.LP
-.sM
-.IN "ConvertSelection" "" "@DEF@"
-.PN ConvertSelection
-.IP "" .2i
-\fIselection\fP, \fItarget\fP\^: ATOM
-.br
-\fIproperty\fP\^: ATOM or
-.PN None
-.br
-\fIrequestor\fP\^: WINDOW
-.br
-\fItime\fP\^: TIMESTAMP or
-.PN CurrentTime
-.LP
-.eM
-.LP
-The selection argument specifies the particular selection involved,
-and the target argument specifies the required form of the information.
-For information about the choice of suitable atoms to use,
-see section 2.6.
-The requestor should set the requestor argument to a window that it created;
-the owner will place the reply property there.
-The requestor should set the time argument to the timestamp on the event 
-that triggered the request for the selection value.
-Note that clients should not specify 
-.PN CurrentTime .
-.NT Convention
-Clients should not use 
-.PN CurrentTime 
-for the time argument of a 
-.PN ConvertSelection
-request.
-Instead, they should use the timestamp of the event that caused the request 
-to be made.
-.NE
-.LP
-The requestor should set the property argument to the name of a property 
-that the owner can use to report the value of the selection.
-Requestors should ensure that the named property does not exist
-on the window before issuing the
-.PN Convert\%Selection
-request.\** The exception to this rule is when the requestor intends to pass
-parameters with the request (see below).
-.NT Rationale
-It is necessary for requestors to delete the property before issuing the
-request so that the target can later be extended to take parameters without
-introducing an incompatibility.  Also note that the requestor of a selection
-need not know the client that owns the selection nor the window on which
-the selection was acquired.
-.NE
-.FS
-This requirement is new in version 2.0, and, in general, existing
-clients do not conform to this requirement.  To prevent these clients
-from breaking, no existing targets should be extended to take
-parameters until sufficient time has passed for clients to be updated.
-Note that the MULTIPLE target was defined to take parameters in version
-1.0 and its definition is not changing.  There is thus no conformance
-problem with MULTIPLE.
-.FE
-.LP
-Some targets may be defined such that requestors can pass parameters
-along with the request.  If the requestor wishes to provide parameters
-to a request, they should be placed in the specified property on the
-requestor window before the requestor issues the
-.PN Convert\%Selection
-request, and this property should be named in the request.
-.LP
-Some targets may be defined so that parameters are optional.  If no
-parameters are to be supplied with the request of such a target, the
-requestor must ensure that the property does not exist before issuing
-the
-.PN Convert\%Selection
-request.
-.LP
-The protocol allows the property field to be set to 
-.PN None ,
-in which case the owner is supposed to choose a property name.
-However, it is difficult for the owner to make this choice safely.
-.NT Conventions
-.IP 1. 5
-Requestors should not use 
-.PN None
-for the property argument of a
-.PN ConvertSelection
-request.
-.IP 2. 5
-Owners receiving 
-.PN ConvertSelection 
-requests with a property argument of
-.PN None
-are talking to an obsolete client.
-They should choose the target atom as the property name to be used 
-for the reply.
-.NE
-.LP
-The result of the 
-.PN ConvertSelection
-request is that a 
-.PN SelectionNotify
-event will be received.
-For the definition of a
-.PN SelectionNotify
-event, see section 2.2.
-.LP
-The requestor, selection, time, and target arguments will be the same
-as those on the 
-.PN ConvertSelection 
-request.
-.LP
-If the property argument is 
-.PN None ,
-the conversion has been refused.
-This can mean either that there is no owner for the selection, 
-that the owner does not support the conversion implied by the target,
-or that the server did not have sufficient space to accommodate the data.
-.LP
-If the property argument is not 
-.PN None ,
-then that property will exist on the requestor window.
-The value of the selection can be retrieved from this
-property by using the 
-.PN GetProperty
-request, which is defined as follows:
-.LP
-.sM
-.IN "GetProperty" "" "@DEF@"
-.PN GetProperty
-.IP "" .2i
-\fIwindow\fP\^: WINDOW
-.br
-\fIproperty\fP\^: ATOM
-.br
-\fItype\fP\^: ATOM or
-.PN AnyPropertyType
-.br
-\fIlong-offset\fP, \fIlong-length\fP\^: CARD32
-.br
-\fIdelete\fP\^: BOOL
-.LP
-\(->
-.IP "" .2i
-type: ATOM or
-.PN None
-.br
-format: {0, 8, 16, 32}
-.br
-bytes-after: CARD32
-.br
-value: LISTofINT8 or LISTofINT16 or LISTofINT32
-.LP
-.eM
-.LP
-When using 
-.PN GetProperty 
-to retrieve the value of a selection,  
-the property argument should be set to the corresponding value in the 
-.PN SelectionNotify
-event.
-Because the requestor has no way of knowing beforehand what type 
-the selection owner will use,
-the type argument should be set to 
-.PN AnyPropertyType .
-Several 
-.PN GetProperty 
-requests may be needed to retrieve all the data in the selection;
-each should set the long-offset argument to the amount of data received so far,
-and the size argument to some reasonable buffer size (see section 2.5).
-If the returned value of bytes-after is zero,
-the whole property has been transferred.
-.LP
-Once all the data in the selection has been retrieved
-(which may require getting the values of several properties \(em
-see section 2.7),
-the requestor should delete the property in the 
-.PN SelectionNotify
-request by using a 
-.PN GetProperty
-request with the delete argument set to
-.PN True .
-As previously discussed,
-the owner has no way of knowing when the data has been
-transferred to the requestor unless the property is removed.
-.NT Convention
-The requestor must delete the property named in the 
-.PN SelectionNotify
-once all the data has been retrieved.
-The requestor should invoke either 
-.PN DeleteProperty 
-or
-.PN GetProperty (delete==True)
-after it has successfully retrieved all the data in the selection.
-For further information,
-see section 2.5.
-.NE
-.nH 2 "Large Data Transfers"
-.LP
-Selections can get large, which poses two problems:
-.bP
-Transferring large amounts of data to the server is expensive.
-.bP
-All servers will have limits on the amount of data that can be stored
-in properties.
-Exceeding this limit will result in an 
-.PN Alloc
-error on the 
-.PN ChangeProperty 
-request that the selection owner uses to store the data.
-.LP
-The problem of limited server resources is addressed by the following
-conventions:
-.NT Conventions
-.IP 1. 5
-Selection owners should transfer the data describing a large selection
-(relative to the maximum-request-size they received 
-in the connection handshake) using the INCR property mechanism 
-(see section 2.7.2).
-.IP 2. 5
-Any client using 
-.PN SetSelectionOwner
-to acquire selection ownership should arrange to process 
-.PN Alloc
-errors in property change requests.
-For clients using Xlib,
-this involves using the
-.PN XSetErrorHandler
-function to override the default handler.
-.IP 3. 5
-A selection owner must confirm that no 
-.PN Alloc
-error occurred while storing the properties for a selection 
-before replying with a confirming 
-.PN SelectionNotify
-event.
-.IP 4. 5
-When storing large amounts of data (relative to maximum-request-size),
-clients should use a sequence of 
-.PN ChangeProperty (mode==Append)
-requests for reasonable quantities of data.
-This avoids locking servers up and limits the waste of data an
-.PN Alloc 
-error would cause.
-.IP 5. 5
-If an 
-.PN Alloc 
-error occurs during the storing of the selection data,
-all properties stored for this selection should be deleted
-and the 
-.PN ConvertSelection
-request should be refused (see section 2.2).
-.IP 6. 5
-To avoid locking servers up for inordinate lengths of time,
-requestors retrieving large quantities of data from a property
-should perform a series of 
-.PN GetProperty 
-requests, each asking for a reasonable amount of data.
-.NE
-.NT "Advice to Implementors"
-Single-threaded servers should take care to avoid locking up during large
-data transfers.
-.NE
-.nH 2 "Use of Selection Atoms"
-.LP
-Defining a new atom consumes resources in the server
-that are not released until the server reinitializes.
-Thus, reducing the need for newly minted atoms is an important goal
-for the use of the selection atoms.
-.nH 3 "Selection Atoms"
-.LP
-There can be an arbitrary number of selections, each named by an atom.
-To conform with the inter-client conventions, however,
-clients need deal with only these three selections:
-.bP
-PRIMARY
-.bP
-SECONDARY
-.bP
-CLIPBOARD
-.LP
-Other selections may be used freely for private communication among
-related groups of clients.
-.nH 4 "The PRIMARY Selection"
-.LP
-The selection named by the atom PRIMARY is used for all commands
-that take only a single argument and is the principal means of communication 
-between clients that use the selection mechanism.
-.nH 4 "The SECONDARY Selection"
-.LP
-The selection named by the atom SECONDARY is used:
-.bP
-As the second argument to commands taking two arguments 
-(for example, \*Qexchange primary and secondary selections\*U)
-.bP
-As a means of obtaining data when there is a primary selection
-and the user does not want to disturb it
-.nH 4 "The CLIPBOARD Selection"
-.LP
-The selection named by the atom CLIPBOARD is used to hold data
-that is being transferred between clients, 
-that is, data that usually is being cut and then pasted
-or copied and then pasted.
-Whenever a client wants to transfer data to the clipboard:
-.bP
-It should assert ownership of the CLIPBOARD.
-.bP
-If it succeeds in acquiring ownership,
-it should be prepared to respond to a request for the contents of the CLIPBOARD
-in the usual way (retaining the data to be able to return it).
-The request may be generated by the clipboard client described below.
-.bP
-If it fails to acquire ownership,
-a cutting client should not actually perform the cut or provide feedback 
-that would suggest that it has actually transferred data to the clipboard.
-.LP
-The owner should repeat this process whenever the data to be transferred
-would change.
-.LP
-Clients wanting to paste data from the clipboard should request 
-the contents of the CLIPBOARD selection in the usual way.
-.LP
-Except while a client is actually deleting or copying data,
-the owner of the CLIPBOARD selection may be a single, special client
-implemented for the purpose.
-This client maintains the content of the clipboard up-to-date
-and responds to requests for data from the clipboard as follows:
-.bP
-It should assert ownership of the CLIPBOARD selection
-and reassert it any time the clipboard data changes.
-.bP
-If it loses the selection (because another client has some new data 
-for the clipboard),
-it should:
-.RS
-.IP \- 5
-Obtain the contents of the selection from the new owner by using the timestamp
-in the 
-.PN SelectionClear
-event.
-.IP \- 5
-Attempt to reassert ownership of the CLIPBOARD selection 
-by using the same timestamp.
-.IP \- 5
-Restart the process using a newly acquired timestamp if this attempt fails.
-This timestamp should be obtained by asking the current owner of the
-CLIPBOARD selection to convert it to a TIMESTAMP.
-If this conversion is refused or if the same timestamp is received twice,
-the clipboard client should acquire a fresh timestamp in the
-usual way (for example by a zero-length append to a property).
-.RE
-.bP
-It should respond to requests for the CLIPBOARD contents in the usual way.
-.LP
-A special CLIPBOARD client is not necessary.
-The protocol used by the cutting client and the pasting client
-is the same whether the CLIPBOARD client is running or not.
-The reasons for running the special client include:
-.bP
-Stability \- If the cutting client were to crash or terminate,
-the clipboard value would still be available.
-.bP
-Feedback \- The clipboard client can display the contents of the clipboard.
-.bP
-Simplicity \- A client deleting data does not have to retain it for so long,
-thus reducing the chance of race conditions causing problems.
-.LP
-The reasons not to run the clipboard client include:
-.bP
-Performance \- Data is transferred only if it is actually required 
-(that is, when some client actually wants the data).
-.bP
-Flexibility \- The clipboard data may be available as more than one target.
-.nH 3 "Target Atoms"
-.LP
-The atom that a requestor supplies as the target of a 
-.PN ConvertSelection
-request determines the form of the data supplied.
-The set of such atoms is extensible, 
-but a generally accepted base set of target atoms is needed.
-As a starting point for this, 
-the following table contains those that have been suggested so far.
-.br
-.ne 6
-.\" This table has very tricky formatting.  Several targets are too long to
-.\" fit, so the table format needs to change around them.  If the table
-.\" format changes, it will need to be changed in several places.  There are
-.\" also two footnotes in this table, but the footnote text can't be
-.\" embedded in the table.  This means that the auto-numbering needs to be
-.\" dinked around with after the end of the table.
-.TS H
-lw(1.8i) lw(1i) lw(3i) .
-_
-.sp 6p
-.B
-Atom	Type 	Data Received
-.R
-.sp 6p
-_
-.sp 6p
-.TH
-.T&
-l s s .
-ADOBE_PORTABLE_DOCUMENT_FORMAT
-.T&
-lw(1.8i) lw(1i) lw(3i) .
-	STRING	T{
-[1]
-T}
-.sp 6p
-APPLE_PICT	APPLE_PICT	T{
-[2]
-T}
-BACKGROUND	PIXEL	A list of pixel values
-BITMAP	BITMAP	A list of bitmap IDs
-CHARACTER_POSITION	SPAN	T{
-The start and end of the selection in bytes
-T}
-CLASS	TEXT	(see section 4.1.2.5)
-CLIENT_WINDOW	WINDOW	T{
-Any top-level window owned by the selection owner
-T}
-COLORMAP	COLORMAP	A list of colormap IDs
-COLUMN_NUMBER	SPAN	T{
-The start and end column numbers
-T}
-COMPOUND_TEXT	COMPOUND_TEXT	Compound Text
-DELETE	NULL	(see section 2.6.3.1)
-DRAWABLE	DRAWABLE	A list of drawable IDs
-.sp 6p
-.T&
-l s s .
-ENCAPSULATED_POSTSCRIPT
-.T&
-lw(1.8i) lw(1i) lw(3i) .
-	STRING	T{
-[3], Appendix H\|\**
-T}
-.sp 6p
-.T&
-l s s .
-ENCAPSULATED_POSTSCRIPT_INTERCHANGE
-.T&
-lw(1.8i) lw(1i) lw(3i) .
-	STRING	T{
-[3], Appendix H
-T}
-.sp 6p
-FILE_NAME	TEXT	The full path name of a file
-FOREGROUND	PIXEL	T{
-A list of pixel values
-T}
-HOST_NAME	TEXT	(see section 4.1.2.9)
-INSERT_PROPERTY	NULL	(see section 2.6.3.3)
-INSERT_SELECTION	NULL	(see section 2.6.3.2)
-LENGTH	INTEGER	T{
-The number of bytes in the selection\|\**
-T}
-LINE_NUMBER	SPAN	T{
-The start and end line numbers
-T}
-LIST_LENGTH	INTEGER	T{
-The number of disjoint parts of the selection
-T}
-MODULE	TEXT	T{
-The name of the selected procedure
-T}
-MULTIPLE	ATOM_PAIR	T{
-(see the discussion that follows)
-T}
-NAME	TEXT	(see section 4.1.2.1)
-ODIF	TEXT	T{
-ISO Office Document Interchange Format
-T}
-OWNER_OS	TEXT	T{
-The operating system of the owner client
-T}
-PIXMAP	T{
-PIXMAP\|\**
-T}	T{
-A list of pixmap IDs
-T}
-POSTSCRIPT	STRING	T{
-[3]
-T}
-PROCEDURE	TEXT	T{
-The name of the selected procedure
-T}
-PROCESS	INTEGER, TEXT	T{
-The process ID of the owner
-T}
-STRING	STRING	ISO Latin-1 (+TAB+NEWLINE) text
-TARGETS	ATOM	A list of valid target atoms
-TASK	INTEGER, TEXT	T{
-The task ID of the owner
-T}
-TEXT	TEXT	T{
-The text in the owner's choice of encoding
-T}
-TIMESTAMP	INTEGER	T{
-The timestamp used to acquire the selection
-T}
-USER	TEXT	T{
-The name of the user running the owner
-T}
-.sp 6p
-_
-.TE
-.\" Conditionalized on groff because
-.\" groff keeps track of footnotes and fn references separately,
-.\" so resetting isn't necessary (and referencing \n* gives a warning).
-.if !\n(GS .nr * \n*-3	\" decrement by the number of footnotes in the table
-.if 0 \{\
-HACK!  There are several footnotes in the table above, each marked with the
-construct "\**".  The actual footnote text is here, because I haven't found
-a way to place it within the table itself.  This causes a numbering problem,
-because each \** increments the footnote counter (number register *) and the
-FS macro uses its current value.  To get around this, we decrement the *
-register by the number of footnotes in the table.  Then, before calling each
-FS macro, we increment the register.
-
-Also note that footnotes must appear within the T{ T} construct in tables.
-If they don't, strange numbering problems will result, probably as a result
-of multiple evaluation.
-\}
-.\" These footnotes are in the wrong order because Sun tbl numbers the
-.\" footnote references wrong in the above table.  Thus this doesn't
-.\" do the right thing with gtbl, which gets the order right.
-.if !\n(GS .nr * +1
-.FS
-Earlier versions of this document erroneously specified that conversion of
-the PIXMAP target returns a property of type DRAWABLE instead of PIXMAP.
-Implementors should be aware of this and may want to support the DRAWABLE
-type as well to allow for compatibility with older clients.
-.FE
-.if !\n(GS .nr * +1
-.FS
-The targets ENCAPSULATED_POSTSCRIPT and ENCAPSULATED_POSTSCRIPT_INTERCHANGE
-are equivalent to the targets _ADOBE_EPS and _ADOBE_EPSI (respectively) that
-appear in the selection targets registry.  The _ADOBE_ targets are
-deprecated, but clients are encouraged to continue to support them for
-backward compatibility.
-.FE
-.if !\n(GS .nr * +1
-.FS
-This definition is ambiguous, as the selection may be converted into any of
-several targets that may return differing amounts of data.  The requestor
-has no way of knowing which, if any, of these targets corresponds to the
-result of LENGTH.  Clients are advised that no guarantees can be made about
-the result of a conversion to LENGTH; its use is thus deprecated.
-.FE
-.LP
-References:
-.IP [1] 5
-Adobe Systems, Incorporated.
-.I
-Portable Document Format Reference Manual.
-.R
-Reading, MA, Addison-Wesley, ISBN 0-201-62628-4.
-.IP [2] 5
-Apple Computer, Incorporated.
-.I
-Inside Macintosh, Volume V.
-.R
-Chapter 4, \*QColor QuickDraw,\*U Color \%Picture Format.
-ISBN 0-201-17719-6.
-.IP [3] 5
-Adobe Systems, Incorporated.
-.I
-PostScript Language Reference Manual.
-.R
-Reading, MA, Addison-Wesley, ISBN 0-201-18127-4.
-.LP
-It is expected that this table will grow over time.
-.LP
-Selection owners are required to support the following targets.
-All other targets are optional.
-.bP
-TARGETS \- The owner should return a list of atoms that represent
-the targets for which an attempt to convert the current selection
-will succeed (barring unforseeable problems such as 
-.PN Alloc 
-errors).
-This list should include all the required atoms.
-.bP
-MULTIPLE \- The MULTIPLE target atom is valid only when a property 
-is specified on the 
-.PN ConvertSelection 
-request.
-If the property argument in the 
-.PN SelectionRequest 
-event is 
-.PN None 
-and the target is MULTIPLE, 
-it should be refused.
-.IP
-When a selection owner receives a 
-.PN SelectionRequest (target==MULTIPLE)
-request,
-the contents of the property named in the request will be a list of atom pairs:
-the first atom naming a target and the second naming a property 
-.Pn ( None 
-is not valid here).
-The effect should be as if the owner had received a sequence of
-.PN SelectionRequest 
-events (one for each atom pair) except that:
-.RS
-.IP \- 5
-The owner should reply with a 
-.PN SelectionNotify 
-only when all the requested conversions have been performed.
-.IP \- 5
-If the owner fails to convert the target named by an atom 
-in the MULTIPLE property,
-it should replace that atom in the property with
-.PN None .
-.RE
-.NT Convention
-The entries in a MULTIPLE property must be processed in the order
-they appear in the property.
-For further information,
-see section 2.6.3.
-.NE
-.RS
-.LP
-The requestor should delete each individual property when it has
-copied the data from that conversion, and the property specified in the
-MULTIPLE request when it has copied all the data.
-.LP
-The requests are otherwise to be processed independently, and they
-should succeed or fail independently.  The MULTIPLE target is an
-optimization that reduces the amount of protocol traffic between the
-owner and the requestor; it is not a transaction mechanism.  For
-example, a client may issue a MULTIPLE request with two targets: a data
-target and the DELETE target.  The DELETE target will still be processed
-even if the conversion of the data target fails.
-.RE
-.bP
-TIMESTAMP \- To avoid some race conditions,
-it is important that requestors be able to discover the timestamp 
-the owner used to acquire ownership.
-Until and unless the protocol is changed so that a
-.PN GetSelectionOwner
-request returns the timestamp used to acquire ownership,
-selection owners must support conversion to TIMESTAMP,
-returning the timestamp they used to obtain the selection.
-.nH 3 "Selection Targets with Side Effects"
-.LP
-Some targets (for example, DELETE) have side effects.
-To render these targets unambiguous,
-the entries in a MULTIPLE property must be processed in the order 
-that they appear in the property.
-.LP
-In general,
-targets with side effects will return no information,
-that is, they will return a zero length property of type NULL.
-(Type NULL means the result of
-.PN InternAtom
-on the string \*QNULL\*U, not the value zero.)
-In all cases,
-the requested side effect must be performed before the conversion is accepted.
-If the requested side effect cannot be performed,
-the corresponding conversion request must be refused.
-.NT Conventions
-.IP 1. 5
-Targets with side effects should return no information
-(that is, they should have a zero-length property of type NULL).
-.IP 2. 5
-The side effect of a target must be performed before the conversion is accepted.
-.IP 3. 5
-If the side effect of a target cannot be performed,
-the corresponding conversion request must be refused.
-.NE
-.NT Problem
-The need to delay responding to the 
-.PN ConvertSelection 
-request until a further conversion has succeeded poses problems 
-for the Intrinsics interface that need to be addressed.
-.NE
-.LP
-These side-effect targets are used to implement operations such as
-\*Qexchange PRIMARY and SECONDARY selections.\*U
-.nH 4 "DELETE"
-.LP
-When the owner of a selection receives a request to convert it to DELETE,
-it should delete the corresponding selection
-(whatever doing so means for its internal data structures)
-and return a zero-length property of type NULL if the deletion was successful.
-.nH 4 "INSERT_SELECTION"
-.LP
-When the owner of a selection receives a request to convert it to 
-INSERT_SELECTION,
-the property named will be of type ATOM_PAIR.
-The first atom will name a selection,
-and the second will name a target.
-The owner should use the selection mechanism to convert the named selection
-into the named target and should insert it at the location of the selection
-for which it got the INSERT_SELECTION request
-(whatever doing so means for its internal data structures).
-.nH 4 "INSERT_PROPERTY"
-.LP
-When the owner of a selection receives a request to convert it to
-INSERT_PROPERTY, 
-it should insert the property named in the request at the location 
-of the selection for which it got the INSERT_SELECTION request
-(whatever doing so means for its internal data structures).
-.nH 2 "Use of Selection Properties"
-.LP
-The names of the properties used in selection data transfer are chosen by
-the requestor.
-The use of 
-.PN None 
-property fields in 
-.PN ConvertSelection 
-requests (which request the selection owner to choose a name)
-is not permitted by these conventions.
-.LP
-The selection owner always chooses the type of the property 
-in the selection data transfer.
-Some types have special semantics assigned by convention,
-and these are reviewed in the following sections.
-.LP
-In all cases,
-a request for conversion to a target should return either
-a property of one of the types listed in the previous table for that target
-or a property of type INCR and then a property of one of the listed types.
-.LP
-Certain selection properties may contain resource IDs.  The selection owner
-should ensure that the resource is not destroyed and that its contents are
-not changed until after the selection transfer is complete.  Requestors that
-rely on the existence or on the proper contents of a resource must operate
-on the resource (for example, by copying the contents of a pixmap) before
-deleting the selection property.
-.LP
-The selection owner will return a list of zero or more items
-of the type indicated by the property type.
-In general,
-the number of items in the list will correspond to the number 
-of disjoint parts of the selection.
-Some targets (for example, side-effect targets) will be of length zero
-irrespective of the number of disjoint selection parts.
-In the case of fixed-size items,
-the requestor may determine the number of items by the property size.
-Selection property types are listed in the table below.
-For variable-length items such as text, 
-the separators are also listed.
-.br
-.ne 6
-.TS H
-l c l.
-_
-.sp 6p
-.B
-Type Atom	Format	Separator
-.R
-.sp 6p
-_
-.sp 6p
-.TH
-APPLE_PICT	8	T{
-Self-sizing
-T}
-ATOM	32	Fixed-size
-ATOM_PAIR	32	Fixed-size
-BITMAP	32	Fixed-size
-C_STRING	8	T{
-Zero
-T}
-COLORMAP	32	T{
-Fixed-size
-T}
-COMPOUND_TEXT	8	Zero
-DRAWABLE	32	Fixed-size
-INCR	32	Fixed-size
-INTEGER	32	Fixed-size
-PIXEL	32	T{
-Fixed-size
-T}
-PIXMAP	32	Fixed-size
-SPAN	32	Fixed-size
-STRING	8	Zero
-WINDOW	32	Fixed-size
-.sp 6p
-_
-.TE
-.LP
-It is expected that this table will grow over time.
-.nH 3 "TEXT Properties"
-.LP
-In general, 
-the encoding for the characters in a text string property is specified 
-by its type.
-It is highly desirable for there to be a simple, invertible mapping 
-between string property types and any character set names
-embedded within font names in any font naming standard adopted by the
-Consortium.
-.LP
-The atom TEXT is a polymorphic target.
-Requesting conversion into TEXT will convert into whatever encoding 
-is convenient for the owner.
-The encoding chosen will be indicated by the type of the property returned.
-TEXT is not defined as a type;
-it will never be the returned type from a selection conversion request.
-.LP
-If the requestor wants the owner to return the contents of the selection
-in a specific encoding,
-it should request conversion into the name of that encoding.
-.LP
-In the table in section 2.6.2,
-the word TEXT (in the Type column) is used to indicate one 
-of the registered encoding names.
-The type would not actually be TEXT;
-it would be STRING or some other ATOM naming the encoding chosen by the owner.
-.LP
-STRING as a type or a target specifies the ISO Latin-1 character set plus the
-control characters TAB (octal 11) and NEWLINE (octal 12).
-The spacing interpretation of TAB is context dependent.
-Other ASCII control characters are explicitly not included in STRING 
-at the present time.
-.LP
-COMPOUND_TEXT as a type or a target specifies the Compound Text interchange
-format; see the \fICompound Text Encoding\fP.
-.LP
-There are some text objects where the source or intended user, as the
-case may be, does not have a specific character set for the text, but
-instead merely requires a zero-terminated sequence of bytes with no
-other restriction; no element of the selection mechanism may assume that
-any byte value is forbidden or that any two differing sequences are
-equivalent.\**  For these objects, the type C_STRING should be used.
-.FS
-Note that this is different from STRING, where many byte values are
-forbidden, and from COMPOUND_TEXT, where, for example, inserting the
-sequence 27,\ 40,\ 66 (designate ASCII into GL) at the start does not alter
-the meaning.
-.FE
-.NT Rationale
-An example of the need for C_STRING is to transmit the names of
-files; many operating systems do not interpret filenames as having
-a character set. For example, the same character string uses a
-different sequence of bytes in ASCII and EBCDIC, and so most
-operating systems see these as different filenames and offer no
-way to treat them as the same. Thus no character-set based
-property type is suitable.
-.NE
-.LP
-Type STRING, COMPOUND_TEXT, and C_STRING properties will consist of a list
-of elements separated by null characters; other encodings will need to
-specify an appropriate list format.
-.nH 3 "INCR Properties"
-.LP
-Requestors may receive a property of type INCR\**
-in response to any target that results in selection data.
-.FS
-These properties were called INCREMENTAL in an earlier draft.
-The protocol for using them has changed, 
-and so the name has changed to avoid confusion.
-.FE
-This indicates that the owner will send the actual data incrementally.
-The contents of the INCR property will be an integer,  
-which represents a lower bound on the number of bytes of data in the selection.
-The requestor and the selection owner transfer the data in the selection 
-in the following manner.
-.LP
-The selection requestor starts the transfer process by deleting
-the (type==INCR) property forming the reply to the selection.
-.LP
-The selection owner then:
-.bP
-Appends the data in suitable-size chunks to the
-same property on the same window as the selection reply
-with a type corresponding to the actual type of the converted selection.
-The size should be less than the maximum-request-size in the connection
-handshake.
-.bP
-Waits between each append for a 
-.PN PropertyNotify (state==Deleted) 
-event that shows that the requestor has read the data.
-The reason for doing this is to limit the consumption of space in the server.
-.bP
-Waits (after the entire data has been transferred to the server) until a 
-.PN PropertyNotify (state==Deleted)
-event that shows that the data has been read by the requestor
-and then writes zero-length data to the property.
-.LP
-The selection requestor:
-.bP
-Waits for the 
-.PN SelectionNotify 
-event.
-.bP
-Loops:
-.RS
-.IP \- 5
-Retrieving data using 
-.PN GetProperty 
-with the delete argument
-.PN True .
-.IP \- 5
-Waiting for a 
-.PN PropertyNotify 
-with the state argument 
-.PN NewValue .
-.RE
-.bP
-Waits until the property named by the
-.PN PropertyNotify
-event is zero-length.
-.bP
-Deletes the zero-length property.
-.LP
-The type of the converted selection is the type of the first partial property.
-The remaining partial properties must have the same type.
-.nH 3 "DRAWABLE Properties"
-.LP
-Requestors may receive properties of type PIXMAP, BITMAP, DRAWABLE, or WINDOW,
-which contain an appropriate ID.
-While information about these drawables is available from the server by means of
-the 
-.PN GetGeometry 
-request,
-the following items are not:
-.bP
-Foreground pixel
-.bP
-Background pixel
-.bP
-Colormap ID
-.LP
-In general,
-requestors converting into targets whose returned type in the table 
-in section 2.6.2 is one of the DRAWABLE types should expect to convert also 
-into the following targets (using the MULTIPLE mechanism):
-.bP
-FOREGROUND returns a PIXEL value.
-.bP
-BACKGROUND returns a PIXEL value.
-.bP
-COLORMAP returns a colormap ID.
-.nH 3 "SPAN Properties"
-.LP
-Properties with type SPAN contain a list of cardinal-pairs
-with the length of the cardinals determined by the format.
-The first specifies the starting position,
-and the second specifies the ending position plus one.
-The base is zero.
-If they are the same,
-the span is zero-length and is before the specified position.
-The units are implied by the target atom, 
-such as LINE_NUMBER or CHARACTER_POSITION.
-.nH 2 "Manager Selections"
-.LP
-Certain clients, often called managers, take on responsibility
-for managing shared resources.  A client that manages a shared
-resource should take ownership of an appropriate selection,
-named using the conventions described in sections 1.2.3
-and 1.2.6.  A client that manages multiple
-shared resources (or groups of resources) should take
-ownership of a selection for each one.
-.LP
-The manager may support conversion of various targets
-for that selection.  Managers are encouraged to use this
-technique as the primary means by which clients interact
-with the managed resource.  Note that the conventions for
-interacting with the window manager predate this section;
-as a result many interactions with the window manager use
-other techniques.
-.LP
-Before a manager takes ownership of a manager selection, it
-should use the
-.PN GetSelection\%Owner
-request to check whether the selection is already owned by another client,
-and, where appropriate, it should ask the user if the new manager should
-replace the old one.  If so, it may then take ownership of the selection.
-Managers should acquire the selection using a window created expressly for
-this purpose.  Managers must conform to the rules for selection owners
-described in sections 2.1 and 2.2, and they must also support the required
-targets listed in section 2.6.2.
-.LP
-If a manager loses ownership of a manager selection, this
-means that a new manager is taking over its responsibilities.
-The old manager must release all resources it has managed
-and must then destroy the window that owned the selection.
-For example, a window manager losing ownership of WM_S2
-must deselect from
-.PN SubstructureRedirect
-on the root window of screen 2 before destroying the window that owned
-WM_S2.
-.LP
-When the new manager notices that the window owning the selection
-has been destroyed, it knows that it can successfully proceed to
-control the resource it is planning to manage.  If the old
-manager does not destroy the window within a reasonable time,
-the new manager should check with the user before destroying
-the window itself or killing the old manager.
-.LP
-If a manager wants to give up, on its own, management of a shared
-resource controlled by a selection, it must do so by releasing
-the resources it is managing and then by destroying the
-window that owns the selection.  It should not first disown
-the selection, since this introduces a race condition.
-.LP
-Clients who are interested in knowing when the owner of a
-manager selection is no longer managing the corresponding shared
-resource should select for
-.PN StructureNotify
-on the window owning the selection so they can be notified when the window
-is destroyed.  Clients are warned that after doing a
-.PN GetSelectionOwner
-and selecting for
-.PN StructureNotify ,
-they should do a
-.PN GetSelectionOwner
-again to ensure that the owner did not change after initially getting the
-selection owner and before selecting for 
-.PN StructureNotify .
-.LP
-Immediately after a manager successfully acquires ownership of a
-manager selection, it should announce its arrival by sending a
-.PN ClientMessage
-event.  This event should be sent using the
-.PN SendEvent
-protocol request with the following arguments:
-.br
-.ne 6
-.TS
-l lw(4.5i) .
-_
-.sp 6p
-.B
-Argument	Value
-.R
-.sp 6p
-_
-.sp 6p
-destination:	T{
-the root window of screen 0, or the root
-window of the appropriate screen if the
-manager is managing a screen-specific resource
-T}
-propagate:	False
-event-mask:	T{
-.PN StructureNotify
-T}
-event:	T{
-.PN ClientMessage
-T}
-\h'4n'type:	MANAGER
-\h'4n'format:	32
-T{
-\h'4n'data[0]:\|\**
-T}	timestamp
-\h'4n'data[1]:	manager selection atom
-\h'4n'data[2]:	the window owning the selection
-\h'4n'data[3]:	manager-selection-specific data
-\h'4n'data[4]:	manager-selection-specific data
-.sp 6p
-_
-.TE
-.FS
-We use the notation data[n] to indicate the n\s-2\uth\d\s0 element 
-of the LISTofINT8, LISTofINT16, or LISTofINT32 in the data field of the 
-.PN ClientMessage ,
-according to the format field.
-The list is indexed from zero.
-.FE
-.LP
-Clients that wish to know when a specific manager has started should
-select for
-.PN Structure\%Notify
-on the appropriate root window and should watch for the appropriate MANAGER
-.PN Client\%Message .
-.nH 1 "Peer-to-Peer Communication by Means of Cut Buffers"
-.LP
-The cut buffer mechanism is much simpler but much less powerful 
-than the selection mechanism.
-The selection mechanism is active in that it provides a link 
-between the owner and requestor clients.
-The cut buffer mechanism is passive;
-an owner places data in a cut buffer from which a requestor retrieves
-the data at some later time.
-.LP
-The cut buffers consist of eight properties on the root of screen zero,
-named by the predefined atoms CUT_BUFFER0 to CUT_BUFFER7.
-These properties must, at present, have type STRING and format 8.
-A client that uses the cut buffer mechanism must initially ensure that
-all eight properties exist by using
-.PN ChangeProperty 
-requests to append zero-length data to each.
-.LP
-A client that stores data in the cut buffers (an owner) first must rotate the
-ring of buffers by plus 1 by using
-.PN RotateProperties 
-requests to rename each buffer;
-that is, CUT_BUFFER0 to CUT_BUFFER1, CUT_BUFFER1 to CUT_BUFFER2, .\^.\^.\|,
-and CUT_BUFFER7 to CUT_BUFFER0.
-It then must store the data into CUT_BUFFER0 by using a
-.PN Change\%Property 
-request in mode 
-.PN Replace .
-.LP
-A client that obtains data from the cut buffers should use a
-.PN GetProperty 
-request to retrieve the contents of CUT_BUFFER0.
-.LP
-In response to a specific user request,
-a client may rotate the cut buffers by minus 1 by using 
-.PN RotateProperties 
-requests to rename each buffer;
-that is, CUT_BUFFER7 to CUT_BUFFER6, CUT_BUFFER6 to CUT_BUFFER5, .\^.\^.\|,
-and CUT_BUFFER0 to CUT_BUFFER7.
-.LP
-Data should be stored to the cut buffers
-and the ring rotated only when requested by explicit user action.
-Users depend on their mental model of cut buffer operation
-and need to be able to identify operations that transfer data to and fro.
-.nH 1 "Client-to-Window-Manager Communication"
-.LP
-To permit window managers to perform their role of mediating the competing
-demands for resources such as screen space,
-the clients being managed must adhere to certain conventions
-and must expect the window managers to do likewise.
-These conventions are covered here from the client's point of view.
-.LP
-In general,
-these conventions are somewhat complex
-and will undoubtedly change as new window management paradigms are developed.
-Thus, there is a strong bias toward defining only those conventions
-that are essential and that apply generally to all window management paradigms.
-Clients designed to run with a particular window manager can easily
-define private protocols to add to these conventions,
-but they must be aware that their users may decide to run some other
-window manager no matter how much the designers of the private protocol
-are convinced that they have seen the \*Qone true light\*U of user interfaces.
-.LP
-It is a principle of these conventions that a general client should
-neither know nor care which window manager is running or, indeed, 
-if one is running at all.
-The conventions do not support all client functions 
-without a window manager running;
-for example, the concept of Iconic 
-is not directly supported by clients.
-If no window manager is running,
-the concept of Iconic does not apply.
-A goal of the conventions is to make it possible to kill and
-restart window managers without loss of functionality.
-.LP
-Each window manager will implement a particular window management policy;
-the choice of an appropriate window management policy
-for the user's circumstances is not one for an individual client to
-make but will be made by the user or the user's system administrator.
-This does not exclude the possibility of writing clients that
-use a private protocol to restrict themselves to operating only
-under a specific window manager.
-Rather, 
-it merely ensures that no claim of general utility is made for such programs.
-.LP
-For example,
-the claim is often made: 
-\*QThe client I'm writing is important, and it needs to be on top.\*U
-Perhaps it is important when it is being run in earnest,
-and it should then be run under the control of a window manager 
-that recognizes \*Qimportant\*U windows through some private protocol 
-and ensures that they are on top.
-However, imagine, for example, that the \*Qimportant\*U client is being debugged.
-Then,  ensuring that it is always on top is no longer 
-the appropriate window management policy,
-and it should be run under a window manager that allows other windows 
-(for example, the debugger) to appear on top.
-.nH 2 "Client's Actions"
-.LP
-In general, 
-the object of the X Version 11 design is that clients should,
-as far as possible, do exactly what they would do in the absence 
-of a window manager, except for the following:
-.bP
-Hinting to the window manager about the resources they would like
-to obtain
-.bP
-Cooperating with the window manager by accepting the resources they
-are allocated even if they are not those requested
-.bP
-Being prepared for resource allocations to change at any time
-.nH 3 "Creating a Top-Level Window"
-.LP
-A client's \fItop-level window\fP is a window whose override-redirect
-attribute is
-.PN False .
-It must either be a child of a root window, or it must have been a child of
-a root window immediately prior to having been reparented by the window
-manager.  If the client reparents the window away from the root, the window
-is no longer a top-level window; but it can become a top-level window again
-if the client reparents it back to the root.
-.LP
-A client usually would expect to create its top-level windows
-as children of one or more of the root windows by using some
-boilerplate like the following:
-.LP
-.Ds 0
-.TA 2i
-.ta 2i
-win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), xsh.x, xsh.y, 
-	xsh.width, xsh.height, bw, bd, bg);
-.De
-.LP
-If a particular one of the root windows was required, however,
-it could use something like the following:
-.LP
-.Ds 0
-.TA 2i
-.ta 2i
-win = XCreateSimpleWindow(dpy, RootWindow(dpy, screen), xsh.x, xsh.y, 
-	xsh.width, xsh.height, bw, bd, bg);
-.De
-.LP
-Ideally,
-it should be possible to override the choice of a root window 
-and allow clients (including window managers) to treat a nonroot window 
-as a pseudo-root.
-This would allow, for example, the testing of window managers and the
-use of application-specific window managers to control the subwindows
-owned by the members of a related suite of clients.
-Doing so properly requires an extension,
-the design of which is under study.
-.LP
-From the client's point of view,
-the window manager will regard its top-level window as being in 
-one of three states:
-.bP
-Normal
-.bP
-Iconic
-.bP
-Withdrawn
-.LP
-Newly created windows start in the Withdrawn state.
-Transitions between states happen when the top-level window is mapped
-and unmapped and when the window manager receives certain messages.
-For further details, see sections 4.1.2.4 and 4.1.4.
-.nH 3 "Client Properties"
-.LP
-Once the client has one or more top-level windows, 
-it should place properties on those windows to inform the window manager 
-of the behavior that the client desires.
-Window managers will assume values they find convenient 
-for any of these properties that are not supplied;
-clients that depend on particular values must explicitly supply them.
-The window manager will not change properties written by the client.
-.LP
-The window manager will examine the contents of these
-properties when the window makes the transition from the Withdrawn state
-and will monitor some properties for changes while the window is 
-in the Iconic or Normal state.
-When the client changes one of these properties, 
-it must use 
-.PN Replace
-mode to overwrite the entire property with new data;
-the window manager will retain no memory of the old value of the property.
-All fields of the property must be set to suitable values in a single 
-.PN Replace
-mode 
-.PN ChangeProperty
-request.
-This ensures that the full contents of the property will be
-available to a new window manager if the existing one crashes,
-if it is shut down and restarted,
-or if the session needs to be shut down and restarted by the session manager.
-.NT Convention
-Clients writing or rewriting window manager properties must
-ensure that the entire content of each property remains valid
-at all times.
-.NE
-.LP
-Some of these properties may contain the IDs of resources, such as
-windows or pixmaps.  Clients should ensure that these resources exist
-for at least as long as the window on which the property resides.
-.LP
-If these properties are longer than expected,
-clients should ignore the remainder of the property.
-Extending these properties is reserved to the X Consortium;
-private extensions to them are forbidden.
-Private additional communication between clients and window managers 
-should take place using separate properties.
-The only exception to this rule is the WM_PROTOCOLS property, which may be
-of arbitrary length and which may contain atoms representing private
-protocols (see section 4.1.2.7).
-.LP
-The next sections describe each of the properties the clients
-need to set, in turn.
-They are summarized in the table in section 4.4.
-.nH 4 "WM_NAME Property"
-.LP
-The WM_NAME property is an uninterpreted string 
-that the client wants the window manager to display
-in association with the window (for example, in a window headline bar).
-.LP
-The encoding used for this string 
-(and all other uninterpreted string properties) 
-is implied by the type of the property.
-The type atoms to be used for this purpose are described in section 2.7.1.
-.LP
-Window managers are expected to make an effort to display this information.
-Simply ignoring WM_NAME is not acceptable behavior.
-Clients can assume that at least the first part of this string
-is visible to the user and that if the information is not visible to the user,
-it is because the user has taken an explicit action to make it invisible.
-.LP
-On the other hand,
-there is no guarantee that the user can see the WM_NAME string 
-even if the window manager supports window headlines.
-The user may have placed the headline off-screen
-or have covered it by other windows.
-WM_NAME should not be used for application-critical information 
-or to announce asynchronous changes of an application's state 
-that require timely user response.
-The expected uses are to permit the user to identify one of a
-number of instances of the same client
-and to provide the user with noncritical state information.
-.LP
-Even window managers that support headline bars will place some limit 
-on the length of the WM_NAME string that can be visible;
-brevity here will pay dividends.
-.nH 4 "WM_ICON_NAME Property"
-.LP
-The WM_ICON_NAME property is an uninterpreted string 
-that the client wants to be displayed in association with the window 
-when it is iconified (for example, in an icon label).
-In other respects, 
-including the type, it is similar to WM_NAME.
-For obvious geometric reasons,
-fewer characters will normally be visible in WM_ICON_NAME than WM_NAME.
-.LP
-Clients should not attempt to display this string in their icon pixmaps
-or windows; rather, they should rely on the window manager to do so.
-.nH 4 "WM_NORMAL_HINTS Property"
-.LP
-The type of the WM_NORMAL_HINTS property is WM_SIZE_HINTS.
-Its contents are as follows:
-.br
-.ne 6
-.TS H
-lw(1i) lw(1i) lw(2i).
-_
-.sp 6p
-.B
-Field	Type	Comments
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-flags	CARD32	(see the next table)
-pad	4*CARD32	For backwards compatibility
-min_width	INT32	If missing, assume base_width
-min_height	INT32	If missing, assume base_height
-max_width	INT32
-max_height	INT32
-width_inc	INT32
-height_inc	INT32
-min_aspect	(INT32,INT32)
-max_aspect	(INT32,INT32)
-base_width	INT32	If missing, assume min_width
-base_height	INT32	If missing, assume min_height
-win_gravity	INT32	T{
-If missing, assume
-.PN NorthWest
-T}
-.sp 6p
-_
-.TE
-.LP
-The WM_SIZE_HINTS.flags bit definitions are as follows:
-.br
-.ne 6
-.TS H
-lw(1i) nw(.5i) lw(3i).
-_
-.sp 6p
-.B
-Name	Value	Field
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-T{
-.PN USPosition
-T}	1	User-specified x, y
-T{
-.PN USSize
-T}	2	User-specified width, height
-T{
-.PN PPosition
-T}	4	Program-specified position
-T{
-.PN PSize
-T}	8	Program-specified size
-T{
-.PN PMinSize
-T}	16	Program-specified minimum size
-T{
-.PN PMaxSize
-T}	32	Program-specified maximum size
-T{
-.PN PResizeInc
-T}	64	Program-specified resize increments
-T{
-.PN PAspect
-T}	128	Program-specified min and max aspect ratios
-T{
-.PN PBaseSize
-T}	256	Program-specified base size
-T{
-.PN PWinGravity
-T}	512	Program-specified window gravity
-.sp 6p
-_
-.TE
-.LP
-To indicate that the size and position of the window 
-(when a transition from the Withdrawn state occurs) was specified by the user, 
-the client should set the
-.PN USPosition
-and
-.PN USSize
-flags, 
-which allow a window manager to know that the user specifically asked where
-the window should be placed or how the window should be sized and that
-further interaction is superfluous.
-To indicate that it was specified by the client without any user involvement,
-the client should set 
-.PN PPosition
-and 
-.PN PSize .
-.LP
-The size specifiers refer to the width and height of the client's
-window excluding borders.
-.LP
-The win_gravity may be any of the values specified for WINGRAVITY in
-the core protocol except for
-.PN Unmap :
-.PN NorthWest 
-(1), 
-.PN North 
-(2), 
-.PN NorthEast 
-(3), 
-.PN West 
-(4), 
-.PN Center
-(5),
-.PN East
-(6), 
-.PN SouthWest
-(7),
-.PN South
-(8), and 
-.PN SouthEast
-(9).  It specifies how and whether the client window wants to be shifted to
-make room for the window manager frame.
-.LP
-If the win_gravity is
-.PN Static ,
-the window manager frame is positioned
-so that the inside border of the client window inside the frame is
-in the same position on the screen as it was when the client
-requested the transition from Withdrawn state.  Other values of
-win_gravity specify a window reference point.  For
-.PN NorthWest ,
-.PN NorthEast ,
-.PN SouthWest ,
-and
-.PN SouthEast
-the reference point is the specified outer corner of the window (on the
-outside border edge).  For
-.PN North ,
-.PN South ,
-.PN East ,
-and
-.PN West
-the reference point is the center of the specified outer edge of the window
-border.  For
-.PN Center
-the reference point is the center of the window.  The reference point of the
-window manager frame is placed at the location on the screen where the
-reference point of the client window was when the client requested the
-transition from Withdrawn state.
-.LP
-The min_width and min_height elements specify the
-minimum size that the window can be for the client to be useful.
-The max_width and max_height elements specify the maximum size.
-The base_width and base_height elements in conjunction with width_inc
-and height_inc define an arithmetic progression of preferred window
-widths and heights for non-negative integers \fIi\fP and \fIj\fP:
-.LP
-.Ds
-.EQ C
-width ~ = ~ base_width ~ + ~ ( i ~ times ~ width_inc )
-.EN
-.EQ C
-height ~ = ~ base_height ~ + ~ ( j ~ times ~ height_inc )
-.EN
-.De
-.LP
-Window managers are encouraged to use \fIi\fP and \fIj\fP 
-instead of width and height in reporting window sizes to users.
-If a base size is not provided, 
-the minimum size is to be used in its place and vice versa.
-.LP
-The min_aspect and max_aspect fields are fractions with the numerator first
-and the denominator second, and they allow a client to specify the range of
-aspect ratios it prefers.  Window managers that honor aspect ratios should
-take into account the base size in determining the preferred window size.  If
-a base size is provided along with the aspect ratio fields, the base size
-should be subtracted from the window size prior to checking that the aspect
-ratio falls in range.  If a base size is not provided, nothing should be
-subtracted from the window size.  (The minimum size is not to be used in
-place of the base size for this purpose.)
-.nH 4 "WM_HINTS Property"
-.LP
-The WM_HINTS property (whose type is WM_HINTS)
-is used to communicate to the window manager.
-It conveys the information the window manager needs 
-other than the window geometry,
-which is available from the window itself;
-the constraints on that geometry,
-which is available from the WM_NORMAL_HINTS structure;
-and various strings,
-which need separate properties, such as WM_NAME.
-The contents of the properties are as follows:
-.br
-.ne 6
-.TS H
-l l l.
-_
-.sp 6p
-.B
-Field	Type	Comments
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-flags	CARD32	(see the next table)
-input	CARD32	The client's input model
-initial_state	CARD32	The state when first mapped
-icon_pixmap	PIXMAP	The pixmap for the icon image
-icon_window	WINDOW	The window for the icon image
-icon_x	INT32	The icon location
-icon_y	INT32
-icon_mask	PIXMAP	The mask for the icon shape
-window_group	WINDOW	The ID of the group leader window
-.sp 6p
-_
-.TE
-.LP
-The WM_HINTS.flags bit definitions are as follows:
-.br
-.ne 6
-.TS H
-lw(1.5i) nw(.5i) lw(1.5i).
-_
-.sp 6p
-.B
-Name	Value	Field
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-T{
-.PN InputHint
-T}	1	input
-T{
-.PN StateHint
-T}	2	initial_state
-T{
-.PN IconPixmapHint
-T}	4	icon_pixmap
-T{
-.PN IconWindowHint
-T}	8	icon_window
-T{
-.PN IconPositionHint
-T}	16	icon_x & icon_y
-T{
-.PN IconMaskHint
-T}	32	icon_mask
-T{
-.PN WindowGroupHint
-T}	64	window_group
-T{
-.PN MessageHint
-T}	128	(this bit is obsolete)
-T{
-.PN UrgencyHint
-T}	256	urgency
-.sp 6p
-_
-.TE
-.LP
-Window managers are free to assume convenient values for all fields of
-the WM_HINTS property if a window is mapped without one.
-.LP
-The input field is used to communicate to the window manager the input focus
-model used by the client (see section 4.1.7).
-.LP
-Clients with the Globally Active and No Input models should set the
-input flag to
-.PN False .
-Clients with the Passive and Locally Active models should set the input
-flag to
-.PN True .
-.LP
-From the client's point of view, 
-the window manager will regard the client's top-level window as being 
-in one of three states:
-.bP
-Normal
-.bP
-Iconic
-.bP
-Withdrawn
-.LP
-The semantics of these states are described in section 4.1.4.
-Newly created windows start in the Withdrawn state.
-Transitions between states happen when a
-top-level window is mapped and unmapped
-and when the window manager receives certain messages.
-.LP
-The value of the initial_state field determines the state the client
-wishes to be in at the time the top-level window is mapped 
-from the Withdrawn state, as shown in the following table:
-.br
-.ne 6
-.TS H
-l n l.
-_
-.sp 6p
-.B
-State	Value	Comments
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-T{
-.PN NormalState
-T}	1	The window is visible.
-T{
-.PN IconicState
-T}	3	The icon is visible.
-.sp 6p
-_
-.TE
-.LP
-The icon_pixmap field may specify a pixmap to be used as an icon.
-This pixmap should be:
-.bP
-One of the sizes specified in the WM_ICON_SIZE property 
-on the root if it exists (see section 4.1.3.2).
-.bP
-1-bit deep.
-The window manager will select, through the defaults database,
-suitable background (for the 0 bits) and foreground (for the 1 bits) colors.
-These defaults can, of course, specify different colors for the icons 
-of different clients.
-.LP
-The icon_mask specifies which pixels of the icon_pixmap should be used as the
-icon, allowing for icons to appear nonrectangular.
-.LP
-The icon_window field is the ID of a window the client wants used as its icon.
-Most, but not all, window managers will support icon windows.
-Those that do not are likely to have a user interface in which small
-windows that behave like icons are completely inappropriate.
-Clients should not attempt to remedy the omission by working around it.
-.LP
-Clients that need more capabilities from the icons than a simple 2-color
-bitmap should use icon windows.
-Rules for clients that do are set out in section 4.1.9.
-.LP
-The (icon_x,icon_y) coordinate is a hint to the window manager 
-as to where it should position the icon.
-The policies of the window manager control the positioning of icons,
-so clients should not depend on attention being paid to this hint.
-.LP
-The window_group field lets the client specify that this window belongs 
-to a group of windows.
-An example is a single client manipulating multiple 
-children of the root window.
-.NT Conventions
-.IP 1. 5
-The window_group field should be set to the ID of the group leader.
-The window group leader may be a window that exists only for that purpose;
-a placeholder group leader of this kind would never be mapped
-either by the client or by the window manager.
-.IP 2. 5
-The properties of the window group leader are those for the group as
-a whole (for example, the icon to be shown when the entire group is iconified).
-.NE
-.LP
-Window managers may provide facilities for manipulating the group as a whole.
-Clients, at present, have no way to operate on the group as a whole.
-.LP
-The messages bit, if set in the flags field, indicates that the
-client is using an obsolete window manager communication protocol,\**
-rather than the WM_PROTOCOLS mechanism of section 4.1.2.7.
-.FS
-This obsolete protocol was described in the July 27, 1988,
-draft of the ICCCM.
-Windows using it can also be detected because their WM_HINTS properties are
-4 bytes longer than expected.
-Window managers are free to support clients using the obsolete protocol
-in a backwards compatibility mode.
-.FE
-.LP
-The
-.PN UrgencyHint
-flag, if set in the flags field, indicates that the client deems the window
-contents to be urgent, requiring the timely response of the user.  The
-window manager must make some effort to draw the user's attention to this
-window while this flag is set.  The window manager must also monitor the
-state of this flag for the entire time the window is in the Normal or Iconic
-state and must take appropriate action when the state of the flag changes.
-The flag is otherwise independent of the window's state; in particular, the
-window manager is not required to deiconify the window if the client sets
-the flag on an Iconic window.  Clients must provide some means by which the
-user can cause the
-.PN UrgencyHint
-flag to be set to zero or the window to be withdrawn.  The user's action can
-either mitigate the actual condition that made the window urgent, or it can
-merely shut off the alarm.
-.NT Rationale
-This mechanism is useful for alarm dialog boxes or reminder windows, in
-cases where mapping the window is not enough (e.g., in the presence of
-multi-workspace or virtual desktop window managers), and where using an
-override-redirect window is too intrusive.  For example, the window manager
-may attract attention to an urgent window by adding an indicator to its
-title bar or its icon.  Window managers may also take additional action
-for a window that is newly urgent, such as by flashing its icon (if the
-window is iconic) or by raising it to the top of the stack.
-.NE
-.nH 4 "WM_CLASS Property"
-.LP
-The WM_CLASS property (of type STRING without control characters)
-contains two consecutive null-terminated strings.
-These specify the Instance and Class names to be used by both the client 
-and the window manager for looking up resources for the application 
-or as identifying information.
-This property must be present when the window leaves the Withdrawn state
-and may be changed only while the window is in the Withdrawn state.
-Window managers may examine the property only when they start up 
-and when the window leaves the Withdrawn state,
-but there should be no need for a client to change its state dynamically.
-.LP
-The two strings, respectively, are:
-.bP
-A string that names the particular instance of the application to which
-the client that owns this window belongs.
-Resources that are specified by instance name override any resources
-that are specified by class name.
-Instance names can be specified by the user in an operating-system specific 
-manner.
-On POSIX-conformant systems,
-the following conventions are used:
-.RS
-.IP \- 5
-If \*Q\-name NAME\*U is given on the command line,
-NAME is used as the instance name.
-.IP \- 5
-Otherwise, if the environment variable RESOURCE_NAME is set,
-its value will be used as the instance name.
-.IP \- 5
-Otherwise,
-the trailing part of the name used to invoke the program
-(argv[0] stripped of any directory names) is used as the instance name.
-.RE
-.bP
-A string that names the general class of applications to which the client 
-that owns this window belongs.
-Resources that are specified by class apply to all applications 
-that have the same class name.
-Class names are specified by the application writer.
-Examples of commonly used class names include: 
-\*QEmacs\*U, \*QXTerm\*U, \*QXClock\*U, \*QXLoad\*U, and so on.
-.LP
-Note that WM_CLASS strings are null-terminated
-and, thus, differ from the general conventions that STRING properties 
-are null-separated.
-This inconsistency is necessary for backwards compatibility.
-.nH 4 "WM_TRANSIENT_FOR Property"
-.LP
-The WM_TRANSIENT_FOR property (of type WINDOW)
-contains the ID of another top-level window.
-The implication is that this window is a pop-up on behalf of the named window,
-and window managers may decide not to decorate transient windows
-or may treat them differently in other ways.
-In particular,
-window managers should present newly mapped WM_TRANSIENT_FOR
-windows without requiring any user interaction,
-even if mapping top-level windows normally does require interaction.
-Dialogue boxes, for example, are an example of windows that should have
-WM_TRANSIENT_FOR set.
-.LP
-It is important not to confuse WM_TRANSIENT_FOR with override-redirect.
-WM_TRANSIENT_FOR should be used in those cases where the pointer
-is not grabbed while the window is mapped (in other words, 
-if other windows are allowed to be active while the transient is up).
-If other windows must be prevented from processing input
-(for example, when implementing pop-up menus),
-use override-redirect and grab the pointer while the window is mapped.
-.nH 4 "WM_PROTOCOLS Property"
-.LP
-The WM_PROTOCOLS property (of type ATOM) is a list of atoms.
-Each atom identifies a communication protocol between the client 
-and the window manager in which the client is willing to participate.
-Atoms can identify both standard protocols and private protocols
-specific to individual window managers.
-.LP
-All the protocols in which a client can volunteer to take part 
-involve the window manager sending the client a 
-.PN ClientMessage
-event and the client taking appropriate action.
-For details of the contents of the event,
-see section 4.2.8.
-In each case,
-the protocol transactions are initiated by the window manager.
-.LP
-The WM_PROTOCOLS property is not required.
-If it is not present,
-the client does not want to participate in any window manager protocols.
-.LP
-The X Consortium will maintain a registry of protocols to avoid collisions 
-in the name space.
-The following table lists the protocols that have been defined to date.
-.br
-.ne 6
-.TS H
-l c l.
-_
-.sp 6p
-.B
-Protocol	Section	Purpose
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-WM_TAKE_FOCUS	4.1.7	Assignment of input focus
-WM_SAVE_YOURSELF	Appendix C	Save client state request (deprecated)
-WM_DELETE_WINDOW	4.2.8.1	Request to delete top-level window
-.sp 6p
-_
-.TE
-It is expected that this table will grow over time.
-.nH 4 "WM_COLORMAP_WINDOWS Property"
-.LP
-The WM_COLORMAP_WINDOWS property (of type WINDOW) on a top-level window 
-is a list of the IDs of windows that may need colormaps installed
-that differ from the colormap of the top-level window.
-The window manager will watch this list of windows for changes in their
-colormap attributes.
-The top-level window is always (implicitly or explicitly) on the watch list.
-For the details of this mechanism,
-see section 4.1.8.
-.nH 4 "WM_CLIENT_MACHINE Property"
-.LP
-The client should set the WM_CLIENT_MACHINE property (of one of the TEXT
-types) to a string that forms the name of the machine running the client as
-seen from the machine running the server.
-.nH 3 "Window Manager Properties"
-.LP
-The properties that were described in the previous section are those 
-that the client is responsible for maintaining on its top-level windows.
-This section describes the properties that the window manager places on
-client's top-level windows and on the root.
-.nH 4 "WM_STATE Property"
-.LP
-The window manager will place a WM_STATE property (of type WM_STATE) on each
-top-level client window that is not in the Withdrawn state.  Top-level
-windows in the Withdrawn state may or may not have the WM_STATE property.
-Once the top-level window has been withdrawn, the client may re-use it for
-another purpose.  Clients that do so should remove the WM_STATE property if
-it is still present.
-.LP
-Some clients (such as \fBxprop\fP) will ask the user to click over a window
-on which the program is to operate.  Typically, the intent is for this to be
-a top-level window.  To find a top-level window, clients should search the
-window hierarchy beneath the selected location for a window with the
-WM_STATE property.  This search must be recursive in order to cover all
-window manager reparenting possibilities.  If no window with a WM_STATE
-property is found, it is recommended that programs use a mapped
-child-of-root window if one is present beneath the selected location.
-.LP
-The contents of the WM_STATE property are defined as follows:
-.br
-.ne 6
-.TS H
-l l l.
-_
-.sp 6p
-.B
-Field	Type	Comments
-.R
-.sp 6p
-_
-.sp 6p
-.TH
-state	CARD32	(see the next table)
-icon	WINDOW	ID of icon window
-.sp 6p
-_
-.TE
-.LP
-The following table lists the WM_STATE.state values:
-.br
-.ne 6
-.TS H
-l n.
-_
-.sp 6p
-.B
-State	Value
-.R
-.sp 6p
-_
-.sp 6p
-.TH
-T{
-.PN WithdrawnState
-T}	0
-T{
-.PN NormalState
-T}	1
-T{
-.PN IconicState
-T}	3
-.sp 6p
-_
-.TE
-.LP
-Adding other fields to this property is reserved to the X Consortium.
-Values for the state field other than those defined in the above
-table are reserved for use by the X Consortium.
-.LP
-The state field describes the window manager's idea of the state 
-the window is in, which may not match the client's idea as expressed 
-in the initial_state field of the WM_HINTS property 
-(for example, if the user has asked the window manager to iconify the window).
-If it is 
-.PN Normal\%State ,
-the window manager believes the client should be animating its window.
-If it is 
-.PN IconicState ,
-the client should animate its icon window.
-In either state,
-clients should be prepared to handle exposure events from either window.
-.LP
-When the window is withdrawn, the window manager will either change the
-state field's value to
-.PN Withdrawn\%State
-or it will remove the WM_STATE property entirely.
-.LP
-The icon field should contain the window ID of the window that the
-window manager uses as the icon for the window on which this property is
-set.  If no such window exists, the icon field should be
-.PN None .
-Note that this window could be but is not necessarily the same window as the
-icon window that the client may have specified in its WM_HINTS property.
-The WM_STATE icon may be a window that the window manager has supplied and
-that contains the client's icon pixmap, or it may be an ancestor of the
-client's icon window.
-.nH 4 "WM_ICON_SIZE Property"
-.LP
-A window manager that wishes to place constraints on the sizes of icon
-pixmaps and/or windows should place a property called WM_ICON_SIZE on the root.
-The contents of this property are listed in the following table. 
-.br
-.ne 6
-.TS H
-l l l.
-_
-.sp 6p
-.B
-Field	Type	Comments
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-min_width	CARD32	The data for the icon size series
-min_height	CARD32
-max_width	CARD32
-max_height	CARD32
-width_inc	CARD32
-height_inc	CARD32
-.sp 6p
-_
-.TE
-.LP
-For more details see section 14.1.12 in \fIXlib \- C Language X Interface\fP.
-.nH 3 "Changing Window State"
-.LP
-From the client's point of view,
-the window manager will regard each of the client's top-level 
-windows as being in one of three states,
-whose semantics are as follows:
-.bP
-.PN NormalState
-\- The client's top-level window is viewable.
-.bP
-.PN IconicState
-\- The client's top-level window is iconic
-(whatever that means for this window manager).
-The client can assume that its top-level window is not viewable,
-its icon_window (if any) will be viewable
-and, failing that, 
-its icon_pixmap (if any) or its WM_ICON_NAME will be displayed.
-.bP
-.PN WithdrawnState
-\- Neither the client's top-level window nor its icon is visible.
-.LP
-In fact,
-the window manager may implement states with semantics 
-other than those described above.
-For example,
-a window manager might implement a concept of an \*Qinactive\*U state
-in which an infrequently used client's window would be represented 
-as a string in a menu.
-But this state is invisible to the client,
-which would see itself merely as being in the Iconic state.
-.LP
-Newly created top-level windows are in the Withdrawn state.
-Once the window has been provided with suitable properties,
-the client is free to change its state as follows:
-.bP
-Withdrawn \(-> Normal \- The client should map the window with 
-WM_HINTS.initial_state being 
-.PN NormalState .
-.bP
-Withdrawn \(-> Iconic \- The client should map the window with 
-WM_HINTS.initial_state being 
-.PN IconicState .
-.bP
-Normal \(-> Iconic \- The client should send a
-.PN ClientMessage
-event as described later in this section.
-.bP
-Normal \(-> Withdrawn \- The client should unmap the window and follow it 
-with a synthetic 
-.PN UnmapNotify
-event as described later in this section.
-.bP
-Iconic \(-> Normal \- The client should map the window.
-The contents of WM_HINTS.initial_state are irrelevant in this case.
-.bP
-Iconic \(-> Withdrawn \- The client should unmap the window 
-and follow it with a synthetic 
-.PN UnmapNotify
-event as described later in this section.
-.LP
-Only the client can effect a transition into or out of the Withdrawn
-state.
-Once a client's window
-has left the Withdrawn state,
-the window will be mapped if it is in the Normal state and the window will be
-unmapped if it is in the Iconic state.  Reparenting window managers
-must unmap the client's window when it is in the Iconic state, even if an
-ancestor window being unmapped renders the client's window unviewable.
-Conversely, if a reparenting window manager renders the client's window
-unviewable by unmapping an ancestor, the client's window is by definition in
-the Iconic state and must also be unmapped.
-.NT "Advice to Implementors"
-Clients can select for
-.PN StructureNotify
-on their
-top-level windows to track transitions between Normal and Iconic states.
-Receipt of a
-.PN MapNotify
-event will indicate a transition to the Normal state, and receipt of an
-.PN UnmapNotify
-event will indicate a transition to the Iconic state.
-.NE
-.LP
-When changing the state of the window to Withdrawn, the client must (in
-addition to unmapping the window) send a synthetic
-.PN UnmapNotify
-event by
-using a
-.PN SendEvent
-request with the following arguments:
-.br
-.ne 6
-.TS
-l lw(3.5i).
-_
-.sp 6p
-.B
-Argument	Value
-.sp 6p
-_
-.sp 6p
-.R
-destination:	The root
-propagate:	T{
-.PN False
-T}
-event-mask:	T{
-.Pn ( SubstructureRedirect|SubstructureNotify )
-T}
-T{
-event: an 
-.PN UnmapNotify
-with:
-T}	T{
-T}
-\h'4n'event:	The root
-\h'4n'window:	The window itself
-\h'4n'from-configure:	T{
-.PN False
-T}
-.sp 6p
-_
-.TE
-.NT Rationale
-The reason for requiring the client to send a synthetic
-.PN UnmapNotify
-event is to ensure that the window manager
-gets some notification of the client's desire to change state,
-even though the window may already be unmapped when the desire is expressed.
-.NE
-.NT "Advice to Implementors"
-For compatibility with obsolete clients, 
-window managers should trigger the transition to the Withdrawn state
-on the real 
-.PN UnmapNotify
-rather than waiting for the synthetic one.
-They should also trigger the transition if they receive a synthetic 
-.PN UnmapNotify
-on a window for which they have not yet received a real 
-.PN UnmapNotify .
-.NE
-.LP
-When a client withdraws a window,
-the window manager will then update or remove the WM_STATE
-property as described in section 4.1.3.1.
-Clients that want to re-use a client window (e.g., by mapping it again or
-reparenting it elsewhere) after withdrawing it must wait for the
-withdrawal to be complete before proceeding.  The preferred method for
-doing this is for clients to wait for the window manager to update or
-remove the WM_STATE property.\**
-.FS
-Earlier versions of these conventions prohibited clients from
-reading the WM_STATE property.  Clients operating under the earlier
-conventions used the technique of tracking
-.PN ReparentNotify
-events to wait for the top-level window to be reparented back to the root
-window.  This is still a valid technique; however, it works only for
-reparenting window managers, and the WM_STATE technique is to be preferred.
-.FE
-.LP
-If the transition is from the Normal to the Iconic state,
-the client should send a 
-.PN ClientMessage 
-event to the root with:
-.bP
-Window == the window to be iconified
-.bP
-Type\** == the atom WM_CHANGE_STATE
-.FS
-The type field of the 
-.PN ClientMessage 
-event (called the message_type field by Xlib) should not be confused with
-the code field of the event itself,
-which will have the value 33 
-.Pn ( ClientMessage ).
-.FE
-.bP
-Format == 32
-.bP
-Data[0] == IconicState
-.NT Rationale
-The format of this 
-.PN ClientMessage 
-event does not match the format of 
-.PN ClientMessages
-in section 4.2.8.
-This is because they are sent by the window manager to clients,
-and this message is sent by clients to the window manager.
-.NE
-.LP
-Other values of data[0] are reserved for future extensions to these
-conventions.  The parameters of the 
-.PN SendEvent 
-request should be those described for the synthetic
-.PN UnmapNotify
-event.
-.NT "Advice to Implementors"
-Clients can also select for 
-.PN VisibilityChange
-events on their top-level or icon windows.
-They will then receive a 
-.PN VisibilityNotify (state==FullyObscured)
-event when the window concerned becomes completely
-obscured even though mapped (and thus, perhaps a waste
-of time to update) and a 
-.PN VisibilityNotify (state!=FullyObscured)
-event when it becomes even partly viewable.
-.NE
-.NT "Advice to Implementors"
-When a window makes a transition from the Normal state to either the Iconic
-or the Withdrawn state, clients should be aware that the window manager
-may make transients for this window inaccessible.  Clients should not rely
-on transient windows being available to the user when the transient owner
-window is not in the Normal state.  When withdrawing a window, clients are
-advised to withdraw transients for the window.
-.NE
-.nH 3 "Configuring the Window"
-.LP
-Clients can resize and reposition their top-level windows by using the 
-.PN ConfigureWindow 
-request.
-The attributes of the window that can be altered 
-with this request are as follows:
-.bP
-The [x,y] location of the window's upper left-outer corner
-.bP
-The [width,height] of the inner region of the window (excluding
-borders)
-.bP
-The border width of the window
-.bP
-The window's position in the stack
-.LP
-The coordinate system in which the location is expressed is that of the root
-(irrespective of any reparenting that may have occurred).
-The border width to be used and win_gravity position hint
-to be used are those most recently requested by the client.
-Client configure requests are interpreted by the window manager
-in the same manner as the initial window geometry mapped from
-the Withdrawn state, as described in section 4.1.2.3.
-Clients must be aware that there is no guarantee that the window manager
-will allocate them the requested size or location and must be prepared to
-deal with any size and location.
-If the window manager decides to respond to a 
-.PN ConfigureRequest
-request by:
-.bP
-Not changing the size, location, border width, or stacking order
-of the window at all.
-.IP
-A client will receive a synthetic 
-.PN ConfigureNotify
-event that describes the (unchanged) geometry of the window.
-The (x,y) coordinates will be in the root coordinate system,
-adjusted for the border width the client requested,
-irrespective of any reparenting that has taken place.
-The border_width will be the border width the client requested.
-The client will not receive a real
-.PN ConfigureNotify
-event because no change has actually taken place.
-.bP
-Moving or restacking the window without resizing it or
-changing its border width.
-.IP
-A client will receive a synthetic 
-.PN ConfigureNotify 
-event following the change that describes the new geometry of the window.
-The event's (x,y) coordinates will be in the root coordinate system adjusted 
-for the border width the client requested.
-The border_width will be the border width the client requested.
-The client may not receive a real 
-.PN ConfigureNotify
-event that describes this change because the window manager may have reparented
-the top-level window.
-If the client does receive a real event,
-the synthetic event will follow the real one.
-.bP
-Resizing the window or changing its border width (regardless of whether the
-window was also moved or restacked).
-.IP
-A client that has selected for 
-.PN StructureNotify
-events will receive a real
-.PN ConfigureNotify
-event.
-Note that the coordinates in this event are relative to the parent,
-which may not be the root if the window has been reparented.
-The coordinates will reflect the actual border width of the window
-(which the window manager may have changed).
-The 
-.PN Translate\%Coordinates
-request can be used to convert the coordinates if required.
-.LP
-The general rule is that coordinates in real 
-.PN ConfigureNotify
-events are in the parent's space; 
-in synthetic events, they are in the root space.
-.NT "Advice to Implementors"
-Clients cannot distinguish between the case where a top-level window is
-resized and moved from the case where the window is resized but not moved,
-since a real
-.PN ConfigureNotify
-event will be received in both cases.  Clients that are concerned with
-keeping track of the absolute position of a top-level window should keep a
-piece of state indicating whether they are certain of its position.  Upon
-receipt of a real
-.PN ConfigureNotify
-event on the top-level window, the client should note that the position is
-unknown.  Upon receipt of a synthetic
-.PN ConfigureNotify
-event, the client should note the position as known, using the position in
-this event.  If the client receives a
-.PN KeyPress ,
-.PN KeyRelease ,
-.PN ButtonPress ,
-.PN ButtonRelease ,
-.PN MotionNotify ,
-.PN EnterNotify ,
-or
-.PN LeaveNotify
-event on the window (or on any descendant), the client can deduce the
-top-level window's position from the difference between the (event-x,
-event-y) and (root-x, root-y) coordinates in these events.  Only when the
-position is unknown does the client need to use the
-.PN Translate\%Coordinates
-request to find the position of a top-level window.
-.NE
-.LP
-Clients should be aware that their borders may not be visible.
-Window managers are free to use reparenting techniques to
-decorate client's top-level windows with borders containing
-titles,  controls, and other details to maintain a consistent look-and-feel.
-If they do,
-they are likely to override the client's attempts to set the border width
-and set it to zero.
-Clients, therefore, should not depend on the top-level window's border 
-being visible or use it to display any critical information.
-Other window managers will allow the top-level windows border to
-be visible.
-.NT Convention
-Clients should set the desired value of the border-width attribute on all 
-.PN ConfigureWindow
-requests to avoid a race condition.
-.NE
-.LP
-Clients that change their position in the stack must be aware 
-that they may have been reparented,
-which means that windows that used to be siblings no longer are.
-Using a nonsibling as the sibling parameter on a 
-.PN ConfigureWindow 
-request will cause an error.
-.NT Convention
-Clients that use a
-.PN ConfigureWindow
-request to request a change in their position in the stack 
-should do so using 
-.PN None
-in the sibling field.
-.NE
-.LP
-Clients that must position themselves in the stack relative to some
-window that was originally a sibling must do the 
-.PN ConfigureWindow
-request (in case they are running under a nonreparenting window manager),
-be prepared to deal with a resulting error,
-and then follow with a synthetic 
-.PN ConfigureRequest 
-event by invoking a
-.PN SendEvent
-request with the following arguments:
-.br
-.ne 6
-.TS
-l lw(3.5i).
-_
-.sp 6p
-.B
-Argument	Value
-.sp 6p
-_
-.sp 6p
-.R
-destination:	The root
-propagate:	T{
-.PN False
-T}
-event-mask:	T{
-.Pn ( SubstructureRedirect|SubstructureNotify )
-T}
-T{
-event: a 
-.PN ConfigureRequest 
-with:
-T}	T{
-T}
-\h'4n'event:	The root
-\h'4n'window:	The window itself
-T{
-\h'4n'\&.\^.\^.
-T}	T{
-Other parameters from the
-.PN ConfigureWindow
-request
-T}
-.sp 6p
-_
-.TE
-.LP
-Window managers are in any case free to position windows in the stack as
-they see fit, and so clients should not rely on receiving the stacking
-order they have requested.  Clients should ignore the above-sibling
-field of both real and synthetic
-.PN ConfigureNotify
-events received on their top-level windows because this field may not
-contain useful information.
-.nH 3 "Changing Window Attributes"
-.LP
-The attributes that may be supplied when a window is created may be
-changed by using the 
-.PN ChangeWindowAttributes
-request.
-The window attributes are listed in the following table:
-.br
-.ne 6
-.TS H
-l l
-l c.
-_
-.sp 6p
-.B
-Attribute	Private to Client
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-Background pixmap	Yes
-Background pixel	Yes
-Border pixmap	Yes
-Border pixel	Yes
-Bit gravity	Yes
-Window gravity	No
-Backing-store hint	Yes
-Save-under hint	No
-Event mask	No
-Do-not-propagate mask	Yes
-Override-redirect flag	No
-Colormap	Yes
-Cursor	Yes
-.sp 6p
-_
-.TE
-.LP
-Most attributes are private to the client and will never be interfered with
-by the window manager.
-For the attributes that are not private to the client:
-.bP
-The window manager is free to override the window gravity;
-a reparenting window manager may want to set the top-level window's
-window gravity for its own purposes.
-.bP
-Clients are free to set the save-under hint on their top-level windows,
-but they must be aware that the hint may be overridden by the window manager.
-.bP
-Windows, in effect, have per-client event masks,
-and so, clients may select for whatever events are convenient irrespective 
-of any events the window manager is selecting for.
-There are some events for which only one client at a time may select,
-but the window manager should not select for them on any of the client's
-windows.
-.bP
-Clients can set override-redirect on top-level windows but are
-encouraged not to do so except as described in sections 4.1.10 and 4.2.9.
-.nH 3 "Input Focus"
-.LP
-There are four models of input handling:
-.bP
-No Input \- The client never expects keyboard input.
-An example would be 
-.PN xload
-or another output-only client.
-.bP
-Passive Input \- The client expects keyboard input but never explicitly sets 
-the input focus.
-An example would be a simple client with no subwindows,
-which will accept input in 
-.PN PointerRoot
-mode or when the window manager sets the input focus to its top-level window 
-(in click-to-type mode).
-.bP
-Locally Active Input \- The client expects keyboard input and explicitly sets 
-the input focus, 
-but it only does so when one of its windows already has the focus.
-An example would be a client with subwindows defining various data
-entry fields that uses Next and Prev keys to move the input focus
-between the fields.
-It does so when its top-level window has acquired the focus in 
-.PN PointerRoot
-mode or when the window manager sets the input focus to its top-level window 
-(in click-to-type mode).
-.bP
-Globally Active Input \- The client expects keyboard input and explicitly sets 
-the input focus, 
-even when it is in windows the client does not own.
-An example would be a client with a scroll bar that wants to allow
-users to scroll the window without disturbing the input focus even if
-it is in some other window.
-It wants to acquire the input focus when the user clicks in the scrolled
-region but not when the user clicks in the scroll bar itself.
-Thus, it wants to prevent the window manager from setting the input focus 
-to any of its windows.
-.LP
-The four input models and the corresponding values of the input field
-and the presence or absence of the WM_TAKE_FOCUS atom in the
-WM_PROTOCOLS property are listed in the following table:
-.br
-.ne 6
-.TS H
-l l l
-l c c.
-_
-.sp 6p
-.B
-Input Model	Input Field	WM_TAKE_FOCUS
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-T{
-No Input
-T}	T{
-.PN False
-T}	T{
-Absent
-T}
-T{
-Passive
-T}	T{
-.PN True
-T}	T{
-Absent
-T}
-T{
-Locally Active
-T}	T{
-.PN True
-T}	T{
-Present
-T}
-T{
-Globally Active
-T}	T{
-.PN False
-T}	T{
-Present
-T}
-.sp 6p
-_
-.TE
-.LP
-Passive and Locally Active clients set the input field of WM_HINTS to
-.PN True ,
-which indicates that they require window manager assistance  in acquiring the
-input focus.
-No Input and Globally Active clients set the input field to
-.PN False ,
-which requests that the window manager not set the input focus 
-to their top-level window.
-.LP
-Clients that use a
-.PN SetInputFocus
-request must set the time field to the timestamp of the event 
-that caused them to make the attempt.
-This cannot be a 
-.PN FocusIn
-event because they do not have timestamps.
-Clients may also acquire 
-the focus without a corresponding 
-.PN EnterNotify .
-Note that clients must not use 
-.PN CurrentTime 
-in the time field.
-.LP
-Clients using the Globally Active model can only use a
-.PN SetInputFocus
-request to acquire the input focus when they do not already have it on
-receipt of one of the following events:
-.bP
-.PN ButtonPress
-.bP
-.PN ButtonRelease
-.bP
-Passive-grabbed 
-.PN KeyPress
-.bP
-Passive-grabbed
-.PN KeyRelease
-.LP
-In general,
-clients should avoid using passive-grabbed key events for this purpose,
-except when they are unavoidable (as, for example, a selection tool 
-that establishes a passive grab on the keys that cut,  copy,  or paste).
-.LP
-The method by which the user commands the window manager to
-set the focus to a window is up to the window manager.
-For example, 
-clients cannot determine whether they will see the click 
-that transfers the focus.
-.LP
-Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property
-may receive a 
-.PN ClientMessage 
-event from the window manager (as described in section 4.2.8)
-with WM_TAKE_FOCUS in its data[0] field and a valid timestamp
-(i.e., not
-.PN CurrentTime )
-in its data[1] field.
-If they want the focus,
-they should respond with a 
-.PN SetInputFocus
-request with its window field set to the window of theirs 
-that last had the input focus or to their default input window,
-and the time field set to the timestamp in the message.
-For further information,
-see section 4.2.7.
-.LP
-A client could receive WM_TAKE_FOCUS when opening from an icon
-or when the user has clicked outside the top-level window in an area that
-indicates to the window manager that it should assign the focus 
-(for example, clicking in the headline bar can be used to assign the focus).
-.LP
-The goal is to support window managers that want to assign the input focus
-to a top-level window in such a way that the top-level window either
-can assign it to one of its subwindows or can decline the offer of the focus.
-For example, a clock or a text editor with no currently open frames 
-might not want to take focus even though the window manager generally 
-believes that clients should take the input focus after being deiconified 
-or raised.
-.LP
-Clients that set the input focus need to decide a value for the
-revert-to field of the 
-.PN SetInputFocus
-request.
-This determines the behavior of the input focus 
-if the window the focus has been set to becomes not viewable.
-The value can be any of the following:
-.bP
-.PN Parent
-\- In general, 
-clients should use this value when assigning focus to one of their subwindows.
-Unmapping the subwindow will cause focus to revert to the parent,
-which is probably what you want.
-.bP
-.PN PointerRoot 
-\- Using
-this value with a click-to-type focus management policy
-leads to race conditions because the window becoming unviewable may
-coincide with the window manager deciding to move the focus elsewhere.
-.bP
-.PN None 
-\- Using
-this value causes problems if the window manager reparents 
-the window, as most window managers will, and then crashes.
-The input focus will be 
-.PN None , 
-and there will probably be no way to change it.
-.LP
-Note that neither
-.PN PointerRoot
-nor
-.PN None
-is really safe to use.
-.NT Convention
-Clients that invoke a
-.PN SetInputFocus 
-request should set the revert-to argument to 
-.PN Parent .
-.NE
-.LP
-A convention is also required for clients that want to give up the
-input focus.
-There is no safe value set for them to set the input focus to;
-therefore, they should ignore input material.
-.NT Convention
-Clients should not give up the input focus of their own volition.
-They should ignore input that they receive instead.
-.NE
-.nH 3 "Colormaps"
-.LP
-The window manager is responsible for installing and uninstalling 
-colormaps on behalf of clients with top-level windows that
-the window manager manages.
-.LP
-Clients provide the window manager with hints as to which colormaps to
-install and uninstall.  Clients must not install or uninstall colormaps
-themselves (except under the circumstances noted below).  When a client's
-top-level window gets the colormap focus (as a result of whatever colormap
-focus policy is implemented by the window manager), the window manager will
-ensure that one or more of the client's colormaps are installed.
-.LP
-Clients whose top-level windows and subwindows all use the same colormap
-should set its ID in the colormap field of the top-level window's
-attributes.  They should not set a WM_COLORMAP_WINDOWS property on the
-top-level window.  If they want to change the colormap, they should change
-the top-level window's colormap attribute.  The window manager will track
-changes to the window's colormap attribute and install colormaps as
-appropriate.
-.LP
-Clients that create windows can use the value 
-.PN CopyFrom\%Parent
-to inherit their parent's colormap.  Window managers will ensure that the
-root window's colormap field contains a colormap that is suitable for
-clients to inherit.  In particular, the colormap will provide
-distinguishable colors for
-.PN BlackPixel 
-and 
-.PN WhitePixel .
-.LP
-Top-level windows that have subwindows or override-redirect pop-up windows
-whose colormap requirements differ from the top-level window should have a
-WM_COLORMAP_WINDOWS property.  This property contains a list of IDs for
-windows whose colormaps the window manager should attempt to have installed
-when, in the course of its individual colormap focus policy, it assigns the
-colormap focus to the top-level window (see section 4.1.2.8).  The list is
-ordered by the importance to the client of having the colormaps installed.
-The window manager will track changes to this property and will track
-changes to the colormap attribute of the windows in the property.
-.LP
-If the relative importance of colormaps changes, the client should update
-the WM_COLORMAP_WINDOWS property to reflect the new ordering.  If the
-top-level window does not appear in the list, the window manager will assume
-it to be of higher priority than any window in the list.
-.LP
-WM_TRANSIENT_FOR windows can either have their own WM_COLORMAP_WINDOWS
-property or appear in the property of the window they are transient for,
-as appropriate.
-.NT Rationale
-An alternative design was considered for how clients should hint to the
-window manager about their colormap requirements.  This alternative design
-specified a list of colormaps instead of a list of windows.  The current
-design, a list of windows, was chosen for two reasons.  First, it allows
-window managers to find the visuals of the colormaps, thus permitting
-visual-dependent colormap installation policies.  Second, it allows window
-managers to select for
-.PN Visibility\%Change
-events on the windows concerned and to ensure that colormaps are only
-installed if the windows that need them are visible.  The alternative design
-allows for neither of these policies.
-.NE
-.NT "Advice to Implementors"
-Clients should be aware of the min-installed-maps and max-installed-maps
-fields of the connection setup information, and the effect that the minimum
-value has on the \*Qrequired list\*U defined by the Protocol in the
-description of the
-.PN Install\%Colormap
-request.  Briefly, the min-installed-maps most recently installed maps are
-guaranteed to be installed.  This value is often one; clients needing
-multiple colormaps should beware.
-.NE
-.LP
-Whenever possible, clients should use the mechanisms described above and let
-the window manager handle colormap installation.  However, clients are
-permitted to perform colormap installation on their own while they have the
-pointer grabbed.  A client performing colormap installation must notify the
-window manager prior to the first installation.  When the client has
-finished its colormap installation, it must also notify the window manager.
-The client notifies the window manager by issuing a
-.PN Send\%Event
-request with the following arguments:
-.br
-.LP
-.ne 6
-.TS
-tab(/) ;
-lB lB
-l lw(3.5i)
-.
-_
-.sp 6p
-Argument/Value
-.sp 6p
-_
-destination:/T{
-the root window of the screen on
-which the colormap is being installed
-T}
-propagate:/T{
-.PN False
-T}
-event-mask:/T{
-.PN ColormapChange
-T}
-T{
-event: a
-.PN ClientMessage
-with:
-T}
-\h'2m'window:/the root window, as above
-\h'2m'type:/WM_COLORMAP_NOTIFY
-\h'2m'format:/32
-\h'2m'data[0]:/T{
-the timestamp of the event that caused
-the client to start or stop installing colormaps
-T}
-\h'2m'data[1]:/T{
-1 if the client is starting colormap installation, 0 if the client is
-finished with colormap installation
-T}
-\h'2m'data[2]:/reserved, must be zero
-\h'2m'data[3]:/reserved, must be zero
-\h'2m'data[4]:/reserved, must be zero
-.sp 6p
-_
-.TE
-.LP
-This feature was introduced in version 2.0 of this document, and there will
-be a significant period of time before all window managers can be expected
-to implement this feature.  Before using this feature, clients must check
-the compliance level of the window manager (using the mechanism described in
-section 4.3) to verify that it supports this feature.  This is necessary to
-prevent colormap installation conflicts between clients and older window
-managers.
-.LP
-Window managers should refrain from installing colormaps while a client has
-requested control of colormap installation.  The window manager should
-continue to track the set of installed colormaps so that it can reinstate
-its colormap focus policy when the client has finished colormap installation.
-.LP
-This technique has race conditions that may result in the colormaps
-continuing to be installed even after a client has issued its notification
-message.  For example, the window manager may have issued some
-.PN Install\%Colormap
-requests that are not executed until after the
-client's 
-.PN SendEvent \%
-and
-.PN Install\%Colormap
-requests, thus uninstalling the client's colormaps.  If this occurs while
-the client still has the pointer grabbed and before the client has issued
-the \*Qfinished\*U message, the client may reinstall the desired colormaps.
-.NT "Advice to Implementors"
-Clients are expected to use this mechanism for things such as
-pop-up windows and for animations that use override-redirect windows.
-.\" Avoid .LP within a .NT, because it resets the margins.  The .NT
-.\" macro should probably be fixed.
-.br
-.sp \n(PDu
-If a client fails to issue the \*Qfinished\*U message, the window manager
-may be left in a state where its colormap installation policy is suspended.
-Window manager implementors may want to implement a feature that resets
-colormap installation policy in response to a command from the user.
-.NE
-.nH 3 "Icons"
-.LP
-A client can hint to the window manager about the desired appearance 
-of its icon by setting:
-.bP
-A string in WM_ICON_NAME.
-.IP
-All clients should do this  
-because it provides a fallback for window managers whose ideas 
-about icons differ widely from those of the client.
-.bP
-A 
-.PN Pixmap 
-into the icon_pixmap field of the WM_HINTS property
-and possibly another into the icon_mask field.
-.IP
-The window manager is expected to display the pixmap masked by the mask.
-The pixmap should be one of the sizes found in the WM_ICON_SIZE property
-on the root.
-If this property is not found,
-the window manager is unlikely to display icon pixmaps.
-Window managers usually will clip or tile pixmaps that do not match
-WM_ICON_SIZE.
-.bP
-A window into the icon_window field of the WM_HINTS property.
-.IP
-The window manager is expected to map that window whenever the client is
-in the Iconic state.
-In general,
-the size of the icon window should be one of those specified in WM_ICON_SIZE 
-on the root, if it exists.
-Window managers are free to resize icon windows.
-.LP
-In the Iconic state,
-the window manager usually will ensure that:
-.bP
-If the window's WM_HINTS.icon_window is set,
-the window it names is visible.
-.bP
-If the window's WM_HINTS.icon_window is not set
-but the window's WM_HINTS.icon_pixmap is set,
-the pixmap it names is visible.
-.bP
-Otherwise,
-the window's WM_ICON_NAME string is visible.
-.LP
-Clients should observe the following conventions about their icon windows:
-.NT Conventions
-.IP 1. 5
-The icon window should be an 
-.PN InputOutput
-child of the root.
-.IP 2. 5
-The icon window should be one of the sizes specified 
-in the WM_ICON_SIZE property on the root.
-.IP 3. 5
-The icon window should use the root visual and default colormap 
-for the screen in question.
-.IP 4. 5
-Clients should not map their icon windows.
-.IP 5. 5
-Clients should not unmap their icon windows.
-.IP 6. 5
-Clients should not configure their icon windows.
-.IP 7. 5
-Clients should not set override-redirect on their icon windows
-or select for 
-.PN Resize\%Redirect 
-events on them.
-.IP 8. 5
-Clients must not depend on being able to receive input events
-by means of their icon windows.
-.IP 9. 5
-Clients must not manipulate the borders of their icon windows.
-.IP 10. 5
-Clients must select for 
-.PN Exposure
-events on their icon window and repaint it when requested.
-.NE
-.LP
-Window managers will differ as to whether they support input events
-to client's icon windows;
-most will allow the client to receive some subset of the keys and buttons.
-.LP
-Window managers will ignore any WM_NAME, WM_ICON_NAME, WM_NORMAL_HINTS,
-WM_HINTS, WM_CLASS, WM_TRANSIENT_FOR, WM_PROTOCOLS, WM_COLORMAP_WINDOWS,
-WM_COMMAND, or WM_CLIENT_MACHINE
-properties they find on icon windows.
-.nH 3 "Pop-up Windows"
-.LP
-Clients that wish to pop up a window can do one of three things:
-.IP 1. 5
-They can create and map another normal top-level window,
-which will get decorated and managed as normal by the window manager.
-See the discussion of window groups that follows.
-.IP 2. 5
-If the window will be visible for a relatively short time
-and deserves a somewhat lighter treatment,
-they can set the WM_TRANSIENT_FOR property.
-They can expect less decoration but can set all the normal
-window manager properties on the window.
-An example would be a dialog box.
-.IP 3. 5
-If the window will be visible for a very short time
-and should not be decorated at all,
-the client can set override-redirect on the window.
-In general,
-this should be done only if the pointer is grabbed while the window is mapped.
-The window manager will never interfere with these windows,
-which should be used with caution.
-An example of an appropriate use is a pop-up menu.
-.NT "Advice to Implementors"
-The user will not be able to move, resize, restack, or transfer the input
-focus to override-redirect windows, since the window manager is not managing
-them.  If it is necessary for a client to receive keystrokes on an
-override-redirect window, either the client must grab the keyboard or the
-client must have another top-level window that is not override-redirect and
-that has selected the Locally Active or Globally Active focus model.  The
-client may set the focus to the override-redirect window when the other
-window receives a WM_TAKE_FOCUS message or one of the events listed in
-section 4.1.7 in the description of the Globally Active focus model.
-.NE
-.LP
-Window managers are free to decide if WM_TRANSIENT_FOR windows
-should be iconified when the window they are transient for is.
-Clients displaying WM_TRANSIENT_FOR windows that have 
-(or request to have) the window they are transient for iconified
-do not need to request that the same operation be performed
-on the WM_TRANSIENT_FOR window;
-the window manager will change its state if that is the policy it wishes 
-to enforce.
-.nH 3 "Window Groups"
-.LP
-A set of top-level windows that should be treated from the user's point of view
-as related (even though they may belong to a number of clients) should be linked
-together using the window_group field of the WM_HINTS structure.
-.LP
-One of the windows (that is, the one the others point to) 
-will be the group leader and will carry the group as opposed 
-to the individual properties.
-Window managers may treat the group leader differently 
-from other windows in the group.
-For example,
-group leaders may have the full set of decorations,
-and other group members may have a restricted set.
-.LP
-It is not necessary that the client ever map the group leader;
-it may be a window that exists solely as a placeholder.
-.LP
-It is up to the window manager to determine the policy 
-for treating the windows in a group.
-At present, 
-there is no way for a client to request a group, 
-as opposed to an individual, operation.
-.nH 2 "Client Responses to Window Manager Actions"
-.LP
-The window manager performs a number of operations on client resources,
-primarily on their top-level windows.
-Clients must not try to fight this but may elect to receive notification 
-of the window manager's operations.
-.nH 3 "Reparenting"
-.LP
-Clients must be aware that some window managers will reparent 
-their top-level windows
-so that a window that was created as a child of the root will be displayed 
-as a child of some window belonging to the window manager.
-The effects that this reparenting will have on the client are as follows:
-.bP
-The parent value returned by a 
-.PN QueryTree
-request will no longer be the value supplied to the 
-.PN CreateWindow 
-request that created the reparented window.
-There should be no need for the client to be aware of the identity 
-of the window to which the top-level window has been reparented.
-In particular,
-a client that wishes to create further top-level windows should continue 
-to use the root as the parent for these new windows.
-.bP
-The server will interpret the (x,y) coordinates in a 
-.PN ConfigureWindow
-request in the new parent's coordinate space.
-In fact, they usually will not be interpreted by the server
-because a reparenting window manager usually will have intercepted
-these operations (see section 4.2.2).
-Clients should use the root coordinate space for these requests
-(see section 4.1.5).
-.bP
-.PN ConfigureWindow
-requests that name a specific sibling window may fail because the window named,
-which used to be a sibling, no longer is after the reparenting operation
-(see section 4.1.5).
-.bP
-The (x,y) coordinates returned by a 
-.PN GetGeometry
-request are in the parent's coordinate space 
-and are thus not directly useful after a reparent operation.
-.bP
-A background of 
-.PN ParentRelative
-will have unpredictable results.
-.bP
-A cursor of 
-.PN None
-will have unpredictable results.
-.LP
-Clients that want to be notified when they are reparented can select for
-.PN StructureNotify
-events on their top-level window.
-They will receive a 
-.PN ReparentNotify
-event if and when reparenting takes place.
-When a client withdraws a top-level window, the window manager will
-reparent it back to the root window if the window had been reparented
-elsewhere.
-.LP
-If the window manager reparents a client's window,
-the reparented window will be placed in the save-set 
-of the parent window.
-This means that the reparented window will not be destroyed 
-if the window manager terminates and will be remapped if it was unmapped.
-Note that this applies to all client windows the window manager reparents,
-including transient windows and client icon windows.
-.nH 3 "Redirection of Operations"
-.LP
-Clients must be aware that some window managers will arrange 
-for some client requests to be intercepted and redirected.
-Redirected requests are not executed; 
-they result instead in events being sent to the window manager,
-which may decide to do nothing, to alter the arguments, 
-or to perform the request on behalf of the client.
-.LP
-The possibility that a request may be redirected means 
-that a client cannot assume that any redirectable request is actually
-performed when the request is issued or is actually performed at all.
-The requests that may be redirected are
-.PN \%MapWindow ,
-.PN Configure\%Window ,
-and
-.PN Circulate\%Window .
-.NT "Advice to Implementors"
-The following is incorrect because the 
-.PN MapWindow
-request may be intercepted and the
-.PN PolyLine
-output made to an unmapped window:
-.LP
-.DS
-MapWindow A
-PolyLine A GC <point> <point> .\^.\^.
-.DE
-.LP
-The client must wait for an 
-.PN Expose
-event before drawing in the window.\**
-.FS
-This is true even if the client set the backing-store attribute to 
-.PN Always .
-The backing-store attribute is a only a hint, 
-and the server may stop maintaining backing store contents at any time.
-.FE
-.LP
-This next example incorrectly assumes that the 
-.PN ConfigureWindow
-request is actually executed with the arguments supplied:
-.LP
-.DS
-ConfigureWindow width=N height=M
-<output assuming window is N by M>
-.DE
-.LP
-The client should select for
-.PN Structure\%Notify
-on its window and monitor the window's size by tracking
-.PN Configure\%Notify
-events.
-.LP
-Clients must be especially careful when attempting to set the focus to a
-window that they have just mapped.  This sequence may result in an X
-protocol error:
-.LP
-.DS
-MapWindow B
-SetInputFocus B
-.DE
-.LP
-If the
-.PN Map\%Window
-request has been intercepted, the window will still be
-unmapped, causing the
-.PN SetInput\%Focus
-request to generate the error.  The solution to this problem is for clients
-to select for
-.PN Visibility\%Change
-on the window and to delay the issuance of the
-.PN SetInput\%Focus
-request until they have received a 
-.PN Visibility\%Notify
-event indicating that the window is visible.
-.LP
-This technique does not guarantee correct operation.  The user may have
-iconified the window by the time the
-.PN SetInput\%Focus
-request reaches the server, still causing an error.  Or the window manager
-may decide to map the window into Iconic state, in which case the window
-will not be visible.  This will delay the generation of the
-.PN Visibility\%Notify
-event indefinitely.  Clients must be prepared to handle these cases.
-.NE
-.LP
-A window with the override-redirect bit set is immune from redirection,
-but the bit should be set on top-level windows only in cases 
-where other windows should be prevented from processing input
-while the override-redirect window is mapped (see section 4.1.10)
-and while responding to 
-.PN ResizeRequest
-events (see section 4.2.9).
-.LP
-Clients that have no non-Withdrawn top-level windows 
-and that map an override-redirect top-level window are taking over total
-responsibility for the state of the system.
-It is their responsibility to:
-.bP
-Prevent any preexisting window manager from interfering with their activities
-.bP
-Restore the status quo exactly after they unmap the window
-so that any preexisting window manager does not get confused
-.LP
-In effect,  clients of this kind are acting as temporary window managers.
-Doing so is strongly discouraged because these clients will be unaware
-of the user interface policies the window manager is trying to maintain
-and because their user interface behavior is likely to conflict with that of
-less demanding clients.
-.nH 3 "Window Move"
-.LP
-If the window manager moves a top-level window without changing its size,
-the client will receive a synthetic 
-.PN ConfigureNotify
-event following the move that describes the new location
-in terms of the root coordinate space.
-Clients must not respond to being moved by attempting to move
-themselves to a better location.
-.LP
-Any real 
-.PN ConfigureNotify
-event on a top-level window implies that the window's position 
-on the root may have changed,
-even though the event reports that the window's position 
-in its parent is unchanged because the window may have been reparented.
-Note that the coordinates in the event will not, in this case,
-be directly useful.
-.LP
-The window manager will send these events by using a
-.PN SendEvent
-request with the following arguments:
-.br
-.ne 6
-.TS
-l l.
-_
-.sp 6p
-.B
-Argument	Value
-.sp 6p
-_
-.sp 6p
-.R
-destination:	The client's window
-propagate:	T{
-.PN False
-T}
-event-mask:	T{
-.PN StructureNotify
-T}
-.sp 6p
-_
-.TE
-.nH 3 "Window Resize"
-.LP
-The client can elect to receive notification of being resized by selecting for
-.PN StructureNotify
-events on its top-level windows.
-It will receive a 
-.PN ConfigureNotify
-event.
-The size information in the event will be correct,
-but the location will be in the parent window (which may not be the root).
-.LP
-The response of the client to being resized should be to accept
-the size it has been given and to do its best with it.
-Clients must not respond to being resized by attempting to resize
-themselves to a better size.
-If the size is impossible to work with,
-clients are free to request to change to the Iconic state.
-.nH 3 "Iconify and Deiconify"
-.LP
-A top-level window that is not Withdrawn will be 
-in the Normal state if it is mapped and in the Iconic state if it is unmapped.
-This will be true even if the window has been reparented;
-the window manager will unmap the window as well as its parent
-when switching to the Iconic state.
-.LP
-The client can elect to be notified of these state changes by selecting for 
-.PN StructureNotify 
-events on the top-level window.
-It will receive a
-.PN UnmapNotify
-event when it goes Iconic and a
-.PN MapNotify
-event when it goes Normal.
-.nH 3 "Colormap Change"
-.LP
-Clients that wish to be notified of their colormaps being installed
-or uninstalled should select for 
-.PN ColormapNotify
-events on their top-level windows and on any windows they have named 
-in WM_COLORMAP_WINDOWS properties on their top-level windows.
-They will receive 
-.PN ColormapNotify
-events with the new field FALSE when the colormap for that window 
-is installed or uninstalled.
-.nH 3 "Input Focus"
-.LP
-Clients can request notification that they have the input focus by selecting
-for 
-.PN FocusChange
-events on their top-level windows;
-they will receive 
-.PN FocusIn 
-and 
-.PN FocusOut
-events.
-Clients that need to set the input focus to one of their
-subwindows should not do so unless
-they have set WM_TAKE_FOCUS in their WM_PROTOCOLS property 
-and have done one of the following:
-.bP
-Set the input field of WM_HINTS to 
-.PN True
-and actually have the input focus in one of their top-level windows
-.bP
-Set the input field of WM_HINTS to 
-.PN False
-and have received a suitable event as described in section 4.1.7
-.bP
-Have received a WM_TAKE_FOCUS message as described in section 4.1.7
-.LP
-Clients should not warp the pointer in an attempt to transfer the focus;
-they should set the focus and leave the pointer alone.
-For further information,
-see section 6.2.
-.LP
-Once a client satisfies these conditions,
-it may transfer the focus to another of its windows by using the 
-.PN SetInputFocus
-request, which is defined as follows:
-.LP
-.sM
-.IN "SetInputFocus" "" "@DEF@"
-.PN SetInputFocus
-.IP "" .2i
-\fIfocus\fP\^: WINDOW or
-.PN PointerRoot
-or
-.PN None
-.br
-\fIrevert-to\fP\^:
-.Pn { Parent ,
-.PN PointerRoot ,
-.PN None }
-.br
-\fItime\fP\^: TIMESTAMP or
-.PN CurrentTime
-.LP
-.eM
-.NT Conventions
-.IP 1. 5
-Clients that use a  
-.PN SetInputFocus
-request must set the time argument to the timestamp of the event 
-that caused them to make the attempt.
-This cannot be a 
-.PN FocusIn
-event because they do not have timestamps.
-Clients may also acquire the focus without a corresponding 
-.PN EnterNotify 
-event.
-Clients must not use 
-.PN CurrentTime
-for the time argument.
-.IP 2. 5
-Clients that use a  
-.PN SetInputFocus
-request to set the focus to one of their windows must set 
-the revert-to field to 
-.PN Parent .
-.NE
-.nH 3 "ClientMessage Events"
-.LP
-There is no way for clients to prevent themselves being sent
-.PN ClientMessage
-events.
-.LP
-Top-level windows with a WM_PROTOCOLS property may be sent 
-.PN ClientMessage
-events specific to the protocols named by the atoms in the property 
-(see section 4.1.2.7).
-For all protocols, the 
-.PN ClientMessage
-events have the following:
-.bP
-WM_PROTOCOLS as the type field
-.bP
-Format 32
-.bP
-The atom that names their protocol in the data[0] field
-.bP
-A timestamp in their data[1] field
-.LP
-The remaining fields of the event,
-including the window field,
-are determined by the protocol.
-.LP
-These events will be sent by using a
-.PN SendEvent
-request with the following arguments:
-.br
-.ne 6
-.TS
-l l.
-_
-.sp 6p
-.B
-Argument	Value
-.sp 6p
-_
-.sp 6p
-.R
-destination:	The client's window
-propagate:	T{
-.PN False
-T}
-event-mask:	() empty
-event:	As specified by the protocol
-.sp 6p
-_
-.TE
-.nH 4 "Window Deletion"
-.LP
-Clients, usually those with multiple top-level windows, whose server
-connection must survive the deletion of some of their top-level windows,
-should include the atom WM_DELETE_WINDOW in the WM_PROTOCOLS property on
-each such window.  They will receive a
-.PN ClientMessage 
-event as described above whose data[0] field is WM_DELETE_WINDOW.
-.LP
-Clients receiving a WM_DELETE_WINDOW message should behave as if the user
-selected \*Qdelete window\*U from a hypothetical menu.
-They should perform any confirmation dialog with the user
-and, if they decide to complete the deletion, should do the following:
-.bP
-Either change the window's state to Withdrawn (as described in section 4.1.4)
-or destroy the window.
-.bP
-Destroy any internal state associated with the window.
-.LP
-If the user aborts the deletion during the confirmation dialog,
-the client should ignore the message.
-.LP
-Clients are permitted to interact with the user and ask, for example,
-whether a file associated with the window to be deleted should be saved
-or the window deletion should be cancelled.
-Clients are not required to destroy the window itself;
-the resource may be reused,
-but all associated state (for example, backing store) should be released.
-.LP
-If the client aborts a destroy and the user then selects DELETE WINDOW again,
-the window manager should start the WM_DELETE_WINDOW protocol again.
-Window managers should not use 
-.PN DestroyWindow
-requests on a window that has WM_DELETE_WINDOW in its WM_PROTOCOLS property.
-.LP
-Clients that choose not to include WM_DELETE_WINDOW in the WM_PROTOCOLS
-property may be disconnected from the server
-if the user asks for one of the client's top-level windows to be deleted.
-.nH 3 "Redirecting Requests"
-.LP
-Normal clients can use the redirection mechanism just as window managers do
-by selecting for 
-.PN SubstructureRedirect
-events on a parent window or 
-.PN ResizeRedirect
-events on a window itself.
-However, at most,
-one client per window can select for these events,
-and a convention is needed to avoid clashes.
-.NT Convention
-Clients (including window managers) should select for 
-.PN SubstructureRedirect
-and
-.PN ResizeRedirect
-events only on windows that they own.
-.NE
-.LP
-In particular, 
-clients that need to take some special action if they are resized can select
-for 
-.PN Resize\%Redirect
-events on their top-level windows.
-They will receive a
-.PN ResizeRequest
-event if the window manager resizes their window,
-and the resize will not actually take place.
-Clients are free to make what use they like of the information
-that the window manager wants to change their size,
-but they must configure the window to the width and height specified 
-in the event in a timely fashion.
-To ensure that the resize will actually happen at this stage
-instead of being intercepted and executed by the window manager
-(and thus restarting the process),
-the client needs temporarily to set override-redirect on the window.
-.NT Convention
-Clients receiving 
-.PN ResizeRequest
-events must respond by doing the following:
-.bP
-Setting override-redirect on the window specified in the event
-.bP
-Configuring the window specified in the event 
-to the width and height specified in the event as soon as possible 
-and before making any other geometry requests
-.bP
-Clearing override-redirect on the window specified in the event
-.NE
-.LP
-If a window manager detects that a client is not obeying this convention,
-it is free to take whatever measures it deems appropriate to deal with
-the client.
-.nH 2 "Communication with the Window Manager by Means of Selections"
-.LP
-For each screen they manage, window managers will acquire ownership of a
-selection named WM_S\fIn\fP, where \fIn\fP is the screen number, as
-described in section 1.2.6.  Window managers should comply with the
-conventions for \*QManager Selections\*U described in section 2.8.  The
-intent is for clients to be able to request a variety of information or
-services by issuing conversion requests on this selection.  Window managers
-should support conversion of the following target on their manager
-selection:
-.LP
-.br
-.ne 8
-.TS
-l l lw(3.5i) .
-_
-.sp 6p
-.B
-Atom	Type	Data Received
-.R
-.sp 6p
-_
-.sp 6p
-VERSION	INTEGER	T{
-Two integers, which are the major and minor
-release numbers (respectively) of the ICCCM
-with which the window manager complies.  For
-this version of the ICCCM, the numbers are
-2 and 0.\**
-T}
-.sp 6p
-_
-.TE
-.FS
-As a special case, clients not wishing to implement a selection
-request may simply issue a
-.PN GetSelectionOwner
-request on the appropriate WM_S\fIn\fP selection.  If this selection is owned,
-clients may assume that the window manager complies with ICCCM version 2.0
-or later.
-.FE
-.nH 2 "Summary of Window Manager Property Types"
-.LP
-The window manager properties are summarized in the following table
-(see also section 14.1 of \fIXlib \- C Language X Interface\fP).
-.br
-.ne 6
-.TS H
-l l n c.
-_
-.sp 6p
-.B
-Name	Type	Format	See Section
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-WM_CLASS	STRING	8	4.1.2.5
-WM_CLIENT_MACHINE	TEXT	\&	4.1.2.9
-WM_COLORMAP_WINDOWS	WINDOW	32	4.1.2.8
-WM_HINTS	WM_HINTS	32	4.1.2.4
-WM_ICON_NAME	TEXT		4.1.2.2
-WM_ICON_SIZE	WM_ICON_SIZE	32	4.1.3.2
-WM_NAME	TEXT		4.1.2.1
-WM_NORMAL_HINTS	WM_SIZE_HINTS	32	4.1.2.3
-WM_PROTOCOLS	ATOM	32	4.1.2.7
-WM_STATE	WM_STATE	32	4.1.3.1
-WM_TRANSIENT_FOR	WINDOW	32	4.1.2.6
-.sp 6p
-_
-.TE
-.nH 1 "Session Management and Additional Inter-Client Exchanges"
-.LP
-This section contains some conventions for clients that participate in
-session management.  See
-.I
-X Session Management Protocol
-.R
-for further details.  Clients that do not support this protocol cannot
-expect their window state (e.g., WM_STATE, position, size, and stacking order)
-to be preserved across sessions.
-.nH 2 "Client Support for Session Management"
-.LP
-Each session participant will obtain a unique client identifier (client-ID)
-from the session manager.  The client must identify one top-level window as
-the \*Qclient leader.\*U This window must be created by the client.  It may
-be in any state, including the Withdrawn state.  The client leader window
-must have a SM_CLIENT_ID property, which contains the client-ID obtained
-from the session management protocol.  That property must:
-.bP
-Be of type STRING
-.bP
-Be of format 8
-.bP
-Contain the client-ID as a string of XPCS characters encoded using ISO
-8859-1
-.LP
-All top-level, nontransient windows created by a client on the same display
-as the client leader must have a WM_CLIENT_LEADER property. This property
-contains a window ID that identifies the client leader window.  The client
-leader window must have a WM_CLIENT_LEADER property containing its own
-window ID (i.e., the client leader window is pointing to itself).  Transient
-windows need not have a WM_CLIENT_LEADER property if the client leader can
-be determined using the information in the WM_TRANSIENT_FOR property.  The
-WM_CLIENT_LEADER property must:
-.bP
-Be of type WINDOW
-.bP
-Be of format 32
-.bP
-Contain the window ID of the client leader window
-.LP
-A client must withdraw all of its top-level windows on the same display
-before modifiying either the WM_CLIENT_LEADER or the SM_CLIENT_ID property
-of its client leader window.
-.LP
-It is necessary that other clients be able to uniquely identify a window
-(across sessions) among all windows related to the same client-ID.  For
-example, a window manager can require this unique ID to restore geometry
-information from a previous session, or a workspace manager could use it to
-restore information about which windows are in which workspace.  A client
-may optionally provide a WM_WINDOW_ROLE property to uniquely identify a
-window within the scope specified above.  The combination of SM_CLIENT_ID
-and WM_WINDOW_ROLE can be used by other clients to uniquely identify a
-window across sessions.
-.LP
-If the WM_WINDOW_ROLE property is not specified on a top-level window, a
-client that needs to uniquely identify that window will try to use instead
-the values of WM_CLASS and WM_NAME.  If a client has multiple windows with
-identical WM_CLASS and WM_NAME properties, then it should provide a
-WM_WINDOW_ROLE property.
-.LP
-The client must set the WM_WINDOW_ROLE property to a string that uniquely
-identifies that window among all windows that have the same client leader
-window.  The property must:
-.bP
-Be of type STRING
-.bP
-Be of format 8
-.bP
-Contain a string restricted to the XPCS characters, encoded in ISO 8859-1
-.nH 2 "Window Manager Support for Session Management"
-.LP
-A window manager supporting session management must register with the
-session manager and obtain its own client-ID.  The window manager should
-save and restore information such as the WM_STATE, the layout of windows on
-the screen, and their stacking order for every client window that has a
-valid SM_CLIENT_ID property (on itself, or on the window named by
-WM_CLIENT_LEADER) and that can be uniquely identified.
-Clients are allowed to change this state during the first phase of the
-session checkpoint process.  Therefore, window managers should request a
-second checkpoint phase and save clients' state only during that phase.
-.nH 2 "Support for ICE Client Rendezvous"
-.IN "ICE Rendezvous"
-.LP
-The Inter-Client Exchange protocol (ICE) defined as of X11R6 
-specifies a generic communication framework, independent of the X
-server, for data exchange between arbitrary clients.  ICE also defines 
-a protocol for any two ICE clients who also have X connections 
-to the same X server to locate (rendezvous with) each other.  
-.LP
-This protocol, called the "ICE X Rendezvous" protocol, is defined in
-the ICE specification, Appendix B,
-and uses the property ICE_PROTOCOLS plus
-.PN ClientMessage
-events.  Refer to that specification for complete details.
-.nH 1 "Manipulation of Shared Resources"
-.LP
-X Version 11 permits clients to manipulate a number of shared resources,
-for example, the input focus, the pointer, and colormaps.
-Conventions are required so that clients share resources in an
-orderly fashion.
-.nH 2 "The Input Focus"
-.LP
-Clients that explicitly set the input focus must observe one of two modes:
-.bP
-Locally active mode
-.bP
-Globally active mode
-.NT Conventions
-.IP 1. 5
-Locally active clients should set the input focus to one of their windows 
-only when it is already in one of their windows
-or when they receive a WM_TAKE_FOCUS message.
-They should set the input field of the WM_HINTS structure to
-.PN True .
-.IP 2. 5
-Globally active clients should set the input focus to one of their windows 
-only when they receive a button event and a passive-grabbed key event,
-or when they receive a WM_TAKE_FOCUS message.
-They should set the input field of the WM_HINTS structure to
-.PN False .
-.IP 3. 5
-In addition, clients should use the timestamp of the event 
-that caused them to attempt to set the input focus as the time field on the 
-.PN SetInputFocus
-request, not
-.PN CurrentTime .
-.NE
-.nH 2 "The Pointer"
-.LP
-In general, clients should not warp the pointer.
-Window managers, however, may do so
-(for example, to maintain the invariant that the pointer is always
-in the window with the input focus).
-Other window managers may want to preserve the illusion that the user
-is in sole control of the pointer.
-.NT Conventions
-.IP 1. 5
-Clients should not warp the pointer.
-.IP 2. 5
-Clients that insist on warping the pointer should do so only
-with the src-window argument of the 
-.PN WarpPointer 
-request set to one of their windows.
-.NE
-.nH 2 "Grabs"
-.LP
-A client's attempt to establish a button or a key grab on a window
-will fail if some other client has already established a conflicting
-grab on the same window.
-The grabs, therefore, are shared resources,
-and their use requires conventions.
-.LP
-In conformance with the principle that clients should behave,
-as far as possible,
-when a window manager is running as they would when it is not,
-a client that has the input focus may assume that it can receive all 
-the available keys and buttons.
-.NT Convention
-Window managers should ensure that they provide some mechanism for
-their clients to receive events from all keys and all buttons,
-except for events involving keys whose KeySyms are registered as being for
-window management functions (for example, a hypothetical WINDOW KeySym).
-.NE
-.LP
-In other words,
-window managers must provide some mechanism by which a client
-can receive events from every key and button (regardless of modifiers)
-unless and until the X Consortium registers some KeySyms as being reserved 
-for window management functions.
-Currently, no KeySyms are registered for window management functions.
-.LP
-Even so, clients are advised to allow the key and button combinations
-used to elicit program actions to be modified,
-because some window managers may choose not to observe this convention
-or may not provide a convenient method for the user to transmit events
-from some keys.
-.NT Convention
-Clients should establish button and key grabs only on windows that
-they own.
-.NE
-.LP
-In particular, this convention means that a window manager that wishes 
-to establish a grab over the client's top-level window should either establish 
-the grab on the root or reparent the window and establish the grab 
-on a proper ancestor.
-In some cases,
-a window manager may want to consume the event received,
-placing the window in a state where a subsequent such event will go to
-the client.
-Examples are:
-.bP
-Clicking in a window to set focus with the click not being offered 
-to the client
-.bP
-Clicking in a buried window to raise it, again, with the click not offered 
-to the client
-.LP
-More typically,
-a window manager should add to, rather than replace, the client's semantics 
-for key+button combinations by allowing the event to be used by the client 
-after the window manager is done with it.
-To ensure this,
-the window manager should establish the grab on the parent 
-by using the following:
-.LP
-.Ds
-pointer/keyboard-mode == Synchronous
-.De
-.LP
-Then, the window manager should release the grab by using an
-.PN AllowEvents 
-request with the following specified:
-.LP
-.Ds
-mode == ReplayPointer/Keyboard
-.De
-.LP
-In this way,
-the client will receive the events as if they had not been intercepted.
-.LP
-Obviously,
-these conventions place some constraints on possible user interface policies.
-There is a trade-off here between freedom for window managers to implement
-their user interface policies and freedom for clients to implement theirs.
-The dilemma is resolved by:
-.bP
-Allowing window managers to decide if and when a client will receive an
-event from any given key or button
-.bP
-Placing a requirement on the window manager to provide some mechanism,
-perhaps a \*QQuote\*U key,
-by which the user can send an event from any key or button to the client
-.nH 2 "Colormaps"
-.LP
-Section 4.1.8 prescribes conventions for clients to communicate with the
-window manager about their colormap needs.  If your clients are
-.PN DirectColor
-type applications,
-you should consult section 14.3 of \fIXlib \- C Language X Interface\fP
-for conventions connected with sharing standard colormaps.
-They should look for and create the properties described there on
-the root window of the appropriate screen.
-.LP
-The contents of the RGB_COLOR_MAP type property are as follows:
-.br
-.ne 6
-.TS H
-l l l.
-_
-.sp 6p
-.B
-Field	Type	Comments
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-colormap	COLORMAP	ID of the colormap described
-red_max	CARD32	Values for pixel calculations
-red_mult	CARD32
-green_max	CARD32
-green_mult	CARD32
-blue_max	CARD32
-blue_mult	CARD32
-base_pixel	CARD32
-visual_id	VISUALID	Visual to which colormap belongs
-kill_id	CARD32	ID for destroying the resources
-.sp 6p
-_
-.TE
-.LP
-When deleting or replacing an RGB_COLOR_MAP,
-it is not sufficient to delete the property;
-it is important to free the associated colormap resources as well.
-If kill_id is greater than one,
-the resources should be freed by issuing a 
-.PN KillClient
-request with kill_id as the argument.
-If kill_id is one,
-the resources should be freed by issuing a
-.PN FreeColormap
-request with colormap as the colormap
-argument.
-If kill_id is zero,
-no attempt should be made to free the resources.
-A client that creates an RGB_COLOR_MAP for which the colormap resource 
-is created specifically for this purpose should set kill_id to one 
-(and can create more than one such standard colormap 
-using a single connection).
-A client that creates an RGB_COLOR_MAP for which the colormap resource 
-is shared in some way (for example, is the default colormap 
-for the root window) should create an arbitrary resource and use its 
-resource ID for kill_id (and should create no other standard colormaps 
-on the connection).
-.NT Convention
-If an RGB_COLOR_MAP property is too short to contain the visual_id field,
-it can be assumed that the visual_id is the root visual 
-of the appropriate screen.
-If an RGB_COLOR_MAP property is too short to contain the kill_id field,
-a value of zero can be assumed.
-.NE
-.LP
-During the connection handshake,
-the server informs the client of the default colormap for each screen.
-This is a colormap for the root visual,
-and clients can use it to improve the extent of colormap sharing
-if they use the root visual.
-.nH 2 "The Keyboard Mapping"
-.LP
-The X server contains a table (which is read by 
-.PN GetKeyboardMapping
-requests) that describes the set of symbols appearing 
-on the corresponding key for each keycode generated by the server.
-This table does not affect the server's operations in any way;
-it is simply a database used by clients that attempt to understand 
-the keycodes they receive.
-Nevertheless, it is a shared resource and requires conventions.
-.LP
-It is possible for clients to modify this table by using a
-.PN ChangeKeyboardMapping
-request.
-In general, clients should not do this.
-In particular, this is not the way in which clients should implement 
-key bindings or key remapping.
-The conversion between a sequence of keycodes received from the server
-and a string in a particular encoding is a private matter for each client
-(as it must be in a world where applications may be using different
-encodings to support different languages and fonts).
-See the Xlib reference manual for converting keyboard events to text.
-.LP
-The only valid reason for using a
-.PN ChangeKeyboardMapping
-request is when the symbols written on the keys have changed as, for example,
-when a Dvorak key conversion kit or a set of APL keycaps has been installed.
-Of course, a client may have to take the change to the keycap on trust.
-.LP
-The following illustrates a permissible interaction between a client 
-and a user:
-.IP Client: 10
-\*QYou just started me on a server without a Pause key.
-Please choose a key to be the Pause key and press it now.\*U
-.IP User: 10
-Presses the Scroll Lock key
-.IP Client: 10
-\*QAdding Pause to the symbols on the Scroll Lock key: Confirm or Abort.\*U
-.IP User: 10
-Confirms
-.IP Client: 10
-Uses a
-.PN ChangeKeyboardMapping
-request to add Pause to the keycode that already contains Scroll Lock and
-issues this request, \*QPlease paint Pause on the Scroll Lock key.\*U
-.NT Convention
-Clients should not use 
-.PN ChangeKeyboardMapping
-requests.
-.NE
-.LP
-If a client succeeds in changing the keyboard mapping table,
-all clients will receive 
-.PN MappingNotify (request==Keyboard)
-events.
-There is no mechanism to avoid receiving these events.
-.NT Convention
-Clients receiving 
-.PN MappingNotify (request==Keyboard)
-events should update any internal keycode translation tables they are using.
-.NE
-.nH 2 "The Modifier Mapping"
-.LP
-X Version 11 supports 8 modifier bits of which 3 are preassigned 
-to Shift, Lock, and Control.
-Each modifier bit is controlled by the state of a set of keys,
-and these sets are specified in a table accessed by
-.PN GetModifierMapping
-and
-.PN SetModifierMapping
-requests.
-This table is a shared resource and requires conventions.
-.LP
-A client that needs to use one of the preassigned modifiers should assume 
-that the modifier table has been set up correctly to control these modifiers.
-The Lock modifier should be interpreted as Caps Lock or Shift Lock
-according as the keycodes in its controlling set include XK_Caps_Lock
-or XK_Shift_Lock.
-.NT Convention
-Clients should determine the meaning of a modifier bit from the KeySyms
-being used to control it.
-.NE
-.LP
-A client that needs to use an extra modifier (for example, META) should do
-the following:
-.bP
-Scan the existing modifier mappings.
-If it finds a modifier that contains a keycode whose set of KeySyms
-includes XK_Meta_L or XK_Meta_R,
-it should use that modifier bit.
-.bP
-If there is no existing modifier controlled by  XK_Meta_L or XK_Meta_R,
-it should select an unused modifier bit (one with an empty controlling set)
-and do the following:
-.RS
-.IP \- 5
-If there is a keycode with XL_Meta_L in its set of KeySyms,
-add that keycode to the set for the chosen modifier.
-.IP \- 5
-If there is a keycode with XL_Meta_R in its set of KeySyms,
-add that keycode to the set for the chosen modifier.
-.IP \- 5
-If the controlling set is still empty,
-interact with the user to select one or more keys to be META.
-.RE
-.bP
-If there are no unused modifier bits,
-ask the user to take corrective action.
-.NT Conventions
-.IP 1. 5
-Clients needing a modifier not currently in use should assign keycodes
-carrying suitable KeySyms to an unused modifier bit.
-.IP 2. 5
-Clients assigning their own modifier bits should ask the user politely to
-remove his or her hands from the key in question if their 
-.PN SetModifierMapping
-request returns a 
-.PN Busy
-status.
-.NE
-.LP
-There is no good solution to the problem of reclaiming assignments
-to the five nonpreassigned modifiers when they are no longer being used.
-.NT Convention
-The user must use
-.PN xmodmap
-or some other utility to deassign obsolete modifier mappings by hand.
-.NE
-.LP
-When a client succeeds in performing a 
-.PN SetModifierMapping
-request,
-all clients will receive 
-.PN MappingNotify (request==Modifier)
-events.
-There is no mechanism for preventing these events from being received.
-A client that uses one of the nonpreassigned modifiers that receives
-one of these events should do a 
-.PN GetModifierMapping
-request to discover the new mapping,
-and if the modifier it is using has been cleared,
-it should reinstall the modifier.
-.LP
-Note that a
-.PN GrabServer
-request must be used to make the 
-.PN GetModifierMapping 
-and
-.PN SetModifierMapping
-pair in these transactions atomic.
-.nH 1 "Device Color Characterization"
-.LP
-.EQ
-delim @@
-define oc % "\\fR{\\fP" %
-define cc % "\\fR}\\fP" %
-.EN
-The X protocol provides explicit Red, Green, and Blue (RGB) values,
-which are used to directly drive a monitor, and color names.  RGB values
-provide a mechanism for accessing the full capabilities of the display
-device, but at the expense of having the color perceived by the user remain
-unknowable through the protocol.  Color names were originally designed to
-provide access to a device-independent color database by having the server
-vendor tune the definitions of the colors in that textual database.
-Unfortunately, this still does not provide the client any way of using
-an existing device-independent color, nor for the client to get
-device-independent color information back about colors that it has selected.
-.LP
-Furthermore, the client must be able to discover which set of colors are
-displayable by the device (the device gamut), both to allow colors to be
-intelligently modified to fit within the device capabilities (gamut
-compression) and to enable the user interface to display a representation of
-the reachable color space to the user (gamut display).
-.LP
-Therefore, a system is needed that will provide full access to
-device-independent color spaces for X clients.  This system should use a
-standard mechanism for naming the colors, be able to provide names for
-existing colors, and provide means by which unreachable colors can be
-modified to fall within the device gamut.
-.LP
-We are fortunate in this area to have a seminal work, the 1931 CIE color
-standard, which is nearly universally agreed upon as adequate for describing
-colors on CRT devices.  This standard uses a tri-stimulus model called CIE
-XYZ in which each perceivable color is specified as a triplet of numbers.
-Other appropriate device-independent color models do exist, but most of them
-are directly traceable back to this original work.
-.LP
-X device color characterization
-provides device-independent color spaces to X clients.  It does this by
-providing the barest possible amount of information to the client that
-allows the client to construct a mapping between CIE XYZ and the regular X
-RGB color descriptions.
-.LP
-Device color characterization is defined by
-the name and contents of two window properties that,
-together, permit converting between CIE XYZ space and
-linear RGB device space (such as standard CRTs).
-Linear RGB devices require just two
-pieces of information to completely characterize them:
-.IP \(bu 5
-A @3 times 3@ matrix @M@ and its inverse @M sup -1@, which convert between
-XYZ and RGB intensity (@RGB sub intensity@):
-.EQ C
-RGB sub intensity ~ = ~ M ~ times ~ XYZ
-.EN
-.EQ C
-XYZ ~ = ~ M sup -1 ~ times ~ RGB sub intensity
-.EN
-.IP \(bu 5
-A way of mapping between RGB intensity and RGB protocol value.  XDCCC
-supports three mechanisms which will be outlined later.
-.LP
-If other device types are eventually necessary, additional
-properties will be required to describe them.
-.nH 2 "XYZ \*(dA RGB Conversion Matrices"
-.LP
-Because of the limited dynamic range of both XYZ and RGB intensity,
-these matrices will be encoded using a fixed-point representation of a
-32-bit two's complement number scaled by @2 sup 27@, giving a range of @-16@ to
-@16 - epsilon@, where @epsilon ~ = ~ 2 sup -27@.
-.LP
-These matrices will be packed into an 18-element list of 32-bit values,
-XYZ \(-> RGB matrix first, in row major order and stored in the
-XDCCC_LINEAR_RGB_MATRICES properties (format = 32) on the root window of
-each screen, using values appropriate for that screen.
-.LP
-This will be encoded as shown in the following table:
-.br
-.ne 6
-.TS
-center;
-c s s
-c c c
-l l l.
-XDCCC_LINEAR_RGB_MATRICES property contents
-.sp 6p
-_
-.sp 6p
-.B
-Field	Type	Comments
-.R
-.sp 6p
-_
-.sp 6p
-@M sub 0,0@	INT32	Interpreted as a fixed-point number @-16~<=~x~<~16@
-@M sub 0,1@	INT32	
-\&.\^.\^.
-@M sub 3,3@	INT32	
-@{M sup -1} sub 0,0@	INT32	
-@{M sup -1} sub 0,1@	INT32	
-\&.\^.\^.
-@{M sup -1} sub 3,3@	INT32	
-.sp 6p
-_
-.TE
-.nH 2 "Intensity \*(dA RGB Value Conversion"
-.LP
-XDCCC provides two representations for describing the conversion
-between RGB intensity and the actual X protocol RGB values:
-.DS
-.TA .5i
-.ta .5i
-0	RGB value/RGB intensity level pairs
-1	RGB intensity ramp
-.DE
-.LP
-In both cases, the relevant data will be stored in the
-XDCCC_LINEAR_RGB_CORRECTION properties on the root window of each screen,
-using values appropriate for that screen, in whatever format provides
-adequate resolution.  Each property can consist of multiple entries
-concatenated together, if different visuals for the screen require different
-conversion data.  An entry with a VisualID of 0 specifies data for all
-visuals of the screen that are not otherwise explicitly listed.
-.LP
-The first representation is an array of RGB value/intensity level pairs, with
-the RGB values in strictly increasing order.  When converting, the client must
-linearly interpolate between adjacent entries in the table to compute the
-desired value.  This allows the server to perform gamma correction
-itself and encode that fact in a short two-element correction table.  The
-intensity will be encoded as an unsigned number to be interpreted as a value
-between 0 and 1 (inclusive).  The precision of this value will depend on the
-format of the property in which it is stored (8, 16, or 32 bits).  For 16-bit
-and 32-bit formats, the RGB value will simply be the value stored in the
-property.  When stored in 8-bit format, the RGB value can be computed from
-the value in the property by:
-.EQ C
-RGB sub value ~ = ~ { Property ~ Value ~ times ~ 65535 } over 255
-.EN
-.LP
-Because the three electron guns in the device may not be exactly alike in
-response characteristics, it is necessary to allow for three separate
-tables, one each for red, green, and blue.  Therefore, each table will be
-preceded by the number of entries in that table, and the set of tables will be
-preceded by the number of tables.
-When three tables are provided, they will be in red, green, blue order.
-.LP
-This will be encoded as shown in the following table:
-.br
-.ne 6
-.TS
-center;
-c s s
-c c c
-l l l.
-XDCCC_LINEAR_RGB_CORRECTION Property Contents for Type 0 Correction
-.sp 6p
-_
-.sp 6p
-.B
-Field	Type	Comments
-.R
-.sp 6p
-_
-.sp 6p
-VisualID0	CARD	Most significant portion of VisualID
-VisualID1	CARD	Exists if and only if the property format is 8
-VisualID2	CARD	Exists if and only if the property format is 8
-VisualID3	CARD	T{
-Least significant portion, exists if and only if the property format
-is 8 or 16
-T}
-type	CARD	0 for this type of correction
-count	CARD	Number of tables following (either 1 or 3)
-length	CARD	Number of pairs \- 1 following in this table
-value	CARD	X Protocol RGB value
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlength+1\fP pairs of value/intensity values
-lengthg	CARD	T{
-Number of pairs \- 1 following in this table (if and
-only if \fIcount\fP is 3)
-T}
-value	CARD	X Protocol RGB value
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlengthg+1\fP pairs of value/intensity values
-lengthb	CARD	T{
-Number of pairs \- 1 following in this table (if and
-only if \fIcount\fP is 3)
-T}
-value	CARD	X Protocol RGB value
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlengthb+1\fP pairs of value/intensity values
-.sp 6p
-_
-.TE
-.LP
-The VisualID is stored in 4, 2, or 1 pieces, depending on whether
-the property format is 8, 16, or 32, respectively.  The VisualID is always
-stored most significant piece first.
-Note that the length fields are stored as one less than the actual length,
-so 256 entries can be stored in format 8.
-.LP
-The second representation is a simple array of intensities for a linear subset
-of RGB values.  The expected size of this table is the bits-per-rgb-value of
-the screen, but it can be any length.  This is similar to the first mechanism,
-except that the RGB value numbers are implicitly defined by the index in the
-array (indices start at 0):
-.EQ C
-RGB sub value ~ = ~ { Array ~ Index ~ times ~ 65535 } over
-{ Array ~ Size ~ - ~ 1 }
-.EN
-When converting, the client may linearly interpolate between entries in this
-table.  The intensity values will be encoded just as in the first
-representation.
-.LP
-This will be encoded as shown in the following table:
-.br
-.ne 6
-.TS
-center;
-c s s
-c c c
-l l l.
-XDCCC_LINEAR_RGB_CORRECTION Property Contents for Type 1 Correction
-.sp 6p
-_
-.sp 6p
-.B
-Field	Type	Comments
-.R
-.sp 6p
-_
-.sp 6p
-VisualID0	CARD	Most significant portion of VisualID
-VisualID1	CARD	Exists if and only if the property format is 8
-VisualID2	CARD	Exists if and only if the property format is 8
-VisualID3	CARD	T{
-Least significant portion, exists if and only if
-the property format is 8 or 16
-T}
-type	CARD	1 for this type of correction
-count	CARD	Number of tables following (either 1 or 3)
-length	CARD	Number of elements \- 1 following in this table
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlength+1\fP intensity elements
-lengthg	CARD	T{
-Number of elements \- 1 following in this table (if and
-only if \fIcount\fP is 3)
-T}
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlengthg+1\fP intensity elements
-lengthb	CARD	T{
-Number of elements \- 1 following in this table (if and
-only if \fIcount\fP is 3)
-T}
-intensity	CARD	Interpret as a number @0~<=~intensity~<=~1@
-\&.\^.\^.	.\^.\^.	Total of \fIlengthb+1\fP intensity elements
-.sp 6p
-_
-.TE
-.nH 1 "Conclusion"
-.LP
-This document provides the protocol-level specification of the minimal
-conventions needed to ensure that X Version 11 clients can interoperate
-properly.  This document specifies interoperability conventions only for the
-X Version 11 protocol.  Clients should be aware of other protocols that
-should be used for better interoperation in the X environment.  The reader
-is referred to
-.I
-X Session Management Protocol
-.R
-for information on session management, and to
-.I
-Inter-Client Exchange Protocol
-.R
-for information on general-purpose communication among clients.
-.nH 2 "The X Registry"
-.IN "Registry"
-.IN "X Registry"
-.LP
-The X Consortium maintains a registry of certain X-related items, to aid in
-avoiding conflicts and in sharing of such items.  Readers are
-encouraged to use the registry.  The classes of items kept in the registry
-that are relevant to the ICCCM include property names, property types,
-selection names, selection targets, WM_PROTOCOLS protocols,
-.PN Client\%Message
-types, and application classes.  Requests to register items, or questions
-about registration, should be addressed to
-.EQ
-delim off
-.EN
-.DS
-	xregistry@x.org
-.DE
-or to
-.DS
-        The X.Org Group -- X11 Registry
-        c/o Ienup Sung
-        Sun Microsystems, Inc.
-        4150 Network Circle, MS SJC07-201
-        Santa Clara, CA 95054
-	USA
-.DE
-Electronic mail will be acknowledged upon receipt.  Please allow up to 4
-weeks for a formal response to registration and inquiries.
-.LP
-The registry is published as part of the X software distribution from the X
-Consortium.  All registered items must have the postal address of someone
-responsible for the item or a reference to a document describing the item
-and the postal address of where to write to obtain the document.
-.bp
-.\" Set registers to number the appendixes A.1, B.1, C.1, ...
-.nr H1 0
-.af H1 A
-.cT "Appendix A" no
-.nH 1 "Revision History"
-.LP
-This appendix describes the revision history of this document and
-summarizes the incompatibilities between this and earlier versions.
-.nH 2 "The X11R2 Draft"
-.LP
-The February 25, 1988, draft that was distributed as part of X Version 11,
-Release 2, was clearly labeled as such,
-and many areas were explicitly labeled as liable to change.
-Nevertheless, in the revision work done since then,
-we have been very careful not to introduce gratuitous incompatibility.
-As far as possible,
-we have tried to ensure that clients obeying the conventions
-in the X11R2 draft would still work.
-.nH 2 "The July 27, 1988, Draft"
-.LP
-The Consortium review was based on a draft dated July 27, 1988.  This draft
-included several areas in which incompatibilities with the X11R2 draft were
-necessary:
-.bP
-The use of property 
-.PN None
-in 
-.PN ConvertSelection
-requests is no longer allowed.
-Owners that receive them are free to use the target atom as the property 
-to respond with,
-which will work in most cases.
-.bP
-The protocol for INCREMENTAL type properties as selection replies has changed,
-and the name has been changed to INCR.
-Selection requestors are free to implement the earlier protocol 
-if they receive properties of type INCREMENTAL.
-.bP
-The protocol for INDIRECT type properties as selection replies has changed,
-and the name has been changed to MULTIPLE.
-Selection requestors are free to implement the earlier protocol 
-if they receive properties of type INDIRECT.
-.bP
-The protocol for the special CLIPBOARD client has changed.
-The earlier protocol is subject to race conditions and should not be used.
-.bP
-The set of state values in WM_HINTS.initial_state has been reduced,
-but the values that are still valid are unchanged.
-Window managers should treat the other values sensibly.
-.bP
-The methods an application uses to change the state of its top-level window
-have changed but in such a way that cases that used to work will still work.
-.bP
-The x, y, width, and height fields have been removed from the WM_NORMAL_HINTS
-property and replaced by pad fields.
-Values set into these fields will be ignored.
-The position and size of the window should be set by setting the appropriate
-window attributes.
-.bP
-A pair of base fields and a win_gravity field have been added 
-to the WM_NORMAL_HINTS property.
-Window managers will assume values for these fields if the client
-sets a short property.
-.nH 2 "The Public Review Drafts"
-.LP
-The Consortium review resulted in several incompatible changes.  These
-changes were included in drafts that were distributed for public review
-during the first half of 1989.
-.bP
-The messages field of the WM_HINTS property was found to be unwieldy
-and difficult to evolve.
-It has been replaced by the WM_PROTOCOLS property,
-but clients that use the earlier mechanism can be detected 
-because they set the messages bit in the flags field of the WM_HINTS property,
-and window managers can provide a backwards compatibility mode.
-.bP
-The mechanism described in the earlier draft by which clients installed
-their own subwindow colormaps could not be made to work reliably
-and mandated some features of the look and feel.
-It has been replaced by the WM_COLORMAP_WINDOWS property.
-Clients that use the earlier mechanism can be detected by the WM_COLORMAPS
-property they set on their top-level window,
-but providing a reliable backwards compatibility mode is not possible.
-.bP
-The recommendations for window manager treatment of top-level window borders
-have been changed as those in the earlier draft produced problems
-with Visibility events.
-For nonwindow manager clients,
-there is no incompatibility.
-.bP
-The pseudoroot facility in the earlier draft has been removed.
-Although it has been successfully implemented,
-it turns out to be inadequate to support the uses envisaged.
-An extension will be required to support these uses fully,
-and it was felt that the maximum freedom should be left to the designers
-of the extension.
-In general,
-the previous mechanism was invisible to clients and no incompatibility
-should result.
-.bP
-The addition of the WM_DELETE_WINDOW protocol (which prevents the danger
-that multi-window clients may be terminated unexpectedly)
-has meant some changes in the WM_SAVE_YOURSELF protocol,
-to ensure that the two protocols are orthogonal.
-Clients using the earlier protocol can be detected (see WM_PROTOCOLS above)
-and supported in a backwards compatibility mode.
-.bP
-The conventions in Section 14.3.1. of \fIXlib \- C Language X Interface\fP
-regarding properties of type RGB_COLOR_MAP have been changed,  
-but clients that use the earlier conventions can be detected 
-because their properties are 4 bytes shorter.
-These clients will work correctly if the server supports only a single Visual
-or if they use only the Visual of the root.
-These are the only cases in which they would have worked, anyway.
-.nH 2 "Version 1.0, July 1989"
-.LP
-The public review resulted in a set of mostly editorial changes.  The
-changes in version 1.0 that introduced some degree of incompatibility with
-the earlier drafts are:
-.bP
-A new section (6.3) was added covering the window manager's
-use of Grabs.
-The restrictions it imposes should affect only window managers.
-.bP
-The TARGETS selection target has been clarified,
-and it may be necessary for clients to add some entries to their replies.
-.bP
-A selection owner using INCR transfer should no longer replace targets in
-a MULTIPLE property with the atom INCR.
-.bP
-The contents of the 
-.PN ClientMessage
-event sent by a client to iconify itself has been clarified,
-but there should be no incompatibility because the earlier contents
-would not in fact have worked.
-.bP
-The border-width in synthetic 
-.PN ConfigureNotify
-events is now specified,
-but this should not cause any incompatibility.
-.bP
-Clients are now asked to set a border-width on all 
-.PN ConfigureWindow
-requests.
-.bP
-Window manager properties on icon windows now will be ignored,
-but there should be no incompatibility 
-because there was no specification that they be obeyed previously.
-.bP
-The ordering of real and synthetic 
-.PN ConfigureNotify
-events is now specified,
-but any incompatibility should affect only window managers.
-.bP
-The semantics of WM_SAVE_YOURSELF have been clarified and restricted to
-be a checkpoint operation only.
-Clients that were using it as part of a shutdown sequence may need to
-be modified,
-especially if they were interacting with the user during the shutdown.
-.bP
-A kill_id field has been added to RGB_COLOR_MAP properties.
-Clients using earlier conventions can be detected by the size of their
-RGB_COLOR_MAP properties,
-and the cases that would have worked will still work.
-.nH 2 "Version 1.1"
-.LP
-Version 1.1 was released with X11R5 in September 1991.  In addition to some
-minor editorial changes, there were a few semantic changes since Version
-1.0:
-.bP
-The section on Device Color Characterization was added.
-.bP
-The meaning of the NULL property type was clarified.
-.bP
-Appropriate references to Compound Text were added.
-.nH 2 "Public Review Draft, December 1993"
-.LP
-The following changes have been made in preparing the public review draft
-for Version 2.0.
-.bP
-[P01] Addition of advice to clients on how to keep track of a top-level
-window's absolute position on the screen.
-.bP
-[P03] A technique for clients to detect when it is safe to reuse a
-top-level window has been added.
-.bP
-[P06] Section 4.1.8, on colormaps, has been rewritten.  A new feature that
-allows clients to install their own colormaps has also been added.
-.bP
-[P08] The LENGTH target has been deprecated.
-.bP
-[P11] The manager selections facility was added.
-.bP
-[P17] The definition of the aspect ratio fields of the WM_NORMAL_HINTS
-property has been changed to include the base size.
-.bP
-[P19]
-.PN StaticGravity
-has been added to the list of values allowed for the win_gravity field of
-the WM_HINTS property.  The meaning of the
-.PN CenterGravity
-value has been clarified.
-.bP
-[P20] A means for clients to query the ICCCM compliance level of the window
-manager has been added.
-.bP
-[P22] The definition of the MULTIPLE selection target has been clarified.
-.bP
-[P25] A definition of \*Qtop-level window\*U has been added.  The WM_STATE
-property has been defined and exposed to clients.
-.bP
-[P26] The definition of window states has been clarified and the wording
-regarding window state changes has been made more consistent.
-.bP
-[P27] Clarified the rules governing when window managers are required to send
-synthetic
-.PN \%ConfigureNotify
-events.
-.bP
-[P28] Added a recommended technique for setting the input focus to a window
-as soon as it is mapped.
-.bP
-[P29] The required lifetime of resource IDs named in window manager
-properties has been specified.
-.bP
-[P30] Advice for dealing with keystrokes and override-redirect windows has
-been added.
-.bP
-[P31] A statement on the ownership of resources transferred through the
-selection mechanism has been added.
-.bP
-[P32] The definition of the CLIENT_WINDOW target has been clarified.
-.bP
-[P33] A rule about requiring the selection owner to reacquire the
-selection under certain circumstances has been added.
-.bP
-[P42] Added several new selection targets.
-.bP
-[P44] Ambiguous wording regarding the withdrawal of top-level windows
-has been removed.
-.bP
-[P45] A facility for requestors to pass parameters during a selection
-request has been added.
-.bP
-[P49] A convention on discrimated names has been added.
-.bP
-[P57] The C_STRING property type was added.
-.bP
-[P62] An ordering requirement on processing selection requests was added.
-.bP
-[P63] The
-.PN VisibleHint
-flag was added.
-.bP
-[P64] The session management section has been updated to align with the new
-session management protocol.  The old session management conventions have
-been moved to Appendix C.
-.bP
-References to the never-forthcoming \fIWindow and Session Manager
-Conventions Manual\fP have been removed.
-.bP
-Information on the X Registry and references to the session management and
-ICE documents have been added.
-.bP
-Numerous editorial and typographical improvements have been made.
-.nH 2 "Version 2.0, April 1994"
-.LP
-The following changes have been made in preparation for releasing
-the final edition of Version 2.0 with X11R6.
-.bP
-The PIXMAP selection target has been revised to return a property of type
-PIXMAP instead of type DRAWABLE.
-.bP
-The session management section has been revised slightly to correspond with
-the changes to the \fIX Session Management Protocol\fP.
-.bP
-Window managers are now prohibited from placing
-.PN CurrentTime
-in the timestamp field of WM_TAKE_FOCUS messages.
-.bP
-In the WM_HINTS property, the
-.PN VisibleHint
-flag has been renamed to
-.PN UrgencyHint .
-Its semantics have also been defined more thoroughly.
-.bP
-Additional editorial and typographical changes have been made.
-.bp
-.cT "Appendix B" no
-.nH 1 "Suggested Protocol Revisions"
-.LP
-During the development of these conventions,
-a number of inadequacies have been discovered in the
-core X11 protocol.
-They are summarized here as input to an eventual protocol revision
-design process:
-.bP
-There is no way for anyone to find out the last-change time of
-a selection.
-The
-.PN Get\%Selection\%Owner
-request should be changed to return the last-change time as well as the owner.
-.bP
-There is no way for a client to find out which selection atoms are valid.
-.bP
-There would be no need for WM_TAKE_FOCUS if the 
-.PN FocusIn
-event contained a timestamp and a previous-focus field.
-This could avoid the potential race condition.
-There is space in the event for this information;
-it should be added at the next protocol revision.
-.bP
-There is a race condition in the
-.PN Install\%Colormap 
-request.
-It does not take a timestamp and may be executed after the top-level colormap
-has been uninstalled.
-The next protocol revision should provide the timestamp in the
-.PN Install\%Colormap ,
-.PN Uninstall\%Colormap ,
-.PN List\%Installed\%Colormaps 
-requests and in the 
-.PN Colormap\%Notify
-event.
-The timestamp should be used in a similar way to the last-focus-change
-time for the input focus.  The lack of timestamps in these packets is the
-reason for restricting colormap installation to the window manager.
-.bP
-The protocol needs to be changed to provide some way of identifying
-the Visual and the Screen of a colormap.
-.bP
-There should be some way to reclaim assignments to the five nonpreassigned
-modifiers when they are no longer needed.  The manual method is unpleasantly
-low-tech.
-.bp
-.cT "Appendix C" no
-.nH 1 "Obsolete Session Manager Conventions"
-.LP
-This appendix contains obsolete conventions for session management using X
-properties and messages.  The conventions described here are deprecated and
-are described only for historical interest.  For further information on
-session management, see
-.I
-X Session Management Protocol.
-.R
-.nH 2 "Properties"
-.LP
-The client communicates with the session manager by placing two properties
-(WM_COMMAND and WM_CLIENT_MACHINE) on its top-level window.
-If the client has a group of top-level windows,
-these properties should be placed on the group leader window.
-.LP
-The window manager is responsible for placing a WM_STATE property
-on each top-level client window for use by session managers and other clients
-that need to be able to identify top-level client windows and their state.
-.nH 3 "WM_COMMAND Property"
-.LP
-The WM_COMMAND property represents the command used to start or restart the
-client.  By updating this property, clients should ensure that it always
-reflects a command that will restart them in their current state.  The
-content and type of the property depend on the operating system of the
-machine running the client.  On POSIX-conformant systems using ISO Latin-1
-characters for their command lines, the property should:
-.bP
-Be of type STRING
-.bP
-Contain a list of null-terminated strings
-.bP
-Be initialized from argv
-.IP
-Other systems will need to set appropriate conventions for the type 
-and contents of WM_COMMAND properties.
-Window and session managers should not assume that STRING is 
-the type of WM_COMMAND or that they will be able to understand 
-or display its contents.
-.LP
-Note that WM_COMMAND strings are null-terminated
-and differ from the general conventions that STRING properties
-are null-separated.
-This inconsistency is necessary for backwards compatibility.
-.LP
-A client with multiple top-level windows should ensure 
-that exactly one of them has a WM_COMMAND with nonzero length.
-Zero-length WM_COMMAND properties can be used to reply to WM_SAVE_YOURSELF
-messages on other top-level windows but will otherwise be ignored.
-.nH 3 "WM_CLIENT_MACHINE Property"
-.LP
-This property is described in section 4.1.2.9.
-.nH 2 "Termination"
-.LP
-Because they communicate by means of unreliable network connections, clients
-must be prepared for their connection to the server to be terminated at any
-time without warning.  They cannot depend on getting notification that
-termination is imminent or on being able to use the server to negotiate with
-the user about their fate.  For example, clients cannot depend on being able
-to put up a dialog box.
-.LP
-Similarly, clients may terminate at any time without notice to the session
-manager.  When a client terminates itself rather than being terminated by
-the session manager, it is viewed as having resigned from the session in
-question, and it will not be revived if the session is revived.
-.nH 2 "Client Responses to Session Manager Actions"
-.LP
-Clients may need to respond to session manager actions in two ways:
-.bP
-Saving their internal state
-.bP
-Deleting a window
-.nH 3 "Saving Client State"
-.LP
-Clients that want to be warned when the session manager feels 
-that they should save their internal state (for example,
-when termination impends) should include the atom WM_SAVE_YOURSELF 
-in the WM_PROTOCOLS property on their top-level windows to participate 
-in the WM_SAVE_YOURSELF protocol.
-They will receive a 
-.PN ClientMessage
-event as described in section 4.2.8 
-with the atom WM_SAVE_YOURSELF in its data[0] field.
-.LP
-Clients that receive WM_SAVE_YOURSELF should place themselves in a state from
-which they can be restarted and should update WM_COMMAND to
-be a command that will restart them in this state.
-The session manager will be waiting for a 
-.PN PropertyNotify
-event on WM_COMMAND as a confirmation that the client has saved its state.
-Therefore, WM_COMMAND should be updated (perhaps with a zero-length append)
-even if its contents are correct.
-No interactions with the user are permitted during this process.
-.LP
-Once it has received this confirmation,
-the session manager will feel free to terminate the client if that is what 
-the user asked for.
-Otherwise,
-if the user asked for the session to be put to sleep,
-the session manager will ensure that the client does not
-receive any mouse or keyboard events.
-.LP
-After receiving a WM_SAVE_YOURSELF, saving its state, and updating WM_COMMAND,
-the client should not change its state (in the sense of doing anything 
-that would require a change to WM_COMMAND) until it receives a mouse 
-or keyboard event.
-Once it does so,
-it can assume that the danger is over.
-The session manager will ensure that these events do not reach
-clients until the danger is over or until the clients have been killed.
-.LP
-Irrespective of how they are arranged in window groups,
-clients with multiple top-level windows should ensure the following:
-.bP
-Only one of their top-level windows has a nonzero-length WM_COMMAND
-property.
-.bP
-They respond to a WM_SAVE_YOURSELF message by:
-.RS
-.IP \- 5
-First, updating the nonzero-length WM_COMMAND property, if necessary
-.IP \- 5
-Second, updating the WM_COMMAND property on the window for which they received
-the WM_SAVE_YOURSELF message if it was not updated in the first step
-.RE
-.LP
-Receiving WM_SAVE_YOURSELF on a window is, conceptually, a command 
-to save the entire client state.\**
-.FS
-This convention has changed since earlier drafts because of the 
-introduction of the protocol in the next section.
-In the public review draft,
-there was ambiguity as to whether WM_SAVE_YOURSELF was a checkpoint 
-or a shutdown facility.
-It is now unambiguously a checkpoint facility;
-if a shutdown facility is judged to be necessary,
-a separate WM_PROTOCOLS protocol will be developed and registered 
-with the X Consortium.
-.FE
-.nH 3 "Window Deletion"
-.LP
-Windows are deleted using the WM_DELETE_WINDOW protocol, which
-is described in section 4.2.8.1.
-.nH 2 "Summary of Session Manager Property Types"
-.LP
-The session manager properties are listed in the following table:
-.br
-.ne 6
-.TS H
-l l n c.
-_
-.sp 6p
-.B
-Name	Type	Format	See Section
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-WM_CLIENT_MACHINE	TEXT		4.1.2.9
-WM_COMMAND	TEXT		C.1.1
-WM_STATE	WM_STATE	32	4.1.3.1
-.sp 6p
-_
-.TE
-.\" Finish up!
-.YZ 3
diff --git a/specs/ICCCM/icccm.xml b/specs/ICCCM/icccm.xml
new file mode 100644
index 0000000..0ed12ad
--- /dev/null
+++ b/specs/ICCCM/icccm.xml
@@ -0,0 +1,9092 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<book id="icccm">
+
+<bookinfo>
+   <title>Inter-Client Communication Conventions Manual</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>Version 2.0</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>David</firstname><surname>Rosenthal</surname>
+         <affiliation><orgname>Sun Microsystems, Inc.</orgname></affiliation>
+      </author>
+      <othercredit>
+         <contrib>Version 2 edited by</contrib>
+         <firstname>Stuart</firstname><othername>W.</othername><surname>Marks</surname>
+         <affiliation><orgname>SunSoft, Inc.</orgname></affiliation>
+      </othercredit>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1988, 1991, 1993, 1994</year><holder>X Consortium</holder></copyright>
+   <copyright><year>1987, 1988, 1989, 1993, 1994</year><holder>Sun Microsystems, Inc</holder></copyright>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.8</productnumber>
+
+
+<legalnotice>
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+</para>
+<para>
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+</para>
+<para>
+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.
+</para>
+<para>
+Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or
+other dealings in this Software without prior written authorization
+from the X Consortium.
+</para>
+<para>
+<!-- .LP -->
+</para>
+
+<para>
+Permission to use, copy, modify, and distribute this documentation
+for any purpose and without fee is hereby granted, provided
+that the above copyright notice and this permission
+notice appear in all copies.
+Sun Microsystems makes no representations about the
+suitability for any purpose of the information in this document.
+This documentation is provided as is without express or implied warranty.
+</para>
+<para>
+X Window System is a trademark of The Open Group
+</para>
+</legalnotice>
+
+</bookinfo>
+
+<chapter>
+<title>TITLE</title>
+<para>
+The goal of the ICCCM Version 2.0 effort was to add new facilities, to fix
+problems with earlier drafts, and to improve readability and
+understandability, while maintaining compatibility with the earlier
+versions.  This document is the product of over two years of discussion among
+the members of the X Consortium's <function>wmtalk</function> working group.
+The following people deserve thanks for their contributions:
+</para>
+
+<literallayout class="monospaced">
+Gabe Beged-Dov     Bill Janssen
+Chan Benson     Vania Joloboff
+Jordan Brown     Phil Karlton
+Larry Cable     Kaleb Keithley
+Ellis Cohen     Mark Manasse
+Donna Converse     Ralph Mor
+Brian Cripe     Todd Newman
+Susan Dahlberg     Bob Scheifler
+Peter Daifuku     Keith Taylor
+Andrew deBlois     Jim VanGilder
+Clive Feather     Mike Wexler
+Stephen Gildea     Michael Yee
+Christian Jacobi
+</literallayout>
+
+<para>
+It has been a privilege for me to work with this fine group of people.
+</para>
+<para>
+Stuart W. Marks
+</para>
+<para>
+December 1993
+</para>
+
+<para>
+David Rosenthal had overall architectural responsibility
+for the conventions defined in this document;
+he wrote most of the text and edited the document,
+but its development has been a communal effort.
+The details were thrashed out in meetings at the January 1988 MIT X Conference
+and at the 1988 Summer Usenix conference,
+and through months (and megabytes) of argument
+on the
+<function>wmtalk</function>
+mail alias.
+Thanks are due to everyone who contributed,
+and especially to the following people.
+</para>
+
+<para>
+<!-- .LP -->
+For the Selection section:
+</para>
+
+<literallayout class="monospaced">
+Jerry Farrell
+Phil Karlton
+Loretta Guarino Reid
+Mark Manasse
+Bob Scheifler
+</literallayout>
+
+<para>
+For the Cut-Buffer section:
+</para>
+
+<literallayout class="monospaced">
+Andrew Palay
+</literallayout>
+
+<para>
+For the Window and Session Manager sections:
+</para>
+<literallayout class="monospaced">
+<!-- .ta 3i -->
+Todd Brunhoff     Matt Landau
+Ellis Cohen       Mark Manasse
+Jim Fulton        Bob Scheifler
+Hania Gajewska    Ralph Swick
+Jordan Hubbard    Mike Wexler
+Kerry Kimbrough   Glenn Widener
+Audrey Ishizaki
+</literallayout>
+
+<para>
+For the Device Color Characterization section:
+</para>
+
+<literallayout class="monospaced">
+Keith Packard
+</literallayout>
+
+<para>
+In addition, thanks are due to those who contributed to the public review:
+</para>
+
+<literallayout class="monospaced">
+Gary Combs        John Irwin
+Errol Crary       Vania Joloboff
+Nancy Cyprych     John Laporta
+John Diamant      Ken Lee
+Clive Feather     Stuart Marks
+Burns Fisher      Alan Mimms
+Richard Greco     Colas Nahaboo
+Tim Greenwood     Mark Patrick
+Kee Hinckley      Steve Pitschke
+Brian Holt        Brad Reed
+John Interrante   John Thomas
+</literallayout>
+
+<sect1 id="introduction">
+<title>Introduction</title>
+<para>
+It was an explicit design goal of X Version 11 to specify mechanism,
+not policy.
+As a result,
+a client that converses with the server using the protocol defined
+by the <emphasis remap='I'>X Window System Protocol</emphasis>, <emphasis remap='I'>Version 11</emphasis> may operate correctly
+in isolation but may not coexist properly with others sharing the same server.
+</para>
+
+<para>
+Being a good citizen in the X Version 11 world involves adhering to
+conventions that govern inter-client communications in the following areas:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Selection mechanism
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Cut buffers
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Window manager
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Session manager
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Manipulation of shared resources
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Device color characterization
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+<!-- .LP -->
+This document proposes suitable conventions without attempting to enforce
+any particular user interface.
+To permit clients written in different languages to communicate,
+these conventions are expressed solely in terms of protocol operations,
+not in terms of their associated Xlib interfaces,
+which are probably more familiar.
+The binding of these operations to the Xlib interface for C
+and to the equivalent interfaces for other languages
+is the subject of other documents.
+</para>
+
+<sect2 id="evolution_of_the_conventions">
+<title>Evolution of the Conventions</title>
+<para>
+In the interests of timely acceptance,
+the <emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis> (ICCCM)
+covers only a minimal set of required conventions.
+These conventions will be added to and updated as appropriate,
+based on the experiences of the X Consortium.
+</para>
+<para>
+As far as possible,
+these conventions are upwardly compatible with those in the February 25, 1988,
+draft that was distributed with the X Version 11, Release 2, of the software.
+In some areas,
+semantic problems were discovered with those conventions,
+and, thus, complete upward compatibility could not be assured.
+These areas are noted in the text and are summarized in Appendix A.
+</para>
+<para>
+<!-- .LP -->
+In the course of developing these conventions,
+a number of minor changes to the protocol were identified as desirable.
+They also are identified in the text, are summarized in Appendix B,
+and are offered as input to a future protocol revision process.
+If and when a protocol revision incorporating these changes is undertaken,
+it is anticipated that the ICCCM will need to be revised.
+Because it is difficult to ensure that clients and servers are upgraded
+simultaneously,
+clients using the revised conventions should examine the minor protocol
+revision number and be prepared to use the older conventions
+when communicating with an older server.
+</para>
+<para>
+It is expected that these revisions will ensure that clients using
+the conventions appropriate to protocol minor revision <emphasis remap='I'>n</emphasis>
+will interoperate correctly with those that use the conventions
+appropriate to protocol minor revision
+<emphasis remap='I'>n</emphasis> + 1 if the server supports both.
+</para>
+</sect2>
+
+<sect2 id="atoms">
+<title>Atoms</title>
+<para>
+Many of the conventions use atoms.
+To assist the reader,
+the following sections attempt to amplify the description of atoms
+that is provided in the protocol specification.
+</para>
+<sect3 id="what_are_atoms">
+<title>What Are Atoms?</title>
+<para>
+At the conceptual level,
+atoms are unique names that clients can use to communicate information
+to each other.
+They can be thought of as a bundle of octets,
+like a string but without an encoding being specified.
+The elements are not necessarily ASCII characters,
+and no case folding happens.
+<footnote><para>
+The comment in the protocol specification for
+<function>InternAtom </function>
+that ISO Latin-1 encoding should be used is in the nature of a convention;
+the server treats the string as a byte sequence.
+</para></footnote>
+</para>
+<para>
+The protocol designers felt that passing these
+sequences of bytes back and forth across the wire would be too costly.
+Further, they thought it important that events
+as they appear on the wire have a fixed size (in fact, 32 bytes)
+and that because some events contain atoms, a fixed-size representation
+for them was needed.
+</para>
+
+<para>
+To allow a fixed-size representation,
+a protocol request
+( <function>InternAtom</function> )
+was provided to register a byte sequence with the server,
+which returns a 32-bit value (with the top three bits zero)
+that maps to the byte sequence.
+The inverse operator is also available
+( <function>GetAtomName</function> ).
+</para>
+</sect3>
+
+<sect3 id="predefined_atoms">
+<title>Predefined Atoms</title>
+<para>
+The protocol specifies a number of atoms as being predefined:
+</para>
+<blockquote>
+<para>
+Predefined atoms are not strictly necessary
+and may not be useful in all environments,
+but they will eliminate many
+<function>InternAtom</function>
+requests in most applications.
+Note that they are predefined only in the sense of having numeric values,
+not in the sense of having required semantics.
+</para>
+</blockquote>
+
+<para>
+Predefined atoms are an implementation trick to avoid the cost of interning
+many of the atoms that are expected to be used during the startup phase
+of all applications.
+The results of the
+<function>InternAtom</function>
+requests, which require a handshake, can be assumed <emphasis remap='I'>a priori</emphasis>.
+</para>
+
+<para>
+Language interfaces should probably cache the atom-name mappings
+and get them only when required.
+The CLX interface, for instance, makes no distinction between predefined atoms
+and other atoms; all atoms are viewed as symbols at the interface.
+However, a CLX implementation will typically keep a symbol or atom cache
+and will typically initialize this cache with the predefined atoms.
+</para>
+</sect3>
+
+<sect3 id="naming_conventions">
+<title>Naming Conventions</title>
+<para>
+The built-in atoms are composed of uppercase ASCII characters with the
+logical words separated by an underscore character (_), for example,
+WM_ICON_NAME.
+The protocol specification recommends that atoms used
+for private vendor-specific reasons should begin with an underscore.
+To prevent conflicts among organizations,
+additional prefixes should be chosen
+(for example,  _DEC_WM_DECORATION_GEOMETRY).
+</para>
+
+<para>
+The names were chosen in this fashion to make it easy to use them in a
+natural way within LISP.
+Keyword constructors allow the programmer to specify the atoms as LISP atoms.
+If the atoms were not all uppercase,
+special quoting conventions would have to be used.
+</para>
+</sect3>
+
+<sect3 id="semantics">
+<title>Semantics</title>
+<para>
+The core protocol imposes no semantics on atoms except as they are used in
+FONTPROP structures.
+For further information on FONTPROP semantics,
+see the <emphasis remap='I'>X Logical Font Description Conventions</emphasis>.
+</para>
+</sect3>
+<sect3 id="name_spaces">
+<title>Name Spaces</title>
+<para>
+The protocol defines six distinct spaces in which atoms are interpreted.
+Any particular atom may or may not have some valid interpretation
+with respect to each of these name spaces.
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <colspec colname='c4' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Space</entry>
+      <entry>Briefly</entry>
+      <entry>Examples</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>Property name</entry>
+      <entry>Name</entry>
+      <entry>WM_HINTS, WM_NAME, RGB_BEST_MAP, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Property type</entry>
+      <entry>Type</entry>
+      <entry>WM_HINTS, CURSOR, RGB_COLOR_MAP, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Selection name</entry>
+      <entry>Selection</entry>
+      <entry>PRIMARY, SECONDARY, CLIPBOARD</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Selection target</entry>
+      <entry>Target</entry>
+      <entry>FILE_NAME, POSTSCRIPT, PIXMAP, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Font property</entry>
+      <entry></entry>
+      <entry>QUAD_WIDTH, POINT_SIZE, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>ClientMessage</function> type</entry>
+      <entry></entry>
+      <entry>WM_SAVE_YOURSELF, _DEC_SAVE_EDITS, &amp;...</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect3>
+
+<sect3 id="discriminated_names">
+<title>Discriminated Names</title>
+<para>
+Sometimes a protocol requires an arbitrary number of similar
+objects that need unique names (usually because the objects are created
+dynamically, so that names cannot be invented in advance). For example, a
+colormap-generating program might use the selection mechanism to offer
+colormaps for each screen and so needs a selection name for each screen.
+Such names are called "discriminated names" and are discriminated by
+some entity. This entity can be:
+</para>
+
+<literallayout class="monospaced">
+    A screen
+    An X resource (a window, a colormap, a visual, etc.)
+    A client
+</literallayout>
+
+<para>
+If it is only necessary to generate a fixed set of names for each value
+of the discriminating entity, then the discriminated names are formed by
+suffixing an ordinary name according to the value of the entity.
+</para>
+
+<para>
+If <emphasis remap='I'>name</emphasis> is a descriptive portion for the name, <emphasis remap='I'>d</emphasis> is a decimal
+number with no leading zeroes, and <emphasis remap='I'>x</emphasis> is a hexadecimal number with
+exactly 8 digits, and using uppercase letters, then such discriminated names
+shall have the form:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <colspec colname='c4' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Name Discriminated by</entry>
+      <entry>Form</entry>
+      <entry>Example</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>screen number</entry>
+      <entry><emphasis remap='I'>name</emphasis>_S<emphasis remap='I'>d</emphasis></entry>
+      <entry>WM_COMMS_S2</entry>
+    </row>
+    <row rowsep="0">
+      <entry>X resource</entry>
+      <entry><emphasis remap='I'>name</emphasis>_R<emphasis remap='I'>x</emphasis></entry>
+      <entry>GROUP_LEADER_R1234ABCD</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+To discriminate a name by client, use an X resource ID created by that
+client.  This resource can be of any type.
+</para>
+
+<para>
+Sometimes it is simply necessary to generate a unique set of names (for
+example, for the properties on a window used by a MULTIPLE selection).
+These names should have the form:
+</para>
+
+<literallayout class="monospaced">
+U<emphasis remap='I'>d</emphasis>     (e.g.,  U0  U1  U2  U3  ...)
+</literallayout>
+
+<para>
+if the names stand totally alone, and the form:
+</para>
+
+<literallayout class="monospaced">
+<emphasis remap='I'>name</emphasis>_U<emphasis remap='I'>d</emphasis>     (e.g.,  FOO_U0  BAR_U0  FOO_U1  BAR_U1  ...)
+</literallayout>
+
+<para>
+if they come in sets (here there are two sets, named "FOO" and
+"BAR").  The stand-alone U<emphasis remap='I'>d</emphasis> form should be used only if it is
+clear that the module using it has complete control over the relevant
+namespace or has the active cooperation of all other entities that might
+also use these names. (Naming properties on a window created specifically
+for a particular selection is such a use; naming properties on the root
+window is almost certainly not.)
+</para>
+
+<para>
+In a particularly difficult case, it might be necessary to combine both
+forms of discrimination. If this happens, the U form should come after
+the other form, thus:
+</para>
+
+<literallayout class="monospaced">
+    FOO_R12345678_U23
+</literallayout>
+
+<blockquote>
+<title>Rationale</title>
+<para>
+Existing protocols will not be changed to use these naming conventions,
+because doing so will cause too much disruption.  However, it is expected
+that future protocols -- both standard and private -- will use these
+conventions.
+</para>
+</blockquote>
+</sect3>
+</sect2>
+</sect1>
+
+<sect1 id="peer_to_peer_communication_by_means_of_selections">
+<title>Peer-to-Peer Communication by Means of Selections</title>
+<para>
+Selections are the primary mechanism that X Version 11 defines
+for the exchange of information between clients,
+for example, by cutting and pasting between windows.
+Note that there can be an arbitrary number of selections
+(each named by an atom) and that they are global to the server.
+<link linkend="use_of_selection_atoms">
+<xref linkend="use_of_selection_atoms"></xref></link>.
+discusses the choice of an atom.
+Each selection is owned by a client and is attached to a window.
+</para>
+<para>
+Selections communicate between an owner and a requestor.
+The owner has the data representing the value of its selection,
+and the requestor receives it.
+A requestor wishing to obtain the value of a selection provides the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The name of the selection
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The name of a property
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A window
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The atom representing the data type required
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Optionally, some parameters for the request
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+If the selection is currently owned,
+the owner receives an event and is expected to do the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Convert the contents of the selection to the requested data type
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Place this data in the named property on the named window
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Send the requestor an event to let it know the property is available
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Clients are strongly encouraged to use this mechanism.
+In particular,
+displaying text in a permanent window without providing the ability
+to select and convert it into a string is definitely considered antisocial.
+</para>
+
+<para>
+Note that all data transferred between an owner and a requestor must usually
+go by means of the server in an X Version 11 environment.
+A client cannot assume that another client can open the same files
+or even communicate directly.
+The other client may be talking to the server by means of
+a completely different networking mechanism (for example,  one client might
+be DECnet and the other TCP/IP).
+Thus, passing indirect references to data
+(such as, file names, host names, and port numbers)
+is permitted only if both clients specifically agree.
+</para>
+
+<sect2 id="acquiring_selection_ownership">
+<title>Acquiring Selection Ownership</title>
+<para>
+A client wishing to acquire ownership of a particular selection
+should call
+<function>SetSelectionOwner,</function>
+which is defined as follows:
+</para>
+
+<para>
+<function>SetSelectionOwner</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>selection</emphasis>: ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>owner</emphasis>: WINDOW or
+<function>None</function>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>time</emphasis>: TIMESTAMP or
+<function>CurrentTime</function>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The client should set the specified selection to the atom that represents
+the selection,
+set the specified owner to some window that the client created,
+and set the specified time to some time between the current last-change time
+of the selection concerned and the current server time.
+This time value usually will be obtained from the timestamp of the event
+that triggers the acquisition of the selection.
+Clients should not set the time
+value to
+<function>CurrentTime ,</function>
+because if they do so, they have no way of finding
+when they gained ownership of the selection.
+Clients must use a window they created so that requestors
+can route events to the owner of the selection.<footnote>
+<para>
+At present, no part of the protocol requires requestors
+to send events to the owner of a selection.
+This restriction is imposed to prepare for possible future extensions.
+</para>
+</footnote>
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients attempting to acquire a selection must set the time value of the
+<function>SetSelectionOwner </function>
+request to the timestamp of the event triggering the acquisition attempt,
+not to
+<function>CurrentTime .</function>
+A zero-length append to a property is a way to obtain a timestamp for
+this purpose;
+the timestamp is in the corresponding
+<function>PropertyNotify</function>
+event.
+</para>
+</blockquote>
+
+<para>
+If the time in the
+<function>SetSelectionOwner </function>
+request is in the future relative to the server's current time
+or is in the past relative to the last time the specified selection
+changed hands, the
+<function>SetSelectionOwner</function>
+request appears to the client to succeed,
+but ownership is not actually transferred.
+</para>
+
+<para>
+Because clients cannot name other clients directly,
+the specified owner window is used to refer to the owning client
+in the replies to
+<function>GetSelectionOwner</function>, in
+<function>SelectionRequest</function> and
+<function>SelectionClear</function>
+events, and possibly as a place to put properties describing the selection
+in question.
+To discover the owner of a particular selection,
+a client should invoke
+<function>GetSelectionOwner</function>,
+which is defined as follows:
+</para>
+
+<para>
+<!-- .IN "GetSelectionOwner" "" "@DEF@" -->
+<function>GetSelectionOwner</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>selection</emphasis>: ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry>-&gt;</entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>owner</emphasis>: WINDOW or
+<function>None</function>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients are expected to provide some visible confirmation
+of selection ownership.
+To make this feedback reliable,
+a client must perform a sequence like the following:
+</para>
+</blockquote>
+
+<literallayout class="monospaced">
+SetSelectionOwner(selection=PRIMARY, owner=Window, time=timestamp)
+owner = GetSelectionOwner(selection=PRIMARY)
+if (owner != Window) Failure
+</literallayout>
+
+<para>
+If the
+<function>SetSelectionOwner</function>
+request succeeds (not merely appears to succeed),
+the client that issues it is recorded by the server as being the owner
+of the selection for the time period starting at the specified time.
+</para>
+</sect2>
+
+<sect2 id="responsibilities_of_the_selection_owner">
+<title>Responsibilities of the Selection Owner</title>
+<para>
+When a requestor wants the value of a selection,
+the owner receives a
+<function>SelectionRequest</function>
+event, which is defined as follows:
+</para>
+
+<para>
+<function>SelectionRequest</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>owner</emphasis>: WINDOW</entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>selection</emphasis>: ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>selection</emphasis>: ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>target</emphasis>: ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>property</emphasis>: ATOM or
+<function>None</function></entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>requestor</emphasis>: WINDOW</entry>
+    </row>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>time</emphasis>: TIMESTAMP or
+<function>CurrentTime</function></entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The specified owner and selection will be the values that were specified in
+the
+<function>SetSelectionOwner </function>
+request.
+The owner should compare the timestamp with the period
+it has owned the selection and, if the time is outside,
+refuse the
+<function>SelectionRequest</function>
+by sending the requestor window a
+<function>SelectionNotify</function>
+event with the property set to
+<function>None</function>
+(by means of a
+<function>SendEvent</function>
+request with an empty event mask).
+</para>
+
+<para>
+More advanced selection owners are free to maintain a history
+of the value of the selection and to respond to requests for the
+value of the selection during periods they owned it
+even though they do not own it now.
+</para>
+
+<para>
+If the specified property is
+<function>None ,</function>
+the requestor is an obsolete client.
+Owners are encouraged to support these clients by using the specified target
+atom as the property name to be used for the reply.
+</para>
+
+<para>
+Otherwise,
+the owner should use the target to decide the form into which the selection
+should be converted.
+Some targets may be defined such that requestors can pass parameters
+along with the request.  The owner will find these parameters in the
+property named in the selection request.  The type, format, and
+contents of this property are dependent upon the definition of the
+target.  If the target is not defined to have parameters, the owner
+should ignore the property if it is present.
+If the selection cannot be converted
+into a form based on the target (and parameters, if any),
+the owner should refuse the
+<function>SelectionRequest</function>
+as previously described.
+</para>
+
+<para>
+If the specified property is not
+<function>None</function>,
+the owner should place the data resulting from converting the selection
+into the specified property on the requestor window
+and should set the property's type to some appropriate value,
+which need not be the same as the specified target.
+<blockquote>
+<title>Convention</title>
+<para>
+All properties used to reply to
+<function>SelectionRequest</function>
+events must be placed on the requestor window.
+</para>
+</blockquote>
+</para>
+
+<para>
+In either case,
+if the data comprising the selection cannot be stored on the requestor window
+(for example, because the server cannot provide sufficient memory),
+the owner must refuse the
+<function>SelectionRequest</function>,
+as previously described.
+See also
+<link linkend="large_data_transfers">
+<xref linkend="large_data_transfers"></xref></link>.
+
+</para>
+
+<para>
+If the property is successfully stored,
+the owner should acknowledge the successful conversion
+by sending the requestor window a
+<function>SelectionNotify </function>
+event (by means of a
+<function>SendEvent</function>
+request with an empty mask).
+<function>SelectionNotify</function>
+is defined as follows:
+</para>
+
+<para>
+<!-- .IN "SelectionNotify" "" "@DEF@" -->
+<function>SelectionNotify</function>
+</para>
+
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry><emphasis remap='I'>requestor</emphasis>: WINDOW</entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>selection</emphasis>,
+<emphasis remap='I'>target</emphasis>: ATOM
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>property</emphasis>: ATOM or
+<function>None</function>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>time</emphasis>: TIMESTAMP or
+<function>CurrentTime</function>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The owner should set the specified selection, target, time,
+and property arguments to the values received in the
+<function>SelectionRequest </function>
+event.
+(Note that setting the property argument to
+<function>None </function>
+indicates that the conversion requested could not be made.)
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+The selection, target, time, and property arguments in the
+<function>SelectionNotify</function>
+event should be set to the values received in the
+<function>SelectionRequest</function>
+event.
+</para>
+</blockquote>
+
+<para>
+If the owner receives more than one
+<function>SelectionRequest</function>
+event with the same requestor, selection, target, and timestamp it must
+respond to them in the same order in which they were received.
+</para>
+
+<blockquote>
+<title>Rationale</title>
+<para>
+It is possible for a requestor to have multiple outstanding requests that
+use the same requestor window, selection, target, and timestamp, and that
+differ only in the property.  If this occurs, and one of the conversion
+requests fails, the resulting
+<function>SelectionNotify</function>
+event will have its property argument set to
+<function>None</function>.
+This may make it impossible for the requestor to determine which conversion
+request had failed, unless the requests are responded to in order.
+</para>
+</blockquote>
+
+<para>
+The data stored in the property must eventually be deleted.
+A convention is needed to assign the responsibility for doing so.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Selection requestors are responsible for deleting properties whose
+names they receive in
+<function>SelectionNotify</function>
+events (See
+<link linkend="requesting_a_selection">
+<xref linkend="requesting_a_selection"></xref></link>
+) or in properties with type MULTIPLE.
+</para>
+</blockquote>
+
+<para>
+A selection owner will often need confirmation that the data comprising the
+selection has actually been transferred.
+(For example,
+if the operation has side effects on the owner's internal data structures,
+these should not take place until the requestor has indicated
+that it has successfully received the data.)
+Owners should express interest in
+<function>PropertyNotify</function>
+events for the specified requestor window
+and wait until the property in the
+<function>SelectionNotify</function>
+event has been deleted before assuming that the selection data has been
+transferred.  For the MULTIPLE request, if the different conversions require
+separate confirmation, the selection owner can also watch for the deletion
+of the individual properties named in the property in the
+<function>SelectionNotify</function>
+event.
+</para>
+
+<para>
+When some other client acquires a selection,
+the previous owner receives a
+<function>SelectionClear </function>
+event, which is defined as follows:
+</para>
+
+<para>
+<!-- .IN "SelectionClear" "" "@DEF@" -->
+<function>SelectionClear</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>owner</emphasis>: WINDOW
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>selection</emphasis>: ATOM
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>time</emphasis>: TIMESTAMP
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+
+<para>
+The timestamp argument is the time at which the ownership changed hands,
+and the owner argument is the window the previous owner specified in its
+<function>SetSelectionOwner </function>
+request.
+</para>
+
+<para>
+If an owner loses ownership while it has a transfer in progress (that is,
+before it receives notification that the requestor has received all the data),
+it must continue to service the ongoing transfer until it is complete.
+</para>
+
+<para>
+If the selection value completely changes, but the owner happens
+to be the same client (for example, selecting a totally different
+piece of text in the same <function>xterm</function> as before),
+then the client should
+reacquire the selection ownership as if it were not the owner,
+providing a new timestamp. If the selection value is modified, but
+can still reasonably be viewed as the same selected object,
+<footnote>
+<para>
+The division between these two cases is a matter of judgment
+on the part of the software developer.
+</para>
+</footnote>
+the owner should take no action.
+</para>
+
+</sect2>
+
+<sect2 id="giving_up_selection_ownership">
+<title>Giving Up Selection Ownership</title>
+<para>
+Clients may either give up selection ownership voluntarily
+or lose it forcibly as the result of some other client's actions.
+</para>
+
+<sect3 id="voluntarily_giving_up_selection_ownership">
+<title>Voluntarily Giving Up Selection Ownership</title>
+<para>
+To relinquish ownership of a selection voluntarily,
+a client should execute a
+<function>SetSelectionOwner</function>
+request for that selection atom, with owner specified as
+<function>None</function>
+and the time specified as the timestamp that was used to acquire the selection.
+</para>
+
+<para>
+Alternatively,
+the client may destroy the window used as the owner value of the
+<function>SetSelectionOwner</function>
+request, or the client may terminate.
+In both cases,
+the ownership of the selection involved will revert to
+<function>None</function>.
+</para>
+</sect3>
+
+<sect3 id="forcibly_giving_up_selection_ownership">
+<title>Forcibly Giving Up Selection Ownership</title>
+<para>
+If a client gives up ownership of a selection
+or if some other client executes a
+<function>SetSelectionOwner</function>
+for it and thus reassigns it forcibly,
+the previous owner will receive a
+<function>SelectionClear</function>
+event. For the definition of a
+<function>SelectionClear</function>
+event, see
+<link linkend="responsibilities_of_the_selection_owner">
+<xref linkend="responsibilities_of_the_selection_owner"></xref></link>
+</para>
+
+<para>
+The timestamp is the time the selection changed hands.
+The specified owner is the window that was specified by the current owner
+in its
+<function>SetSelectionOwner</function>
+request.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="requesting_a_selection">
+<title>Requesting a Selection</title>
+<para>
+A client that wishes to obtain the value of a selection in a particular
+form (the requestor) issues a
+<function>ConvertSelection</function>
+request, which is defined as follows:
+</para>
+
+<!-- .IN "ConvertSelection" "" "@DEF@" -->
+<para>
+<function>ConvertSelection</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>selection</emphasis>,
+<emphasis remap='I'>target</emphasis>: ATOM
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>property</emphasis>: ATOM or
+<function>None</function>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>requestor</emphasis>: WINDOW
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>time</emphasis>: TIMESTAMP or
+<function>CurrentTime</function>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The selection argument specifies the particular selection involved,
+and the target argument specifies the required form of the information.
+For information about the choice of suitable atoms to use,
+see
+<link linkend="use_of_selection_atoms">
+<xref linkend="use_of_selection_atoms"></xref></link>
+The requestor should set the requestor argument to a window that it created;
+the owner will place the reply property there.
+The requestor should set the time argument to the timestamp on the event
+that triggered the request for the selection value.
+Note that clients should not specify
+<function>CurrentTime</function>.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients should not use
+<function>CurrentTime</function>
+for the time argument of a
+<function>ConvertSelection</function>
+request.
+Instead, they should use the timestamp of the event that caused the request
+to be made.
+</para>
+</blockquote>
+
+<para>
+The requestor should set the property argument to the name of a property
+that the owner can use to report the value of the selection.
+Requestors should ensure that the named property does not exist
+on the window before issuing the
+<function>ConvertSelection</function>
+request.<footnote>
+<para>
+This requirement is new in version 2.0, and, in general, existing
+clients do not conform to this requirement.  To prevent these clients
+from breaking, no existing targets should be extended to take
+parameters until sufficient time has passed for clients to be updated.
+Note that the MULTIPLE target was defined to take parameters in version
+1.0 and its definition is not changing.  There is thus no conformance
+problem with MULTIPLE.
+</para>
+</footnote>
+The exception to this rule is when the requestor intends to pass
+parameters with the request (see below).
+</para>
+
+<blockquote>
+<title>Rationale</title>
+<para>
+It is necessary for requestors to delete the property before issuing the
+request so that the target can later be extended to take parameters without
+introducing an incompatibility.  Also note that the requestor of a selection
+need not know the client that owns the selection nor the window on which
+the selection was acquired.
+</para>
+</blockquote>
+
+<para>
+Some targets may be defined such that requestors can pass parameters
+along with the request.  If the requestor wishes to provide parameters
+to a request, they should be placed in the specified property on the
+requestor window before the requestor issues the
+<function>ConvertSelection</function>
+request, and this property should be named in the request.
+</para>
+
+<para>
+Some targets may be defined so that parameters are optional.  If no
+parameters are to be supplied with the request of such a target, the
+requestor must ensure that the property does not exist before issuing
+the
+<function>ConvertSelection</function>
+request.
+</para>
+
+<para>
+The protocol allows the property field to be set to
+<function>None ,</function>
+in which case the owner is supposed to choose a property name.
+However, it is difficult for the owner to make this choice safely.
+</para>
+
+<para><emphasis role="bold">Conventions</emphasis></para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Requestors should not use
+<function>None</function>
+for the property argument of a
+<function>ConvertSelection</function>
+request.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Owners receiving
+<function>ConvertSelection </function>
+requests with a property argument of
+<function>None</function>
+are talking to an obsolete client.
+They should choose the target atom as the property name to be used
+for the reply.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The result of the
+<function>ConvertSelection</function>
+request is that a
+<function>SelectionNotify</function>
+event will be received.
+For the definition of a
+<function>SelectionNotify</function>
+event, see
+<link linkend="responsibilities_of_the_selection_owner">
+<xref linkend="responsibilities_of_the_selection_owner"></xref></link>.
+</para>
+
+<para>
+The requestor, selection, time, and target arguments will be the same
+as those on the
+<function>ConvertSelection </function>
+request.
+</para>
+
+<para>
+If the property argument is
+<function>None ,</function>
+the conversion has been refused.
+This can mean either that there is no owner for the selection,
+that the owner does not support the conversion implied by the target,
+or that the server did not have sufficient space to accommodate the data.
+</para>
+
+<para>
+If the property argument is not
+<function>None ,</function>
+then that property will exist on the requestor window.
+The value of the selection can be retrieved from this
+property by using the
+<function>GetProperty</function>
+request, which is defined as follows:
+</para>
+
+<para>
+<!-- .IN "GetProperty" "" "@DEF@" -->
+<function>GetProperty</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>window</emphasis>: WINDOW
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>property</emphasis>: ATOM
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>type</emphasis>: ATOM or
+<function>AnyPropertyType</function>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>long-offset</emphasis>,
+<emphasis remap='I'>long-length</emphasis>: CARD32
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+<emphasis remap='I'>delete</emphasis>: BOOL
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+-&gt;
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+type: ATOM or <function>None</function>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+format: {0, 8, 16, 32}
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+bytes-after: CARD32
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>
+value: LISTofINT8 or LISTofINT16 or LISTofINT32
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+<function>GetProperty</function>
+to retrieve the value of a selection,
+the property argument should be set to the corresponding value in the
+<function>SelectionNotify</function>
+event.
+Because the requestor has no way of knowing beforehand what type
+the selection owner will use,
+the type argument should be set to
+<function>AnyPropertyType</function>.
+Several
+<function>GetProperty</function>
+requests may be needed to retrieve all the data in the selection;
+each should set the long-offset argument to the amount of data received so far,
+and the size argument to some reasonable buffer size (see
+<link linkend="large_data_transfers">
+<xref linkend="large_data_transfers"></xref></link>.
+).
+If the returned value of bytes-after is zero, <!-- xref -->
+the whole property has been transferred.
+</para>
+
+<para>
+Once all the data in the selection has been retrieved
+(which may require getting the values of several properties --
+see
+<link linkend="use_of_selection_properties">
+<xref linkend="use_of_selection_properties"></xref></link>.
+),
+the requestor should delete the property in the
+<function>SelectionNotify</function>
+request by using a
+<function>GetProperty</function>
+request with the delete argument set to
+<function>True</function>.
+As previously discussed,
+the owner has no way of knowing when the data has been
+transferred to the requestor unless the property is removed.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+The requestor must delete the property named in the
+<function>SelectionNotify</function>
+once all the data has been retrieved.
+The requestor should invoke either
+<function>DeleteProperty</function> or
+<function>GetProperty</function>
+(delete==True)
+after it has successfully retrieved all the data in the selection.
+For further information,
+see
+<link linkend="large_data_transfers">
+<xref linkend="large_data_transfers"></xref></link>.
+
+</para>
+</blockquote>
+</sect2>
+
+<sect2 id="large_data_transfers">
+<title>Large Data Transfers</title>
+<para>
+Selections can get large, which poses two problems:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Transferring large amounts of data to the server is expensive.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+All servers will have limits on the amount of data that can be stored
+in properties.
+Exceeding this limit will result in an
+<function>Alloc</function>
+error on the
+<function>ChangeProperty </function>
+request that the selection owner uses to store the data.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The problem of limited server resources is addressed by the following
+conventions:
+</para>
+
+<para>
+<emphasis role="bold">Conventions</emphasis>
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Selection owners should transfer the data describing a large selection
+(relative to the maximum-request-size they received
+in the connection handshake) using the INCR property mechanism
+(see
+<link linkend="incr_properties">
+<xref linkend="incr_properties"></xref></link>.
+). <!-- xref -->
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Any client using
+<function>SetSelectionOwner</function>
+to acquire selection ownership should arrange to process
+<function>Alloc</function>
+errors in property change requests.
+For clients using Xlib,
+this involves using the
+<function>XSetErrorHandler</function>
+function to override the default handler.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A selection owner must confirm that no
+<function>Alloc</function>
+error occurred while storing the properties for a selection
+before replying with a confirming
+<function>SelectionNotify</function>
+event.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+When storing large amounts of data (relative to maximum-request-size),
+clients should use a sequence of
+<function>ChangeProperty (mode==Append)</function>
+requests for reasonable quantities of data.
+This avoids locking servers up and limits the waste of data an
+<function>Alloc </function>
+error would cause.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If an
+<function>Alloc </function>
+error occurs during the storing of the selection data,
+all properties stored for this selection should be deleted
+and the
+<function>ConvertSelection</function>
+request should be refused (see
+<link linkend="responsibilities_of_the_selection_owner">
+<xref linkend="responsibilities_of_the_selection_owner"></xref></link>.
+). <!-- xref -->
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+To avoid locking servers up for inordinate lengths of time,
+requestors retrieving large quantities of data from a property
+should perform a series of
+<function>GetProperty </function>
+requests, each asking for a reasonable amount of data.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+Single-threaded servers should take care to avoid locking up during large
+data transfers.
+</para>
+</blockquote>
+</sect2>
+
+<sect2 id="use_of_selection_atoms">
+<title>Use of Selection Atoms</title>
+<para>
+Defining a new atom consumes resources in the server
+that are not released until the server reinitializes.
+Thus, reducing the need for newly minted atoms is an important goal
+for the use of the selection atoms.
+</para>
+
+<sect3 id="selection_atoms">
+<title>Selection Atoms</title>
+<para>
+There can be an arbitrary number of selections, each named by an atom.
+To conform with the inter-client conventions, however,
+clients need deal with only these three selections:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+PRIMARY
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+SECONDARY
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+CLIPBOARD
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Other selections may be used freely for private communication among
+related groups of clients.
+</para>
+
+<sect4 id="the_primary_Selection">
+<title>The PRIMARY Selection</title>
+<para>
+The selection named by the atom PRIMARY is used for all commands
+that take only a single argument and is the principal means of communication
+between clients that use the selection mechanism.
+</para>
+</sect4>
+
+<sect4 id="the_secondary_Selection">
+<title>The SECONDARY Selection</title>
+<para>
+The selection named by the atom SECONDARY is used:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+As the second argument to commands taking two arguments
+(for example, "exchange primary and secondary selections")
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+As a means of obtaining data when there is a primary selection
+and the user does not want to disturb it
+    </para>
+  </listitem>
+</itemizedlist>
+
+</sect4>
+<sect4 id="the_clipboard_selection">
+<title>The CLIPBOARD Selection</title>
+<para>
+The selection named by the atom CLIPBOARD is used to hold data
+that is being transferred between clients,
+that is, data that usually is being cut and then pasted
+or copied and then pasted.
+Whenever a client wants to transfer data to the clipboard:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+It should assert ownership of the CLIPBOARD.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If it succeeds in acquiring ownership,
+it should be prepared to respond to a request for the contents of the CLIPBOARD
+in the usual way (retaining the data to be able to return it).
+The request may be generated by the clipboard client described below.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If it fails to acquire ownership,
+a cutting client should not actually perform the cut or provide feedback
+that would suggest that it has actually transferred data to the clipboard.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The owner should repeat this process whenever the data to be transferred
+would change.
+</para>
+
+<para>
+Clients wanting to paste data from the clipboard should request
+the contents of the CLIPBOARD selection in the usual way.
+</para>
+
+<para>
+Except while a client is actually deleting or copying data,
+the owner of the CLIPBOARD selection may be a single, special client
+implemented for the purpose.
+This client maintains the content of the clipboard up-to-date
+and responds to requests for data from the clipboard as follows:
+</para>
+
+
+<itemizedlist>
+  <listitem>
+    <para>
+It should assert ownership of the CLIPBOARD selection
+and reassert it any time the clipboard data changes.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If it loses the selection (because another client has some new data
+for the clipboard),
+it should:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+Obtain the contents of the selection from the new owner by using the timestamp
+in the
+<function>SelectionClear</function>
+event.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Attempt to reassert ownership of the CLIPBOARD selection
+by using the same timestamp.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Restart the process using a newly acquired timestamp if this attempt fails.
+This timestamp should be obtained by asking the current owner of the
+CLIPBOARD selection to convert it to a TIMESTAMP.
+If this conversion is refused or if the same timestamp is received twice,
+the clipboard client should acquire a fresh timestamp in the
+usual way (for example by a zero-length append to a property).
+        </para>
+      </listitem>
+    </itemizedlist>
+  </listitem>
+  <listitem>
+    <para>
+It should respond to requests for the CLIPBOARD contents in the usual way.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+A special CLIPBOARD client is not necessary.
+The protocol used by the cutting client and the pasting client
+is the same whether the CLIPBOARD client is running or not.
+The reasons for running the special client include:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Stability - If the cutting client were to crash or terminate,
+the clipboard value would still be available.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Feedback - The clipboard client can display the contents of the clipboard.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Simplicity - A client deleting data does not have to retain it for so long,
+thus reducing the chance of race conditions causing problems.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The reasons not to run the clipboard client include:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Performance - Data is transferred only if it is actually required
+(that is, when some client actually wants the data).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Flexibility - The clipboard data may be available as more than one target.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect4>
+</sect3>
+
+<sect3 id="target_atoms">
+<title>Target Atoms</title>
+<para>
+The atom that a requestor supplies as the target of a
+<function>ConvertSelection</function>
+request determines the form of the data supplied.
+The set of such atoms is extensible,
+but a generally accepted base set of target atoms is needed.
+As a starting point for this,
+the following table contains those that have been suggested so far.
+</para>
+
+<!--
+This table has very tricky formatting.  Several targets are too long to
+fit, so the table format needs to change around them.  If the table
+format changes, it will need to be changed in several places.  There are
+also two footnotes in this table, but the footnote text can't be
+embedded in the table.  This means that the auto-numbering needs to be
+dinked around with after the end of the table.
+-->
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Atom</entry>
+      <entry>Type </entry>
+      <entry>Data Received</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>ADOBE_PORTABLE_DOCUMENT_FORMAT</entry>
+      <entry>STRING</entry>
+      <entry>[1]</entry>
+    </row>
+    <row rowsep="0">
+      <entry>APPLE_PICT</entry>
+      <entry>APPLE_PICT</entry>
+      <entry>[2]</entry>
+    </row>
+    <row rowsep="0">
+      <entry>BACKGROUND</entry>
+      <entry>PIXEL</entry>
+      <entry>A list of pixel values</entry>
+    </row>
+    <row rowsep="0">
+      <entry>BITMAP</entry>
+      <entry>BITMAP</entry>
+      <entry>A list of bitmap IDs</entry>
+    </row>
+    <row rowsep="0">
+      <entry>CHARACTER_POSITION</entry>
+      <entry>SPAN</entry>
+      <entry>The start and end of the selection in bytes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>CLASS</entry>
+      <entry>TEXT</entry>
+      <entry>(see
+<link linkend="wm_class_property">
+<xref linkend="wm_class_property"></xref></link>.
+)</entry> <!-- xref -->
+    </row>
+    <row rowsep="0">
+      <entry>CLIENT_WINDOW</entry>
+      <entry>WINDOW</entry>
+      <entry>Any top-level window owned by the selection owner</entry>
+    </row>
+    <row rowsep="0">
+      <entry>COLORMAP</entry>
+      <entry>COLORMAP</entry>
+      <entry>A list of colormap IDs</entry>
+    </row>
+    <row rowsep="0">
+      <entry>COLUMN_NUMBER</entry>
+      <entry>SPAN</entry>
+      <entry>The start and end column numbers</entry>
+    </row>
+    <row rowsep="0">
+      <entry>COMPOUND_TEXT</entry>
+      <entry>COMPOUND_TEXT</entry>
+      <entry>Compound Text</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DELETE</entry>
+      <entry>NULL</entry>
+      <entry>(see
+<link linkend="delete">
+<xref linkend="delete"></xref></link>.
+)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DRAWABLE</entry>
+      <entry>DRAWABLE</entry>
+      <entry>A list of drawable IDs</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ENCAPSULATED_POSTSCRIPT</entry>
+      <entry>STRING</entry>
+      <entry>[3], Appendix H
+<footnote><para>
+Earlier versions of this document erroneously specified that conversion of
+the PIXMAP target returns a property of type DRAWABLE instead of PIXMAP.
+Implementors should be aware of this and may want to support the DRAWABLE
+type as well to allow for compatibility with older clients.
+</para></footnote>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>ENCAPSULATED_POSTSCRIPT_INTERCHANGE</entry>
+      <entry>STRING</entry>
+      <entry>[3], Appendix H</entry>
+    </row>
+    <row rowsep="0">
+      <entry>FILE_NAME</entry>
+      <entry>TEXT</entry>
+      <entry>The full path name of a file</entry>
+    </row>
+    <row rowsep="0">
+      <entry>FOREGROUND</entry>
+      <entry>PIXEL</entry>
+      <entry>A list of pixel values</entry>
+    </row>
+    <row rowsep="0">
+      <entry>HOST_NAME</entry>
+      <entry>TEXT</entry>
+      <entry>(see
+<link linkend="wm_client_machine_property">
+<xref linkend="wm_client_machine_property"></xref></link>.
+)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>INSERT_PROPERTY</entry>
+      <entry>NULL</entry>
+      <entry>(see
+<link linkend="insert_property">
+<xref linkend="insert_property"></xref></link>.
+)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>INSERT_SELECTION</entry>
+      <entry>NULL</entry>
+      <entry>(see
+<link linkend="insert_selection">
+<xref linkend="insert_selection"></xref></link>.
+)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>LENGTH</entry>
+      <entry>INTEGER</entry>
+      <entry>The number of bytes in the selection
+<footnote><para>
+The targets ENCAPSULATED_POSTSCRIPT and ENCAPSULATED_POSTSCRIPT_INTERCHANGE
+are equivalent to the targets _ADOBE_EPS and _ADOBE_EPSI (respectively) that
+appear in the selection targets registry.  The _ADOBE_ targets are
+deprecated, but clients are encouraged to continue to support them for
+backward compatibility.
+</para></footnote>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>LINE_NUMBER</entry>
+      <entry>SPAN</entry>
+      <entry>The start and end line numbers</entry>
+    </row>
+    <row rowsep="0">
+      <entry>LIST_LENGTH</entry>
+      <entry>INTEGER</entry>
+      <entry>The number of disjoint parts of the selection</entry>
+    </row>
+    <row rowsep="0">
+      <entry>MODULE</entry>
+      <entry>TEXT</entry>
+      <entry>The name of the selected procedure</entry>
+    </row>
+    <row rowsep="0">
+      <entry>MULTIPLE</entry>
+      <entry>ATOM_PAIR</entry>
+      <entry>(see the discussion that follows)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>NAME</entry>
+      <entry>TEXT</entry>
+      <entry>(see
+<link linkend="wm_name_property">
+<xref linkend="wm_name_property"></xref></link>.
+)</entry> <!-- xref -->
+    </row>
+    <row rowsep="0">
+      <entry>ODIF</entry>
+      <entry>TEXT</entry>
+      <entry>ISO Office Document Interchange Format</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OWNER_OS</entry>
+      <entry>TEXT</entry>
+      <entry>The operating system of the owner client</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PIXMAP</entry>
+      <entry>PIXMAP
+<footnote>
+<para>
+This definition is ambiguous, as the selection may be converted into any of
+several targets that may return differing amounts of data.  The requestor
+has no way of knowing which, if any, of these targets corresponds to the
+result of LENGTH.  Clients are advised that no guarantees can be made about
+the result of a conversion to LENGTH; its use is thus deprecated.
+</para>
+</footnote>
+      </entry>
+      <entry>A list of pixmap IDs</entry>
+    </row>
+    <row rowsep="0">
+      <entry>POSTSCRIPT</entry>
+      <entry>STRING</entry>
+      <entry>[3]</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PROCEDURE</entry>
+      <entry>TEXT</entry>
+      <entry>The name of the selected procedure</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PROCESS</entry>
+      <entry>INTEGER, TEXT</entry>
+      <entry>The process ID of the owner</entry>
+    </row>
+    <row rowsep="0">
+      <entry>STRING</entry>
+      <entry>STRING</entry>
+      <entry>ISO Latin-1 (+TAB+NEWLINE) text</entry>
+    </row>
+    <row rowsep="0">
+      <entry>TARGETS</entry>
+      <entry>ATOM</entry>
+      <entry>A list of valid target atoms</entry>
+    </row>
+    <row rowsep="0">
+      <entry>TASK</entry>
+      <entry>INTEGER, TEXT</entry>
+      <entry>The task ID of the owner</entry>
+    </row>
+    <row rowsep="0">
+      <entry>TEXT</entry>
+      <entry>TEXT</entry>
+      <entry>The text in the owner's choice of encoding</entry>
+    </row>
+    <row rowsep="0">
+      <entry>TIMESTAMP</entry>
+      <entry>INTEGER</entry>
+      <entry>The timestamp used to acquire the selection</entry>
+    </row>
+    <row rowsep="0">
+      <entry>USER</entry>
+      <entry>TEXT</entry>
+      <entry>The name of the user running the owner</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<!--
+Conditionalized on groff because
+groff keeps track of footnotes and fn references separately,
+so resetting isn't necessary (and referencing \n* gives a warning).
+.if !\n(GS .nr * \n*-3     \" decrement by the number of footnotes in the table
+.if 0 \{\
+HACK!  There are several footnotes in the table above, each marked with the
+construct "*".  The actual footnote text is here, because I haven't found
+a way to place it within the table itself.  This causes a numbering problem,
+because each * increments the footnote counter (number register *) and the
+FS macro uses its current value.  To get around this, we decrement the *
+register by the number of footnotes in the table.  Then, before calling each
+FS macro, we increment the register.
+
+Also note that footnotes must appear within the T{ T} construct in tables.
+If they don't, strange numbering problems will result, probably as a result
+of multiple evaluation.
+\}
+ -->
+
+<!-- .\" These footnotes are in the wrong order because Sun tbl numbers the -->
+<!-- .\" footnote references wrong in the above table.  Thus this doesn't -->
+<!-- .\" do the right thing with gtbl, which gets the order right. -->
+<!-- .if !\n(GS .nr * +1 -->
+<!-- .FS -->
+<!-- .FE -->
+<!-- .if !\n(GS .nr * +1 -->
+<!-- .FS -->
+<!-- .FE -->
+<!-- .if !\n(GS .nr * +1 -->
+<!-- .FS -->
+<!-- .FE -->
+
+<para>
+References:
+</para>
+
+<orderedlist>
+  <listitem>
+    <para>
+Adobe Systems, Incorporated.
+<emphasis>Portable Document Format Reference Manual.</emphasis>
+Reading, MA, Addison-Wesley, ISBN 0-201-62628-4.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Apple Computer, Incorporated.
+<emphasis>Inside Macintosh, Volume V.</emphasis>
+Chapter 4, "Color QuickDraw," Color Picture Format.
+ISBN 0-201-17719-6.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Adobe Systems, Incorporated.
+<emphasis>PostScript Language Reference Manual.</emphasis>
+Reading, MA, Addison-Wesley, ISBN 0-201-18127-4.
+    </para>
+  </listitem>
+</orderedlist>
+
+<para>
+It is expected that this table will grow over time.
+</para>
+
+<para>
+Selection owners are required to support the following targets.
+All other targets are optional.
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+TARGETS - The owner should return a list of atoms that represent
+the targets for which an attempt to convert the current selection
+will succeed (barring unforseeable problems such as
+<function>Alloc </function>
+errors).
+This list should include all the required atoms.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+MULTIPLE - The MULTIPLE target atom is valid only when a property
+is specified on the
+<function>ConvertSelection </function>
+request.
+If the property argument in the
+<function>SelectionRequest </function>
+event is
+<function>None </function>
+and the target is MULTIPLE,
+it should be refused.
+    </para>
+    <para>
+When a selection owner receives a
+<function>SelectionRequest (target==MULTIPLE)</function>
+request,
+the contents of the property named in the request will be a list of atom pairs:
+the first atom naming a target and the second naming a property
+<function>( None </function>
+is not valid here).
+The effect should be as if the owner had received a sequence of
+<function>SelectionRequest </function>
+events (one for each atom pair) except that:
+<!-- .RS -->
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+The owner should reply with a
+<function>SelectionNotify </function>
+only when all the requested conversions have been performed.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+If the owner fails to convert the target named by an atom
+in the MULTIPLE property,
+it should replace that atom in the property with
+<function>None .</function>
+        </para>
+      </listitem>
+    </itemizedlist>
+    <blockquote><title>Convention</title>
+        <para>
+The entries in a MULTIPLE property must be processed in the order
+they appear in the property.
+For further information,
+see
+<link linkend="selection_targets_with_side_effects">
+<xref linkend="selection_targets_with_side_effects"></xref></link>.
+        </para>
+    </blockquote>
+    <para>
+The requestor should delete each individual property when it has
+copied the data from that conversion, and the property specified in the
+MULTIPLE request when it has copied all the data.
+    </para>
+    <para>
+The requests are otherwise to be processed independently, and they
+should succeed or fail independently.  The MULTIPLE target is an
+optimization that reduces the amount of protocol traffic between the
+owner and the requestor; it is not a transaction mechanism.  For
+example, a client may issue a MULTIPLE request with two targets: a data
+target and the DELETE target.  The DELETE target will still be processed
+even if the conversion of the data target fails.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+TIMESTAMP - To avoid some race conditions,
+it is important that requestors be able to discover the timestamp
+the owner used to acquire ownership.
+Until and unless the protocol is changed so that a
+<function>GetSelectionOwner</function>
+request returns the timestamp used to acquire ownership,
+selection owners must support conversion to TIMESTAMP,
+returning the timestamp they used to obtain the selection.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="selection_targets_with_side_effects">
+<title>Selection Targets with Side Effects</title>
+<para>
+Some targets (for example, DELETE) have side effects.
+To render these targets unambiguous,
+the entries in a MULTIPLE property must be processed in the order
+that they appear in the property.
+</para>
+<para>
+In general,
+targets with side effects will return no information,
+that is, they will return a zero length property of type NULL.
+(Type NULL means the result of
+<function>InternAtom</function>
+on the string "NULL", not the value zero.)
+In all cases,
+the requested side effect must be performed before the conversion is accepted.
+If the requested side effect cannot be performed,
+the corresponding conversion request must be refused.
+</para>
+
+<blockquote>
+<title>Conventions</title>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Targets with side effects should return no information
+(that is, they should have a zero-length property of type NULL).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The side effect of a target must be performed before the conversion is accepted.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the side effect of a target cannot be performed,
+the corresponding conversion request must be refused.
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+<blockquote>
+<title>Problem</title>
+
+<para>
+The need to delay responding to the
+<function>ConvertSelection </function>
+request until a further conversion has succeeded poses problems
+for the Intrinsics interface that need to be addressed.
+</para>
+</blockquote>
+
+<para>
+These side-effect targets are used to implement operations such as
+"exchange PRIMARY and SECONDARY selections."
+</para>
+
+<sect4 id="delete">
+<title>DELETE</title>
+<para>
+When the owner of a selection receives a request to convert it to DELETE,
+it should delete the corresponding selection
+(whatever doing so means for its internal data structures)
+and return a zero-length property of type NULL if the deletion was successful.
+</para>
+</sect4>
+
+<sect4 id="insert_selection">
+<title>INSERT_SELECTION</title>
+<para>
+When the owner of a selection receives a request to convert it to
+INSERT_SELECTION,
+the property named will be of type ATOM_PAIR.
+The first atom will name a selection,
+and the second will name a target.
+The owner should use the selection mechanism to convert the named selection
+into the named target and should insert it at the location of the selection
+for which it got the INSERT_SELECTION request
+(whatever doing so means for its internal data structures).
+</para>
+</sect4>
+<sect4 id="insert_property">
+<title>INSERT_PROPERTY</title>
+<para>
+When the owner of a selection receives a request to convert it to
+INSERT_PROPERTY,
+it should insert the property named in the request at the location
+of the selection for which it got the INSERT_SELECTION request
+(whatever doing so means for its internal data structures).
+</para>
+</sect4>
+</sect3>
+</sect2>
+
+<sect2 id="use_of_selection_properties">
+<title>Use of Selection Properties</title>
+<para>
+The names of the properties used in selection data transfer are chosen by
+the requestor.
+The use of
+<function>None </function>
+property fields in
+<function>ConvertSelection </function>
+requests (which request the selection owner to choose a name)
+is not permitted by these conventions.
+</para>
+<para>
+The selection owner always chooses the type of the property
+in the selection data transfer.
+Some types have special semantics assigned by convention,
+and these are reviewed in the following sections.
+</para>
+<para>
+In all cases,
+a request for conversion to a target should return either
+a property of one of the types listed in the previous table for that target
+or a property of type INCR and then a property of one of the listed types.
+</para>
+<para>
+Certain selection properties may contain resource IDs.  The selection owner
+should ensure that the resource is not destroyed and that its contents are
+not changed until after the selection transfer is complete.  Requestors that
+rely on the existence or on the proper contents of a resource must operate
+on the resource (for example, by copying the contents of a pixmap) before
+deleting the selection property.
+</para>
+<para>
+The selection owner will return a list of zero or more items
+of the type indicated by the property type.
+In general,
+the number of items in the list will correspond to the number
+of disjoint parts of the selection.
+Some targets (for example, side-effect targets) will be of length zero
+irrespective of the number of disjoint selection parts.
+In the case of fixed-size items,
+the requestor may determine the number of items by the property size.
+Selection property types are listed in the table below.
+For variable-length items such as text,
+the separators are also listed.
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Type Atom</entry>
+      <entry>Format</entry>
+      <entry>Separator</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>APPLE_PICT</entry>
+      <entry>8</entry>
+      <entry>Self-sizing</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ATOM</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ATOM_PAIR</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>BITMAP</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>C_STRING</entry>
+      <entry>8</entry>
+      <entry>Zero</entry>
+    </row>
+    <row rowsep="0">
+      <entry>COLORMAP</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>COMPOUND_TEXT</entry>
+      <entry>8</entry>
+      <entry>Zero</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DRAWABLE</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>INCR</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>INTEGER</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PIXEL</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PIXMAP</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SPAN</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+    <row rowsep="0">
+      <entry>STRING</entry>
+      <entry>8</entry>
+      <entry>Zero</entry>
+    </row>
+    <row rowsep="0">
+      <entry>WINDOW</entry>
+      <entry>32</entry>
+      <entry>Fixed-size</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+It is expected that this table will grow over time.
+</para>
+
+<sect3 id="text_properties">
+<title>TEXT Properties</title>
+<para>
+In general,
+the encoding for the characters in a text string property is specified
+by its type.
+It is highly desirable for there to be a simple, invertible mapping
+between string property types and any character set names
+embedded within font names in any font naming standard adopted by the
+Consortium.
+</para>
+
+<para>
+The atom TEXT is a polymorphic target.
+Requesting conversion into TEXT will convert into whatever encoding
+is convenient for the owner.
+The encoding chosen will be indicated by the type of the property returned.
+TEXT is not defined as a type;
+it will never be the returned type from a selection conversion request.
+</para>
+
+<para>
+If the requestor wants the owner to return the contents of the selection
+in a specific encoding,
+it should request conversion into the name of that encoding.
+</para>
+
+<para>
+In the table in
+<link linkend="target_atoms">
+<xref linkend="target_atoms"></xref></link>,
+the word TEXT (in the Type column) is used to indicate one
+of the registered encoding names.
+The type would not actually be TEXT;
+it would be STRING or some other ATOM naming the encoding chosen by the owner.
+</para>
+
+<para>
+STRING as a type or a target specifies the ISO Latin-1 character set plus the
+control characters TAB (octal 11) and NEWLINE (octal 12).
+The spacing interpretation of TAB is context dependent.
+Other ASCII control characters are explicitly not included in STRING
+at the present time.
+</para>
+
+<para>
+COMPOUND_TEXT as a type or a target specifies the Compound Text interchange
+format; see the
+<emphasis remap='I'>Compound Text Encoding</emphasis>. <!-- xref -->
+</para>
+
+<para>
+<!-- .LP -->
+There are some text objects where the source or intended user, as the
+case may be, does not have a specific character set for the text, but
+instead merely requires a zero-terminated sequence of bytes with no
+other restriction; no element of the selection mechanism may assume that
+any byte value is forbidden or that any two differing sequences are
+equivalent.
+  <footnote>
+    <para>
+Note that this is different from STRING, where many byte values are
+forbidden, and from COMPOUND_TEXT, where, for example, inserting the
+sequence 27,\ 40,\ 66 (designate ASCII into GL) at the start does not alter
+the meaning.
+    </para>
+  </footnote>
+  For these objects, the type C_STRING should be used.
+</para>
+<blockquote>
+<title>Rationale</title>
+<para>
+An example of the need for C_STRING is to transmit the names of
+files; many operating systems do not interpret filenames as having
+a character set. For example, the same character string uses a
+different sequence of bytes in ASCII and EBCDIC, and so most
+operating systems see these as different filenames and offer no
+way to treat them as the same. Thus no character-set based
+property type is suitable.
+</para>
+</blockquote>
+
+<para>
+Type STRING, COMPOUND_TEXT, and C_STRING properties will consist of a list
+of elements separated by null characters; other encodings will need to
+specify an appropriate list format.
+</para>
+</sect3>
+
+<sect3 id="incr_properties">
+<title>INCR Properties</title>
+<para>
+Requestors may receive a property of type INCR
+<footnote>
+<para>
+These properties were called INCREMENTAL in an earlier draft.
+The protocol for using them has changed,
+and so the name has changed to avoid confusion.
+</para>
+</footnote>
+in response to any target that results in selection data.
+</para>
+<para>
+This indicates that the owner will send the actual data incrementally.
+The contents of the INCR property will be an integer,
+which represents a lower bound on the number of bytes of data in the selection.
+The requestor and the selection owner transfer the data in the selection
+in the following manner.
+</para>
+<para>
+The selection requestor starts the transfer process by deleting
+the (type==INCR) property forming the reply to the selection.
+</para>
+<para>
+The selection owner then:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Appends the data in suitable-size chunks to the
+same property on the same window as the selection reply
+with a type corresponding to the actual type of the converted selection.
+The size should be less than the maximum-request-size in the connection
+handshake.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Waits between each append for a
+<function>PropertyNotify</function>
+(state==Deleted) event that shows that the requestor has read the data.
+The reason for doing this is to limit the consumption of space in the server.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Waits (after the entire data has been transferred to the server) until a
+<function>PropertyNotify</function>
+(state==Deleted)
+event that shows that the data has been read by the requestor
+and then writes zero-length data to the property.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The selection requestor:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Waits for the
+<function>SelectionNotify </function>
+event.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Loops:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+Retrieving data using
+<function>GetProperty </function>
+with the delete argument
+<function>True .</function>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Waiting for a
+<function>PropertyNotify </function>
+with the state argument
+<function>NewValue</function>.
+        </para>
+      </listitem>
+    </itemizedlist>
+  </listitem>
+  <listitem>
+    <para>
+Waits until the property named by the
+<function>PropertyNotify</function>
+event is zero-length.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Deletes the zero-length property.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The type of the converted selection is the type of the first partial property.
+The remaining partial properties must have the same type.
+</para>
+</sect3>
+
+<sect3 id="drawable_properties">
+<title>DRAWABLE Properties</title>
+<para>
+Requestors may receive properties of type PIXMAP, BITMAP, DRAWABLE, or WINDOW,
+which contain an appropriate ID.
+While information about these drawables is available from the server by means of
+the
+<function>GetGeometry</function> request,
+the following items are not:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Foreground pixel
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Background pixel
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Colormap ID
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In general,
+requestors converting into targets whose returned type in the table in
+<link linkend="target_atoms">
+<xref linkend="target_atoms"></xref></link>
+is one of the DRAWABLE types should expect to convert also
+into the following targets (using the MULTIPLE mechanism):
+</para>
+
+
+<itemizedlist>
+  <listitem>
+    <para>
+FOREGROUND returns a PIXEL value.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+BACKGROUND returns a PIXEL value.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+COLORMAP returns a colormap ID.
+    </para>
+  </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="span_properties">
+<title>SPAN Properties</title>
+<para>
+Properties with type SPAN contain a list of cardinal-pairs
+with the length of the cardinals determined by the format.
+The first specifies the starting position,
+and the second specifies the ending position plus one.
+The base is zero.
+If they are the same,
+the span is zero-length and is before the specified position.
+The units are implied by the target atom,
+such as LINE_NUMBER or CHARACTER_POSITION.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="manager_selections">
+<title>Manager Selections</title>
+<para>
+Certain clients, often called managers, take on responsibility
+for managing shared resources.  A client that manages a shared
+resource should take ownership of an appropriate selection,
+named using the conventions described in
+<link linkend="naming_conventions">
+<xref linkend="naming_conventions"></xref></link>
+and
+<link linkend="discriminated_names">
+<xref linkend="discriminated_names"></xref></link>.
+A client that manages multiple
+shared resources (or groups of resources) should take
+ownership of a selection for each one.
+</para>
+<para>
+The manager may support conversion of various targets
+for that selection.  Managers are encouraged to use this
+technique as the primary means by which clients interact
+with the managed resource.  Note that the conventions for
+interacting with the window manager predate this section;
+as a result many interactions with the window manager use
+other techniques.
+</para>
+<para>
+Before a manager takes ownership of a manager selection, it
+should use the
+<function>GetSelectionOwner</function>
+request to check whether the selection is already owned by another client,
+and, where appropriate, it should ask the user if the new manager should
+replace the old one.  If so, it may then take ownership of the selection.
+Managers should acquire the selection using a window created expressly for
+this purpose.  Managers must conform to the rules for selection owners
+described in
+<link linkend="acquiring_selection_ownership">
+<xref linkend="acquiring_selection_ownership"></xref></link>
+and
+<link linkend="responsibilities_of_the_selection_owner">
+<xref linkend="responsibilities_of_the_selection_owner"></xref></link>
+, and they must also support the required
+targets listed in
+<link linkend="use_of_selection_atoms">
+<xref linkend="use_of_selection_atoms"></xref></link>.
+</para>
+
+<para>
+If a manager loses ownership of a manager selection, this
+means that a new manager is taking over its responsibilities.
+The old manager must release all resources it has managed
+and must then destroy the window that owned the selection.
+For example, a window manager losing ownership of WM_S2
+must deselect from
+<function>SubstructureRedirect</function>
+on the root window of screen 2 before destroying the window that owned
+WM_S2.
+</para>
+
+<para>
+When the new manager notices that the window owning the selection
+has been destroyed, it knows that it can successfully proceed to
+control the resource it is planning to manage.  If the old
+manager does not destroy the window within a reasonable time,
+the new manager should check with the user before destroying
+the window itself or killing the old manager.
+</para>
+<para>
+<!-- .LP -->
+If a manager wants to give up, on its own, management of a shared
+resource controlled by a selection, it must do so by releasing
+the resources it is managing and then by destroying the
+window that owns the selection.  It should not first disown
+the selection, since this introduces a race condition.
+</para>
+<para>
+<!-- .LP -->
+Clients who are interested in knowing when the owner of a
+manager selection is no longer managing the corresponding shared
+resource should select for
+<function>StructureNotify</function>
+on the window owning the selection so they can be notified when the window
+is destroyed.  Clients are warned that after doing a
+<function>GetSelectionOwner</function>
+and selecting for
+<function>StructureNotify</function>,
+they should do a
+<function>GetSelectionOwner</function>
+again to ensure that the owner did not change after initially getting the
+selection owner and before selecting for
+<function>StructureNotify</function>.
+</para>
+
+<para>
+Immediately after a manager successfully acquires ownership of a
+manager selection, it should announce its arrival by sending a
+<function>ClientMessage</function>
+event.  This event should be sent using the
+<function>SendEvent</function>
+protocol request with the following arguments:
+</para>
+
+<!-- .br -->
+<!-- .ne 6 -->
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row>
+      <entry namest="c1" nameend="c2">Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">destination:</entry>
+      <entry>
+the root window of screen 0, or the root
+window of the appropriate screen if the
+manager is managing a screen-specific resource</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">propogate:</entry>
+      <entry>False</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">event-mask:</entry>
+      <entry><function>StructureNotify</function></entry>
+    </row>
+    <row rowsep="0">
+      <entry>event:</entry>
+      <entry></entry>
+      <entry><function>ClientMessage</function></entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>type:</entry>
+      <entry>MANAGER</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>format:</entry>
+      <entry>32</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[0]
+<footnote>
+<para>
+We use the notation data[n] to indicate the n
+<superscript>th</superscript> element
+of the LISTofINT8, LISTofINT16, or LISTofINT32 in the data field of the
+<function>ClientMessage</function>,
+according to the format field.
+The list is indexed from zero.
+</para>
+</footnote>
+      </entry>
+      <entry>timestamp</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[1]:</entry>
+      <entry>manager selection atom</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[2]:</entry>
+      <entry>the window owning the selection</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[3]:</entry>
+      <entry>manager-selection-specific data</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[4]:</entry>
+      <entry>manager-selection-specific data</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Clients that wish to know when a specific manager has started should
+select for
+<function>StructureNotify</function>
+on the appropriate root window and should watch for the appropriate MANAGER
+<function>ClientMessage</function>.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="peer_to_peer_communication_by_means_of_cut_buffers">
+<title>Peer-to-Peer Communication by Means of Cut Buffers</title>
+<para>
+The cut buffer mechanism is much simpler but much less powerful
+than the selection mechanism.
+The selection mechanism is active in that it provides a link
+between the owner and requestor clients.
+The cut buffer mechanism is passive;
+an owner places data in a cut buffer from which a requestor retrieves
+the data at some later time.
+</para>
+
+<para>
+The cut buffers consist of eight properties on the root of screen zero,
+named by the predefined atoms CUT_BUFFER0 to CUT_BUFFER7.
+These properties must, at present, have type STRING and format 8.
+A client that uses the cut buffer mechanism must initially ensure that
+all eight properties exist by using
+<function>ChangeProperty </function>
+requests to append zero-length data to each.
+</para>
+
+<para>
+A client that stores data in the cut buffers (an owner) first must rotate the
+ring of buffers by plus 1 by using
+<function>RotateProperties</function>
+requests to rename each buffer;
+that is, CUT_BUFFER0 to CUT_BUFFER1, CUT_BUFFER1 to CUT_BUFFER2, ...,
+and CUT_BUFFER7 to CUT_BUFFER0.
+It then must store the data into CUT_BUFFER0 by using a
+<function>ChangeProperty</function>
+request in mode
+<function>Replace</function>.
+</para>
+
+<para>
+A client that obtains data from the cut buffers should use a
+<function>GetProperty </function>
+request to retrieve the contents of CUT_BUFFER0.
+</para>
+
+<para>
+In response to a specific user request,
+a client may rotate the cut buffers by minus 1 by using
+<function>RotateProperties </function>
+requests to rename each buffer;
+that is, CUT_BUFFER7 to CUT_BUFFER6, CUT_BUFFER6 to CUT_BUFFER5, ...,
+and CUT_BUFFER0 to CUT_BUFFER7.
+</para>
+
+<para>
+Data should be stored to the cut buffers
+and the ring rotated only when requested by explicit user action.
+Users depend on their mental model of cut buffer operation
+and need to be able to identify operations that transfer data to and fro.
+</para>
+</sect1>
+
+<sect1 id="client_to_window_manager_communication">
+<title>Client-to-Window-Manager Communication</title>
+<para>
+To permit window managers to perform their role of mediating the competing
+demands for resources such as screen space,
+the clients being managed must adhere to certain conventions
+and must expect the window managers to do likewise.
+These conventions are covered here from the client's point of view.
+</para>
+<para>
+In general,
+these conventions are somewhat complex
+and will undoubtedly change as new window management paradigms are developed.
+Thus, there is a strong bias toward defining only those conventions
+that are essential and that apply generally to all window management paradigms.
+Clients designed to run with a particular window manager can easily
+define private protocols to add to these conventions,
+but they must be aware that their users may decide to run some other
+window manager no matter how much the designers of the private protocol
+are convinced that they have seen the "one true light" of user interfaces.
+</para>
+<para>
+It is a principle of these conventions that a general client should
+neither know nor care which window manager is running or, indeed,
+if one is running at all.
+The conventions do not support all client functions
+without a window manager running;
+for example, the concept of Iconic
+is not directly supported by clients.
+If no window manager is running,
+the concept of Iconic does not apply.
+A goal of the conventions is to make it possible to kill and
+restart window managers without loss of functionality.
+</para>
+<para>
+Each window manager will implement a particular window management policy;
+the choice of an appropriate window management policy
+for the user's circumstances is not one for an individual client to
+make but will be made by the user or the user's system administrator.
+This does not exclude the possibility of writing clients that
+use a private protocol to restrict themselves to operating only
+under a specific window manager.
+Rather,
+it merely ensures that no claim of general utility is made for such programs.
+</para>
+
+<para>
+For example,
+the claim is often made:
+"The client I'm writing is important, and it needs to be on top."
+Perhaps it is important when it is being run in earnest,
+and it should then be run under the control of a window manager
+that recognizes "important" windows through some private protocol
+and ensures that they are on top.
+However, imagine, for example, that the "important" client is being debugged.
+Then,  ensuring that it is always on top is no longer
+the appropriate window management policy,
+and it should be run under a window manager that allows other windows
+(for example, the debugger) to appear on top.
+</para>
+
+<sect2 id="clients_ctions">
+<title>Client's Actions</title>
+<para>
+In general,
+the object of the X Version 11 design is that clients should,
+as far as possible, do exactly what they would do in the absence
+of a window manager, except for the following:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Hinting to the window manager about the resources they would like
+to obtain
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Cooperating with the window manager by accepting the resources they
+are allocated even if they are not those requested
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Being prepared for resource allocations to change at any time
+    </para>
+  </listitem>
+</itemizedlist>
+
+<sect3 id="creating_a_top_level_window">
+<title>Creating a Top-Level Window</title>
+<para>
+A client's
+<emphasis remap='I'>top-level window</emphasis> is a window whose
+override-redirect attribute is
+<function>False</function>.
+It must either be a child of a root window, or it must have been a child of
+a root window immediately prior to having been reparented by the window
+manager.  If the client reparents the window away from the root, the window
+is no longer a top-level window; but it can become a top-level window again
+if the client reparents it back to the root.
+</para>
+<para>
+A client usually would expect to create its top-level windows
+as children of one or more of the root windows by using some
+boilerplate like the following:
+</para>
+
+<literallayout class="monospaced">
+win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), xsh.x, xsh.y,
+     xsh.width, xsh.height, bw, bd, bg);
+</literallayout>
+
+<para>
+If a particular one of the root windows was required, however,
+it could use something like the following:
+</para>
+
+<literallayout class="monospaced">
+win = XCreateSimpleWindow(dpy, RootWindow(dpy, screen), xsh.x, xsh.y,
+     xsh.width, xsh.height, bw, bd, bg);
+</literallayout>
+
+<para>
+Ideally,
+it should be possible to override the choice of a root window
+and allow clients (including window managers) to treat a nonroot window
+as a pseudo-root.
+This would allow, for example, the testing of window managers and the
+use of application-specific window managers to control the subwindows
+owned by the members of a related suite of clients.
+Doing so properly requires an extension,
+the design of which is under study.
+</para>
+
+<para>
+From the client's point of view,
+the window manager will regard its top-level window as being in
+one of three states:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Normal
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Iconic
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Withdrawn
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Newly created windows start in the Withdrawn state.
+Transitions between states happen when the top-level window is mapped
+and unmapped and when the window manager receives certain messages.
+For further details, see
+<link linkend="wm_hints_property">
+<xref linkend="wm_hints_property"></xref></link>.
+ and
+<link linkend="changing_window_state">
+<xref linkend="changing_window_state"></xref></link>.
+</para>
+</sect3>
+
+<sect3 id="client_properties">
+<title>Client Properties</title>
+<para>
+Once the client has one or more top-level windows,
+it should place properties on those windows to inform the window manager
+of the behavior that the client desires.
+Window managers will assume values they find convenient
+for any of these properties that are not supplied;
+clients that depend on particular values must explicitly supply them.
+The window manager will not change properties written by the client.
+</para>
+<para>
+The window manager will examine the contents of these
+properties when the window makes the transition from the Withdrawn state
+and will monitor some properties for changes while the window is
+in the Iconic or Normal state.
+When the client changes one of these properties,
+it must use
+<function>Replace</function>
+mode to overwrite the entire property with new data;
+the window manager will retain no memory of the old value of the property.
+All fields of the property must be set to suitable values in a single
+<function>Replace</function>
+mode <function>ChangeProperty</function>
+request.
+This ensures that the full contents of the property will be
+available to a new window manager if the existing one crashes,
+if it is shut down and restarted,
+or if the session needs to be shut down and restarted by the session manager.
+</para>
+
+<blockquote><title>Convention</title>
+<para>
+Clients writing or rewriting window manager properties must
+ensure that the entire content of each property remains valid
+at all times.
+</para>
+</blockquote>
+
+<para>
+Some of these properties may contain the IDs of resources, such as
+windows or pixmaps.  Clients should ensure that these resources exist
+for at least as long as the window on which the property resides.
+</para>
+<para>
+If these properties are longer than expected,
+clients should ignore the remainder of the property.
+Extending these properties is reserved to the X Consortium;
+private extensions to them are forbidden.
+Private additional communication between clients and window managers
+should take place using separate properties.
+The only exception to this rule is the WM_PROTOCOLS property, which may be
+of arbitrary length and which may contain atoms representing private
+protocols (see
+<link linkend="wm_protocols_property">
+<xref linkend="wm_protocols_property"></xref></link>
+).
+</para>
+
+<para>
+The next sections describe each of the properties the clients
+need to set, in turn.
+They are summarized in the table in
+<link linkend="summary_of_window_manager_property_types">
+<xref linkend="summary_of_window_manager_property_types"></xref></link>
+
+</para>
+
+<sect4 id="wm_name_property">
+<title>WM_NAME Property</title>
+<para>
+The WM_NAME property is an uninterpreted string
+that the client wants the window manager to display
+in association with the window (for example, in a window headline bar).
+</para>
+<para>
+The encoding used for this string
+(and all other uninterpreted string properties)
+is implied by the type of the property.
+The type atoms to be used for this purpose are described in
+<link linkend="text_properties">
+<xref linkend="text_properties"></xref></link>.
+</para>
+
+<para>
+Window managers are expected to make an effort to display this information.
+Simply ignoring WM_NAME is not acceptable behavior.
+Clients can assume that at least the first part of this string
+is visible to the user and that if the information is not visible to the user,
+it is because the user has taken an explicit action to make it invisible.
+</para>
+
+<para>
+On the other hand,
+there is no guarantee that the user can see the WM_NAME string
+even if the window manager supports window headlines.
+The user may have placed the headline off-screen
+or have covered it by other windows.
+WM_NAME should not be used for application-critical information
+or to announce asynchronous changes of an application's state
+that require timely user response.
+The expected uses are to permit the user to identify one of a
+number of instances of the same client
+and to provide the user with noncritical state information.
+</para>
+
+<para>
+Even window managers that support headline bars will place some limit
+on the length of the WM_NAME string that can be visible;
+brevity here will pay dividends.
+</para>
+</sect4>
+
+<sect4 id="wm_icon_name_property">
+<title>WM_ICON_NAME Property</title>
+<para>
+The WM_ICON_NAME property is an uninterpreted string
+that the client wants to be displayed in association with the window
+when it is iconified (for example, in an icon label).
+In other respects,
+including the type, it is similar to WM_NAME.
+For obvious geometric reasons,
+fewer characters will normally be visible in WM_ICON_NAME than WM_NAME.
+</para>
+
+<para>
+Clients should not attempt to display this string in their icon pixmaps
+or windows; rather, they should rely on the window manager to do so.
+</para>
+</sect4>
+
+<sect4 id="wm_normal_hints_property">
+<title>WM_NORMAL_HINTS Property</title>
+<para>
+The type of the WM_NORMAL_HINTS property is WM_SIZE_HINTS.
+Its contents are as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>flags</entry>
+      <entry>CARD32</entry>
+      <entry>(see the next table)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>pad</entry>
+      <entry>4*CARD32</entry>
+      <entry>For backwards compatibility</entry>
+    </row>
+    <row rowsep="0">
+      <entry>min_width</entry>
+      <entry>INT32</entry>
+      <entry>If missing, assume base_width</entry>
+    </row>
+    <row rowsep="0">
+      <entry>min_height</entry>
+      <entry>INT32</entry>
+      <entry>If missing, assume base_height</entry>
+    </row>
+    <row rowsep="0">
+      <entry>max_width</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>max_height</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>width_inc</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>height_inc</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>min_aspect</entry>
+      <entry>(INT32,INT32)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>max_aspect</entry>
+      <entry>(INT32,INT32)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>base_width</entry>
+      <entry>INT32</entry>
+      <entry>If missing, assume min_width</entry>
+    </row>
+    <row rowsep="0">
+      <entry>base_height</entry>
+      <entry>INT32</entry>
+      <entry>If missing, assume min_height</entry>
+    </row>
+    <row rowsep="0">
+      <entry>win_gravity</entry>
+      <entry>INT32</entry>
+      <entry>If missing, assume <function>NorthWest</function></entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The WM_SIZE_HINTS.flags bit definitions are as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Name</entry>
+      <entry>Value</entry>
+      <entry>Field</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry><function>USPosition</function></entry>
+      <entry>1</entry>
+      <entry>User-specified x, y</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>USSize</function></entry>
+      <entry>2</entry>
+      <entry>User-specified width, height</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PPosition</function></entry>
+      <entry>4</entry>
+      <entry>Program-specified position</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PSize</function></entry>
+      <entry>8</entry>
+      <entry>Program-specified size</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PMinSize</function></entry>
+      <entry>16</entry>
+      <entry>Program-specified minimum size</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PMaxSize</function></entry>
+      <entry>32</entry>
+      <entry>Program-specified maximum size</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PResizeInc</function></entry>
+      <entry>64</entry>
+      <entry>Program-specified resize increments</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PAspect</function></entry>
+      <entry>128</entry>
+      <entry>Program-specified min and max aspect ratios</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PBaseSize</function></entry>
+      <entry>256</entry>
+      <entry>Program-specified base size</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>PWinGravity</function></entry>
+      <entry>512</entry>
+      <entry>Program-specified window gravity</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+To indicate that the size and position of the window
+(when a transition from the Withdrawn state occurs) was specified by the user,
+the client should set the
+<function>USPosition</function>
+and
+<function>USSize</function>
+flags,
+which allow a window manager to know that the user specifically asked where
+the window should be placed or how the window should be sized and that
+further interaction is superfluous.
+To indicate that it was specified by the client without any user involvement,
+the client should set
+<function>PPosition</function>
+and
+<function>PSize .</function>
+</para>
+
+<para>
+The size specifiers refer to the width and height of the client's
+window excluding borders.
+</para>
+
+<para>
+The win_gravity may be any of the values specified for WINGRAVITY in
+the core protocol except for
+<function>Unmap</function>:
+<function>NorthWest </function>
+(1),
+<function>North </function>
+(2),
+<function>NorthEast </function>
+(3),
+<function>West </function>
+(4),
+<function>Center</function>
+(5),
+<function>East</function>
+(6),
+<function>SouthWest</function>
+(7),
+<function>South</function>
+(8), and
+<function>SouthEast</function>
+(9).  It specifies how and whether the client window wants to be shifted to
+make room for the window manager frame.
+</para>
+
+<para>
+If the win_gravity is
+<function>Static</function>,
+the window manager frame is positioned
+so that the inside border of the client window inside the frame is
+in the same position on the screen as it was when the client
+requested the transition from Withdrawn state.  Other values of
+win_gravity specify a window reference point.  For
+<function>NorthWest</function>,
+<function>NorthEast</function>,
+<function>SouthWest</function>,
+and
+<function>SouthEast</function>
+the reference point is the specified outer corner of the window (on the
+outside border edge).  For
+<function>North</function>,
+<function>South</function>,
+<function>East</function>
+and
+<function>West</function>
+the reference point is the center of the specified outer edge of the window
+border.  For
+<function>Center</function>
+the reference point is the center of the window.  The reference point of the
+window manager frame is placed at the location on the screen where the
+reference point of the client window was when the client requested the
+transition from Withdrawn state.
+</para>
+
+<para>
+The min_width and min_height elements specify the
+minimum size that the window can be for the client to be useful.
+The max_width and max_height elements specify the maximum size.
+The base_width and base_height elements in conjunction with width_inc
+and height_inc define an arithmetic progression of preferred window
+widths and heights for non-negative integers
+<emphasis remap='I'>i</emphasis> and <emphasis remap='I'>j</emphasis>:
+</para>
+
+<literallayout class="monospaced">
+width = base_width + ( i x width_inc )
+
+height = base_height + ( j x height_inc )
+</literallayout>
+
+<para>
+Window managers are encouraged to use
+<emphasis remap='I'>i</emphasis> and <emphasis remap='I'>j</emphasis>
+instead of width and height in reporting window sizes to users.
+If a base size is not provided,
+the minimum size is to be used in its place and vice versa.
+</para>
+
+<para>
+The min_aspect and max_aspect fields are fractions with the numerator first
+and the denominator second, and they allow a client to specify the range of
+aspect ratios it prefers.  Window managers that honor aspect ratios should
+take into account the base size in determining the preferred window size.  If
+a base size is provided along with the aspect ratio fields, the base size
+should be subtracted from the window size prior to checking that the aspect
+ratio falls in range.  If a base size is not provided, nothing should be
+subtracted from the window size.  (The minimum size is not to be used in
+place of the base size for this purpose.)
+</para>
+</sect4>
+
+<sect4 id="wm_hints_property">
+<title>WM_HINTS Property</title>
+<para>
+The WM_HINTS property (whose type is WM_HINTS)
+is used to communicate to the window manager.
+It conveys the information the window manager needs
+other than the window geometry,
+which is available from the window itself;
+the constraints on that geometry,
+which is available from the WM_NORMAL_HINTS structure;
+and various strings,
+which need separate properties, such as WM_NAME.
+The contents of the properties are as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>flags</entry>
+      <entry>CARD32</entry>
+      <entry>(see the next table)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>input</entry>
+      <entry>CARD32</entry>
+      <entry>The client's input model</entry>
+    </row>
+    <row rowsep="0">
+      <entry>initial_state</entry>
+      <entry>CARD32</entry>
+      <entry>The state when first mapped</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon_pixmap</entry>
+      <entry>PIXMAP</entry>
+      <entry>The pixmap for the icon image</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon_window</entry>
+      <entry>WINDOW</entry>
+      <entry>The window for the icon image</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon_x</entry>
+      <entry>INT32</entry>
+      <entry>The icon location</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon_y</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon_mask</entry>
+      <entry>PIXMAP</entry>
+      <entry>The mask for the icon shape</entry>
+    </row>
+    <row rowsep="0">
+      <entry>window_group</entry>
+      <entry>WINDOW</entry>
+      <entry>The ID of the group leader window</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The WM_HINTS.flags bit definitions are as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Name</entry>
+      <entry>Value</entry>
+      <entry>Field</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row>
+      <entry><function>InputHint</function></entry>
+      <entry>1</entry>
+      <entry>input</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>StateHint</function></entry>
+      <entry>2</entry>
+      <entry>initial_state</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>IconPixmapHint</function></entry>
+      <entry>4</entry>
+      <entry>icon_pixmap</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>IconWindowHint</function></entry>
+      <entry>8</entry>
+      <entry>icon_window</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>IconPositionHint</function></entry>
+      <entry>16</entry>
+      <entry>icon_x &amp; icon_y</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>IconMaskHint</function></entry>
+      <entry>32</entry>
+      <entry>icon_mask</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>WindowGroupHint</function></entry>
+      <entry>64</entry>
+      <entry>window_group</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>MessageHint</function></entry>
+      <entry>128</entry>
+      <entry>(this bit is obsolete)</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>UrgencyHint</function></entry>
+      <entry>256</entry>
+      <entry>urgency</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Window managers are free to assume convenient values for all fields of
+the WM_HINTS property if a window is mapped without one.
+</para>
+
+<para>
+The input field is used to communicate to the window manager the input focus
+model used by the client (see
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>
+).
+</para>
+
+<para>
+Clients with the Globally Active and No Input models should set the
+input flag to
+<function>False .</function>
+Clients with the Passive and Locally Active models should set the input
+flag to
+<function>True .</function>
+</para>
+
+<para>
+From the client's point of view,
+the window manager will regard the client's top-level window as being
+in one of three states:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Normal
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Iconic
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Withdrawn
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The semantics of these states are described in
+<link linkend="changing_window_state">
+<xref linkend="changing_window_state"></xref></link>.
+Newly created windows start in the Withdrawn state.
+Transitions between states happen when a
+top-level window is mapped and unmapped
+and when the window manager receives certain messages.
+</para>
+
+<para>
+The value of the initial_state field determines the state the client
+wishes to be in at the time the top-level window is mapped
+from the Withdrawn state, as shown in the following table:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>State</entry>
+      <entry>Value</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>NormalState</entry>
+      <entry>1</entry>
+      <entry>The window is visible</entry>
+    </row>
+    <row rowsep="0">
+      <entry>IconicState</entry>
+      <entry>3</entry>
+      <entry>The icon is visible</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The icon_pixmap field may specify a pixmap to be used as an icon.
+This pixmap should be:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+One of the sizes specified in the WM_ICON_SIZE property
+on the root if it exists (see
+<link linkend="wm_icon_size_property">
+<xref linkend="wm_icon_size_property"></xref></link>
+).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+1-bit deep.
+The window manager will select, through the defaults database,
+suitable background (for the 0 bits) and foreground (for the 1 bits) colors.
+These defaults can, of course, specify different colors for the icons
+of different clients.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The icon_mask specifies which pixels of the icon_pixmap should be used as the
+icon, allowing for icons to appear nonrectangular.
+</para>
+<para>
+The icon_window field is the ID of a window the client wants used as its icon.
+Most, but not all, window managers will support icon windows.
+Those that do not are likely to have a user interface in which small
+windows that behave like icons are completely inappropriate.
+Clients should not attempt to remedy the omission by working around it.
+</para>
+<para>
+Clients that need more capabilities from the icons than a simple 2-color
+bitmap should use icon windows.
+Rules for clients that do are set out in
+<link linkend="icons">
+<xref linkend="icons"></xref></link>.
+</para>
+
+<para>
+The (icon_x,icon_y) coordinate is a hint to the window manager
+as to where it should position the icon.
+The policies of the window manager control the positioning of icons,
+so clients should not depend on attention being paid to this hint.
+</para>
+
+<para>
+The window_group field lets the client specify that this window belongs
+to a group of windows.
+An example is a single client manipulating multiple
+children of the root window.
+</para>
+
+<blockquote>
+<title>Conventions</title>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The window_group field should be set to the ID of the group leader.
+The window group leader may be a window that exists only for that purpose;
+a placeholder group leader of this kind would never be mapped
+either by the client or by the window manager.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The properties of the window group leader are those for the group as
+a whole (for example, the icon to be shown when the entire group is iconified).
+<!-- .NE -->
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+<para>
+Window managers may provide facilities for manipulating the group as a whole.
+Clients, at present, have no way to operate on the group as a whole.
+</para>
+
+<para>
+The messages bit, if set in the flags field, indicates that the
+client is using an obsolete window manager communication protocol,
+<footnote>
+<para>
+This obsolete protocol was described in the July 27, 1988,
+draft of the ICCCM.
+Windows using it can also be detected because their WM_HINTS properties are
+4 bytes longer than expected.
+Window managers are free to support clients using the obsolete protocol
+in a backwards compatibility mode.
+</para>
+</footnote>
+rather than the WM_PROTOCOLS mechanism of
+<link linkend="wm_protocols_property">
+<xref linkend="wm_protocols_property"></xref></link>
+</para>
+
+<para>
+The
+<function>UrgencyHint</function>
+flag, if set in the flags field, indicates that the client deems the window
+contents to be urgent, requiring the timely response of the user.  The
+window manager must make some effort to draw the user's attention to this
+window while this flag is set.  The window manager must also monitor the
+state of this flag for the entire time the window is in the Normal or Iconic
+state and must take appropriate action when the state of the flag changes.
+The flag is otherwise independent of the window's state; in particular, the
+window manager is not required to deiconify the window if the client sets
+the flag on an Iconic window.  Clients must provide some means by which the
+user can cause the
+<function>UrgencyHint</function>
+flag to be set to zero or the window to be withdrawn.  The user's action can
+either mitigate the actual condition that made the window urgent, or it can
+merely shut off the alarm.
+</para>
+
+<blockquote><title>Rationale</title>
+<para>
+This mechanism is useful for alarm dialog boxes or reminder windows, in
+cases where mapping the window is not enough (e.g., in the presence of
+multi-workspace or virtual desktop window managers), and where using an
+override-redirect window is too intrusive.  For example, the window manager
+may attract attention to an urgent window by adding an indicator to its
+title bar or its icon.  Window managers may also take additional action
+for a window that is newly urgent, such as by flashing its icon (if the
+window is iconic) or by raising it to the top of the stack.
+</para>
+</blockquote>
+</sect4>
+
+<sect4 id="wm_class_property">
+<title>WM_CLASS Property</title>
+<para>
+The WM_CLASS property (of type STRING without control characters)
+contains two consecutive null-terminated strings.
+These specify the Instance and Class names to be used by both the client
+and the window manager for looking up resources for the application
+or as identifying information.
+This property must be present when the window leaves the Withdrawn state
+and may be changed only while the window is in the Withdrawn state.
+Window managers may examine the property only when they start up
+and when the window leaves the Withdrawn state,
+but there should be no need for a client to change its state dynamically.
+</para>
+<para>
+The two strings, respectively, are:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+A string that names the particular instance of the application to which
+the client that owns this window belongs.
+Resources that are specified by instance name override any resources
+that are specified by class name.
+Instance names can be specified by the user in an operating-system specific
+manner.
+On POSIX-conformant systems,
+the following conventions are used:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+If "-name NAME" is given on the command line,
+NAME is used as the instance name.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Otherwise, if the environment variable RESOURCE_NAME is set,
+its value will be used as the instance name.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Otherwise, the trailing part of the name used to invoke the program
+(argv[0] stripped of any directory names) is used as the instance name.
+        </para>
+      </listitem>
+    </itemizedlist>
+  </listitem>
+  <listitem>
+    <para>
+A string that names the general class of applications to which the client
+that owns this window belongs.
+Resources that are specified by class apply to all applications
+that have the same class name.
+Class names are specified by the application writer.
+Examples of commonly used class names include:
+"Emacs", "XTerm", "XClock", "XLoad", and so on.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Note that WM_CLASS strings are null-terminated
+and, thus, differ from the general conventions that STRING properties
+are null-separated.
+This inconsistency is necessary for backwards compatibility.
+</para>
+</sect4>
+
+<sect4 id="wm_transient_for_property">
+<title>WM_TRANSIENT_FOR Property</title>
+<para>
+The WM_TRANSIENT_FOR property (of type WINDOW)
+contains the ID of another top-level window.
+The implication is that this window is a pop-up on behalf of the named window,
+and window managers may decide not to decorate transient windows
+or may treat them differently in other ways.
+In particular,
+window managers should present newly mapped WM_TRANSIENT_FOR
+windows without requiring any user interaction,
+even if mapping top-level windows normally does require interaction.
+Dialogue boxes, for example, are an example of windows that should have
+WM_TRANSIENT_FOR set.
+</para>
+
+<para>
+It is important not to confuse WM_TRANSIENT_FOR with override-redirect.
+WM_TRANSIENT_FOR should be used in those cases where the pointer
+is not grabbed while the window is mapped (in other words,
+if other windows are allowed to be active while the transient is up).
+If other windows must be prevented from processing input
+(for example, when implementing pop-up menus),
+use override-redirect and grab the pointer while the window is mapped.
+</para>
+</sect4>
+
+<sect4 id="wm_protocols_property">
+<title>WM_PROTOCOLS Property</title>
+<para>
+The WM_PROTOCOLS property (of type ATOM) is a list of atoms.
+Each atom identifies a communication protocol between the client
+and the window manager in which the client is willing to participate.
+Atoms can identify both standard protocols and private protocols
+specific to individual window managers.
+</para>
+<para>
+All the protocols in which a client can volunteer to take part
+involve the window manager sending the client a
+<function>ClientMessage</function>
+event and the client taking appropriate action.
+For details of the contents of the event,
+see
+<link linkend="clientmessage_events">
+<xref linkend="clientmessage_events"></xref></link>
+In each case,
+the protocol transactions are initiated by the window manager.
+</para>
+<para>
+The WM_PROTOCOLS property is not required.
+If it is not present,
+the client does not want to participate in any window manager protocols.
+</para>
+<para>
+The X Consortium will maintain a registry of protocols to avoid collisions
+in the name space.
+The following table lists the protocols that have been defined to date.
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row>
+      <entry>Protocol</entry>
+      <entry>Section</entry>
+      <entry>Purpose</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>WM_TAKE_FOCUS</entry>
+      <entry>
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>
+      </entry>
+      <entry>Assignment of input focus</entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_SAVE_YOURSELF</entry>
+      <entry>Appendix C</entry>
+      <entry>Save client state request (deprecated)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_DELETE_WINDOW</entry>
+      <entry>
+<link linkend="window_deletion">
+<xref linkend="window_deletion"></xref></link>
+      </entry>
+      <entry>Request to delete top-level window</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+It is expected that this table will grow over time.
+</para>
+</sect4>
+
+<sect4 id="wm_colormap_windows_property">
+<title>WM_COLORMAP_WINDOWS Property</title>
+<para>
+The WM_COLORMAP_WINDOWS property (of type WINDOW) on a top-level window
+is a list of the IDs of windows that may need colormaps installed
+that differ from the colormap of the top-level window.
+The window manager will watch this list of windows for changes in their
+colormap attributes.
+The top-level window is always (implicitly or explicitly) on the watch list.
+For the details of this mechanism,
+see
+<link linkend="colormaps">
+<xref linkend="colormaps"></xref></link>
+</para>
+</sect4>
+
+<sect4 id="wm_client_machine_property">
+<title>WM_CLIENT_MACHINE Property</title>
+<para>
+The client should set the WM_CLIENT_MACHINE property (of one of the TEXT
+types) to a string that forms the name of the machine running the client as
+seen from the machine running the server.
+</para>
+</sect4>
+</sect3>
+
+<sect3 id="window_manager_properties">
+<title>Window Manager Properties</title>
+<para>
+The properties that were described in the previous section are those
+that the client is responsible for maintaining on its top-level windows.
+This section describes the properties that the window manager places on
+client's top-level windows and on the root.
+</para>
+
+<sect4 id="wm_state_property">
+<title>WM_STATE Property</title>
+<para>
+The window manager will place a WM_STATE property (of type WM_STATE) on each
+top-level client window that is not in the Withdrawn state.  Top-level
+windows in the Withdrawn state may or may not have the WM_STATE property.
+Once the top-level window has been withdrawn, the client may re-use it for
+another purpose.  Clients that do so should remove the WM_STATE property if
+it is still present.
+</para>
+<para>
+
+Some clients (such as <function>xprop</function>) will ask the user to
+click over a window
+on which the program is to operate.  Typically, the intent is for this to be
+a top-level window.  To find a top-level window, clients should search the
+window hierarchy beneath the selected location for a window with the
+WM_STATE property.  This search must be recursive in order to cover all
+window manager reparenting possibilities.  If no window with a WM_STATE
+property is found, it is recommended that programs use a mapped
+child-of-root window if one is present beneath the selected location.
+</para>
+
+<para>
+The contents of the WM_STATE property are defined as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row>
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>state</entry>
+      <entry>CARD32</entry>
+      <entry>(see the next table)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>icon</entry>
+      <entry>WINDOW</entry>
+      <entry>ID of icon window</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The following table lists the WM_STATE.state values:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row>
+      <entry>State</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>WithdrawnState</entry>
+      <entry>0</entry>
+    </row>
+    <row rowsep="0">
+      <entry>NormalState</entry>
+      <entry>1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>IconicState</entry>
+      <entry>3</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Adding other fields to this property is reserved to the X Consortium.
+Values for the state field other than those defined in the above
+table are reserved for use by the X Consortium.
+</para>
+<para>
+<!-- .LP -->
+The state field describes the window manager's idea of the state
+the window is in, which may not match the client's idea as expressed
+in the initial_state field of the WM_HINTS property
+(for example, if the user has asked the window manager to iconify the window).
+If it is
+<function>NormalState ,</function>
+the window manager believes the client should be animating its window.
+If it is
+<function>IconicState ,</function>
+the client should animate its icon window.
+In either state,
+clients should be prepared to handle exposure events from either window.
+</para>
+<para>
+<!-- .LP -->
+When the window is withdrawn, the window manager will either change the
+state field's value to
+<function>WithdrawnState</function>
+or it will remove the WM_STATE property entirely.
+</para>
+<para>
+<!-- .LP -->
+The icon field should contain the window ID of the window that the
+window manager uses as the icon for the window on which this property is
+set.  If no such window exists, the icon field should be
+<function>None .</function>
+Note that this window could be but is not necessarily the same window as the
+icon window that the client may have specified in its WM_HINTS property.
+The WM_STATE icon may be a window that the window manager has supplied and
+that contains the client's icon pixmap, or it may be an ancestor of the
+client's icon window.
+</para>
+</sect4>
+
+<sect4 id="wm_icon_size_property">
+<title>WM_ICON_SIZE Property</title>
+<para>
+A window manager that wishes to place constraints on the sizes of icon
+pixmaps and/or windows should place a property called WM_ICON_SIZE on the root.
+The contents of this property are listed in the following table.
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>min_width</entry>
+      <entry>CARD32</entry>
+      <entry>The data for the icon size series</entry>
+    </row>
+    <row rowsep="0">
+      <entry>min_height</entry>
+      <entry>CARD32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>max_width</entry>
+      <entry>CARD32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>max_height</entry>
+      <entry>CARD32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>width_inc</entry>
+      <entry>CARD32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>height_inc</entry>
+      <entry>CARD32</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+For more details see section 14.1.12 in  <!-- xref -->
+<emphasis remap='I'>Xlib - C Language X Interface</emphasis>.
+</para>
+</sect4>
+</sect3>
+
+<sect3 id="changing_window_state">
+<title>Changing Window State</title>
+<para>
+From the client's point of view,
+the window manager will regard each of the client's top-level
+windows as being in one of three states,
+whose semantics are as follows:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+<function>NormalState</function>
+- The client's top-level window is viewable.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>IconicState</function>
+- The client's top-level window is iconic
+(whatever that means for this window manager).
+The client can assume that its top-level window is not viewable,
+its icon_window (if any) will be viewable
+and, failing that,
+its icon_pixmap (if any) or its WM_ICON_NAME will be displayed.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>WithdrawnState</function>
+- Neither the client's top-level window nor its icon is visible.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In fact,
+the window manager may implement states with semantics
+other than those described above.
+For example,
+a window manager might implement a concept of an "inactive" state
+in which an infrequently used client's window would be represented
+as a string in a menu.
+But this state is invisible to the client,
+which would see itself merely as being in the Iconic state.
+</para>
+
+<para>
+Newly created top-level windows are in the Withdrawn state.
+Once the window has been provided with suitable properties,
+the client is free to change its state as follows:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Withdrawn -&gt; Normal - The client should map the window with
+WM_HINTS.initial_state being
+<function>NormalState</function>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Withdrawn -&gt; Iconic - The client should map the window with
+WM_HINTS.initial_state being
+<function>IconicState .</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Normal -&gt; Iconic - The client should send a
+<function>ClientMessage</function>
+event as described later in this section.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Normal -&gt; Withdrawn - The client should unmap the window and follow it
+with a synthetic
+<function>UnmapNotify</function>
+event as described later in this section.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Iconic -&gt; Normal - The client should map the window.
+The contents of WM_HINTS.initial_state are irrelevant in this case.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Iconic -&gt; Withdrawn - The client should unmap the window
+and follow it with a synthetic
+<function>UnmapNotify</function>
+event as described later in this section.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Only the client can effect a transition into or out of the Withdrawn
+state.
+Once a client's window
+has left the Withdrawn state,
+the window will be mapped if it is in the Normal state and the window will be
+unmapped if it is in the Iconic state.  Reparenting window managers
+must unmap the client's window when it is in the Iconic state, even if an
+ancestor window being unmapped renders the client's window unviewable.
+Conversely, if a reparenting window manager renders the client's window
+unviewable by unmapping an ancestor, the client's window is by definition in
+the Iconic state and must also be unmapped.
+</para>
+
+<blockquote><title>Advice to Implementors</title>
+<para>
+Clients can select for
+<function>StructureNotify</function>
+on their
+top-level windows to track transitions between Normal and Iconic states.
+Receipt of a
+<function>MapNotify</function>
+event will indicate a transition to the Normal state, and receipt of an
+<function>UnmapNotify</function>
+event will indicate a transition to the Iconic state.
+</para>
+</blockquote>
+
+<para>
+When changing the state of the window to Withdrawn, the client must (in
+addition to unmapping the window) send a synthetic
+<function>UnmapNotify</function>
+event by
+using a
+<function>SendEvent</function>
+request with the following arguments:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">destination</entry>
+      <entry>The root</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">propogate</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">event-mask</entry>
+      <entry>(<emphasis role="bold">SubstructureRedirect|SubstructureNotify</emphasis>)</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">
+event: an <function>UnmapNotify</function> with:
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>event:</entry>
+      <entry>The root</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>window:</entry>
+      <entry>The window itself</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>from-configure:</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<blockquote>
+<title>Rationale</title>
+<para>
+The reason for requiring the client to send a synthetic
+<function>UnmapNotify</function>
+event is to ensure that the window manager
+gets some notification of the client's desire to change state,
+even though the window may already be unmapped when the desire is expressed.
+</para>
+</blockquote>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+For compatibility with obsolete clients,
+window managers should trigger the transition to the Withdrawn state
+on the real
+<function>UnmapNotify</function>
+rather than waiting for the synthetic one.
+They should also trigger the transition if they receive a synthetic
+<function>UnmapNotify</function>
+on a window for which they have not yet received a real
+<function>UnmapNotify</function>.
+</para>
+</blockquote>
+
+<para>
+When a client withdraws a window,
+the window manager will then update or remove the WM_STATE
+property as described in
+<link linkend="wm_state_property">
+<xref linkend="wm_state_property"></xref></link>.
+Clients that want to re-use a client window (e.g., by mapping it again or
+reparenting it elsewhere) after withdrawing it must wait for the
+withdrawal to be complete before proceeding.  The preferred method for
+doing this is for clients to wait for the window manager to update or
+remove the WM_STATE property.
+<footnote><para>
+Earlier versions of these conventions prohibited clients from
+reading the WM_STATE property.  Clients operating under the earlier
+conventions used the technique of tracking
+<function>ReparentNotify</function>
+events to wait for the top-level window to be reparented back to the root
+window.  This is still a valid technique; however, it works only for
+reparenting window managers, and the WM_STATE technique is to be preferred.
+</para></footnote>
+</para>
+
+<para>
+If the transition is from the Normal to the Iconic state,
+the client should send a
+<function>ClientMessage </function>
+event to the root with:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Window == the window to be iconified
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Type
+<footnote>
+<para>
+The type field of the
+<function>ClientMessage </function>
+event (called the message_type field by Xlib) should not be confused with
+the code field of the event itself,
+which will have the value 33
+<function>( ClientMessage ).</function>
+</para>
+</footnote>
+== the atom WM_CHANGE_STATE
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Format == 32
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Data[0] == IconicState
+    </para>
+  </listitem>
+</itemizedlist>
+
+<blockquote><title>Rationale</title>
+<para>
+The format of this
+<function>ClientMessage </function>
+event does not match the format of
+<function>ClientMessages</function>
+in
+<link linkend="clientmessage_events">
+<xref linkend="clientmessage_events"></xref></link>.
+This is because they are sent by the window manager to clients,
+and this message is sent by clients to the window manager.
+</para>
+</blockquote>
+
+<para>
+Other values of data[0] are reserved for future extensions to these
+conventions.  The parameters of the
+<function>SendEvent </function>
+request should be those described for the synthetic
+<function>UnmapNotify</function>
+event.
+</para>
+
+<blockquote><title>Advice to Implementors</title>
+<para>
+Clients can also select for
+<function>VisibilityChange</function>
+events on their top-level or icon windows.
+They will then receive a
+<function>VisibilityNotify</function>
+(state==FullyObscured)
+event when the window concerned becomes completely
+obscured even though mapped (and thus, perhaps a waste
+of time to update) and a
+<function>VisibilityNotify</function>
+(state!=FullyObscured)
+event when it becomes even partly viewable.
+</para>
+</blockquote>
+
+<blockquote><title>Advice to Implementors</title>
+<para>
+When a window makes a transition from the Normal state to either the Iconic
+or the Withdrawn state, clients should be aware that the window manager
+may make transients for this window inaccessible.  Clients should not rely
+on transient windows being available to the user when the transient owner
+window is not in the Normal state.  When withdrawing a window, clients are
+advised to withdraw transients for the window.
+</para>
+</blockquote>
+
+</sect3>
+
+<sect3 id="configuring_the_window">
+<title>Configuring the Window</title>
+<para>
+Clients can resize and reposition their top-level windows by using the
+<function>ConfigureWindow</function>
+request.
+The attributes of the window that can be altered
+with this request are as follows:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The [x,y] location of the window's upper left-outer corner
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The [width,height] of the inner region of the window (excluding
+borders)
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The border width of the window
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The window's position in the stack
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The coordinate system in which the location is expressed is that of the root
+(irrespective of any reparenting that may have occurred).
+The border width to be used and win_gravity position hint
+to be used are those most recently requested by the client.
+Client configure requests are interpreted by the window manager
+in the same manner as the initial window geometry mapped from
+the Withdrawn state, as described in
+<link linkend="wm_normal_hints_property">
+<xref linkend="wm_normal_hints_property"></xref></link>
+Clients must be aware that there is no guarantee that the window manager
+will allocate them the requested size or location and must be prepared to
+deal with any size and location.
+If the window manager decides to respond to a
+<function>ConfigureRequest</function>
+request by:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Not changing the size, location, border width, or stacking order
+of the window at all.
+</para>
+    <para>
+A client will receive a synthetic
+<function>ConfigureNotify</function>
+event that describes the (unchanged) geometry of the window.
+The (x,y) coordinates will be in the root coordinate system,
+adjusted for the border width the client requested,
+irrespective of any reparenting that has taken place.
+The border_width will be the border width the client requested.
+The client will not receive a real
+<function>ConfigureNotify</function>
+event because no change has actually taken place.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Moving or restacking the window without resizing it or
+changing its border width.
+    </para>
+    <para>
+A client will receive a synthetic
+<function>ConfigureNotify </function>
+event following the change that describes the new geometry of the window.
+The event's (x,y) coordinates will be in the root coordinate system adjusted
+for the border width the client requested.
+The border_width will be the border width the client requested.
+The client may not receive a real
+<function>ConfigureNotify</function>
+event that describes this change because the window manager may have reparented
+the top-level window.
+If the client does receive a real event,
+the synthetic event will follow the real one.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Resizing the window or changing its border width (regardless of whether the
+window was also moved or restacked).
+    </para>
+    <para>
+A client that has selected for
+<function>StructureNotify</function>
+events will receive a real
+<function>ConfigureNotify</function>
+event.
+Note that the coordinates in this event are relative to the parent,
+which may not be the root if the window has been reparented.
+The coordinates will reflect the actual border width of the window
+(which the window manager may have changed).
+The
+<function>TranslateCoordinates</function>
+request can be used to convert the coordinates if required.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The general rule is that coordinates in real
+<function>ConfigureNotify</function>
+events are in the parent's space;
+in synthetic events, they are in the root space.
+</para>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+Clients cannot distinguish between the case where a top-level window is
+resized and moved from the case where the window is resized but not moved,
+since a real
+<function>ConfigureNotify</function>
+event will be received in both cases.  Clients that are concerned with
+keeping track of the absolute position of a top-level window should keep a
+piece of state indicating whether they are certain of its position.  Upon
+receipt of a real
+<function>ConfigureNotify</function>
+event on the top-level window, the client should note that the position is
+unknown.  Upon receipt of a synthetic
+<function>ConfigureNotify</function>
+event, the client should note the position as known, using the position in
+this event.  If the client receives a
+<function>KeyPress</function>,
+<function>KeyRelease</function>,
+<function>ButtonPress</function>,
+<function>ButtonRelease</function>,
+<function>MotionNotify</function>,
+<function>EnterNotify</function>
+or
+<function>LeaveNotify</function>
+event on the window (or on any descendant), the client can deduce the
+top-level window's position from the difference between the (event-x,
+event-y) and (root-x, root-y) coordinates in these events.  Only when the
+position is unknown does the client need to use the
+<function>TranslateCoordinates</function>
+request to find the position of a top-level window.
+</para>
+</blockquote>
+
+<para>
+Clients should be aware that their borders may not be visible.
+Window managers are free to use reparenting techniques to
+decorate client's top-level windows with borders containing
+titles,  controls, and other details to maintain a consistent look-and-feel.
+If they do,
+they are likely to override the client's attempts to set the border width
+and set it to zero.
+Clients, therefore, should not depend on the top-level window's border
+being visible or use it to display any critical information.
+Other window managers will allow the top-level windows border to
+be visible.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients should set the desired value of the border-width attribute on all
+<function>ConfigureWindow</function>
+requests to avoid a race condition.
+</para>
+</blockquote>
+
+<para>
+Clients that change their position in the stack must be aware
+that they may have been reparented,
+which means that windows that used to be siblings no longer are.
+Using a nonsibling as the sibling parameter on a
+<function>ConfigureWindow </function>
+request will cause an error.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients that use a
+<function>ConfigureWindow</function>
+request to request a change in their position in the stack
+should do so using
+<function>None</function>
+in the sibling field.
+</para>
+</blockquote>
+
+<para>
+Clients that must position themselves in the stack relative to some
+window that was originally a sibling must do the
+<function>ConfigureWindow</function>
+request (in case they are running under a nonreparenting window manager),
+be prepared to deal with a resulting error,
+and then follow with a synthetic
+<function>ConfigureRequest </function>
+event by invoking a
+<function>SendEvent</function>
+request with the following arguments:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">destination</entry>
+      <entry>The root</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">propogate</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">event-mask</entry>
+      <entry>(<emphasis role="bold">SubstructureRedirect|SubstructureNotify</emphasis>)</entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">
+event: an <function>ConfigureRequest</function> with:
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>event:</entry>
+      <entry>The root</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>window:</entry>
+      <entry>The window itself</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>...</entry>
+      <entry>Other parameters from the <emphasis role="bold">ConfigureWindow</emphasis> request</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Window managers are in any case free to position windows in the stack as
+they see fit, and so clients should not rely on receiving the stacking
+order they have requested.  Clients should ignore the above-sibling
+field of both real and synthetic
+<function>ConfigureNotify</function>
+events received on their top-level windows because this field may not
+contain useful information.
+</para>
+</sect3>
+
+<sect3 id="changing_window_attributes">
+<title>Changing Window Attributes</title>
+<para>
+The attributes that may be supplied when a window is created may be
+changed by using the
+<function>ChangeWindowAttributes</function>
+request.
+The window attributes are listed in the following table:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Attribute</entry>
+      <entry>Private to Client</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>Background pixmap</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Background pixel</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Border pixmap</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Border pixel</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Bit gravity</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Window gravity</entry>
+      <entry>No</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Backing-store hint</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Save-under hint</entry>
+      <entry>No</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Event Mask</entry>
+      <entry>No</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Do-not-propagate mask</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Override-redirect flag</entry>
+      <entry>No</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Colormap</entry>
+      <entry>Yes</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Cursor</entry>
+      <entry>Yes</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Most attributes are private to the client and will never be interfered with
+by the window manager.
+For the attributes that are not private to the client:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The window manager is free to override the window gravity;
+a reparenting window manager may want to set the top-level window's
+window gravity for its own purposes.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients are free to set the save-under hint on their top-level windows,
+but they must be aware that the hint may be overridden by the window manager.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Windows, in effect, have per-client event masks,
+and so, clients may select for whatever events are convenient irrespective
+of any events the window manager is selecting for.
+There are some events for which only one client at a time may select,
+but the window manager should not select for them on any of the client's
+windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients can set override-redirect on top-level windows but are
+encouraged not to do so except as described in
+<link linkend="pop_up_windows">
+<xref linkend="pop_up_windows"></xref></link>.
+and
+<link linkend="redirecting_requests">
+<xref linkend="redirecting_requests"></xref></link>.
+<!-- xref -->
+    </para>
+  </listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="input_focus">
+<title>Input Focus</title>
+<para>
+There are four models of input handling:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+No Input - The client never expects keyboard input.
+An example would be
+<function>xload</function>
+or another output-only client.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Passive Input - The client expects keyboard input but never explicitly sets
+the input focus.
+An example would be a simple client with no subwindows,
+which will accept input in
+<function>PointerRoot</function>
+mode or when the window manager sets the input focus to its top-level window
+(in click-to-type mode).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Locally Active Input - The client expects keyboard input and explicitly sets
+the input focus,
+but it only does so when one of its windows already has the focus.
+An example would be a client with subwindows defining various data
+entry fields that uses Next and Prev keys to move the input focus
+between the fields.
+It does so when its top-level window has acquired the focus in
+<function>PointerRoot</function>
+mode or when the window manager sets the input focus to its top-level window
+(in click-to-type mode).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Globally Active Input - The client expects keyboard input and explicitly sets
+the input focus,
+even when it is in windows the client does not own.
+An example would be a client with a scroll bar that wants to allow
+users to scroll the window without disturbing the input focus even if
+it is in some other window.
+It wants to acquire the input focus when the user clicks in the scrolled
+region but not when the user clicks in the scroll bar itself.
+Thus, it wants to prevent the window manager from setting the input focus
+to any of its windows.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The four input models and the corresponding values of the input field
+and the presence or absence of the WM_TAKE_FOCUS atom in the
+WM_PROTOCOLS property are listed in the following table:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Input Model</entry>
+      <entry>Input Field</entry>
+      <entry>WM_TAKE_FOCUS</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>No Input</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+      <entry>Absent</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Passive</entry>
+      <entry><emphasis role="bold">True</emphasis></entry>
+      <entry>Absent</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Locally Active</entry>
+      <entry><emphasis role="bold">True</emphasis></entry>
+      <entry>Present</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Globally Active</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+      <entry>Present</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Passive and Locally Active clients set the input field of WM_HINTS to
+<function>True</function>,
+which indicates that they require window manager assistance  in acquiring the
+input focus.
+No Input and Globally Active clients set the input field to
+<function>False</function>,
+which requests that the window manager not set the input focus
+to their top-level window.
+</para>
+
+<para>
+Clients that use a
+<function>SetInputFocus</function>
+request must set the time field to the timestamp of the event
+that caused them to make the attempt.
+This cannot be a
+<function>FocusIn</function>
+event because they do not have timestamps.
+Clients may also acquire
+the focus without a corresponding
+<function>EnterNotify</function>.
+Note that clients must not use
+<function>CurrentTime </function>
+in the time field.
+</para>
+
+<para>
+Clients using the Globally Active model can only use a
+<function>SetInputFocus</function>
+request to acquire the input focus when they do not already have it on
+receipt of one of the following events:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<function>ButtonPress</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>ButtonRelease</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Passive-grabbed
+<function>KeyPress</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Passive-grabbed
+<function>KeyRelease</function>
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In general,
+clients should avoid using passive-grabbed key events for this purpose,
+except when they are unavoidable (as, for example, a selection tool
+that establishes a passive grab on the keys that cut,  copy,  or paste).
+</para>
+
+<para>
+The method by which the user commands the window manager to
+set the focus to a window is up to the window manager.
+For example,
+clients cannot determine whether they will see the click
+that transfers the focus.
+</para>
+
+<para>
+Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property
+may receive a
+<function>ClientMessage </function>
+event from the window manager (as described in
+<link linkend="clientmessage_events">
+<xref linkend="clientmessage_events"></xref></link>.
+)
+with WM_TAKE_FOCUS in its data[0] field and a valid timestamp
+(i.e., not
+<function>CurrentTime )</function>
+in its data[1] field.
+If they want the focus,
+they should respond with a
+<function>SetInputFocus</function>
+request with its window field set to the window of theirs
+that last had the input focus or to their default input window,
+and the time field set to the timestamp in the message.
+For further information,
+see
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>
+</para>
+<para>
+<!-- .LP -->
+A client could receive WM_TAKE_FOCUS when opening from an icon
+or when the user has clicked outside the top-level window in an area that
+indicates to the window manager that it should assign the focus
+(for example, clicking in the headline bar can be used to assign the focus).
+</para>
+<para>
+<!-- .LP -->
+The goal is to support window managers that want to assign the input focus
+to a top-level window in such a way that the top-level window either
+can assign it to one of its subwindows or can decline the offer of the focus.
+For example, a clock or a text editor with no currently open frames
+might not want to take focus even though the window manager generally
+believes that clients should take the input focus after being deiconified
+or raised.
+</para>
+<para>
+<!-- .LP -->
+Clients that set the input focus need to decide a value for the
+revert-to field of the
+<function>SetInputFocus</function>
+request.
+This determines the behavior of the input focus
+if the window the focus has been set to becomes not viewable.
+The value can be any of the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<function>Parent</function>
+- In general,
+clients should use this value when assigning focus to one of their subwindows.
+Unmapping the subwindow will cause focus to revert to the parent,
+which is probably what you want.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+<function>PointerRoot </function>
+- Using
+this value with a click-to-type focus management policy
+leads to race conditions because the window becoming unviewable may
+coincide with the window manager deciding to move the focus elsewhere.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>None</function>
+- Using
+this value causes problems if the window manager reparents
+the window, as most window managers will, and then crashes.
+The input focus will be
+<function>None</function>,
+and there will probably be no way to change it.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Note that neither
+<function>PointerRoot</function>
+nor
+<function>None</function>
+is really safe to use.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients that invoke a
+<function>SetInputFocus </function>
+request should set the revert-to argument to
+<function>Parent</function>.
+</para>
+</blockquote>
+
+<para>
+A convention is also required for clients that want to give up the
+input focus.
+There is no safe value set for them to set the input focus to;
+therefore, they should ignore input material.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients should not give up the input focus of their own volition.
+They should ignore input that they receive instead.
+</para>
+</blockquote>
+</sect3>
+
+<sect3 id="colormaps">
+<title>Colormaps</title>
+<para>
+The window manager is responsible for installing and uninstalling
+colormaps on behalf of clients with top-level windows that
+the window manager manages.
+</para>
+<para>
+Clients provide the window manager with hints as to which colormaps to
+install and uninstall.  Clients must not install or uninstall colormaps
+themselves (except under the circumstances noted below).  When a client's
+top-level window gets the colormap focus (as a result of whatever colormap
+focus policy is implemented by the window manager), the window manager will
+ensure that one or more of the client's colormaps are installed.
+</para>
+<para>
+<!-- .LP -->
+Clients whose top-level windows and subwindows all use the same colormap
+should set its ID in the colormap field of the top-level window's
+attributes.  They should not set a WM_COLORMAP_WINDOWS property on the
+top-level window.  If they want to change the colormap, they should change
+the top-level window's colormap attribute.  The window manager will track
+changes to the window's colormap attribute and install colormaps as
+appropriate.
+</para>
+<para>
+<!-- .LP -->
+Clients that create windows can use the value
+<function>CopyFromParent</function>
+to inherit their parent's colormap.  Window managers will ensure that the
+root window's colormap field contains a colormap that is suitable for
+clients to inherit.  In particular, the colormap will provide
+distinguishable colors for
+<function>BlackPixel</function>
+and
+<function>WhitePixel</function>.
+</para>
+<para>
+<!-- .LP -->
+Top-level windows that have subwindows or override-redirect pop-up windows
+whose colormap requirements differ from the top-level window should have a
+WM_COLORMAP_WINDOWS property.  This property contains a list of IDs for
+windows whose colormaps the window manager should attempt to have installed
+when, in the course of its individual colormap focus policy, it assigns the
+colormap focus to the top-level window (see
+<link linkend="wm_colormap_windows_property">
+<xref linkend="wm_colormap_windows_property"></xref></link>
+).  The list is
+ordered by the importance to the client of having the colormaps installed.
+The window manager will track changes to this property and will track
+changes to the colormap attribute of the windows in the property.
+</para>
+<para>
+<!-- .LP -->
+If the relative importance of colormaps changes, the client should update
+the WM_COLORMAP_WINDOWS property to reflect the new ordering.  If the
+top-level window does not appear in the list, the window manager will assume
+it to be of higher priority than any window in the list.
+</para>
+<para>
+<!-- .LP -->
+WM_TRANSIENT_FOR windows can either have their own WM_COLORMAP_WINDOWS
+property or appear in the property of the window they are transient for,
+as appropriate.
+</para>
+
+<blockquote>
+<title>Rationale</title>
+<para>
+An alternative design was considered for how clients should hint to the
+window manager about their colormap requirements.  This alternative design
+specified a list of colormaps instead of a list of windows.  The current
+design, a list of windows, was chosen for two reasons.  First, it allows
+window managers to find the visuals of the colormaps, thus permitting
+visual-dependent colormap installation policies.  Second, it allows window
+managers to select for
+<function>VisibilityChange</function>
+events on the windows concerned and to ensure that colormaps are only
+installed if the windows that need them are visible.  The alternative design
+allows for neither of these policies.
+</para>
+</blockquote>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+Clients should be aware of the min-installed-maps and max-installed-maps
+fields of the connection setup information, and the effect that the minimum
+value has on the "required list" defined by the Protocol in the
+description of the
+<function>InstallColormap</function>
+request.  Briefly, the min-installed-maps most recently installed maps are
+guaranteed to be installed.  This value is often one; clients needing
+multiple colormaps should beware.
+</para>
+</blockquote>
+
+<para>
+Whenever possible, clients should use the mechanisms described above and let
+the window manager handle colormap installation.  However, clients are
+permitted to perform colormap installation on their own while they have the
+pointer grabbed.  A client performing colormap installation must notify the
+window manager prior to the first installation.  When the client has
+finished its colormap installation, it must also notify the window manager.
+The client notifies the window manager by issuing a
+<function>SendEvent</function>
+request with the following arguments:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">destination</entry>
+      <entry>
+The root window of the screen on which the colormap is installed
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">propogate</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">event-mask</entry>
+      <entry><emphasis role="bold">ColormapChange</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry namest="c1" nameend="c2">
+event: an <function>ClientMessage</function> with:
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>window:</entry>
+      <entry>The root window, as above</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>type:</entry>
+      <entry>WM_COLORMAP_NOTIFY</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>format</entry>
+      <entry>32</entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[0]</entry>
+      <entry>
+the timestampe of the event that caused the client to start or stop
+installing colormaps
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[1]</entry>
+      <entry>
+1 if the client is starting colormap installation,
+0 if the client is finished with colormap installation
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[2]</entry>
+      <entry>
+reserved, must be zero
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[3]</entry>
+      <entry>
+reserved, must be zero
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry></entry>
+      <entry>data[4]</entry>
+      <entry>
+reserved, must be zero
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+
+
+<para>
+This feature was introduced in version 2.0 of this document, and there will
+be a significant period of time before all window managers can be expected
+to implement this feature.  Before using this feature, clients must check
+the compliance level of the window manager (using the mechanism described in
+<link linkend="communication_with_the_window_manager_by_means_of_selections">
+<xref linkend="communication_with_the_window_manager_by_means_of_selections"></xref></link>
+) to verify that it supports this feature.  This is necessary to
+prevent colormap installation conflicts between clients and older window
+managers.
+</para>
+<para>
+<!-- .LP -->
+Window managers should refrain from installing colormaps while a client has
+requested control of colormap installation.  The window manager should
+continue to track the set of installed colormaps so that it can reinstate
+its colormap focus policy when the client has finished colormap installation.
+</para>
+<para>
+<!-- .LP -->
+This technique has race conditions that may result in the colormaps
+continuing to be installed even after a client has issued its notification
+message.  For example, the window manager may have issued some
+<function>InstallColormap</function>
+requests that are not executed until after the
+client's
+<function>SendEvent</function>
+and
+<function>InstallColormap</function>
+requests, thus uninstalling the client's colormaps.  If this occurs while
+the client still has the pointer grabbed and before the client has issued
+the "finished" message, the client may reinstall the desired colormaps.
+</para>
+
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+Clients are expected to use this mechanism for things such as
+pop-up windows and for animations that use override-redirect windows.
+</para>
+<!-- .\" Avoid .LP within a .NT, because it resets the margins.  The .NT -->
+<!-- .\" macro should probably be fixed. -->
+<!-- .br -->
+<!-- .sp \n(PDu -->
+<para>
+If a client fails to issue the "finished" message, the window manager
+may be left in a state where its colormap installation policy is suspended.
+Window manager implementors may want to implement a feature that resets
+colormap installation policy in response to a command from the user.
+</para>
+</blockquote>
+</sect3>
+
+<sect3 id="icons">
+<title>Icons</title>
+<para>
+A client can hint to the window manager about the desired appearance
+of its icon by setting:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+A string in WM_ICON_NAME.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+All clients should do this
+because it provides a fallback for window managers whose ideas
+about icons differ widely from those of the client.
+    </para>
+    <para>
+A
+<function>Pixmap</function>
+into the icon_pixmap field of the WM_HINTS property
+and possibly another into the icon_mask field.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The window manager is expected to display the pixmap masked by the mask.
+The pixmap should be one of the sizes found in the WM_ICON_SIZE property
+on the root.
+If this property is not found,
+the window manager is unlikely to display icon pixmaps.
+Window managers usually will clip or tile pixmaps that do not match
+WM_ICON_SIZE.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A window into the icon_window field of the WM_HINTS property.
+    </para>
+    <para>
+The window manager is expected to map that window whenever the client is
+in the Iconic state.
+In general,
+the size of the icon window should be one of those specified in WM_ICON_SIZE
+on the root, if it exists.
+Window managers are free to resize icon windows.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In the Iconic state,
+the window manager usually will ensure that:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+If the window's WM_HINTS.icon_window is set,
+the window it names is visible.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the window's WM_HINTS.icon_window is not set
+but the window's WM_HINTS.icon_pixmap is set,
+the pixmap it names is visible.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Otherwise,
+the window's WM_ICON_NAME string is visible.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Clients should observe the following conventions about their icon windows:
+</para>
+
+<blockquote>
+<title>Conventions</title>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The icon window should be an
+<function>InputOutput</function>
+child of the root.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The icon window should be one of the sizes specified
+in the WM_ICON_SIZE property on the root.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The icon window should use the root visual and default colormap
+for the screen in question.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients should not map their icon windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients should not unmap their icon windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients should not configure their icon windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients should not set override-redirect on their icon windows
+or select for
+<function>ResizeRedirect </function>
+events on them.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients must not depend on being able to receive input events
+by means of their icon windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients must not manipulate the borders of their icon windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients must select for
+<function>Exposure</function>
+events on their icon window and repaint it when requested.
+<!-- .NE -->
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+<para>
+Window managers will differ as to whether they support input events
+to client's icon windows;
+most will allow the client to receive some subset of the keys and buttons.
+</para>
+<para>
+<!-- .LP -->
+Window managers will ignore any WM_NAME, WM_ICON_NAME, WM_NORMAL_HINTS,
+WM_HINTS, WM_CLASS, WM_TRANSIENT_FOR, WM_PROTOCOLS, WM_COLORMAP_WINDOWS,
+WM_COMMAND, or WM_CLIENT_MACHINE
+properties they find on icon windows.
+</para>
+</sect3>
+
+<sect3 id="pop_up_windows">
+<title>Pop-up Windows</title>
+<para>
+Clients that wish to pop up a window can do one of three things:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+They can create and map another normal top-level window,
+which will get decorated and managed as normal by the window manager.
+See the discussion of window groups that follows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the window will be visible for a relatively short time
+and deserves a somewhat lighter treatment,
+they can set the WM_TRANSIENT_FOR property.
+They can expect less decoration but can set all the normal
+window manager properties on the window.
+An example would be a dialog box.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the window will be visible for a very short time
+and should not be decorated at all,
+the client can set override-redirect on the window.
+In general,
+this should be done only if the pointer is grabbed while the window is mapped.
+The window manager will never interfere with these windows,
+which should be used with caution.
+An example of an appropriate use is a pop-up menu.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+The user will not be able to move, resize, restack, or transfer the input
+focus to override-redirect windows, since the window manager is not managing
+them.  If it is necessary for a client to receive keystrokes on an
+override-redirect window, either the client must grab the keyboard or the
+client must have another top-level window that is not override-redirect and
+that has selected the Locally Active or Globally Active focus model.  The
+client may set the focus to the override-redirect window when the other
+window receives a WM_TAKE_FOCUS message or one of the events listed in
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>
+in the description of the Globally Active focus model.
+</para>
+</blockquote>
+
+<para>
+Window managers are free to decide if WM_TRANSIENT_FOR windows
+should be iconified when the window they are transient for is.
+Clients displaying WM_TRANSIENT_FOR windows that have
+(or request to have) the window they are transient for iconified
+do not need to request that the same operation be performed
+on the WM_TRANSIENT_FOR window;
+the window manager will change its state if that is the policy it wishes
+to enforce.
+</para>
+</sect3>
+
+<sect3 id="window_groups">
+<title>Window Groups</title>
+<para>
+A set of top-level windows that should be treated from the user's point of view
+as related (even though they may belong to a number of clients) should be linked
+together using the window_group field of the WM_HINTS structure.
+</para>
+<para>
+One of the windows (that is, the one the others point to)
+will be the group leader and will carry the group as opposed
+to the individual properties.
+Window managers may treat the group leader differently
+from other windows in the group.
+For example,
+group leaders may have the full set of decorations,
+and other group members may have a restricted set.
+</para>
+<para>
+<!-- .LP -->
+It is not necessary that the client ever map the group leader;
+it may be a window that exists solely as a placeholder.
+</para>
+<para>
+<!-- .LP -->
+It is up to the window manager to determine the policy
+for treating the windows in a group.
+At present,
+there is no way for a client to request a group,
+as opposed to an individual, operation.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="client_responses_to_window_manager_actions">
+<title>Client Responses to Window Manager Actions</title>
+<para>
+The window manager performs a number of operations on client resources,
+primarily on their top-level windows.
+Clients must not try to fight this but may elect to receive notification
+of the window manager's operations.
+</para>
+
+<sect3 id="reparenting">
+<title>Reparenting</title>
+<para>
+Clients must be aware that some window managers will reparent
+their top-level windows
+so that a window that was created as a child of the root will be displayed
+as a child of some window belonging to the window manager.
+The effects that this reparenting will have on the client are as follows:
+</para>
+
+
+<itemizedlist>
+  <listitem>
+    <para>
+The parent value returned by a
+<function>QueryTree</function>
+request will no longer be the value supplied to the
+<function>CreateWindow </function>
+request that created the reparented window.
+There should be no need for the client to be aware of the identity
+of the window to which the top-level window has been reparented.
+In particular,
+a client that wishes to create further top-level windows should continue
+to use the root as the parent for these new windows.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The server will interpret the (x,y) coordinates in a
+<function>ConfigureWindow</function>
+request in the new parent's coordinate space.
+In fact, they usually will not be interpreted by the server
+because a reparenting window manager usually will have intercepted
+these operations (see
+<link linkend="redirection_of_operations">
+<xref linkend="redirection_of_operations"></xref></link>
+).
+Clients should use the root coordinate space for these requests
+(see
+<link linkend="configuring_the_window">
+<xref linkend="configuring_the_window"></xref></link>
+).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+<function>ConfigureWindow</function>
+requests that name a specific sibling window may fail because the window named,
+which used to be a sibling, no longer is after the reparenting operation
+(see
+<link linkend="configuring_the_window">
+<xref linkend="configuring_the_window"></xref></link>
+).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The (x,y) coordinates returned by a
+<function>GetGeometry</function>
+request are in the parent's coordinate space
+and are thus not directly useful after a reparent operation.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+A background of
+<function>ParentRelative</function>
+will have unpredictable results.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+A cursor of
+<function>None</function>
+will have unpredictable results.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Clients that want to be notified when they are reparented can select for
+<function>StructureNotify</function>
+events on their top-level window.
+They will receive a
+<function>ReparentNotify</function>
+event if and when reparenting takes place.
+When a client withdraws a top-level window, the window manager will
+reparent it back to the root window if the window had been reparented
+elsewhere.
+</para>
+
+<para>
+If the window manager reparents a client's window,
+the reparented window will be placed in the save-set
+of the parent window.
+This means that the reparented window will not be destroyed
+if the window manager terminates and will be remapped if it was unmapped.
+Note that this applies to all client windows the window manager reparents,
+including transient windows and client icon windows.
+</para>
+</sect3>
+
+<sect3 id="redirection_of_operations">
+<title>Redirection of Operations</title>
+<para>
+Clients must be aware that some window managers will arrange
+for some client requests to be intercepted and redirected.
+Redirected requests are not executed;
+they result instead in events being sent to the window manager,
+which may decide to do nothing, to alter the arguments,
+or to perform the request on behalf of the client.
+</para>
+
+<para>
+The possibility that a request may be redirected means
+that a client cannot assume that any redirectable request is actually
+performed when the request is issued or is actually performed at all.
+The requests that may be redirected are
+<function>MapWindow ,</function>
+<function>ConfigureWindow</function>,
+and
+<function>CirculateWindow</function>.
+</para>
+
+<blockquote>
+<title>Advice to Implementors</title>
+<para>
+The following is incorrect because the
+<function>MapWindow</function>
+request may be intercepted and the
+<function>PolyLine</function>
+output made to an unmapped window:
+</para>
+<literallayout class="monospaced">
+MapWindow A
+PolyLine A GC &lt;point&gt; &lt;point&gt; ...
+</literallayout>
+
+<para>
+The client must wait for an
+<function>Expose</function>
+event before drawing in the window.
+<footnote><para>
+This is true even if the client set the backing-store attribute to
+<function>Always .</function>
+The backing-store attribute is a only a hint,
+and the server may stop maintaining backing store contents at any time.
+</para>
+</footnote>
+</para>
+
+<para>
+This next example incorrectly assumes that the
+<function>ConfigureWindow</function>
+request is actually executed with the arguments supplied:
+</para>
+
+<literallayout class="monospaced">
+ConfigureWindow width=N height=M
+&lt;output assuming window is N by M&gt;
+</literallayout>
+
+<para>
+The client should select for
+<function>StructureNotify</function>
+on its window and monitor the window's size by tracking
+<function>ConfigureNotify</function>
+events.
+</para>
+
+<para>
+Clients must be especially careful when attempting to set the focus to a
+window that they have just mapped.  This sequence may result in an X
+protocol error:
+</para>
+
+<literallayout class="monospaced">
+MapWindow B
+SetInputFocus B
+</literallayout>
+
+<para>
+If the
+<function>MapWindow</function>
+request has been intercepted, the window will still be
+unmapped, causing the
+<function>SetInputFocus</function>
+request to generate the error.  The solution to this problem is for clients
+to select for
+<function>VisibilityChange</function>
+on the window and to delay the issuance of the
+<function>SetInputFocus</function>
+request until they have received a
+<function>VisibilityNotify</function>
+event indicating that the window is visible.
+</para>
+
+<para>
+This technique does not guarantee correct operation.  The user may have
+iconified the window by the time the
+<function>SetInputFocus</function>
+request reaches the server, still causing an error.  Or the window manager
+may decide to map the window into Iconic state, in which case the window
+will not be visible.  This will delay the generation of the
+<function>VisibilityNotify</function>
+event indefinitely.  Clients must be prepared to handle these cases.
+</para>
+</blockquote>
+
+<para>
+A window with the override-redirect bit set is immune from redirection,
+but the bit should be set on top-level windows only in cases
+where other windows should be prevented from processing input
+while the override-redirect window is mapped (see
+<link linkend="pop_up_windows">
+<xref linkend="pop_up_windows"></xref></link>
+)
+and while responding to
+<function>ResizeRequest</function>
+events (see
+<link linkend="redirecting_requests">
+<xref linkend="redirecting_requests"></xref></link>
+).
+</para>
+
+<para>
+Clients that have no non-Withdrawn top-level windows
+and that map an override-redirect top-level window are taking over total
+responsibility for the state of the system.
+It is their responsibility to:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Prevent any preexisting window manager from interfering with their activities
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Restore the status quo exactly after they unmap the window
+so that any preexisting window manager does not get confused
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In effect,  clients of this kind are acting as temporary window managers.
+Doing so is strongly discouraged because these clients will be unaware
+of the user interface policies the window manager is trying to maintain
+and because their user interface behavior is likely to conflict with that of
+less demanding clients.
+</para>
+</sect3>
+
+<sect3 id="window_move">
+<title>Window Move</title>
+
+<para>
+If the window manager moves a top-level window without changing its size,
+the client will receive a synthetic
+<function>ConfigureNotify</function>
+event following the move that describes the new location
+in terms of the root coordinate space.
+Clients must not respond to being moved by attempting to move
+themselves to a better location.
+</para>
+
+<para>
+Any real
+<function>ConfigureNotify</function>
+event on a top-level window implies that the window's position
+on the root may have changed,
+even though the event reports that the window's position
+in its parent is unchanged because the window may have been reparented.
+Note that the coordinates in the event will not, in this case,
+be directly useful.
+</para>
+
+<para>
+The window manager will send these events by using a
+<function>SendEvent</function>
+request with the following arguments:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>destination</entry>
+      <entry>The client's window</entry>
+    </row>
+    <row rowsep="0">
+      <entry>propagate</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry>event-mask</entry>
+      <entry><emphasis role="bold">StructureNotify</emphasis></entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect3>
+
+
+<sect3 id="window_resize">
+<title>Window Resize</title>
+<para>
+The client can elect to receive notification of being resized by selecting for
+<function>StructureNotify</function>
+events on its top-level windows.
+It will receive a
+<function>ConfigureNotify</function>
+event.
+The size information in the event will be correct,
+but the location will be in the parent window (which may not be the root).
+</para>
+
+<para>
+The response of the client to being resized should be to accept
+the size it has been given and to do its best with it.
+Clients must not respond to being resized by attempting to resize
+themselves to a better size.
+If the size is impossible to work with,
+clients are free to request to change to the Iconic state.
+</para>
+</sect3>
+
+<sect3 id="iconify_and_deiconify">
+<title>Iconify and Deiconify</title>
+<para>
+A top-level window that is not Withdrawn will be
+in the Normal state if it is mapped and in the Iconic state if it is unmapped.
+This will be true even if the window has been reparented;
+the window manager will unmap the window as well as its parent
+when switching to the Iconic state.
+</para>
+
+<para>
+The client can elect to be notified of these state changes by selecting for
+<function>StructureNotify</function>
+events on the top-level window.
+It will receive a
+<function>UnmapNotify</function>
+event when it goes Iconic and a
+<function>MapNotify</function>
+event when it goes Normal.
+</para>
+</sect3>
+
+<sect3 id="colormap_change">
+<title>Colormap Change</title>
+<para>
+Clients that wish to be notified of their colormaps being installed
+or uninstalled should select for
+<function>ColormapNotify</function>
+events on their top-level windows and on any windows they have named
+in WM_COLORMAP_WINDOWS properties on their top-level windows.
+They will receive
+<function>ColormapNotify</function>
+events with the new field FALSE when the colormap for that window
+is installed or uninstalled.
+</para>
+</sect3>
+
+<sect3 id="input_focus_2">
+<title>Input Focus</title>
+<para>
+Clients can request notification that they have the input focus by selecting
+for
+<function>FocusChange</function>
+events on their top-level windows;
+they will receive
+<function>FocusIn </function>
+and
+<function>FocusOut</function>
+events.
+Clients that need to set the input focus to one of their
+subwindows should not do so unless
+they have set WM_TAKE_FOCUS in their WM_PROTOCOLS property
+and have done one of the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Set the input field of WM_HINTS to
+<function>True</function>
+and actually have the input focus in one of their top-level windows
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Set the input field of WM_HINTS to
+<function>False</function>
+and have received a suitable event as described in
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Have received a WM_TAKE_FOCUS message as described in
+<link linkend="input_focus">
+<xref linkend="input_focus"></xref></link>.
+    </para>
+  </listitem>
+</itemizedlist>
+<para>
+Clients should not warp the pointer in an attempt to transfer the focus;
+they should set the focus and leave the pointer alone.
+For further information,
+see
+<link linkend="the_pointer">
+<xref linkend="the_pointer"></xref></link>.
+</para>
+<para>
+<!-- .LP -->
+Once a client satisfies these conditions,
+it may transfer the focus to another of its windows by using the
+<function>SetInputFocus</function>
+request, which is defined as follows:
+</para>
+
+<!-- .IN "SetInputFocus" "" "@DEF@" -->
+<para>
+<function>SetInputFocus</function>
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <tbody>
+    <row>
+      <entry>
+<emphasis remap='I'>focus</emphasis>: WINDOW or
+<emphasis role="bold">PointerRoot</emphasis> or
+<emphasis role="bold">None</emphasis>
+      </entry>
+    </row>
+    <row>
+      <entry>
+<emphasis remap='I'>revert-to</emphasis>:
+{ <emphasis role="bold">Parent</emphasis>,
+<emphasis role="bold">PointerRoot</emphasis>,
+<emphasis role="bold">None</emphasis> }
+      </entry>
+    </row>
+    <row>
+      <entry>
+<emphasis remap='I'>time</emphasis>: TIMESTAMP or CurrentTime
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+
+
+<blockquote>
+<title>Conventions</title>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Clients that use a
+<function>SetInputFocus</function>
+request must set the time argument to the timestamp of the event
+that caused them to make the attempt.
+This cannot be a
+<function>FocusIn</function>
+event because they do not have timestamps.
+Clients may also acquire the focus without a corresponding
+<function>EnterNotify </function>
+event.
+Clients must not use
+<function>CurrentTime</function>
+for the time argument.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients that use a
+<function>SetInputFocus</function>
+request to set the focus to one of their windows must set
+the revert-to field to
+<function>Parent</function>.
+<!-- .NE -->
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+</sect3>
+
+<sect3 id="clientmessage_events">
+<title>ClientMessage Events</title>
+<para>
+There is no way for clients to prevent themselves being sent
+<function>ClientMessage</function>
+events.
+</para>
+<para>
+Top-level windows with a WM_PROTOCOLS property may be sent
+<function>ClientMessage</function>
+events specific to the protocols named by the atoms in the property
+(see
+<link linkend="wm_protocols_property">
+<xref linkend="wm_protocols_property"></xref></link>
+).
+For all protocols, the
+<function>ClientMessage</function>
+events have the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+WM_PROTOCOLS as the type field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Format 32
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The atom that names their protocol in the data[0] field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A timestamp in their data[1] field
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The remaining fields of the event,
+including the window field,
+are determined by the protocol.
+</para>
+
+<para>
+These events will be sent by using a
+<function>SendEvent</function>
+request with the following arguments:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Argument</entry>
+      <entry>Value</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>destination</entry>
+      <entry>The client's window</entry>
+    </row>
+    <row rowsep="0">
+      <entry>propagate</entry>
+      <entry><emphasis role="bold">False</emphasis></entry>
+    </row>
+    <row rowsep="0">
+      <entry>event-mask</entry>
+      <entry>() empty</entry>
+    </row>
+    <row rowsep="0">
+      <entry>event</entry>
+      <entry>As specified by the protocol</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<sect4 id="window_deletion">
+<title>Window Deletion</title>
+<para>
+Clients, usually those with multiple top-level windows, whose server
+connection must survive the deletion of some of their top-level windows,
+should include the atom WM_DELETE_WINDOW in the WM_PROTOCOLS property on
+each such window.  They will receive a
+<function>ClientMessage </function>
+event as described above whose data[0] field is WM_DELETE_WINDOW.
+</para>
+
+<para>
+Clients receiving a WM_DELETE_WINDOW message should behave as if the user
+selected "delete window" from a hypothetical menu.
+They should perform any confirmation dialog with the user
+and, if they decide to complete the deletion, should do the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Either change the window's state to Withdrawn (as described in
+<link linkend="changing_window_state">
+<xref linkend="changing_window_state"></xref></link>
+)
+or destroy the window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Destroy any internal state associated with the window.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+If the user aborts the deletion during the confirmation dialog,
+the client should ignore the message.
+</para>
+
+<para>
+Clients are permitted to interact with the user and ask, for example,
+whether a file associated with the window to be deleted should be saved
+or the window deletion should be cancelled.
+Clients are not required to destroy the window itself;
+the resource may be reused,
+but all associated state (for example, backing store) should be released.
+</para>
+
+<para>
+If the client aborts a destroy and the user then selects DELETE WINDOW again,
+the window manager should start the WM_DELETE_WINDOW protocol again.
+Window managers should not use
+<function>DestroyWindow</function>
+requests on a window that has WM_DELETE_WINDOW in its WM_PROTOCOLS property.
+</para>
+
+<para>
+Clients that choose not to include WM_DELETE_WINDOW in the WM_PROTOCOLS
+property may be disconnected from the server
+if the user asks for one of the client's top-level windows to be deleted.
+</para>
+</sect4>
+</sect3>
+
+<sect3 id="redirecting_requests">
+<title>Redirecting Requests</title>
+<para>
+Normal clients can use the redirection mechanism just as window managers do
+by selecting for
+<function>SubstructureRedirect</function>
+events on a parent window or
+<function>ResizeRedirect</function>
+events on a window itself.
+However, at most,
+one client per window can select for these events,
+and a convention is needed to avoid clashes.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients (including window managers) should select for
+<function>SubstructureRedirect</function>
+and
+<function>ResizeRedirect</function>
+events only on windows that they own.
+</para>
+</blockquote>
+
+<para>
+In particular,
+clients that need to take some special action if they are resized can select
+for
+<function>ResizeRedirect</function>
+events on their top-level windows.
+They will receive a
+<function>ResizeRequest</function>
+event if the window manager resizes their window,
+and the resize will not actually take place.
+Clients are free to make what use they like of the information
+that the window manager wants to change their size,
+but they must configure the window to the width and height specified
+in the event in a timely fashion.
+To ensure that the resize will actually happen at this stage
+instead of being intercepted and executed by the window manager
+(and thus restarting the process),
+the client needs temporarily to set override-redirect on the window.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients receiving
+<function>ResizeRequest</function>
+events must respond by doing the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Setting override-redirect on the window specified in the event
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Configuring the window specified in the event
+to the width and height specified in the event as soon as possible
+and before making any other geometry requests
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clearing override-redirect on the window specified in the event
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+<para>
+If a window manager detects that a client is not obeying this convention,
+it is free to take whatever measures it deems appropriate to deal with
+the client.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="communication_with_the_window_manager_by_means_of_selections">
+<title>Communication with the Window Manager by Means of Selections</title>
+<para>
+For each screen they manage, window managers will acquire ownership of a
+selection named WM_S<emphasis remap='I'>n</emphasis>, where
+<emphasis remap='I'>n</emphasis> is the screen number, as
+described in
+<link linkend="discriminated_names">
+<xref linkend="discriminated_names"></xref></link>
+Window managers should comply with the
+conventions for "Manager Selections" described in
+<link linkend="manager_selections">
+<xref linkend="manager_selections"></xref></link>.
+The
+intent is for clients to be able to request a variety of information or
+services by issuing conversion requests on this selection.  Window managers
+should support conversion of the following target on their manager
+selection:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Atom</entry>
+      <entry>Type</entry>
+      <entry>Data Received</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>VERSION</entry>
+      <entry>INTEGER</entry>
+      <entry>
+Two integers, which are the major and minor release numbers (respectively) of
+the ICCCM with which the window manager complies.  For this version of the
+ICCCM, the numbers are 2 and 0.
+<footnote>
+<para>
+As a special case, clients not wishing to implement a selection
+request may simply issue a
+<function>GetSelectionOwner</function>
+request on the appropriate WM_S<emphasis remap='I'>n</emphasis> selection.
+If this selection is owned,
+clients may assume that the window manager complies with ICCCM version 2.0
+or later.
+</para>
+</footnote>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect2>
+
+<sect2 id="summary_of_window_manager_property_types">
+<title>Summary of Window Manager Property Types</title>
+<para>
+The window manager properties are summarized in the following table
+(see also section 14.1 of  <!-- xref -->
+<emphasis remap='I'>Xlib - C Language X Interface</emphasis>).
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <colspec colname='c4' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Name</entry>
+      <entry>Type</entry>
+      <entry>Format</entry>
+      <entry>See Section</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>WM_CLASS</entry>
+      <entry>STRING</entry>
+      <entry>8</entry>
+      <entry>
+<link linkend="wm_class_property">
+<xref linkend="wm_class_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_CLIENT_MACHINE</entry>
+      <entry>TEXT</entry>
+      <entry></entry>
+      <entry>
+<link linkend="wm_client_machine_property">
+<xref linkend="wm_client_machine_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_COLORMAP_WINDOWS</entry>
+      <entry>WINDOW</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_colormap_windows_property">
+<xref linkend="wm_colormap_windows_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_HINTS</entry>
+      <entry>WM_HINTS</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_hints_property">
+<xref linkend="wm_hints_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_ICON_NAME</entry>
+      <entry>TEXT</entry>
+      <entry></entry>
+      <entry>
+<link linkend="wm_icon_name_property">
+<xref linkend="wm_icon_name_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_ICON_SIZE</entry>
+      <entry>WM_ICON_SIZE</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_icon_size_property">
+<xref linkend="wm_icon_size_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_NAME</entry>
+      <entry>TEXT</entry>
+      <entry></entry>
+      <entry>
+<link linkend="wm_name_property">
+<xref linkend="wm_name_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_NORMAL_HINTS</entry>
+      <entry>WM_SIZE_HINTS</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_normal_hints_property">
+<xref linkend="wm_normal_hints_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_PROTOCOLS</entry>
+      <entry>ATOM</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_protocols_property">
+<xref linkend="wm_protocols_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_STATE</entry>
+      <entry>WM_STATE</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_state_property">
+<xref linkend="wm_state_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_TRANSIENT_FOR</entry>
+      <entry>WINDOW</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_transient_for_property">
+<xref linkend="wm_transient_for_property"></xref></link>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect2>
+</sect1>
+
+<sect1 id="session_management_and_additional_inter_Client_exchanges">
+<title>Session Management and Additional Inter-Client Exchanges</title>
+<para>
+This section contains some conventions for clients that participate in
+session management.  See
+<emphasis remap='I'>X Session Management Protocol</emphasis>
+for further details.  Clients that do not support this protocol cannot
+expect their window state (e.g., WM_STATE, position, size, and stacking order)
+to be preserved across sessions.
+</para>
+
+<sect2 id="client_support_for_session_management">
+<title>Client Support for Session Management</title>
+<para>
+Each session participant will obtain a unique client identifier (client-ID)
+from the session manager.  The client must identify one top-level window as
+the "client leader." This window must be created by the client.  It may
+be in any state, including the Withdrawn state.  The client leader window
+must have a SM_CLIENT_ID property, which contains the client-ID obtained
+from the session management protocol.  That property must:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Be of type STRING
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be of format 8
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Contain the client-ID as a string of XPCS characters encoded using ISO
+8859-1
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+All top-level, nontransient windows created by a client on the same display
+as the client leader must have a WM_CLIENT_LEADER property. This property
+contains a window ID that identifies the client leader window.  The client
+leader window must have a WM_CLIENT_LEADER property containing its own
+window ID (i.e., the client leader window is pointing to itself).  Transient
+windows need not have a WM_CLIENT_LEADER property if the client leader can
+be determined using the information in the WM_TRANSIENT_FOR property.  The
+WM_CLIENT_LEADER property must:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Be of type WINDOW
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be of format 32
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Contain the window ID of the client leader window
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+A client must withdraw all of its top-level windows on the same display
+before modifiying either the WM_CLIENT_LEADER or the SM_CLIENT_ID property
+of its client leader window.
+</para>
+
+<para>
+It is necessary that other clients be able to uniquely identify a window
+(across sessions) among all windows related to the same client-ID.  For
+example, a window manager can require this unique ID to restore geometry
+information from a previous session, or a workspace manager could use it to
+restore information about which windows are in which workspace.  A client
+may optionally provide a WM_WINDOW_ROLE property to uniquely identify a
+window within the scope specified above.  The combination of SM_CLIENT_ID
+and WM_WINDOW_ROLE can be used by other clients to uniquely identify a
+window across sessions.
+</para>
+
+<para>
+If the WM_WINDOW_ROLE property is not specified on a top-level window, a
+client that needs to uniquely identify that window will try to use instead
+the values of WM_CLASS and WM_NAME.  If a client has multiple windows with
+identical WM_CLASS and WM_NAME properties, then it should provide a
+WM_WINDOW_ROLE property.
+</para>
+
+<para>
+The client must set the WM_WINDOW_ROLE property to a string that uniquely
+identifies that window among all windows that have the same client leader
+window.  The property must:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Be of type STRING
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be of format 8
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Contain a string restricted to the XPCS characters, encoded in ISO 8859-1
+    </para>
+  </listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="window_manager_support_for_session_management">
+<title>Window Manager Support for Session Management</title>
+<para>
+A window manager supporting session management must register with the
+session manager and obtain its own client-ID.  The window manager should
+save and restore information such as the WM_STATE, the layout of windows on
+the screen, and their stacking order for every client window that has a
+valid SM_CLIENT_ID property (on itself, or on the window named by
+WM_CLIENT_LEADER) and that can be uniquely identified.
+Clients are allowed to change this state during the first phase of the
+session checkpoint process.  Therefore, window managers should request a
+second checkpoint phase and save clients' state only during that phase.
+</para>
+</sect2>
+
+<sect2 id="support_for_ice_client_rendezvous">
+<title>Support for ICE Client Rendezvous</title>
+<para>
+The Inter-Client Exchange protocol (ICE) defined as of X11R6
+specifies a generic communication framework, independent of the X
+server, for data exchange between arbitrary clients.  ICE also defines
+a protocol for any two ICE clients who also have X connections
+to the same X server to locate (rendezvous with) each other.
+</para>
+<para>
+This protocol, called the "ICE X Rendezvous" protocol, is defined in
+the ICE specification, Appendix B,
+and uses the property ICE_PROTOCOLS plus
+<function>ClientMessage</function>
+events.  Refer to that specification for complete details.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="manipulation_of_shared_resources">
+<title>Manipulation of Shared Resources</title>
+<para>
+X Version 11 permits clients to manipulate a number of shared resources,
+for example, the input focus, the pointer, and colormaps.
+Conventions are required so that clients share resources in an
+orderly fashion.
+</para>
+<sect2 id="the_input_focus">
+<title>The Input Focus</title>
+<para>
+Clients that explicitly set the input focus must observe one of two modes:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Locally active mode
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Globally active mode
+    </para>
+  </listitem>
+</itemizedlist>
+
+<blockquote>
+<title>Conventions</title>
+<itemizedlist>
+  <listitem>
+    <para>
+Locally active clients should set the input focus to one of their windows
+only when it is already in one of their windows
+or when they receive a WM_TAKE_FOCUS message.
+They should set the input field of the WM_HINTS structure to
+<function>True .</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Globally active clients should set the input focus to one of their windows
+only when they receive a button event and a passive-grabbed key event,
+or when they receive a WM_TAKE_FOCUS message.
+They should set the input field of the WM_HINTS structure to
+<function>False .</function>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+In addition, clients should use the timestamp of the event
+that caused them to attempt to set the input focus as the time field on the
+<function>SetInputFocus</function>
+request, not
+<function>CurrentTime</function>.
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+
+</sect2>
+
+<sect2 id="the_pointer">
+<title>The Pointer</title>
+<para>
+In general, clients should not warp the pointer.
+Window managers, however, may do so
+(for example, to maintain the invariant that the pointer is always
+in the window with the input focus).
+Other window managers may want to preserve the illusion that the user
+is in sole control of the pointer.
+</para>
+<blockquote>
+<title>Conventions</title>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Clients should not warp the pointer.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clients that insist on warping the pointer should do so only
+with the src-window argument of the
+<function>WarpPointer</function>
+request set to one of their windows.
+    </para>
+  </listitem>
+</itemizedlist>
+</blockquote>
+</sect2>
+
+<sect2 id="grabs">
+<title>Grabs</title>
+<para>
+A client's attempt to establish a button or a key grab on a window
+will fail if some other client has already established a conflicting
+grab on the same window.
+The grabs, therefore, are shared resources,
+and their use requires conventions.
+</para>
+<para>
+In conformance with the principle that clients should behave,
+as far as possible,
+when a window manager is running as they would when it is not,
+a client that has the input focus may assume that it can receive all
+the available keys and buttons.
+</para>
+
+<blockquote>
+<title> Convention</title>
+<para>
+Window managers should ensure that they provide some mechanism for
+their clients to receive events from all keys and all buttons,
+except for events involving keys whose KeySyms are registered as being for
+window management functions (for example, a hypothetical WINDOW KeySym).
+</para>
+</blockquote>
+
+<para>
+In other words,
+window managers must provide some mechanism by which a client
+can receive events from every key and button (regardless of modifiers)
+unless and until the X Consortium registers some KeySyms as being reserved
+for window management functions.
+Currently, no KeySyms are registered for window management functions.
+</para>
+<para>
+Even so, clients are advised to allow the key and button combinations
+used to elicit program actions to be modified,
+because some window managers may choose not to observe this convention
+or may not provide a convenient method for the user to transmit events
+from some keys.
+</para>
+<blockquote>
+<title>Convention</title>
+<para>
+Clients should establish button and key grabs only on windows that
+they own.
+</para>
+</blockquote>
+
+<para>
+In particular, this convention means that a window manager that wishes
+to establish a grab over the client's top-level window should either establish
+the grab on the root or reparent the window and establish the grab
+on a proper ancestor.
+In some cases,
+a window manager may want to consume the event received,
+placing the window in a state where a subsequent such event will go to
+the client.
+Examples are:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Clicking in a window to set focus with the click not being offered
+to the client
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Clicking in a buried window to raise it, again, with the click not offered
+to the client
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+More typically,
+a window manager should add to, rather than replace, the client's semantics
+for key+button combinations by allowing the event to be used by the client
+after the window manager is done with it.
+To ensure this,
+the window manager should establish the grab on the parent
+by using the following:
+</para>
+
+<literallayout class="monospaced">
+pointer/keyboard-mode == Synchronous
+</literallayout>
+
+<para>
+Then, the window manager should release the grab by using an
+<function>AllowEvents </function>
+request with the following specified:
+</para>
+
+<literallayout class="monospaced">
+mode == ReplayPointer/Keyboard
+</literallayout>
+
+<para>
+In this way,
+the client will receive the events as if they had not been intercepted.
+</para>
+
+<para>
+Obviously,
+these conventions place some constraints on possible user interface policies.
+There is a trade-off here between freedom for window managers to implement
+their user interface policies and freedom for clients to implement theirs.
+The dilemma is resolved by:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Allowing window managers to decide if and when a client will receive an
+event from any given key or button
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Placing a requirement on the window manager to provide some mechanism,
+perhaps a "Quote" key,
+by which the user can send an event from any key or button to the client
+    </para>
+  </listitem>
+</itemizedlist>
+
+</sect2>
+<sect2 id="colormaps_2">
+<title>Colormaps</title>
+<para>
+<link linkend="colormaps">
+<xref linkend="colormaps"></xref></link>
+prescribes conventions for clients to communicate with the
+window manager about their colormap needs.  If your clients are
+<function>DirectColor</function>
+type applications,
+you should consult section 14.3 of
+<emphasis remap='I'>Xlib - C Language X Interface</emphasis>
+for conventions connected with sharing standard colormaps.
+They should look for and create the properties described there on
+the root window of the appropriate screen.
+</para>
+
+<para>
+The contents of the RGB_COLOR_MAP type property are as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>colormap</entry>
+      <entry>COLORMAP</entry>
+      <entry>ID of the colormap described</entry>
+    </row>
+    <row rowsep="0">
+      <entry>red_max</entry>
+      <entry>CARD32</entry>
+      <entry>Values for pixel calculations</entry>
+    </row>
+    <row rowsep="0">
+      <entry>red_mult</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>green_max</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>green_mult</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>blue_max</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>blue_mult</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>base_pixel</entry>
+      <entry>CARD32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>visual_id</entry>
+      <entry>VISUALID</entry>
+      <entry>Visual to which colormap belongs</entry>
+    </row>
+    <row rowsep="0">
+      <entry>kill_id</entry>
+      <entry>CARD32</entry>
+      <entry>ID for destroying the resources</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+When deleting or replacing an RGB_COLOR_MAP,
+it is not sufficient to delete the property;
+it is important to free the associated colormap resources as well.
+If kill_id is greater than one,
+the resources should be freed by issuing a
+<function>KillClient</function>
+request with kill_id as the argument.
+If kill_id is one,
+the resources should be freed by issuing a
+<function>FreeColormap</function>
+request with colormap as the colormap
+argument.
+If kill_id is zero,
+no attempt should be made to free the resources.
+A client that creates an RGB_COLOR_MAP for which the colormap resource
+is created specifically for this purpose should set kill_id to one
+(and can create more than one such standard colormap
+using a single connection).
+A client that creates an RGB_COLOR_MAP for which the colormap resource
+is shared in some way (for example, is the default colormap
+for the root window) should create an arbitrary resource and use its
+resource ID for kill_id (and should create no other standard colormaps
+on the connection).
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+If an RGB_COLOR_MAP property is too short to contain the visual_id field,
+it can be assumed that the visual_id is the root visual
+of the appropriate screen.
+If an RGB_COLOR_MAP property is too short to contain the kill_id field,
+a value of zero can be assumed.
+</para>
+</blockquote>
+
+<para>
+During the connection handshake,
+the server informs the client of the default colormap for each screen.
+This is a colormap for the root visual,
+and clients can use it to improve the extent of colormap sharing
+if they use the root visual.
+</para>
+</sect2>
+
+<sect2 id="the_keyboard_mapping">
+<title>The Keyboard Mapping</title>
+<para>
+The X server contains a table (which is read by
+<function>GetKeyboardMapping</function>
+requests) that describes the set of symbols appearing
+on the corresponding key for each keycode generated by the server.
+This table does not affect the server's operations in any way;
+it is simply a database used by clients that attempt to understand
+the keycodes they receive.
+Nevertheless, it is a shared resource and requires conventions.
+</para>
+<para>
+It is possible for clients to modify this table by using a
+<function>ChangeKeyboardMapping</function>
+request.
+In general, clients should not do this.
+In particular, this is not the way in which clients should implement
+key bindings or key remapping.
+The conversion between a sequence of keycodes received from the server
+and a string in a particular encoding is a private matter for each client
+(as it must be in a world where applications may be using different
+encodings to support different languages and fonts).
+See the Xlib reference manual for converting keyboard events to text.
+</para>
+<para>
+The only valid reason for using a
+<function>ChangeKeyboardMapping</function>
+request is when the symbols written on the keys have changed as, for example,
+when a Dvorak key conversion kit or a set of APL keycaps has been installed.
+Of course, a client may have to take the change to the keycap on trust.
+</para>
+<para>
+<!-- .LP -->
+The following illustrates a permissible interaction between a client
+and a user:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+"You just started me on a server without a Pause key.
+Please choose a key to be the Pause key and press it now."
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Presses the Scroll Lock key
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+"Adding Pause to the symbols on the Scroll Lock key: Confirm or Abort."
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Confirms
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Uses a
+<function>ChangeKeyboardMapping</function>
+request to add Pause to the keycode that already contains Scroll Lock and
+issues this request, "Please paint Pause on the Scroll Lock key."
+<!-- .NT Convention -->
+Clients should not use
+<function>ChangeKeyboardMapping</function>
+requests.
+<!-- .NE -->
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+If a client succeeds in changing the keyboard mapping table,
+all clients will receive
+<function>MappingNotify</function>
+(request==Keyboard) events.
+There is no mechanism to avoid receiving these events.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients receiving
+<function>MappingNotify</function>
+(request==Keyboard)
+events should update any internal keycode translation tables they are using.
+</para>
+</blockquote>
+
+</sect2>
+
+<sect2 id="the_modifier_mapping">
+<title>The Modifier Mapping</title>
+<para>
+X Version 11 supports 8 modifier bits of which 3 are preassigned
+to Shift, Lock, and Control.
+Each modifier bit is controlled by the state of a set of keys,
+and these sets are specified in a table accessed by
+<function>GetModifierMapping</function> and
+<function>SetModifierMapping</function> requests.
+This table is a shared resource and requires conventions.
+</para>
+
+<para>
+A client that needs to use one of the preassigned modifiers should assume
+that the modifier table has been set up correctly to control these modifiers.
+The Lock modifier should be interpreted as Caps Lock or Shift Lock
+according as the keycodes in its controlling set include XK_Caps_Lock
+or XK_Shift_Lock.
+</para>
+
+
+<blockquote>
+<title>Convention</title>
+<para>
+Clients should determine the meaning of a modifier bit from the KeySyms
+being used to control it.
+</para>
+</blockquote>
+
+<para>
+A client that needs to use an extra modifier (for example, META) should do
+the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Scan the existing modifier mappings.
+If it finds a modifier that contains a keycode whose set of KeySyms
+includes XK_Meta_L or XK_Meta_R,
+it should use that modifier bit.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If there is no existing modifier controlled by  XK_Meta_L or XK_Meta_R,
+it should select an unused modifier bit (one with an empty controlling set)
+and do the following:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+If there is a keycode with XL_Meta_L in its set of KeySyms,
+add that keycode to the set for the chosen modifier.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+If there is a keycode with XL_Meta_R in its set of KeySyms,
+add that keycode to the set for the chosen modifier.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+If the controlling set is still empty,
+interact with the user to select one or more keys to be META.
+        </para>
+      </listitem>
+    </itemizedlist>
+  </listitem>
+  <listitem>
+    <para>
+If there are no unused modifier bits,
+ask the user to take corrective action.
+    </para>
+
+    <blockquote>
+    <title>Conventions</title>
+      <itemizedlist>
+        <listitem>
+          <para>
+Clients needing a modifier not currently in use should assign keycodes
+carrying suitable KeySyms to an unused modifier bit.
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+Clients assigning their own modifier bits should ask the user politely to
+remove his or her hands from the key in question if their
+<function>SetModifierMapping</function>
+request returns a
+<function>Busy</function>
+status.
+          </para>
+        </listitem>
+      </itemizedlist>
+    </blockquote>
+  </listitem>
+</itemizedlist>
+
+<para>
+There is no good solution to the problem of reclaiming assignments
+to the five nonpreassigned modifiers when they are no longer being used.
+</para>
+
+<blockquote>
+<title>Convention</title>
+<para>
+The user must use
+<function>xmodmap</function>
+or some other utility to deassign obsolete modifier mappings by hand.
+</para>
+</blockquote>
+
+<para>
+When a client succeeds in performing a
+<function>SetModifierMapping</function>
+request,
+all clients will receive
+<function>MappingNotify</function>
+(request==Modifier) events.
+There is no mechanism for preventing these events from being received.
+A client that uses one of the nonpreassigned modifiers that receives
+one of these events should do a
+<function>GetModifierMapping</function>
+request to discover the new mapping,
+and if the modifier it is using has been cleared,
+it should reinstall the modifier.
+</para>
+
+<para>
+Note that a
+<function>GrabServer</function>
+request must be used to make the
+<function>GetModifierMapping </function>
+and
+<function>SetModifierMapping</function>
+pair in these transactions atomic.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="device_color_characterization">
+<title>Device Color Characterization</title>
+<!-- .EQ -->
+<!--
+delim @@
+define oc % "\\fR{\\fP" %
+define cc % "\\fR}\\fP" %
+-->
+<para>
+The X protocol provides explicit Red, Green, and Blue (RGB) values,
+which are used to directly drive a monitor, and color names.  RGB values
+provide a mechanism for accessing the full capabilities of the display
+device, but at the expense of having the color perceived by the user remain
+unknowable through the protocol.  Color names were originally designed to
+provide access to a device-independent color database by having the server
+vendor tune the definitions of the colors in that textual database.
+Unfortunately, this still does not provide the client any way of using
+an existing device-independent color, nor for the client to get
+device-independent color information back about colors that it has selected.
+</para>
+<para>
+Furthermore, the client must be able to discover which set of colors are
+displayable by the device (the device gamut), both to allow colors to be
+intelligently modified to fit within the device capabilities (gamut
+compression) and to enable the user interface to display a representation of
+the reachable color space to the user (gamut display).
+</para>
+<para>
+Therefore, a system is needed that will provide full access to
+device-independent color spaces for X clients.  This system should use a
+standard mechanism for naming the colors, be able to provide names for
+existing colors, and provide means by which unreachable colors can be
+modified to fall within the device gamut.
+</para>
+<para>
+We are fortunate in this area to have a seminal work, the 1931 CIE color
+standard, which is nearly universally agreed upon as adequate for describing
+colors on CRT devices.  This standard uses a tri-stimulus model called CIE
+XYZ in which each perceivable color is specified as a triplet of numbers.
+Other appropriate device-independent color models do exist, but most of them
+are directly traceable back to this original work.
+</para>
+<para>
+X device color characterization
+provides device-independent color spaces to X clients.  It does this by
+providing the barest possible amount of information to the client that
+allows the client to construct a mapping between CIE XYZ and the regular X
+RGB color descriptions.
+</para>
+<para>
+Device color characterization is defined by
+the name and contents of two window properties that,
+together, permit converting between CIE XYZ space and
+linear RGB device space (such as standard CRTs).
+Linear RGB devices require just two
+pieces of information to completely characterize them:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+A 3 x 3 matrix M and its inverse M<superscript>-1</superscript>,
+which convert between
+XYZ and RGB intensity (RGB<subscript>intensity</subscript>):
+<blockquote>
+
+<para>
+RGB<subscript>intensity</subscript> = M x XYZ
+</para>
+
+<para>
+XYZ = M<superscript>-1</superscript> x RGB<subscript>intensity</subscript>
+</para>
+
+</blockquote>
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A way of mapping between RGB intensity and RGB protocol value.  XDCCC
+supports three mechanisms which will be outlined later.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+If other device types are eventually necessary, additional
+properties will be required to describe them.
+</para>
+
+<sect2 id="xyz_rgb_conversion_matrices">
+<title>XYZ &lt;-&gt; RGB Conversion Matrices</title>
+<para>
+Because of the limited dynamic range of both XYZ and RGB intensity,
+these matrices will be encoded using a fixed-point representation of a
+32-bit two's complement number scaled by 2<superscript>27</superscript>,
+giving a range of -16 to 16 - &#x0395;, where
+&#x0395; = 2<superscript>-27</superscript>.
+</para>
+
+<para>
+These matrices will be packed into an 18-element list of 32-bit values,
+XYZ -&gt; RGB matrix first, in row major order and stored in the
+XDCCC_LINEAR_RGB_MATRICES properties (format = 32) on the root window of
+each screen, using values appropriate for that screen.
+</para>
+
+<para>
+This will be encoded as shown in the following table:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>M<subscript>0,0</subscript></entry>
+      <entry>INT32</entry>
+      <entry>Interpreted as a fixed-point number -16 &le; x &lt; 16</entry>
+    </row>
+    <row rowsep="0">
+      <entry>M<subscript>0,1</subscript></entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>M<subscript>3,3</subscript></entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>M<superscript>-1</superscript><subscript>0,0</subscript></entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>M<superscript>-1</superscript><subscript>0,1</subscript></entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+    <row rowsep="0">
+      <entry>M<superscript>-1</superscript><subscript>3,3</subscript></entry>
+      <entry>INT32</entry>
+      <entry></entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect2>
+
+<sect2 id="intensity_da_rgb_value_conversion">
+<title>Intensity (dA RGB Value Conversion</title>
+<para>
+XDCCC provides two representations for describing the conversion
+between RGB intensity and the actual X protocol RGB values:
+</para>
+
+<literallayout class="monospaced">
+0     RGB value/RGB intensity level pairs
+1     RGB intensity ramp
+</literallayout>
+
+<para>
+In both cases, the relevant data will be stored in the
+XDCCC_LINEAR_RGB_CORRECTION properties on the root window of each screen,
+using values appropriate for that screen, in whatever format provides
+adequate resolution.  Each property can consist of multiple entries
+concatenated together, if different visuals for the screen require different
+conversion data.  An entry with a VisualID of 0 specifies data for all
+visuals of the screen that are not otherwise explicitly listed.
+</para>
+<para>
+The first representation is an array of RGB value/intensity level pairs, with
+the RGB values in strictly increasing order.  When converting, the client must
+linearly interpolate between adjacent entries in the table to compute the
+desired value.  This allows the server to perform gamma correction
+itself and encode that fact in a short two-element correction table.  The
+intensity will be encoded as an unsigned number to be interpreted as a value
+between 0 and 1 (inclusive).  The precision of this value will depend on the
+format of the property in which it is stored (8, 16, or 32 bits).  For 16-bit
+and 32-bit formats, the RGB value will simply be the value stored in the
+property.  When stored in 8-bit format, the RGB value can be computed from
+the value in the property by:
+<!-- FIXME: -->
+</para>
+<para>
+<!-- .EQ C -->
+RGB sub value ~ = ~ { Property ~ Value ~ times ~ 65535 } over 255
+<!-- .EN -->
+</para>
+<para>
+Because the three electron guns in the device may not be exactly alike in
+response characteristics, it is necessary to allow for three separate
+tables, one each for red, green, and blue.  Therefore, each table will be
+preceded by the number of entries in that table, and the set of tables will be
+preceded by the number of tables.
+When three tables are provided, they will be in red, green, blue order.
+</para>
+<para>
+This will be encoded as shown in the following table:
+</para>
+
+<para>
+XDCCC_LINEAR_RGB_CORRECTION Property Contents for Type 0 Correction
+</para>
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>VisualID0</entry>
+      <entry>CARD</entry>
+      <entry>Most significant portion of VisualID</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID1</entry>
+      <entry>CARD</entry>
+      <entry>Exists if and only if the property format is 8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID2</entry>
+      <entry>CARD</entry>
+      <entry>Exists if and only if the property format is 8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID3</entry>
+      <entry>CARD</entry>
+      <entry>
+Least significant portion, exists if and only if the property
+format is 8 or 16
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>type</entry>
+      <entry>CARD</entry>
+      <entry>0 for this type of correction</entry>
+    </row>
+    <row rowsep="0">
+      <entry>count</entry>
+      <entry>CARD</entry>
+      <entry>Number of tables following (either 1 or 3)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>length</entry>
+      <entry>CARD</entry>
+      <entry>Number of pairs -1 following in this table</entry>
+    </row>
+    <row rowsep="0">
+      <entry>value</entry>
+      <entry>CARD</entry>
+      <entry>X Protocol RBG value</entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>lengthg</entry>
+      <entry>CARD</entry>
+      <entry>
+Number of pairs -1 following in this table (if and only if
+<emphasis>count</emphasis> is 3
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>value</entry>
+      <entry>CARD</entry>
+      <entry>X Protocol RBG value</entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as a number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>lengthb</entry>
+      <entry>CARD</entry>
+      <entry>
+Number of pairs -1 following in this table (if and only if
+<emphasis>count</emphasis> is 3
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>value</entry>
+      <entry>CARD</entry>
+      <entry>X Protocol RBG value</entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as a number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The VisualID is stored in 4, 2, or 1 pieces, depending on whether
+the property format is 8, 16, or 32, respectively.  The VisualID is always
+stored most significant piece first.
+Note that the length fields are stored as one less than the actual length,
+so 256 entries can be stored in format 8.
+</para>
+<para>
+The second representation is a simple array of intensities for a linear subset
+of RGB values.  The expected size of this table is the bits-per-rgb-value of
+the screen, but it can be any length.  This is similar to the first mechanism,
+except that the RGB value numbers are implicitly defined by the index in the
+array (indices start at 0):
+</para>
+<blockquote>
+<para>
+<!-- FIXME -->
+<!-- .EQ C -->
+RGB sub value ~ = ~ { Array ~ Index ~ times ~ 65535 } over
+{ Array ~ Size ~ - ~ 1 }
+</para>
+</blockquote>
+
+<para>
+When converting, the client may linearly interpolate between entries in this
+table.  The intensity values will be encoded just as in the first
+representation.
+</para>
+
+<para>
+This will be encoded as shown in the following table:
+</para>
+
+<para>
+XDCCC_LINEAR_RGB_CORRECTION Property Contents for Type 1 Correction
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Field</entry>
+      <entry>Type</entry>
+      <entry>Comments</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>VisualID0</entry>
+      <entry>CARD</entry>
+      <entry>Most significant portion of VisualID</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID1</entry>
+      <entry>CARD</entry>
+      <entry>Exists if and only if the property format is 8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID2</entry>
+      <entry>CARD</entry>
+      <entry>Exists if and only if the property format is 8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>VisualID3</entry>
+      <entry>CARD</entry>
+      <entry>
+Least significant portion, exists if and only if the property
+format is 8 or 16
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>type</entry>
+      <entry>CARD</entry>
+      <entry>1 for this type of correction</entry>
+    </row>
+    <row rowsep="0">
+      <entry>count</entry>
+      <entry>CARD</entry>
+      <entry>Number of tables following (either 1 or 3)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>length</entry>
+      <entry>CARD</entry>
+      <entry>Number of pairs -1 following in this table</entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>lengthg</entry>
+      <entry>CARD</entry>
+      <entry>
+Number of pairs -1 following in this table (if and only if
+<emphasis>count</emphasis> is 3
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as a number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>lengthb</entry>
+      <entry>CARD</entry>
+      <entry>
+Number of pairs -1 following in this table (if and only if
+<emphasis>count</emphasis> is 3
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>intensity</entry>
+      <entry>CARD</entry>
+      <entry>
+Interpret as a number 0 &le; <emphasis>intensity</emphasis> &le; 1
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>...</entry>
+      <entry>...</entry>
+      <entry>
+Total of <emphasis remap='I'>length+1</emphasis> pairs of
+value/intensity values
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect2>
+</sect1>
+
+<sect1 id="conclusion">
+<title>Conclusion</title>
+<para>
+This document provides the protocol-level specification of the minimal
+conventions needed to ensure that X Version 11 clients can interoperate
+properly.  This document specifies interoperability conventions only for the
+X Version 11 protocol.  Clients should be aware of other protocols that
+should be used for better interoperation in the X environment.  The reader
+is referred to
+<emphasis remap='I'>X Session Management Protocol</emphasis>
+for information on session management, and to
+<emphasis remap='I'>Inter-Client Exchange Protocol</emphasis>
+for information on general-purpose communication among clients.
+</para>
+
+<sect2 id="the_x_registry">
+<title>The X Registry</title>
+<!-- .IN "X Registry" -->
+<para>
+The X Consortium maintains a registry of certain X-related items, to aid in
+avoiding conflicts and in sharing of such items.  Readers are
+encouraged to use the registry.  The classes of items kept in the registry
+that are relevant to the ICCCM include property names, property types,
+selection names, selection targets, WM_PROTOCOLS protocols,
+<function>ClientMessage</function>
+types, and application classes.  Requests to register items, or questions
+about registration, should be addressed to
+</para>
+<literallayout class="monospaced">
+     xregistry@x.org
+</literallayout>
+<para>
+or to
+</para>
+<literallayout class="monospaced">
+        The X.Org Group -- X11 Registry
+        c/o Ienup Sung
+        Sun Microsystems, Inc.
+        4150 Network Circle, MS SJC07-201
+        Santa Clara, CA 95054
+     USA
+</literallayout>
+<para>
+Electronic mail will be acknowledged upon receipt.  Please allow up to 4
+weeks for a formal response to registration and inquiries.
+</para>
+<para>
+The registry is published as part of the X software distribution from the X
+Consortium.  All registered items must have the postal address of someone
+responsible for the item or a reference to a document describing the item
+and the postal address of where to write to obtain the document.
+</para>
+<!-- .bp -->
+<!-- .\" Set registers to number the appendixes A.1, B.1, C.1, ... -->
+<!-- .nr H1 0 -->
+<!-- .af H1 A -->
+<!-- .cT "Appendix A" no -->
+</sect2>
+</sect1>
+</chapter>
+
+<appendix id="revision_history">
+<title>Revision History</title>
+<para>
+This appendix describes the revision history of this document and
+summarizes the incompatibilities between this and earlier versions.
+</para>
+<sect1 id="the_x11r2_draft">
+<title>The X11R2 Draft</title>
+<para>
+The February 25, 1988, draft that was distributed as part of X Version 11,
+Release 2, was clearly labeled as such,
+and many areas were explicitly labeled as liable to change.
+Nevertheless, in the revision work done since then,
+we have been very careful not to introduce gratuitous incompatibility.
+As far as possible,
+we have tried to ensure that clients obeying the conventions
+in the X11R2 draft would still work.
+</para>
+</sect1>
+
+<sect1 id="the_july_draft">
+<title>The July 27, 1988, Draft</title>
+<para>
+The Consortium review was based on a draft dated July 27, 1988.  This draft
+included several areas in which incompatibilities with the X11R2 draft were
+necessary:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The use of property
+<function>None</function>
+in
+<function>ConvertSelection</function>
+requests is no longer allowed.
+Owners that receive them are free to use the target atom as the property
+to respond with,
+which will work in most cases.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The protocol for INCREMENTAL type properties as selection replies has changed,
+and the name has been changed to INCR.
+Selection requestors are free to implement the earlier protocol
+if they receive properties of type INCREMENTAL.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The protocol for INDIRECT type properties as selection replies has changed,
+and the name has been changed to MULTIPLE.
+Selection requestors are free to implement the earlier protocol
+if they receive properties of type INDIRECT.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The protocol for the special CLIPBOARD client has changed.
+The earlier protocol is subject to race conditions and should not be used.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The set of state values in WM_HINTS.initial_state has been reduced,
+but the values that are still valid are unchanged.
+Window managers should treat the other values sensibly.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The methods an application uses to change the state of its top-level window
+have changed but in such a way that cases that used to work will still work.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The x, y, width, and height fields have been removed from the WM_NORMAL_HINTS
+property and replaced by pad fields.
+Values set into these fields will be ignored.
+The position and size of the window should be set by setting the appropriate
+window attributes.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A pair of base fields and a win_gravity field have been added
+to the WM_NORMAL_HINTS property.
+Window managers will assume values for these fields if the client
+sets a short property.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="the_public_review_drafts">
+<title>The Public Review Drafts</title>
+<para>
+The Consortium review resulted in several incompatible changes.  These
+changes were included in drafts that were distributed for public review
+during the first half of 1989.
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The messages field of the WM_HINTS property was found to be unwieldy
+and difficult to evolve.
+It has been replaced by the WM_PROTOCOLS property,
+but clients that use the earlier mechanism can be detected
+because they set the messages bit in the flags field of the WM_HINTS property,
+and window managers can provide a backwards compatibility mode.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The mechanism described in the earlier draft by which clients installed
+their own subwindow colormaps could not be made to work reliably
+and mandated some features of the look and feel.
+It has been replaced by the WM_COLORMAP_WINDOWS property.
+Clients that use the earlier mechanism can be detected by the WM_COLORMAPS
+property they set on their top-level window,
+but providing a reliable backwards compatibility mode is not possible.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The recommendations for window manager treatment of top-level window borders
+have been changed as those in the earlier draft produced problems
+with Visibility events.
+For nonwindow manager clients,
+there is no incompatibility.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The pseudoroot facility in the earlier draft has been removed.
+Although it has been successfully implemented,
+it turns out to be inadequate to support the uses envisaged.
+An extension will be required to support these uses fully,
+and it was felt that the maximum freedom should be left to the designers
+of the extension.
+In general,
+the previous mechanism was invisible to clients and no incompatibility
+should result.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The addition of the WM_DELETE_WINDOW protocol (which prevents the danger
+that multi-window clients may be terminated unexpectedly)
+has meant some changes in the WM_SAVE_YOURSELF protocol,
+to ensure that the two protocols are orthogonal.
+Clients using the earlier protocol can be detected (see WM_PROTOCOLS above)
+and supported in a backwards compatibility mode.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The conventions in Section 14.3.1. of
+<emphasis remap='I'>Xlib - C Language X Interface</emphasis>
+regarding properties of type RGB_COLOR_MAP have been changed,
+but clients that use the earlier conventions can be detected
+because their properties are 4 bytes shorter.
+These clients will work correctly if the server supports only a single Visual
+or if they use only the Visual of the root.
+These are the only cases in which they would have worked, anyway.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="version_1.0_july_1989">
+<title>Version 1.0, July 1989</title>
+<para>
+The public review resulted in a set of mostly editorial changes.  The
+changes in version 1.0 that introduced some degree of incompatibility with
+the earlier drafts are:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+A new section (
+<link linkend="grabs">
+<xref linkend="grabs"></xref></link>
+) was added covering the window manager's
+use of Grabs.
+The restrictions it imposes should affect only window managers.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The TARGETS selection target has been clarified,
+and it may be necessary for clients to add some entries to their replies.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+A selection owner using INCR transfer should no longer replace targets in
+a MULTIPLE property with the atom INCR.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The contents of the
+<function>ClientMessage</function>
+event sent by a client to iconify itself has been clarified,
+but there should be no incompatibility because the earlier contents
+would not in fact have worked.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The border-width in synthetic
+<function>ConfigureNotify</function>
+events is now specified,
+but this should not cause any incompatibility.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Clients are now asked to set a border-width on all
+<function>ConfigureWindow</function>
+requests.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Window manager properties on icon windows now will be ignored,
+but there should be no incompatibility
+because there was no specification that they be obeyed previously.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The ordering of real and synthetic
+<function>ConfigureNotify</function>
+events is now specified,
+but any incompatibility should affect only window managers.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The semantics of WM_SAVE_YOURSELF have been clarified and restricted to
+be a checkpoint operation only.
+Clients that were using it as part of a shutdown sequence may need to
+be modified,
+especially if they were interacting with the user during the shutdown.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+A kill_id field has been added to RGB_COLOR_MAP properties.
+Clients using earlier conventions can be detected by the size of their
+RGB_COLOR_MAP properties,
+and the cases that would have worked will still work.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="version_1.1">
+<title>Version 1.1</title>
+<para>
+Version 1.1 was released with X11R5 in September 1991.  In addition to some
+minor editorial changes, there were a few semantic changes since Version
+1.0:
+</para>
+
+
+<itemizedlist>
+  <listitem>
+    <para>
+<!-- .bP -->
+The section on Device Color Characterization was added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The meaning of the NULL property type was clarified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Appropriate references to Compound Text were added.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="public_review_draft_december_1993">
+<title>Public Review Draft, December 1993</title>
+<para>
+The following changes have been made in preparing the public review draft
+for Version 2.0.
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+[P01] Addition of advice to clients on how to keep track of a top-level
+window's absolute position on the screen.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P03] A technique for clients to detect when it is safe to reuse a
+top-level window has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P06]
+<link linkend="colormaps">
+<xref linkend="colormaps"></xref></link>
+, on colormaps, has been rewritten.  A new feature that
+allows clients to install their own colormaps has also been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P08] The LENGTH target has been deprecated.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P11] The manager selections facility was added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P17] The definition of the aspect ratio fields of the WM_NORMAL_HINTS
+property has been changed to include the base size.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P19]
+<function>StaticGravity</function>
+has been added to the list of values allowed for the win_gravity field of
+the WM_HINTS property.  The meaning of the
+<function>CenterGravity</function>
+value has been clarified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P20] A means for clients to query the ICCCM compliance level of the window
+manager has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P22] The definition of the MULTIPLE selection target has been clarified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P25] A definition of "top-level window" has been added.  The WM_STATE
+property has been defined and exposed to clients.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P26] The definition of window states has been clarified and the wording
+regarding window state changes has been made more consistent.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P27] Clarified the rules governing when window managers are required to send
+synthetic
+<function>ConfigureNotify</function>
+events.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P28] Added a recommended technique for setting the input focus to a window
+as soon as it is mapped.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P29] The required lifetime of resource IDs named in window manager
+properties has been specified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P30] Advice for dealing with keystrokes and override-redirect windows has
+been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P31] A statement on the ownership of resources transferred through the
+selection mechanism has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P32] The definition of the CLIENT_WINDOW target has been clarified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P33] A rule about requiring the selection owner to reacquire the
+selection under certain circumstances has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P42] Added several new selection targets.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P44] Ambiguous wording regarding the withdrawal of top-level windows
+has been removed.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P45] A facility for requestors to pass parameters during a selection
+request has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P49] A convention on discrimated names has been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P57] The C_STRING property type was added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P62] An ordering requirement on processing selection requests was added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P63] The
+<function>VisibleHint</function>
+flag was added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+[P64] The session management section has been updated to align with the new
+session management protocol.  The old session management conventions have
+been moved to Appendix C.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+References to the never-forthcoming
+<emphasis remap='I'>Window and Session Manager
+Conventions Manual</emphasis> have been removed.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Information on the X Registry and references to the session management and
+ICE documents have been added.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Numerous editorial and typographical improvements have been made.
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="version_2.0_april_1994">
+<title>Version 2.0, April 1994</title>
+<para>
+The following changes have been made in preparation for releasing
+the final edition of Version 2.0 with X11R6.
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+<!-- .bP -->
+The PIXMAP selection target has been revised to return a property of type
+PIXMAP instead of type DRAWABLE.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The session management section has been revised slightly to correspond with
+the changes to the
+<emphasis remap='I'>X Session Management Protocol</emphasis>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Window managers are now prohibited from placing
+<function>CurrentTime</function>
+in the timestamp field of WM_TAKE_FOCUS messages.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+In the WM_HINTS property, the
+<function>VisibleHint</function>
+flag has been renamed to
+<function>UrgencyHint .</function>
+Its semantics have also been defined more thoroughly.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Additional editorial and typographical changes have been made.
+    </para>
+  </listitem>
+</itemizedlist>
+<!-- .bp -->
+<!-- .cT "Appendix B" no -->
+</sect1>
+</appendix>
+
+<appendix id="suggested_protocol_revisions">
+<title>Suggested Protocol Revisions</title>
+<para>
+During the development of these conventions,
+a number of inadequacies have been discovered in the
+core X11 protocol.
+They are summarized here as input to an eventual protocol revision
+design process:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+There is no way for anyone to find out the last-change time of
+a selection.
+The
+<function>GetSelectionOwner</function>
+request should be changed to return the last-change time as well as the owner.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+There is no way for a client to find out which selection atoms are valid.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+There would be no need for WM_TAKE_FOCUS if the
+<function>FocusIn</function>
+event contained a timestamp and a previous-focus field.
+This could avoid the potential race condition.
+There is space in the event for this information;
+it should be added at the next protocol revision.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+There is a race condition in the
+<function>InstallColormap </function>
+request.
+It does not take a timestamp and may be executed after the top-level colormap
+has been uninstalled.
+The next protocol revision should provide the timestamp in the
+<function>InstallColormap ,</function>
+<function>UninstallColormap ,</function>
+<function>ListInstalledColormaps </function>
+requests and in the
+<function>ColormapNotify</function>
+event.
+The timestamp should be used in a similar way to the last-focus-change
+time for the input focus.  The lack of timestamps in these packets is the
+reason for restricting colormap installation to the window manager.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+The protocol needs to be changed to provide some way of identifying
+the Visual and the Screen of a colormap.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+There should be some way to reclaim assignments to the five nonpreassigned
+modifiers when they are no longer needed.  The manual method is unpleasantly
+low-tech.
+    </para>
+  </listitem>
+</itemizedlist>
+<!-- .bp -->
+</appendix>
+
+<appendix id="obsolete_session_manager_conventions">
+<title>Obsolete Session Manager Conventions</title>
+
+<para>
+This appendix contains obsolete conventions for session management using X
+properties and messages.  The conventions described here are deprecated and
+are described only for historical interest.  For further information on
+session management, see
+<emphasis remap='I'>X Session Management Protocol</emphasis>.
+</para>
+
+<sect1 id="properties">
+<title>Properties</title>
+<para>
+The client communicates with the session manager by placing two properties
+(WM_COMMAND and WM_CLIENT_MACHINE) on its top-level window.
+If the client has a group of top-level windows,
+these properties should be placed on the group leader window.
+</para>
+<para>
+The window manager is responsible for placing a WM_STATE property
+on each top-level client window for use by session managers and other clients
+that need to be able to identify top-level client windows and their state.
+</para>
+
+<sect2 id="wm_command_property">
+<title>WM_COMMAND Property</title>
+<para>
+The WM_COMMAND property represents the command used to start or restart the
+client.  By updating this property, clients should ensure that it always
+reflects a command that will restart them in their current state.  The
+content and type of the property depend on the operating system of the
+machine running the client.  On POSIX-conformant systems using ISO Latin-1
+characters for their command lines, the property should:
+</para>
+
+<!-- .bP -->
+<itemizedlist>
+  <listitem>
+    <para>
+Be of type STRING
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Contain a list of null-terminated strings
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be initialized from argv
+    </para>
+    <para>
+Other systems will need to set appropriate conventions for the type
+and contents of WM_COMMAND properties.
+Window and session managers should not assume that STRING is
+the type of WM_COMMAND or that they will be able to understand
+or display its contents.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+Note that WM_COMMAND strings are null-terminated
+and differ from the general conventions that STRING properties
+are null-separated.
+This inconsistency is necessary for backwards compatibility.
+</para>
+<para>
+A client with multiple top-level windows should ensure
+that exactly one of them has a WM_COMMAND with nonzero length.
+Zero-length WM_COMMAND properties can be used to reply to WM_SAVE_YOURSELF
+messages on other top-level windows but will otherwise be ignored.
+</para>
+</sect2>
+
+<sect2 id="wm_client_machine_property_2">
+<title>WM_CLIENT_MACHINE Property</title>
+<para>
+This property is described in
+<link linkend="wm_client_machine_property">
+<xref linkend="wm_client_machine_property"></xref></link>.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="termination">
+<title>Termination</title>
+<para>
+Because they communicate by means of unreliable network connections, clients
+must be prepared for their connection to the server to be terminated at any
+time without warning.  They cannot depend on getting notification that
+termination is imminent or on being able to use the server to negotiate with
+the user about their fate.  For example, clients cannot depend on being able
+to put up a dialog box.
+</para>
+<para>
+Similarly, clients may terminate at any time without notice to the session
+manager.  When a client terminates itself rather than being terminated by
+the session manager, it is viewed as having resigned from the session in
+question, and it will not be revived if the session is revived.
+</para>
+</sect1>
+
+<sect1 id="client_responses_to_session_manager_actions">
+<title>Client Responses to Session Manager Actions</title>
+<para>
+Clients may need to respond to session manager actions in two ways:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Saving their internal state
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<!-- .bP -->
+Deleting a window
+    </para>
+  </listitem>
+</itemizedlist>
+
+<sect2 id="saving_client_state">
+<title>Saving Client State</title>
+<para>
+Clients that want to be warned when the session manager feels
+that they should save their internal state (for example,
+when termination impends) should include the atom WM_SAVE_YOURSELF
+in the WM_PROTOCOLS property on their top-level windows to participate
+in the WM_SAVE_YOURSELF protocol.
+They will receive a
+<function>ClientMessage</function>
+event as described in
+<link linkend="clientmessage_events">
+<xref linkend="clientmessage_events"></xref></link>
+with the atom WM_SAVE_YOURSELF in its data[0] field.
+</para>
+
+<para>
+Clients that receive WM_SAVE_YOURSELF should place themselves in a state from
+which they can be restarted and should update WM_COMMAND to
+be a command that will restart them in this state.
+The session manager will be waiting for a
+<function>PropertyNotify</function>
+event on WM_COMMAND as a confirmation that the client has saved its state.
+Therefore, WM_COMMAND should be updated (perhaps with a zero-length append)
+even if its contents are correct.
+No interactions with the user are permitted during this process.
+</para>
+
+<para>
+Once it has received this confirmation,
+the session manager will feel free to terminate the client if that is what
+the user asked for.
+Otherwise,
+if the user asked for the session to be put to sleep,
+the session manager will ensure that the client does not
+receive any mouse or keyboard events.
+</para>
+
+<para>
+After receiving a WM_SAVE_YOURSELF, saving its state, and updating WM_COMMAND,
+the client should not change its state (in the sense of doing anything
+that would require a change to WM_COMMAND) until it receives a mouse
+or keyboard event.
+Once it does so,
+it can assume that the danger is over.
+The session manager will ensure that these events do not reach
+clients until the danger is over or until the clients have been killed.
+</para>
+
+<para>
+Irrespective of how they are arranged in window groups,
+clients with multiple top-level windows should ensure the following:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Only one of their top-level windows has a nonzero-length WM_COMMAND
+property.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+They respond to a WM_SAVE_YOURSELF message by:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+First, updating the nonzero-length WM_COMMAND property, if necessary
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+Second, updating the WM_COMMAND property on the window for which they received
+the WM_SAVE_YOURSELF message if it was not updated in the first step
+        </para>
+      </listitem>
+    </itemizedlist>
+  </listitem>
+</itemizedlist>
+
+<para>
+Receiving WM_SAVE_YOURSELF on a window is, conceptually, a command
+to save the entire client state.
+<footnote><para>
+This convention has changed since earlier drafts because of the
+introduction of the protocol in the next section.
+In the public review draft,
+there was ambiguity as to whether WM_SAVE_YOURSELF was a checkpoint
+or a shutdown facility.
+It is now unambiguously a checkpoint facility;
+if a shutdown facility is judged to be necessary,
+a separate WM_PROTOCOLS protocol will be developed and registered
+with the X Consortium.
+</para>
+</footnote>
+</para>
+</sect2>
+
+<sect2 id="window_deletion_2">
+<title>Window Deletion</title>
+<para>
+Windows are deleted using the WM_DELETE_WINDOW protocol, which
+is described in
+<link linkend="window_deletion">
+<xref linkend="window_deletion"></xref></link>.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="summary_of_session_manager_property_types">
+<title>Summary of Session Manager Property Types</title>
+<para>
+The session manager properties are listed in the following table:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='4' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <colspec colname='c4' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Name</entry>
+      <entry>Type</entry>
+      <entry>Format</entry>
+      <entry>See Section</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>WM_CLIENT_MACHINE</entry>
+      <entry>TEXT</entry>
+      <entry></entry>
+      <entry>
+<link linkend="wm_client_machine_property">
+<xref linkend="wm_client_machine_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_COMMAND</entry>
+      <entry>TEXT</entry>
+      <entry></entry>
+      <entry>
+<link linkend="wm_command_property">
+<xref linkend="wm_command_property"></xref></link>
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>WM_STATE</entry>
+      <entry>WM_STATE</entry>
+      <entry>32</entry>
+      <entry>
+<link linkend="wm_state_property">
+<xref linkend="wm_state_property"></xref></link>
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect1>
+</appendix>
+</book>
diff --git a/specs/ICCCM/indexmacros.t b/specs/ICCCM/indexmacros.t
deleted file mode 100644
index 13a4375..0000000
--- a/specs/ICCCM/indexmacros.t
+++ /dev/null
@@ -1,3 +0,0 @@
-.eh '\s+1\fBInter-Client Communication Conventions\fP''\fBX11, Release 6.8\fP\s-1'
-.oh '\s+1\fBInter-Client Communication Conventions\fP''\fBX11, Release 6.8\fP\s-1'
-.so index.pageno
diff --git a/specs/XLFD/xlfd.tbl.ms b/specs/XLFD/xlfd.tbl.ms
deleted file mode 100644
index e14f90e..0000000
--- a/specs/XLFD/xlfd.tbl.ms
+++ /dev/null
@@ -1,2827 +0,0 @@
-.\" Use tbl and -ms and macros.t	-*- Nroff -*-
-.\" $Xorg: xlfd.tbl.ms,v 1.3 2000/08/17 19:42:22 cpqbld Exp $
-.\" $XdotOrg: xc/doc/specs/XLFD/xlfd.tbl.ms,v 1.2 2004/04/23 18:42:17 eich Exp $
-.nr sM 4		\" section on Matrix Transformations
-.nr sS 5		\" section on Scalable fonts
-.nr sP 6		\" section on Polymorphic font support
-.EH ''''
-.OH ''''
-.EF ''''
-.OF ''''
-.ps 11
-.nr PS 11
-.if n .nr LL 72m
-\&
-.sp 8
-.ce 100
-\s+2\fBX Logical Font Description Conventions\fP\s-2
-
-\fBVersion 1.5\fP
-
-\fBX Consortium Standard\fP
-
-\fBX Version 11, Release 6.8\fP
-.sp 6
-\s+1Jim Flowers\s-1
-.sp 6p
-\s+1Digital Equipment Corporation\s-1
-.sp 6
-\s+1Version 1.5 edited by Stephen Gildea\s0
-.sp 6p
-\s+1X Consortium, Inc.\s0
-.ce 0
-.bp
-\&
-.ps 9
-.nr PS 9
-.sp 8
-.LP
-\fIX Window System\fP is a trademark of The Open Group.
-.LP             
-Helvetica and Times are registered trademarks of Linotype Company.
-.LP
-ITC Avant Garde Gothic is a registered trademark of International 
-Typeface Corporation.
-.LP
-Times Roman is a registered trademark of Monotype Corporation.
-.LP
-Bitstream Amerigo is a registered trademark of Bitstream Inc.
-.LP             
-Stone is a registered trademark of Adobe Systems Inc.
-.LP
-Copyright \(co 1988, 1994 X Consortium
-.LP
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-\*QSoftware\*U), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-.LP
-The above copyright notice and this permission notice shall be included
-in all copies or substantial portions of the Software.
-.LP
-THE SOFTWARE IS PROVIDED \*QAS IS\*U, 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.
-.LP
-Except as contained in this notice, the name of the X Consortium shall
-not be used in advertising or otherwise to promote the sale, use or
-other dealings in this Software without prior written authorization
-from the X Consortium.
-.LP
-Copyright \(co 1988, 1989 
-Digital Equipment Corporation, Maynard MA.  All rights reserved.
-.LP 
-Permission to use, copy, modify, and distribute this documentation 
-for any purpose and without fee is hereby granted, provided 
-that the above copyright notice and this permission 
-notice appear in all copies.
-Digital Equipment Corporation makes no representations
-about the 
-suitability for any purpose of the information in this document. 
-This documentation is provided as is without express or implied warranty. 
-.ps 11
-.nr PS 11
-.bp 1
-.EH '\fBX Logical Font Description Conventions\fP''\fBX11, Release 6.8\fP'
-.OH '\fBX Logical Font Description Conventions\fP''\fBX11, Release 6.8\fP'
-.EF ''\fB\\\\n(PN\fP''
-.OF ''\fB\\\\n(PN\fP''
-.NH 1 
-Introduction
-.XS
-\*(SN Introduction
-.XE
-.LP 
-It is a requirement that X client applications must be portable across server
-implementations, with very different file systems, naming conventions, and 
-font libraries.
-However, font access requests, 
-as defined by the \fIX Window System Protocol\fP,
-neither specify server-independent conventions for font names 
-nor provide adequate font properties for logically describing typographic fonts.
-.LP
-X clients must be able to dynamically determine the fonts available 
-on any given server so that understandable information can be presented 
-to the user or so that intelligent font fallbacks can be chosen.
-It is desirable for the most common queries to be accomplished 
-without the overhead of opening each font and inspecting font properties, 
-by means of simple 
-.PN ListFonts 
-requests.
-For example, if a user selected a Helvetica typeface family, 
-a client application should be able to query the server 
-for all Helvetica fonts and present only those setwidths, weights, slants, 
-point sizes, and character sets available for that family.
-.LP
-This document gives a standard logical font description 
-(hereafter referred to as XLFD) and the conventions to be used 
-in the core protocol so that clients can query and access screen type libraries
-in a consistent manner across all X servers.
-In addition to completely specifying a given font by means of its 
-.PN FontName ,
-the XLFD also provides for a standard set of key 
-.PN FontProperties
-that describe the font in more detail.
-.LP
-The XLFD provides an adequate set of typographic font properties, 
-such as \s-1CAP_HEIGHT\s+1, \s-1X_HEIGHT\s+1,
-and \s-1RELATIVE_SETWIDTH\s+1, 
-for publishing and other applications to do intelligent font matching 
-or substitution when handling documents created on some foreign server 
-that use potentially unknown fonts.
-In addition, 
-this information is required by certain clients 
-to position subscripts automatically and determine small capital heights, 
-recommended leading, word-space values, and so on.
-.NH 1
-Requirements and Goals
-.XS
-\*(SN Requirements and Goals
-.XE
-.LP 
-The XLFD meets the short-term and long-term goals to have a 
-standard logical font description that:
-.IP \(bu 5
-Provides unique, descriptive font names that support simple pattern
-matching
-.IP \(bu 5
-Supports multiple font vendors, arbitrary character sets, and encodings
-.IP \(bu 5
-Supports naming and instancing of scalable and polymorphic fonts
-.IP \(bu 5
-Supports transformations and subsetting of fonts
-.IP \(bu 5
-Is independent of X server and operating or file system implementations
-.IP \(bu 5
-Supports arbitrarily complex font matching or substitution
-.IP \(bu 5
-Is extensible
-.NH 2
-Provide Unique and Descriptive Font Names
-.XS
-\*(SN Provide Unique and Descriptive Font Names
-.XE
-.LP
-It should be possible to have font names that are long enough and 
-descriptive enough to have a reasonable probability of being unique 
-without inventing a new registration organization.
-Resolution and size-dependent font masters, multivendor font libraries, 
-and so on must be anticipated and handled by the font name alone.
-.LP
-The name itself should be structured to be amenable to simple pattern 
-matching and parsing, thus allowing X clients to restrict font queries to 
-some subset of all possible fonts in the server.
-.NH 2
-Support Multiple Font Vendors and Character Sets
-.XS
-\*(SN Support Multiple Font Vendors and Character Sets
-.XE
-.LP
-The font name and properties should distinguish between fonts 
-that were supplied by different font vendors 
-but that possibly share the same name.
-We anticipate a highly competitive font market where users will be able to 
-buy fonts from many sources according to their particular requirements.
-.LP
-A number of font vendors deliver each font with all glyphs designed for that
-font, where charset mappings are defined by encoding vectors.
-Some server implementations may force these mappings to proprietary 
-or standard charsets statically in the font data.
-Others may desire to perform the mapping dynamically in the server.
-Provisions must be made in the font name 
-that allows a font request to specify or identify specific charset mappings 
-in server environments where multiple charsets are supported.
-.NH 2
-Support Scalable and Polymorphic Fonts
-.XS
-\*(SN Support Scalable and Polymorphic Fonts
-.XE
-.LP
-If a font source can be scaled to an arbitrary size or varied in other
-ways, it should be possible for an application to determine
-that fact from the font name, and the
-application should be able to construct a font name for any specific
-instance.
-.NH 2
-Support Transformations and Subsetting of Fonts
-.XS
-\*(SN Support Transformations and Subsetting of Fonts
-.XE
-.LP
-Arbitrary two-dimensional linear transformations of fonts should be
-able to be requested by applications.  Since such transformed fonts
-may be used for special effects requiring a few characters from each
-of many differently transformed fonts, it should be possible to
-request only a few characters from a font for efficiency.
-.NH 2
-Be Independent of X Server and Operating or File System Implementations
-.XS
-\*(SN Be Independent of X Server and Operating or File System Implementations
-.XE
-.LP
-X client applications that require a particular font should be able to use 
-the descriptive name without knowledge of the file system or other 
-repository in use by the server.
-However, 
-it should be possible for servers to translate a given font name 
-into a file name syntax that it knows how to deal with,
-without compromising the uniqueness of the font name.
-This algorithm should be reversible (exactly how this translation is done is 
-implementation dependent).
-.NH 2
-Support Arbitrarily Complex Font Matching and Substitution
-.XS
-\*(SN Support Arbitrarily Complex Font Matching and Substitution
-.XE
-.LP
-In addition to the font name, 
-the XLFD should define a standard list of descriptive font properties,
-with agreed-upon fallbacks for all fonts.
-This allows client applications to derive font-specific formatting 
-or display data and to perform font matching or substitution 
-when asked to handle potentially unknown fonts, as required.
-.NH 2
-Be Extensible
-.XS
-\*(SN Be Extensible
-.XE
-.LP
-The XLFD must be extensible so that new and/or private descriptive font 
-properties can be added to conforming fonts without making existing 
-X client or server implementations obsolete.
-.NH 1
-X Logical Font Description
-.XS
-\*(SN X Logical Font Description
-.XE
-.LP
-XLFD is divided into two basic components: 
-the 
-.PN FontName , 
-which gives all font information needed to uniquely identify a font 
-in X protocol requests (for example,
-.PN OpenFont , 
-.PN ListFonts , 
-and so on) and a variable list of optional 
-.PN FontProperties ,
-which describe a font in more detail.
-.LP
-The 
-.PN FontName 
-is used in font queries and is returned as data in certain X protocol requests.
-It is also specified as the data value for the 
-.PN FONT
-item in the X Consortium Character Bitmap Distribution Format Standard
-(BDF V2.1).
-.LP
-The 
-.PN FontProperties 
-are supplied on a font-by-font basis and are returned 
-as data in certain X protocol requests as part of the 
-.PN XFontStruct
-data structure.
-The names and associated data values for each of the 
-.PN FontProperties 
-may also appear as items of the 
-\s-1\fBSTARTPROPERTIES\fP\s+1...\s-1\fBENDPROPERTIES\fP\s+1 list 
-in the BDF V2.1 specification.
-.NH 2
-FontName
-.XS
-\*(SN FontName
-.XE
-.LP
-Each 
-.PN FontName 
-is logically composed of two strings: a 
-.PN FontNameRegistry
-prefix that is followed by a 
-.PN FontNameSuffix .
-The
-.PN FontName
-uses the ISO 8859-1 encoding.
-The 
-.PN FontNameRegistry
-is an
-.IN x-registered-name
-x-registered-name (a name that has been registered with the X Consortium)
-that identifies the registration authority that owns the specified 
-.PN FontNameSuffix
-syntax and semantics.
-.LP
-All font names that conform to this specification are to use a 
-.PN FontNameRegistry
-prefix, which is defined to be the string \*Q\-\*U
-(HYPHEN).
-All 
-.PN FontNameRegistry 
-prefixes of the form: +\fIversion\fP\-,
-where the specified version indicates some future XLFD specification, 
-are reserved by the X Consortium for future extensions to XLFD font names.
-If required, extensions to the current XLFD font name shall be constructed 
-by appending new fields to the current structure, 
-each delimited by the existing field delimiter.
-The availability of other 
-.PN FontNameRegistry
-prefixes or fonts that support other registries 
-is server implementation dependent.
-.LP
-In the X protocol specification, 
-the 
-.PN FontName 
-is required to be a string; 
-hence, numeric field values are represented in the name as string equivalents.
-All 
-.PN FontNameSuffix 
-fields are also defined as 
-.PN FontProperties ; 
-numeric property values are represented as signed or unsigned integers,
-as appropriate.
-.NH 3
-FontName Syntax
-.XS
-\*(SN FontName Syntax
-.XE
-.LP
-The
-.PN FontName 
-is a structured, parsable string (of type STRING8) 
-whose Backus-Naur Form syntax description is as follows:
-.IN "FontName Syntax"
-.SM
-.TS 
-rw(1.5i) lw(3.75i).
-.sp 6p
-T{
-FontName ::=
-T}	T{
-XFontNameRegistry XFontNameSuffix | 
-PrivFontNameRegistry PrivFontNameSuffix
-T}
-T{
-XFontNameRegistry ::=
-T}	T{
-XFNDelim | XFNExtPrefix Version XFNDelim
-T}
-T{
-XFontNameSuffix ::=
-T}	T{
-FOUNDRY XFNDelim FAMILY_NAME XFNDelim WEIGHT_NAME
-XFNDelim SLANT XFNDelim SETWIDTH_NAME XFNDelim ADD_
-STYLE_NAME XFNDelim PIXEL_SIZE XFNDelim POINT_SIZE 
-XFNDelim RESOLUTION_X XFNDelim RESOLUTION_Y XFNDelim 
-SPACING XFNDelim AVERAGE_WIDTH XFNDelim CHARSET_REGISTRY
-XFNDelim CHARSET_ENCODING
-T}
-T{
-Version ::=
-T}	T{
-STRING8 \- the XLFD version that defines an extension 
-to the font name syntax (for example, \*Q1.4\*U)
-T}
-XFNExtPrefix ::=	OCTET \- \*Q+\*U (PLUS)
-XFNDelim ::=	OCTET \- \*Q\-\*U (HYPHEN)
-T{
-PrivFontNameRegistry ::=
-T}	T{
-STRING8 \- other than those strings reserved by XLFD
-T}
-PrivFontNameSuffix ::=	STRING8
-.TE
-.NL
-.LP
-Field values are constructed as strings of ISO 8859-1 graphic characters, 
-excluding the following:
-.IP \(bu 5
-\*Q\-\*U (HYPHEN), the XLFD font name delimiter character
-.IP \(bu 5
-\*Q?\*U (QUESTION MARK) and \*Q*\*U (ASTERISK), the X protocol 
-font name wildcard characters
-.IP \(bu 5
-\*Q\^,\^\*U (COMMA), used by Xlib to separate XLFD font names in a font set.
-.IP \(bu 5
-\*Q\fC"\fP\*U (QUOTATION MARK), used by some commercial products to quote a
-font name.
-.LP
-Alphabetic case distinctions are allowed but are for human readability 
-concerns only.
-Conforming X servers will perform matching on font name query or open requests 
-independent of case.
-The entire font name string must have no more than 255 characters.
-It is recommended that clients construct font name query patterns 
-by explicitly including all field delimiters to avoid unexpected results.
-Note that SPACE is a valid character of a 
-.PN FontName 
-field; for example, the string \*QITC Avant Garde Gothic\*U might be a
-FAMILY_NAME.
-.NH 3
-FontName Field Definitions
-.XS
-\*(SN FontName Field Definitions
-.XE
-.LP
-This section discusses the
-.PN FontName :
-.IP \(bu 5
-FOUNDRY field
-.IP \(bu 5
-FAMILY_NAME field
-.IP \(bu 5
-WEIGHT_NAME field
-.IP \(bu 5
-SLANT field
-.IP \(bu 5
-SETWIDTH_NAME field
-.IP \(bu 5
-ADD_STYLE_NAME field
-.IP \(bu 5
-PIXEL_SIZE field
-.IP \(bu 5
-POINT_SIZE field
-.IP \(bu 5
-RESOLUTION_X and RESOLUTION_Y fields
-.IP \(bu 5
-SPACING field
-.IP \(bu 5
-AVERAGE_WIDTH field
-.IP \(bu 5
-CHARSET_REGISTRY and CHARSET_ENCODING fields
-.NH 4
-FOUNDRY Field
-.XS
-\*(SN FOUNDRY Field
-.XE
-.LP
-FOUNDRY is an x-registered-name,
-the name or identifier of the digital type foundry 
-that digitized and supplied the font data, 
-or if different, the identifier of the organization that last modified 
-the font shape or metric information.
-.LP
-The reason this distinction is necessary is 
-that a given font design may be licensed from one source (for example, ITC) 
-but digitized and sold by any number of different type suppliers.
-Each digital version of the original design, in general, will be somewhat 
-different in metrics and shape from the idealized original font data, 
-because each font foundry, for better or for worse, has its own standards 
-and practices for tweaking a typeface for a particular generation 
-of output technologies or has its own perception of market needs.
-.LP
-It is up to the type supplier to register with the X Consortium a 
-suitable name for this 
-.PN FontName 
-field according to the registration procedures defined by the Consortium.
-.LP
-The X Consortium shall define procedures for registering foundry 
-and other names and shall maintain and publish, 
-as part of its public distribution, 
-a registry of such registered names for use in XLFD font names and properties.
-.LP
-.NH 4
-FAMILY_NAME Field
-.XS
-\*(SN FAMILY_NAME Field
-.XE
-.LP
-FAMILY_NAME is a string that identifies the range or family of 
-typeface designs that are all variations of one basic typographic style.
-This must be spelled out in full,
-with words separated by spaces, as required.
-This name must be human-understandable and suitable for presentation to a 
-font user to identify the typeface family.
-.LP
-It is up to the type supplier to supply and maintain a suitable string for 
-this field and font property, to secure the proper legal title to a given 
-name, and to guard against the infringement of other's copyrights or 
-trademarks.
-By convention, FAMILY_NAME is not translated.
-FAMILY_NAME may include an indication of design ownership 
-if considered a valid part of the 
-typeface family name.
-.LP
-The following are examples of FAMILY_NAME:
-.IP \(bu 5
-Helvetica
-.IP \(bu 5
-ITC Avant Garde Gothic 
-.IP \(bu 5
-Times
-.IP \(bu 5
-Times Roman
-.IP \(bu 5
-Bitstream Amerigo
-.IP \(bu 5
-Stone
-.NH 4
-WEIGHT_NAME Field
-.XS
-\*(SN WEIGHT_NAME Field
-.XE
-.LP
-WEIGHT_NAME is a string that identifies the font's typographic weight, 
-that is, the nominal blackness of the font, 
-according to the FOUNDRY's judgment.
-This name must be human-understandable and suitable for presentation to a 
-font user.
-The value \*Q0\*U is used to indicate a polymorphic font (see section \n(sP).
-.LP
-The interpretation of this field is somewhat problematic 
-because the typographic judgment of weight has traditionally 
-depended on the overall design of the typeface family in question;
-that is, it is possible that the DemiBold weight of one font could be 
-almost equivalent in typographic feel to a Bold font from another family.
-.LP
-WEIGHT_NAME is captured as an arbitrary string 
-because it is an important part of a font's complete human-understandable name.
-However, it should not be used for font matching or substitution.
-For this purpose,
-X client applications should use the weight-related font properties 
-(RELATIVE_WEIGHT and WEIGHT) that give the coded relative weight 
-and the calculated weight, respectively.
-.NH 4
-SLANT Field
-.XS
-\*(SN SLANT Field
-.XE
-.LP
-SLANT is a code-string that indicates the overall posture of the 
-typeface design used in the font.
-The encoding is as follows:
-.TS H
-lw(.5i) lw(1.25i) lw(3.5i).
-_
-.sp 6p
-.B
-Code	English Translation	Description
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-\*QR\*U	Roman	Upright design
-\*QI\*U	Italic	T{
-Italic design, slanted clockwise from the vertical
-T}
-\*QO\*U	Oblique	T{
-Obliqued upright design, slanted clockwise from the vertical
-T}
-\*QRI\*U	Reverse Italic	T{
-Italic design, slanted counterclockwise from the vertical
-T}
-\*QRO\*U	Reverse Oblique	T{
-Obliqued upright design, slanted counterclockwise from the vertical
-T}
-\*QOT\*U	Other	Other
-numeric	Polymorphic	See section \n(sP on polymorphic font support.
-.sp 6p
-_
-.TE
-.LP
-The SLANT codes are for programming convenience only and usually are 
-converted into their equivalent human-understandable form before being 
-presented to a user.
-.NH 4
-SETWIDTH_NAME Field
-.XS
-\*(SN SETWIDTH_NAME Field
-.XE
-.LP 
-SETWIDTH_NAME is a string that gives the font's typographic 
-proportionate width, that is, the nominal width per horizontal unit of the 
-font, according to the FOUNDRY's judgment.
-The value \*Q0\*U is used to indicate a polymorphic font (see section \n(sP).
-.LP
-As with WEIGHT_NAME, the interpretation of this field or font property is 
-somewhat problematic, because the designer's judgment of setwidth has 
-traditionally depended on the overall design of the typeface family in 
-question.
-For purposes of font matching or substitution,
-X client applications should either use the RELATIVE_SETWIDTH font property 
-that gives the relative coded proportionate width or calculate 
-the proportionate width.
-.LP
-The following are examples of SETWIDTH_NAME:
-.IP \(bu 5
-Normal 
-.IP \(bu 5
-Condensed 
-.IP \(bu 5
-Narrow 
-.IP \(bu 5
-Double Wide
-.NH 4
-ADD_STYLE_NAME Field
-.XS
-\*(SN ADD_STYLE_NAME Field
-.XE
-.LP
-ADD_STYLE_NAME is a string that identifies additional typographic 
-style information that is not captured by other fields but is needed 
-to identify the particular font.
-The character \*Q[\*U anywhere in the field is used to indicate a
-polymorphic font (see section \n(sP).
-.LP
-ADD_STYLE_NAME is not a typeface classification field 
-and is only used for uniqueness.
-Its use, as such, is not limited to typographic style distinctions.
-.LP
-The following are examples of ADD_STYLE_NAME:
-.IP \(bu 5
-Serif
-.IP \(bu 5
-Sans Serif
-.IP \(bu 5
-Informal
-.IP \(bu 5
-Decorated
-.NH 4
-PIXEL_SIZE Field
-.XS
-\*(SN PIXEL_SIZE Field
-.XE
-.LP 
-PIXEL_SIZE
-gives the body size of the font at a particular 
-POINT_SIZE and RESOLUTION_Y.
-PIXEL_SIZE is either an integer-string or a string beginning
-with \*Q[\*U.  A string beginning with \*Q[\*U represents a matrix
-(see section \n(sM).
-PIXEL_SIZE usually incorporates additional vertical spacing 
-that is considered part of the font design.
-(Note, however, that this value is not necessarily equivalent to the height 
-of the font bounding box.)
-Zero is used to indicate a scalable font (see section \n(sS).
-.LP
-PIXEL_SIZE usually is used by X client applications that need to 
-query fonts according to device-dependent size, 
-regardless of the point size or vertical resolution 
-for which the font was designed.
-.NH 4
-POINT_SIZE Field
-.XS
-\*(SN POINT_SIZE Field
-.XE
-.LP 
-POINT_SIZE gives the body size 
-for which the font was designed.
-POINT_SIZE is either an integer-string or a string beginning
-with \*Q[\*U.  A string beginning with \*Q[\*U represents a matrix
-(see section \n(sM).
-This field usually incorporates additional vertical spacing 
-that is considered part of the font design.
-(Note, however, that POINT_SIZE is not necessarily equivalent to the height 
-of the font bounding box.) 
-POINT_SIZE is expressed in decipoints (where points are as defined 
-in the X protocol or 72.27 points equal 1 inch).
-Zero is used to indicate a scalable font (see section \n(sS).
-.LP
-POINT_SIZE and RESOLUTION_Y are used by X clients to query fonts 
-according to device-independent size to maintain constant text 
-size on the display regardless of the PIXEL_SIZE used for the font.
-.NH 4
-RESOLUTION_X and RESOLUTION_Y Fields
-.XS
-\*(SN RESOLUTION_X and RESOLUTION_Y Fields
-.XE
-.LP 
-RESOLUTION_X and RESOLUTION_Y are unsigned integer-strings that give 
-the horizontal and vertical resolution,
-measured in pixels or dots per inch (dpi),
-for which the font was designed.
-Zero is used to indicate a scalable font (see section \n(sS).
-Horizontal and vertical values are required 
-because a separate bitmap font must be designed 
-for displays with very different aspect ratios
-(for example, 1:1, 4:3, 2:1, and so on).
-.LP 
-The separation of pixel or point size and resolution is necessary 
-because X allows for servers with very different video characteristics 
-(for example, horizontal and vertical resolution, screen and pixel size, 
-pixel shape, and so on) to potentially access the same font library.
-The font name, for example, must differentiate between a 14-point font designed
-for 75 dpi (body size of about 14 pixels) or a 14-point font designed 
-for 150 dpi (body size of about 28 pixels).
-Further, in servers that implement some or all fonts as continuously scaled 
-and scan-converted outlines,
-POINT_SIZE and RESOLUTION_Y will help the server to differentiate 
-between potentially separate font masters for text, title,
-and display sizes or for other typographic considerations.
-.NH 4 
-SPACING Field
-.XS
-\*(SN SPACING Field
-.XE
-.LP 
-SPACING is a code-string that indicates the escapement class of the font, 
-that is, monospace (fixed pitch), proportional (variable pitch), 
-or charcell (a special monospaced font that conforms to the traditional 
-data-processing character cell font model).
-The encoding is as follows:
-.ne 5
-.SM
-.TS H
-lw(.5i) lw(1.25i) lw(3.5i).
-_
-.sp 6p
-.B
-Code	English Translation	Description
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-\*QP\*U	Proportional	T{
-A font whose logical character widths vary for each glyph.
-Note that no other restrictions are placed on the metrics 
-of a proportional font.
-T}
-\*QM\*U	Monospaced	T{
-A font whose logical character widths are constant 
-(that is, every glyph in the font has the same logical width).
-No other restrictions are placed on the metrics of a monospaced font.
-T}
-\*QC\*U	CharCell	T{
-A monospaced font that follows the standard typewriter character cell model
-(that is, the glyphs of the font can be modeled by X clients as \*Qboxes\*U 
-of the same width and height that are imaged side-by-side 
-to form text strings or top-to-bottom to form text lines).
-By definition, 
-all glyphs have the same logical character width, 
-and no glyphs have \*Qink\*U outside of the character cell.
-There is no kerning (that is, on a per-character basis with positive metrics: 
-0 <= left-bearing <= right-bearing <= width; 
-with negative metrics: width <= left-bearing <= right-bearing <= zero).
-Also, the vertical extents of the font do not exceed the vertical spacing 
-(that is, on a per-character basis: 
-ascent <= font-ascent and descent <= font-descent).
-The cell height = font-descent + font-ascent, and the width = AVERAGE_WIDTH.
-T}
-.sp 6p
-_
-.TE
-.NL
-.NH 4
-AVERAGE_WIDTH Field
-.XS
-\*(SN AVERAGE_WIDTH Field
-.XE
-.LP 
-AVERAGE_WIDTH is an integer-string typographic metric value 
-that gives the unweighted arithmetic mean of the absolute value of the
-width of each glyph in the font 
-(measured in tenths of pixels), multiplied by \-1 if the dominant
-writing direction for the font is right-to-left.
-A leading \*Q\^~\^\*U (TILDE) indicates a negative value.
-For monospaced and character cell fonts, 
-this is the width of all glyphs in the font.
-Zero is used to indicate a scalable font (see section \n(sS).
-.NH 4
-CHARSET_REGISTRY and CHARSET_ENCODING Fields
-.XS
-\*(SN CHARSET_REGISTRY and CHARSET_ENCODING Fields
-.XE
-.LP
-The character set used to encode the glyphs of the font (and implicitly 
-the font's glyph repertoire), as maintained by the X Consortium character
-set registry.
-CHARSET_REGISTRY is an x-registered-name that identifies 
-the registration authority that owns the specified encoding.
-CHARSET_ENCODING is a registered name that identifies the coded character set 
-as defined by that registration authority
-and, optionally, a subsetting hint.
-.LP
-Although the X protocol does not explicitly have any knowledge about 
-character set encodings, 
-it is expected that server implementors will prefer to embed knowledge 
-of certain proprietary or standard charsets into their font library 
-for reasons of performance and convenience.
-The CHARSET_REGISTRY and CHARSET_ENCODING fields or properties allow 
-an X client font request to specify a specific charset mapping 
-in server environments where multiple charsets are supported.
-The availability of any particular 
-character set is font and server implementation dependent.
-.LP
-To prevent collisions when defining character set names, 
-it is recommended that CHARSET_REGISTRY and CHARSET_ENCODING name pairs 
-be constructed according to the following conventions:
-.IN "CHARSET Syntax"
-.SM
-.TS
-rw(1.5i) lw(3.75i).
-.sp 6p
-CharsetRegistry ::=	T{
-StdCharsetRegistryName | PrivCharsetRegistryName
-T}
-CharsetEncoding ::=	T{
-StdCharsetEncodingName | PrivCharsetEncodingName
-T}
-StdCharsetRegistryName ::=	T{
-StdOrganizationId StdNumber | StdOrganizationId StdNumber Dot Year
-T}
-PrivCharsetRegistryName ::=	OrganizationId STRING8
-StdCharsetEncodingName ::=	T{
-STRING8\-numeric part number of referenced standard
-T}
-PrivCharsetEncodingName ::=	STRING8
-StdOrganizationId ::=	T{
-STRING8\-the registered name or acronym of the referenced standard organization
-T}
-StdNumber ::=	STRING8\-referenced standard number
-OrganizationId ::=	T{
-STRING8\-the registered name or acronym of the organization
-T}
-Dot ::=	OCTET\-\*Q\^.\^\*U (FULL STOP)
-Year ::=	STRING8\-numeric year (for example, 1989)
-.TE
-.NL
-.LP
-The X Consortium shall maintain and publish a registry 
-of such character set names for use in X protocol font names and properties 
-as specified in XLFD.
-.LP
-The ISO Latin-1 character set shall be registered by the X Consortium as the 
-CHARSET_REGISTRY-CHARSET_ENCODING value pair: \*QISO8859-1\*U.
-.LP
-If the CHARSET_ENCODING contains a \*Q[\*U (LEFT SQUARE BRACKET),
-the \*Q[\*U and the characters after it up to a \*Q]\*U (RIGHT SQUARE
-BRACKET) are a
-subsetting hint telling the font source that the client is interested
-only in a subset of the characters of the font.
-The font source can, optionally, return a font that
-contains only those characters or any superset of those characters.  The
-client can expect to obtain valid glyphs and metrics only for those
-characters, and not for any other characters in the font.
-The font properties may optionally be calculated by considering only
-the characters in the subset.
-.LP
-The BNF for the subsetting hint is
-.SM
-.TS
-rw(1.5i) l.
-Subset ::=	LeftBracket RangeList RightBracket
-RangeList ::=	Range | Range Space RangeList
-Range ::=	Number | Number Underscore Number
-Number ::=	\*Q0x\*U HexNumber | DecNumber
-HexNumber ::=	HexDigit | HexDigit HexNumber
-DecNumber ::=	DecDigit | DecDigit DecNumber
-DecDigit ::=	\*Q0\*U | \*Q1\*U | \*Q2\*U | \*Q3\*U | \*Q4\*U | \*Q5\*U | \*Q6\*U | \*Q7\*U | \*Q8\*U | \*Q9\*U
-HexDigit ::=	DecDigit | \*Qa\*U | \*Qb\*U | \*Qc\*U | \*Qd\*U | \*Qe\*U | \*Qf\*U
-LeftBracket ::=	\*Q[\*U (LEFT SQUARE BRACKET)
-RightBracket ::=	\*Q]\*U (RIGHT SQUARE BRACKET)
-Space ::=	\*Q\0\*U (SPACE)
-Underscore ::=	\*Q_\*U (LOW LINE)
-.TE
-.NL
-.LP
-Each Range specifies characters that are to be part of the subset
-included in the font.
-A Range containing two Numbers specifies the first and last character,
-inclusively, of a range of characters.
-A Range that is a single Number specifies a single character to be
-included in the font.
-A HexNumber is interpreted as a hexadecimal number.
-A DecNumber is interpreted as a decimal number.
-The font consists of the union of all the Ranges in the
-RangeList.
-.LP
-For example,
-.br
-.ft C
-.SM
-	-misc-fixed-medium-r-normal--0-0-0-0-c-0-iso8859-1[65 70 80_90]
-.NL
-.ft P
-.br
-tells the font source that the client is interested only in characters
-65, 70, and 80\-90.
-.NH 3
-Examples
-.XS
-\*(SN Examples
-.XE
-.LP
-The following examples of font names are derived from the screen fonts 
-shipped with the X Consortium distribution.
-.\" why is this table so long?  I took out some fonts in v1.5
-.\" to make the page breaks better.
-.SM
-.TS H
-lw(1.45i) lw(4.45i).
-_
-.sp 6p
-.B
-Font	X FontName
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-\fB75-dpi Fonts\fP
-.sp 3p
-T{
-Charter 12 pt
-T}	T{
--Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-ISO8859-1
-T}
-T{
-Charter Bold 12 pt
-T}	T{
--Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1
-T}
-T{
-Charter Bold Italic 12 pt
-T}	T{
--Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1
-T}
-T{
-Charter Italic 12 pt
-T}	T{
--Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1
-T}
-Courier 8 pt	-Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1
-Courier 10 pt	-Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1
-Courier 12 pt	-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1
-Courier 24 pt	-Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1
-T{
-Courier Bold 10 pt
-T}	T{
--Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1
-T}
-T{
-Courier Bold Oblique 10 pt
-T}	T{
--Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1
-T}
-T{
-Courier Oblique 10 pt
-T}	T{
--Adobe-Courier-Medium-O-Normal--10-100-75-75-M-60-ISO8859-1
-T}
-.sp 3p
-.ne 2
-\fB100-dpi Fonts\fP
-.sp 3p
-T{
-Symbol 10 pt
-T}	T{
--Adobe-Symbol-Medium-R-Normal--14-100-100-100-P-85-Adobe-FONTSPECIFIC
-T}
-T{
-Symbol 14 pt
-T}	T{
--Adobe-Symbol-Medium-R-Normal--20-140-100-100-P-107-Adobe-FONTSPECIFIC
-T}
-T{
-Symbol 18 pt
-T}	T{
--Adobe-Symbol-Medium-R-Normal--25-180-100-100-P-142-Adobe-FONTSPECIFIC
-T}
-T{
-Symbol 24 pt
-T}	T{
--Adobe-Symbol-Medium-R-Normal--34-240-100-100-P-191-Adobe-FONTSPECIFIC
-T}
-T{
-Times Bold 10 pt
-T}	T{
--Adobe-Times-Bold-R-Normal--14-100-100-100-P-76-ISO8859-1
-T}
-T{
-Times Bold Italic 10 pt
-T}	T{
--Adobe-Times-Bold-I-Normal--14-100-100-100-P-77-ISO8859-1
-T}
-T{
-Times Italic 10 pt
-T}	T{
--Adobe-Times-Medium-I-Normal--14-100-100-100-P-73-ISO8859-1
-T}
-T{
-Times Roman 10 pt
-T}	T{
--Adobe-Times-Medium-R-Normal--14-100-100-100-P-74-ISO8859-1
-T}
-_
-.TE
-.NL
-.NH 2
-Font Properties
-.XS
-\*(SN Font Properties
-.XE
-.LP
-All font properties are optional but will generally include the 
-font name fields and, on a font-by-font basis, any other useful font 
-descriptive and use information that may be required to use the font 
-intelligently.
-The XLFD specifies an extensive set of standard X font properties,
-their interpretation, and fallback rules when the property is not defined 
-for a given font.
-The goal is to provide client applications with enough font information 
-to be able to make automatic formatting and display decisions 
-with good typographic results.
-.LP
-Font property names use the ISO 8859-1 encoding.
-.LP
-Additional standard X font property definitions may be defined in the 
-future and private properties may exist in X fonts at any time.
-Private font properties should be defined to conform to the general mechanism 
-defined in the X protocol to prevent overlap of name space and ambiguous 
-property names, that is, private font property names are of the form: 
-\*Q_\*U (LOW LINE), 
-followed by the organizational identifier, followed by \*Q_\*U (LOW LINE), 
-and terminated with the property name.
-.LP
-The Backus-Naur Form syntax description of X font properties is as follows:
-.IN "Font Properties" "BNF Syntax"
-.SM
-.TS
-rw(1.5i) lw(3.75i).
-.sp 6p
-Properties ::=	OptFontPropList
-OptFontPropList ::=	NULL | OptFontProp OptFontPropList
-OptFontProp ::=	PrivateFontProp | XFontProp
-PrivateFontProp ::=	T{
-STRING8 | Underscore OrganizationId Underscore STRING8
-T}
-XFontProp ::=	T{
-FOUNDRY | FAMILY_NAME | WEIGHT_NAME | SLANT | SETWIDTH_NAME | ADD_STYLE_NAME 
-| PIXEL_SIZE | POINT_SIZE | RESOLUTION_X | RESOLUTION_Y | SPACING | 
-AVERAGE_WIDTH | CHARSET_REGISTRY | CHARSET_ENCODING | QUAD_WIDTH | 
-RESOLUTION | MIN_SPACE | NORM_SPACE | MAX_SPACE | END_SPACE | SUPERSCRIPT_X | 
-SUPERSCRIPT_Y | SUBSCRIPT_X | SUBSCRIPT_Y | UNDERLINE_POSITION | 
-UNDERLINE_THICKNESS | STRIKEOUT_ASCENT | STRIKEOUT_DESCENT | ITALIC_ANGLE 
-| X_HEIGHT | WEIGHT | FACE_NAME |
-FULL_NAME | FONT |
-COPYRIGHT | AVG_CAPITAL_WIDTH | 
-AVG_LOWERCASE_WIDTH | RELATIVE_SETWIDTH | RELATIVE_WEIGHT | CAP_HEIGHT | 
-SUPERSCRIPT_ SIZE | FIGURE_WIDTH | SUBSCRIPT_SIZE | SMALL_CAP_SIZE | 
-NOTICE | DESTINATION
-| FONT_TYPE | FONT_VERSION | RASTERIZER_NAME | RASTERIZER_VERSION |
-RAW_ASCENT | RAW_DESCENT | RAW_* | AXIS_NAMES | AXIS_LIMITS |
-AXIS_TYPES
-T}
-Underscore ::=	OCTET\-\*Q_\*U (LOW LINE)
-OrganizationId ::=	T{
-STRING8\-the registered name of the organization
-T}
-.TE
-.NL
-.NH 3
-FOUNDRY
-.XS
-\*(SN FOUNDRY
-.XE
-.LP
-FOUNDRY is as defined in the
-.PN FontName 
-except that the property type is ATOM.
-.LP
-FOUNDRY cannot be calculated or defaulted if not supplied as a font property.
-.NH 3
-FAMILY_NAME
-.XS
-\*(SN FAMILY_NAME
-.XE
-.LP
-FAMILY_NAME is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-FAMILY_NAME cannot be calculated or defaulted if not supplied as a font 
-property.
-.NH 3
-WEIGHT_NAME
-.XS
-\*(SN WEIGHT_NAME
-.XE
-.LP
-WEIGHT_NAME is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-WEIGHT_NAME can be defaulted if not supplied as a font property, as follows:
-.LP
-.DS
-if (WEIGHT_NAME undefined) then 
-   WEIGHT_NAME = ATOM(\*QMedium\*U)
-.DE
-.NH 3
-SLANT
-.XS
-\*(SN SLANT
-.XE
-.LP
-SLANT is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-SLANT can be defaulted if not supplied as a font property, as follows:
-.LP
-.DS
-if (SLANT undefined) then 
-   SLANT = ATOM(\*QR\*U)
-.DE
-.NH 3
-SETWIDTH_NAME
-.XS
-\*(SN SETWIDTH_NAME
-.XE
-.LP
-SETWIDTH_NAME is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-SETWIDTH_NAME can be defaulted if not supplied as a font property, as follows:
-.LP
-.DS
-if (SETWIDTH_NAME undefined) then
-   SETWIDTH_NAME = ATOM(\*QNormal\*U)
-.DE
-.NH 3
-ADD_STYLE_NAME
-.XS
-\*(SN ADD_STYLE_NAME
-.XE
-.LP
-ADD_STYLE_NAME is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-ADD_STYLE_NAME can be defaulted if not supplied as a font property, as follows:
-.LP
-.DS
-if (ADD_STYLE_NAME undefined) then
-   ADD_STYLE_NAME = ATOM(\*Q\*U)
-.DE
-.NH 3
-PIXEL_SIZE
-.XS
-\*(SN PIXEL_SIZE
-.XE
-.LP
-PIXEL_SIZE is as defined in the 
-.PN FontName
-except that the property type is INT32.
-.LP
-X clients requiring pixel values for the various typographic fixed 
-spaces (em space, en space, and thin space) can use the following 
-algorithm for computing these values from other properties specified 
-for a font:
-.LP
-.DS
-DeciPointsPerInch = 722.7
-EMspace = ROUND ((RESOLUTION_X * POINT_SIZE) / DeciPointsPerInch)
-ENspace = ROUND (EMspace / 2)
-THINspace = ROUND (EMspace / 3)\fP
-.DE
-.LP
-where a slash (\^/\^) denotes real division, 
-an asterisk (\^*\^) denotes real multiplication,
-and ROUND denotes a function that rounds its real argument
-\fIa\fP up or down
-to the next integer.
-This rounding is done according to X = FLOOR (\fIa\fP + 0.5),
-where FLOOR is a function that rounds its real argument down to the
-nearest integer.
-.LP
-PIXEL_SIZE can be approximated if not supplied as a font property, 
-according to the following algorithm:
-.LP
-.DS
-DeciPointsPerInch = 722.7
-if (PIXEL_SIZE undefined) then
-   PIXEL_SIZE = ROUND ((RESOLUTION_Y * POINT_SIZE) / DeciPointsPerInch)
-.DE
-.NH 3
-POINT_SIZE
-.XS
-\*(SN POINT_SIZE
-.XE
-.LP
-POINT_SIZE is as defined in the 
-.PN FontName
-except that the property type is INT32.
-.LP
-X clients requiring device-independent values for em space, 
-en space, and thin space can use the following algorithm:
-.LP
-.DS I
-EMspace = ROUND (POINT_SIZE / 10)
-ENspace = ROUND (POINT_SIZE / 20)
-THINspace = ROUND (POINT_SIZE / 30)
-.DE
-.LP
-Design POINT_SIZE cannot be calculated or approximated.
-.NH 3
-RESOLUTION_X
-.XS
-\*(SN RESOLUTION_X
-.XE
-.LP
-RESOLUTION_X is as defined in the 
-.PN FontName
-except that the property type is CARD32.
-.LP
-RESOLUTION_X cannot be calculated or approximated.
-.NH 3
-RESOLUTION_Y
-.XS
-\*(SN RESOLUTION_Y
-.XE
-.LP
-RESOLUTION_Y is as defined in the 
-.PN FontName 
-except that the property type is CARD32.
-.LP
-RESOLUTION_X cannot be calculated or approximated.
-.NH 3
-SPACING
-.XS
-\*(SN SPACING
-.XE
-.LP
-SPACING is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-SPACING can be calculated if not supplied as a font property, 
-according to the definitions given above for the 
-.PN FontName .
-.NH 3
-AVERAGE_WIDTH
-.XS
-\*(SN AVERAGE_WIDTH
-.XE
-.LP
-AVERAGE_WIDTH is as defined in the 
-.PN FontName
-except that the property type is INT32.
-.LP
-AVERAGE_WIDTH can be calculated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (AVERAGE_WIDTH undefined) then
-   AVERAGE_WIDTH = ROUND (MEAN (ABS (width of each glyph in font)) * 10)
-	* (if (dominant writing direction L-to-R) then 1 else \-1)
-.DE
-.LP
-where MEAN is a function that returns the arithmetic mean of its arguments.
-.LP
-X clients that require values for the number of characters per inch (pitch) 
-of a monospaced font can use the following algorithm using the 
-AVERAGE_WIDTH and RESOLUTION_X font properties:
-.LP
-.DS
-if (SPACING not proportional) then
-   CharPitch = (RESOLUTION_X * 10) / AVERAGE_WIDTH
-.DE
-.NH 3
-CHARSET_REGISTRY
-.XS
-\*(SN CHARSET_REGISTRY
-.XE
-.LP
-CHARSET_REGISTRY is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-CHARSET_REGISTRY cannot be defaulted if not supplied as a font property.
-.NH 3
-CHARSET_ENCODING
-.XS
-\*(SN CHARSET_ENCODING
-.XE
-.LP
-CHARSET_ENCODING is as defined in the 
-.PN FontName
-except that the property type is ATOM.
-.LP
-CHARSET_ENCODING cannot be defaulted if not supplied as a font property.
-.NH 3
-MIN_SPACE
-.XS
-\*(SN MIN_SPACE
-.XE
-.LP
-MIN_SPACE is an integer value (of type INT32)
-that gives the recommended minimum word-space value to be used with this font.
-.LP
-MIN_SPACE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS I
-if (MIN_SPACE undefined) then
-   MIN_SPACE = ROUND(0.75 * NORM_SPACE)
-.DE
-.NH 3
-NORM_SPACE
-.XS
-\*(SN NORM_SPACE
-.XE
-.LP
-NORM_SPACE is an integer value (of type INT32)
-that gives the recommended normal word-space value to be used with this font.
-.LP
-NORM_SPACE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS 0
-DeciPointsPerInch = 722.7
-if (NORM_SPACE undefined) then
-   if (SPACE glyph exists) then
-      NORM_SPACE = width of SPACE
-   else NORM_SPACE = ROUND((0.33 * RESOLUTION_X * POINT_SIZE)/ DeciPointsPerInch)
-.DE
-.NH 3
-MAX_SPACE
-.XS
-\*(SN MAX_SPACE
-.XE
-.LP
-MAX_SPACE is an integer value (of type INT32)
-that gives the recommended maximum word-space value to be used with this font.
-.LP
-MAX_SPACE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (MAX_SPACE undefined) then
-   MAX_SPACE = ROUND(1.5 * NORM_SPACE)
-.DE
-.NH 3
-END_SPACE
-.XS
-\*(SN END_SPACE
-.XE
-.LP
-END_SPACE is an integer value (of type INT32)
-that gives the recommended spacing at the end of sentences.
-.LP
-END_SPACE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS 
-if (END_SPACE undefined) then
-   END_SPACE = NORM_SPACE
-.DE
-.NH 3
-AVG_CAPITAL_WIDTH 
-.XS
-\*(SN AVG_CAPITAL_WIDTH
-.XE
-.LP
-AVG_CAPITAL_WIDTH is an integer value (of type INT32)
-that gives the unweighted arithmetic mean of the absolute value of the
-width of each capital glyph in the font, in tenths of pixels,
-multiplied by \-1 if the dominant
-writing direction for the font is right-to-left.
-This property applies to both Latin and non-Latin fonts.
-For Latin fonts, 
-capitals are the glyphs A through Z.
-This property is usually used for font matching or substitution.
-.LP
-AVG_CAPITAL_WIDTH can be calculated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS I
-if (AVG_CAPITAL_WIDTH undefined) then
-   if (capitals exist) then
-      AVG_CAPITAL_WIDTH = ROUND (MEAN
-		     (ABS (width of each capital glyph)) * 10)
-	   * (if (dominant writing direction L-to-R) then 1 else \-1)
-   else AVG_CAPITAL_WIDTH undefined
-.DE
-.NH 3
-AVG_LOWERCASE_WIDTH
-.XS
-\*(SN AVG_LOWERCASE_WIDTH
-.XE
-.LP
-AVG_LOWERCASE_WIDTH is an integer value (of type INT32)
-that gives the unweighted arithmetic mean width of the absolute value
-of the width of each lowercase glyph in the font in tenths of pixels,
-multiplied by \-1 if the dominant
-writing direction for the font is right-to-left.
-For Latin fonts, 
-lowercase are the glyphs a through z.
-This property is usually used for font matching or substitution.
-.LP
-Where appropriate, 
-AVG_LOWERCASE_WIDTH can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (AVG_LOWERCASE_WIDTH undefined) then
-   if (lowercase exists) then
-      AVG_LOWERCASE_WIDTH = ROUND (MEAN
-                       (ABS (width of each lowercase glyph)) * 10)
-	* (if (dominant writing direction L-to-R) then 1 else \-1)
-   else AVG_LOWERCASE_WIDTH undefined
-.DE
-.NH 3
-QUAD_WIDTH 
-.XS
-\*(SN QUAD_WIDTH
-.XE
-.LP
-QUAD_WIDTH is an integer typographic metric (of type INT32) 
-that gives the width of a quad (em) space.
-.NT Note
-Because all typographic fixed spaces (em, en, and thin) are constant 
-for a given font size (that is, they do not vary according to setwidth),
-the use of this font property has been deprecated.
-X clients that require typographic fixed space values are encouraged 
-to discontinue use of QUAD_WIDTH and compute these values 
-from other font properties (for example, PIXEL_SIZE).
-X clients that require  a font-dependent width value should use either 
-the FIGURE_WIDTH or one of the average character width font properties
-(AVERAGE_WIDTH, AVG_CAPITAL_WIDTH or AVG_LOWERCASE_WIDTH).
-.NE
-.NH 3
-FIGURE_WIDTH
-.XS
-\*(SN FIGURE_WIDTH
-.XE
-.LP
-FIGURE_WIDTH is an integer typographic metric (of type INT32)
-that gives the width of the tabular figures and the dollar sign,
-if suitable for tabular setting (all widths equal).
-For Latin fonts, these tabular figures are the Arabic numerals 0 through 9.
-.LP
-FIGURE_WIDTH can be approximated if not supplied as a font property, 
-according to the following algorithm:
-.LP
-.DS I
-if (numerals and DOLLAR sign are defined & widths are equal) then
-   FIGURE_WIDTH = width of DOLLAR
-else FIGURE_WIDTH property undefined
-.DE
-.NH 3
-SUPERSCRIPT_X 
-.XS
-\*(SN SUPERSCRIPT_X
-.XE
-.LP
-SUPERSCRIPT_X is an integer value (of type INT32)
-that gives the recommended horizontal offset in pixels 
-from the position point to the X origin of synthetic superscript text.
-If the current position point is at [X,Y], 
-then superscripts should begin at [X + SUPERSCRIPT_X, Y \- SUPERSCRIPT_Y].
-.LP
-SUPERSCRIPT_X can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SUPERSCRIPT_X undefined) then
-   if (TANGENT(ITALIC_ANGLE) defined) then
-      SUPERSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))
-   else SUPERSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)
-.DE
-.LP
-where TANGENT is a trigonometric function that returns the tangent of 
-its argument, which is in 1/64 degrees.
-.NH 3
-SUPERSCRIPT_Y
-.XS
-\*(SN SUPERSCRIPT_Y
-.XE
-.LP
-SUPERSCRIPT_Y is an integer value (of type INT32)
-that gives the recommended vertical offset in pixels 
-from the position point to the Y origin of synthetic superscript text.
-If the current position point is at [X,Y], 
-then superscripts should begin at [X + SUPERSCRIPT_X, Y \- SUPERSCRIPT_Y].
-.LP
-SUPERSCRIPT_Y can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SUPERSCRIPT_Y undefined) then
-   SUPERSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)
-.DE
-.NH 3
-SUBSCRIPT_X
-.XS
-\*(SN SUBSCRIPT_X
-.XE
-.LP
-SUBSCRIPT_X is an integer value (of type INT32)
-that gives the recommended horizontal offset in pixels 
-from the position point to the X origin of synthetic subscript text.
-If the current position point is at [X,Y], 
-then subscripts should begin at [X + SUBSCRIPT_X, Y + SUBSCRIPT_Y].
-.LP
-SUBSCRIPT_X can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SUBSCRIPT_X undefined) then
-   if (TANGENT(ITALIC_ANGLE) defined) then
-      SUBSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))
-   else SUBSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)
-.DE
-.NH 3
-SUBSCRIPT_Y 
-.XS
-\*(SN SUBSCRIPT_Y
-.XE
-.LP
-SUBSCRIPT_Y is an integer value (of type INT32)
-that gives the recommended vertical offset in pixels 
-from the position point to the Y origin of synthetic subscript text.
-If the current position point is at [X,Y], 
-then subscripts should begin at [X + SUBSCRIPT_X, Y + SUBSCRIPT_Y].
-.LP
-SUBSCRIPT_Y can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SUBSCRIPT_Y undefined) then
-   SUBSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)
-.DE
-.NH 3
-SUPERSCRIPT_SIZE 
-.XS
-\*(SN SUPERSCRIPT_SIZE
-.XE
-.LP
-SUPERSCRIPT_SIZE is an integer value (of type INT32)
-that gives the recommended body size of synthetic superscripts 
-to be used with this font, in pixels.
-This will generally be smaller than the size of the current font;
-that is, superscripts are imaged from a smaller font
-offset according to SUPERSCRIPT_X and SUPERSCRIPT_Y.
-.LP
-SUPERSCRIPT_SIZE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SUPERSCRIPT_SIZE undefined) then
-   SUPERSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)
-.DE
-.NH 3
-SUBSCRIPT_SIZE
-.XS
-\*(SN SUBSCRIPT_SIZE
-.XE
-.LP
-SUBSCRIPT_SIZE is an integer value (of type INT32)
-that gives the recommended body size of synthetic subscripts 
-to be used with this font, in pixels.
-As with SUPERSCRIPT_SIZE, 
-this will generally be smaller than the size of the current font; 
-that is, subscripts are imaged from a smaller 
-font offset according to SUBSCRIPT_X and SUBSCRIPT_Y.
-.LP
-SUBSCRIPT_SIZE can be approximated if not provided as a font property, 
-according to the algorithm:
-.LP
-.DS
-if (SUBSCRIPT_SIZE undefined) then
-   SUBSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)
-.DE
-.NH 3
-SMALL_CAP_SIZE
-.XS
-\*(SN SMALL_CAP_SIZE
-.XE
-.LP
-SMALL_CAP_SIZE is an integer value (of type INT32)
-that gives the recommended body size of synthetic small capitals 
-to be used with this font, in pixels.
-Small capitals are generally imaged from a smaller font 
-of slightly more weight.
-No offset [X,Y] is necessary.
-.LP
-SMALL_CAP_SIZE can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (SMALL_CAP_SIZE undefined) then
-   SMALL_CAP_SIZE = ROUND(PIXEL_SIZE * ((X_HEIGHT 
-                              + ((CAP_HEIGHT \- X_HEIGHT) / 3)) / CAP_HEIGHT))
-.DE
-.NH 3
-UNDERLINE_POSITION
-.XS
-\*(SN UNDERLINE_POSITION
-.XE
-.LP
-UNDERLINE_POSITION is an integer value (of type INT32)
-that gives the recommended vertical offset in pixels
-from the baseline to the top of the underline.
-If the current position point is at [X,Y], 
-the top of the baseline is given by [X, Y + UNDERLINE_POSITION].
-.LP
-UNDERLINE_POSITION can be approximated if not provided as a font 
-property, according to the following algorithm:
-.LP
-.DS
-if (UNDERLINE_POSITION undefined) then
-   UNDERLINE_POSITION = ROUND((maximum descent) / 2)
-.DE
-where \fImaximum descent\fP is the maximum descent (below the baseline)
-in pixels of any glyph in the font.
-.NH 3
-UNDERLINE_THICKNESS 
-.XS
-\*(SN UNDERLINE_THICKNESS
-.XE
-.LP
-UNDERLINE_THICKNESS is an integer value (of type INT32)
-that gives the recommended underline thickness, in pixels.
-.LP
-UNDERLINE_THICKNESS can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-CapStemWidth = average width of the stems of capitals
-if (UNDERLINE_THICKNESS undefined) then
-   UNDERLINE_THICKNESS = CapStemWidth
-.DE
-.NH 3
-STRIKEOUT_ASCENT
-.XS
-\*(SN STRIKEOUT_ASCENT
-.XE
-.LP
-STRIKEOUT_ASCENT is an integer value (of type INT32)
-that gives the vertical ascent for boxing or voiding glyphs in this font.
-If the current position is at [X,Y] and the string extent is EXTENT, 
-the upper-left corner of the strikeout box is at [X, Y \- STRIKEOUT_ASCENT] 
-and the lower-right corner of the box is at [X + EXTENT, Y + STRIKEOUT_DESCENT].
-.LP
-STRIKEOUT_ASCENT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (STRIKEOUT_ASCENT undefined)
-   STRIKEOUT_ASCENT = maximum ascent
-.DE
-where \fImaximum ascent\fP is the maximum ascent (above the baseline)
-in pixels of any glyph in the font.
-.NH 3
-STRIKEOUT_DESCENT
-.XS
-\*(SN STRIKEOUT_DESCENT
-.XE
-.LP
-STRIKEOUT_DESCENT is an integer value (of type INT32)
-that gives the vertical descent for boxing or voiding glyphs in this font.
-If the current position is at [X,Y] and the string extent is EXTENT,
-the upper-left corner of the strikeout box is at [X, Y \- STRIKEOUT_ASCENT] 
-and the lower-right corner of the box is at [X + EXTENT, Y + STRIKEOUT_DESCENT].
-.LP
-STRIKEOUT_DESCENT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (STRIKEOUT_DESCENT undefined)
-   STRIKEOUT_DESCENT = maximum descent
-.DE
-where \fImaximum descent\fP is the maximum descent (below the baseline)
-in pixels of any glyph in the font.
-.NH 3
-ITALIC_ANGLE
-.XS
-\*(SN ITALIC_ANGLE
-.XE
-.LP
-ITALIC_ANGLE is an integer value (of type INT32)
-that gives the nominal posture angle of the typeface design, in 1/64 degrees, 
-measured from the glyph origin counterclockwise from the three o'clock position.
-.LP
-ITALIC_ANGLE can be defaulted if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (ITALIC_ANGLE undefined) then
-   ITALIC_ANGLE = (90 * 64)
-.DE
-.NH 3
-CAP_HEIGHT 
-.XS
-\*(SN CAP_HEIGHT
-.XE
-.LP
-CAP_HEIGHT is an integer value (of type INT32)
-that gives the nominal height of the capital letters contained in the font, 
-as specified by the FOUNDRY or typeface designer.
-.LP
-Certain clients require CAP_HEIGHT to compute scale factors and 
-positioning offsets for synthesized glyphs where this 
-information or designed glyphs are not explicitly provided by the font 
-(for example, small capitals, superiors, inferiors, and so on).
-CAP_HEIGHT is also a critical factor in font matching and substitution.
-.LP
-CAP_HEIGHT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (CAP_HEIGHT undefined) then
-   if (Latin font) then
-      CAP_HEIGHT = XCharStruct.ascent[glyph X]
-   else if (capitals exist) then
-       CAP_HEIGHT = XCharStruct.ascent[some unaccented capital glyph]
-   else CAP_HEIGHT undefined
-.DE
-.NH 3
-X_HEIGHT
-.XS
-\*(SN X_HEIGHT
-.XE
-.LP
-X_HEIGHT is an integer value (of type INT32)
-that gives the nominal height above the baseline of the lowercase glyphs 
-contained in the font, 
-as specified by the FOUNDRY or typeface designer.
-.LP
-As with CAP_HEIGHT, 
-X_HEIGHT is required by certain clients to compute scale factors 
-for synthesized small capitals where this information is not explicitly 
-provided by the font resource.
-X_HEIGHT is a critical factor in font matching and substitution.
-.LP
-X_HEIGHT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS I
-if (X_HEIGHT undefined) then
-   if (Latin font) then
-      X_HEIGHT = XCharStruct.ascent[glyph x]
-   else if (lowercase exists) then
-        X_HEIGHT = XCharStruct.ascent[some unaccented lc glyph without an ascender]
-   else X_HEIGHT undefined
-.DE
-.NH 3
-RELATIVE_SETWIDTH
-.XS
-\*(SN RELATIVE_SETWIDTH
-.XE
-.LP
-RELATIVE_SETWIDTH is an unsigned integer value (of type CARD32)
-that gives the coded proportionate width of the font,
-relative to all known fonts of the same typeface family, 
-according to the type designer's or FOUNDRY's judgment.
-.LP
-RELATIVE_SETWIDTH ranges from 10 to 90 or is 0 if undefined or unknown.
-The following reference values are defined:
-.TS H
-lw(.5i) lw(1i) lw(2.75i).
-_
-.sp 6p
-.B
-Code	English Translation	Description
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-0	Undefined	Undefined or unknown
-10	UltraCondensed	The lowest ratio of average width to height
-20	ExtraCondensed
-30	Condensed	Condensed, Narrow, Compressed, ...
-40	SemiCondensed
-50	Medium	Medium, Normal, Regular, ...
-60	SemiExpanded	SemiExpanded, DemiExpanded, ...
-70	Expanded
-80	ExtraExpanded	ExtraExpanded, Wide, ...
-90	UltraExpanded	The highest ratio of average width to height
-.sp 6p
-_
-.TE
-.LP
-RELATIVE_SETWIDTH can be defaulted if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (RELATIVE_SETWIDTH undefined) then
-   RELATIVE_SETWIDTH = 50
-.DE
-.LP
-For polymorphic fonts, RELATIVE_SETWIDTH is not necessarily a
-linear function of the font's setwidth axis.
-.LP
-X clients that want to obtain a calculated proportionate width of the 
-font (that is, a font-independent way of identifying the proportionate 
-width across all fonts and all font vendors) can use the following algorithm: 
-.LP
-.DS
-SETWIDTH = AVG_CAPITAL_WIDTH / (CAP_HEIGHT * 10)
-.DE
-.LP
-where SETWIDTH is a real number with zero being the narrowest 
-calculated setwidth.
-.NH 3
-RELATIVE_WEIGHT
-.XS
-\*(SN RELATIVE_WEIGHT
-.XE
-.LP
-RELATIVE_WEIGHT is an unsigned integer value (of type CARD32)
-that gives the coded weight of the font, 
-relative to all known fonts of the same typeface family, 
-according to the type designer's or FOUNDRY's judgment.
-.LP
-RELATIVE_WEIGHT ranges from 10 to 90 or is 0 if undefined or unknown.
-The following reference values are defined:
-.TS H
-lw(.5i) lw(1i) lw(3.75i).
-_
-.sp 6p
-.B
-Code	English Translation	Description
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-0	Undefined	Undefined or unknown
-10	UltraLight	The lowest ratio of stem width to height
-20	ExtraLight
-30	Light
-40	SemiLight	SemiLight, Book, ...
-50	Medium	Medium, Normal, Regular,...
-60	SemiBold	SemiBold, DemiBold, ...
-70	Bold
-80	ExtraBold	ExtraBold, Heavy, ...
-90	UltraBold	T{
-UltraBold, Black, ..., the highest ratio of stem width to height
-T}
-.sp 6p
-_
-.TE
-.LP
-RELATIVE_WEIGHT can be defaulted if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (RELATIVE_WEIGHT undefined) then
-   RELATIVE_WEIGHT = 50
-.DE
-.LP
-For polymorphic fonts, RELATIVE_WEIGHT is not necessarily a
-linear function of the font's weight axis.
-.NH 3 
-WEIGHT
-.XS
-\*(SN WEIGHT
-.XE
-.LP
-Calculated WEIGHT is an unsigned integer value (of type CARD32)
-that gives the calculated weight of the font, 
-computed as the ratio of capital stem width to CAP_HEIGHT, 
-in the range 0 to 1000, where 0 is the lightest weight.
-.LP
-WEIGHT can be calculated if not supplied as a font property, 
-according to the following algorithm:
-.LP
-.DS
-CapStemWidth = average width of the stems of capitals
-if (WEIGHT undefined) then
-   WEIGHT = ROUND ((CapStemWidth * 1000) / CAP_HEIGHT)
-.DE
-.LP
-A calculated value for weight is necessary when matching fonts from 
-different families because both the RELATIVE_WEIGHT and the WEIGHT_NAME are 
-assigned by the typeface supplier, according to its tradition and practice, 
-and therefore, are somewhat subjective.
-Calculated WEIGHT provides a font-independent way of identifying 
-the weight across all fonts and all font vendors.
-.NH 3
-RESOLUTION 
-.XS
-\*(SN RESOLUTION 
-.XE
-.LP
-RESOLUTION is an integer value (of type INT32)
-that gives the resolution for which this font was created,
-measured in 1/100 pixels per point.
-.NT Note
-As independent horizontal and vertical design resolution components
-are required to accommodate displays with nonsquare aspect ratios,
-the use of this font property has been deprecated,
-and independent RESOLUTION_X and RESOLUTION_Y font name fields/properties 
-have been defined (see sections 3.1.2.9 and 3.1.2.10).
-X clients are encouraged to discontinue use of the RESOLUTION property
-and are encouraged to use the appropriate X,Y resolution properties,
-as required.
-.NE                     \" Note End
-.NH 3
-FONT
-.XS
-\*(SN FONT
-.XE
-.LP
-FONT is a string (of type ATOM) that gives the full XLFD name of the
-font\*-that is, the value can be used to open another
-instance of the same font.
-.LP
-If not provided, the FONT property cannot be calculated.
-.NH 3
-FACE_NAME 
-.XS
-\*(SN FACE_NAME
-.XE
-.LP
-FACE_NAME is a human-understandable string (of type ATOM)
-that gives the full device-independent typeface name, 
-including the owner, weight, slant, set, and so on 
-but not the resolution, size, and so on.
-This property may be used as feedback during font selection.
-.LP
-FACE_NAME cannot be calculated or approximated if not provided as a font 
-property.
-.NH 3
-FULL_NAME
-.XS
-\*(SN FULL_NAME
-.XE
-.LP
-FULL_NAME is the same as FACE_NAME.
-Its use is deprecated, but it is found on some old fonts.
-.NH 3
-COPYRIGHT 
-.XS
-\*(SN COPYRIGHT
-.XE
-.LP
-COPYRIGHT is a human-understandable string (of type ATOM)
-that gives the copyright information of the legal owner 
-of the digital font data.
-.LP
-This information is a required component of a font
-but is independent of the particular format used to represent it 
-(that is, it cannot be captured as a comment that could later 
-be thrown away for efficiency reasons).
-.LP
-COPYRIGHT cannot be calculated or approximated if not provided as a font 
-property.
-.NH 3
-NOTICE
-.XS
-\*(SN NOTICE
-.XE
-.LP
-NOTICE is a human-understandable string (of type ATOM)
-that gives the copyright information of the legal owner of the font design
-or, if not applicable, the trademark information for the typeface FAMILY_NAME.
-.LP
-Typeface design and trademark protection laws vary from country to country, 
-the USA having no design copyright protection currently
-while various countries in Europe offer both design and typeface family name 
-trademark protection.
-As with COPYRIGHT, 
-this information is a required component of a font 
-but is independent of the particular format used to represent it.
-.LP
-NOTICE cannot be calculated or approximated if not provided as a font property.
-.NH 3
-DESTINATION 
-.XS
-\*(SN DESTINATION
-.XE
-.LP
-DESTINATION is an unsigned integer code (of type CARD32)
-that gives the font design destination, 
-that is, whether it was designed as a screen proofing font to match 
-printer font glyph widths (WYSIWYG), as an optimal video font (possibly with 
-corresponding printer font) for extended screen viewing (video text), and so on.
-.LP
-The font design considerations are very different, 
-and at current display resolutions, 
-the readability and legibility of these two kinds of screen fonts 
-are very different.
-DESTINATION allows publishing clients that use X to model the printed page
-and video text clients, such as on-line documentation browsers, 
-to query for X screen fonts that suit their particular requirements.
-.LP
-The encoding is as follows:
-.TS H
-lw(.5i) lw(1i) lw(3.75i).
-_
-.sp 6p
-.B
-Code	English Translation	Description
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-0	WYSIWYG	T{
-The font is optimized to match the typographic design and metrics of an 
-equivalent printer font.
-T}
-1	Video text	T{
-The font is optimized for screen legibility and readability.
-T}
-.sp 6p
-_
-.TE
-
-.NH 3
-FONT_TYPE
-.XS
-\*(SN FONT_TYPE
-.XE
-.LP
-FONT_TYPE is a human-understandable string (of type ATOM) that
-describes the format of
-the font data as they are read from permanent storage by the current font source.
-It is a static attribute of the source data.  It can be used
-by clients to select a type of bitmap or outline font
-without regard to the rasterizer used to render the font.
-.LP
-Predefined values are as follows:
-.TS H
-l lw(5i).
-_
-.sp 6p
-.B
-Value	When applicable
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-\*QBitmap\*U	T{
-Hand-tuned bitmap fonts.  Some
-attempt has been made to optimize
-the visual appearance of the font
-for the requested size and
-resolution.
-T}
-\*QPrebuilt\*U	T{
-All bitmap format fonts that
-cannot be described as \*QBitmap\*U,
-that is, hand-tuned.  For example,
-a bitmap format font that was
-generated mechanically using a
-scalable font rasterizer
-would be considered \*QPrebuilt\*U, not \*QBitmap\*U.
-T}
-\*QType 1\*U	Any Type 1 font.
-\*QTrueType\*U	Any TrueType font.
-\*QSpeedo\*U	Any Speedo font.
-\*QF3\*U	Any F3 font.
-.sp 6p
-_
-.TE
-.LP
-Other values may be registered with the X Consortium.
-.NH 3
-FONT_VERSION
-.XS
-\*(SN FONT_VERSION
-.XE
-.LP
-FONT_VERSION is a human-understandable string (of type ATOM)
-that describes the formal or informal version of the font.
-\fBNone\fP is a valid value.
-.NH 3
-RASTERIZER_NAME
-.XS
-\*(SN RASTERIZER_NAME
-.XE
-.LP
-RASTERIZER_NAME is a human-understandable string (of type ATOM)
-that is the specific name of the
-rasterizer that has performed some rasterization operation
-(such as scaling from outlines) on this font.
-.LP
-To define a RASTERIZER_NAME, the following format is
-recommended:
-.SM
-.TS
-rw(1.5i) lw(3.75i).
-RasterizerName ::=	OrganizationId Space Rasterizer
-OrganizationId ::=	T{
-STRING8\*-the X Registry ORGANIZATION name
-of the rasterizer implementor or maintainer.
-T}
-Rasterizer ::=	T{
-the case-sensitive, human-understandable product name
-of the rasterizer.  Words within this
-name should be separated by a single SPACE.
-T}
-Space ::=	OCTET\-\*Q\0\*U (SPACE)
-.TE
-.NL
-.LP
-Examples:
-.nf
-		X Consortium Bit Scaler
-		X Consortium Type 1 Rasterizer
-		X Consortium Speedo Rasterizer
-		Adobe Type Manager
-		Sun TypeScaler
-.fi
-.LP
-If RASTERIZER_NAME is not defined, or is \fBNone\fP, no
-rasterization operation has been applied to the FONT_TYPE.
-.NH 3
-RASTERIZER_VERSION
-.XS
-\*(SN RASTERIZER_VERSION
-.XE
-.LP
-RASTERIZER_VERSION is a human-understandable string (of type
-ATOM) that represents the formal or informal version of a
-font rasterizer.
-The RASTERIZER_VERSION should match the corresponding
-product version number known to users, when applicable.
-.NH 3
-RAW_ASCENT
-.XS
-\*(SN RAW_ASCENT
-.XE
-.LP
-For a font with a transformation matrix, RAW_ASCENT is the font ascent
-in 1000 pixel metrics
-(see section \n(sM.1).
-.NH 3
-RAW_DESCENT
-.XS
-\*(SN RAW_DESCENT
-.XE
-.LP
-For a font with a transformation matrix, RAW_DESCENT is the font
-descent in 1000 pixel metrics
-(see section \n(sM.1).
-.NH 3
-RAW_*
-.XS
-\*(SN RAW_*
-.XE
-.LP
-For a font with a transformation matrix, 
-all font properties that represent horizontal or vertical sizes or
-displacements will be accompanied by a new property, named as the
-original except prefixed with \*QRAW_\*U, that is computed as
-described in section \n(sM.1.
-.NH 3
-AXIS_NAMES
-.XS
-\*(SN AXIS_NAMES
-.XE
-.LP
-AXIS_NAMES is a list of all the
-names of the axes for a polymorphic font, separated by a null (0) byte.
-These names are suitable for presentation in a user interface
-(see section \n(sP).
-.NH 3
-AXIS_LIMITS
-.XS
-\*(SN AXIS_LIMITS
-.XE
-.LP
-AXIS_LIMITS is a list of integers, two for each axis,
-giving the minimum and maximum allowable values for that axis of a
-polymorphic font
-(see section \n(sP).
-.NH 3
-AXIS_TYPES
-.XS
-\*(SN AXIS_TYPES
-.XE
-.LP
-AXIS_TYPES is like AXIS_NAMES,
-but can be registered as having specific semantics
-(see section \n(sP).
-.NH 2
-Built-in Font Property Atoms
-.XS
-\*(SN Built-in Font Property Atoms
-.XE
-.LP
-The following font property atom definitions were predefined in the initial 
-version of the core protocol:
-.TS H
-l l.
-_
-.sp 6p
-.B
-Font Property/Atom Name	Property Type
-.sp 6p
-_
-.sp 6p
-.TH
-.R
-MIN_SPACE	INT32
-NORM_SPACE	INT32
-MAX_SPACE	INT32
-END_SPACE	INT32
-SUPERSCRIPT_X	INT32
-SUPERSCRIPT_Y	INT32
-SUBSCRIPT_X	INT32
-SUBSCRIPT_Y	INT32
-UNDERLINE_POSITION	INT32
-UNDERLINE_THICKNESS	INT32
-STRIKEOUT_ASCENT	INT32
-STRIKEOUT_DESCENT	INT32
-FONT_ASCENT	INT32
-FONT_DESCENT	INT32
-ITALIC_ANGLE	INT32
-X_HEIGHT	INT32
-QUAD_WIDTH	INT32 \- deprecated
-WEIGHT	CARD32
-POINT_SIZE	INT32
-RESOLUTION	CARD32 \- deprecated
-COPYRIGHT	ATOM
-FULL_NAME	ATOM \- deprecated
-FAMILY_NAME	ATOM
-DEFAULT_CHAR	CARD32
-.sp 6p
-_
-.TE
-.br
-.\" section \n(sM
-.NH 1
-Matrix Transformations
-.XS
-\*(SN Matrix Transformations
-.XE
-.LP
-An XLFD name presented to the server can have the POINT_SIZE or PIXEL_SIZE
-field begin with the character \*Q[\*U.  If the first character of the field
-is \*Q[\*U, the character must be followed with ASCII representations of
-four floating point numbers and a trailing \*Q]\*U, with white space
-separating the numbers and optional white space separating the numbers
-from the \*Q[\*U and \*Q]\*U characters.  Numbers use standard floating point
-syntax but use the character \*Q\^~\^\*U to represent a minus sign in the mantissa
-or exponent.
-.LP
-The BNF for a matrix transformation string is as follows:
-.SM
-.TS
-rw(1.5i) l.
-MatrixString ::=	T{
-LeftBracket OptionalSpace Float Space Float Space
-Float Space Float OptionalSpace RightBracket
-T}
-OptionalSpace ::=	\*Q\*U | Space
-Space ::=	SpaceChar | SpaceChar Space
-Float ::=	Mantissa | Mantissa Exponent
-Mantissa ::=	Sign Number | Number
-Sign ::=	Plus | Tilde
-Number ::=	Integer | Integer Dot Integer | Dot Integer
-Integer ::=	Digit | Digit Integer
-Digit ::=	\*Q0\*U | \*Q1\*U | \*Q2\*U | \*Q3\*U | \*Q4\*U | \*Q5\*U | \*Q6\*U | \*Q7\*U | \*Q8\*U | \*Q9\*U
-Exponent ::=	\*Qe\*U SignedInteger | \*QE\*U SignedInteger
-SignedInteger ::=	Sign Integer | Integer
-LeftBracket ::=	OCTET \- \*Q[\*U (LEFT SQUARE BRACKET)
-RightBracket ::=	OCTET \- \*Q]\*U (RIGHT SQUARE BRACKET)
-SpaceChar ::=	OCTET \- \*Q\0\*U (SPACE)
-Tilde ::=	OCTET \- \*Q\^~\^\*U (TILDE)
-Plus ::=	OCTET \- \*Q+\*U (PLUS)
-Dot ::=	OCTET \- \*Q\^.\^\*U (FULL STOP)
-.TE
-.NL
-.LP
-The string \*Q[a b c d]\*U represents a graphical transformation of the glyphs
-in the font by the matrix
-.TS
-c c c c c.
-[	a	b	0	]
-[	c	d	0	]
-[	0	0	1	]
-.TE
-.LP
-All transformations occur around the origin of the glyph.  The
-relationship between the current scalar values and the matrix
-transformation values is that the scalar value \*QN\*U in the POINT_SIZE field
-produces the same glyphs as the matrix \*Q[N/10 0 0 N/10]\*U in that field,
-and the scalar value \*QN\*U in the PIXEL_SIZE field produces the same glyphs
-as the matrix \*Q[N*RESOLUTION_X/RESOLUTION_Y 0 0 N]\*U in that field.
-.LP
-If matrices are specified for both the POINT_SIZE and PIXEL_SIZE, they
-must bear the following relationship to each other within an
-implementation-specific tolerance:
-.br
-	PIXEL_SIZE_MATRIX = [Sx 0 0 Sy] * POINT_SIZE_MATRIX
-.br
-where
-.br
-	Sx = RESOLUTION_X / 72.27
-.br
-	Sy = RESOLUTION_Y / 72.27
-.LP
-If either the POINT_SIZE or PIXEL_SIZE field is unspecified (either \*Q0\*U or
-wildcarded), the preceding formulas can be used to compute one from the
-other.
-.\"
-.NH 2
-Metrics and Font Properties
-.XS
-\*(SN Metrics and Font Properties
-.XE
-.LP
-In this section, the phrase \*Q1000 pixel metrics\*U means the
-metrics that would be obtained if the rasterizer took the base untransformed
-design used to generate the transformed font and scaled it linearly to a
-height of 1000 pixels, with no rotation component.  Note that there may be no
-way for the application to actually request this font since the rasterizer
-may use different outlines or rasterization techniques at that size from the
-ones used to generate the transformed font.
-.LP
-Notes on properties and metrics:
-.LP
-The per-char ink metrics (lbearing, rbearing, ascent, and descent)
-represent the ink extent of the transformed glyph around its origin.
-.LP
-The per-char width is the x component of the transformed character width.
-.LP
-The font ascent and descent are the y component of the transformed font
-ascent or descent.
-.LP
-The FONT property returns a name reflecting the matrix being
-used\*-that is, the name returned can be used to open another
-instance of the same font.  The returned name is not necessarily an
-exact copy of the requested name.  If, for example, the user
-requests
-.br
-.ft C
-.SM
-   \-misc\-fixed\-medium\-r\-normal\-\-0\-[2e1 0 0.0 +10.0]\-72\-72\-c\-0\-iso8859\-1
-.NL
-.ft P
-.br
-the resulting FONT property might be
-.br
-.ft C
-.SM
-   \-misc\-fixed\-medium\-r\-normal\-\-[19.9 0 0 10]\-[20 0 0 10]\-72\-72\-c\-0\-iso8859\-1
-.NL
-.ft P
-.br
-The FONT property will always include matrices in both the PIXEL_SIZE
-and the POINT_SIZE fields.
-.LP
-To allow accurate client positioning of transformed characters, the
-attributes field of the XCharInfo contains the width of the character in
-1000 pixel metrics.  This attributes field should be interpreted as a signed
-integer.
-.LP
-There will always be 2 new font properties defined, RAW_ASCENT and
-RAW_DESCENT, that hold the ascent and descent in 1000 pixel metrics.
-.LP
-All font properties that represent horizontal widths or displacements
-have as their value the x component of the transformed width or
-displacement.  All font properties that represent vertical heights or
-displacements have as their value the y component of the transformed
-height or displacement.  Each such property will be accompanied by a new
-property, named as the original except prefixed with \*QRAW_\*U, that gives
-the value of the width, height, or displacement in 1000 pixel metrics.
-.NH 1
-Scalable Fonts
-.XS
-\*(SN Scalable Fonts
-.XE
-.LP
-The XLFD is designed to support scalable fonts.  A scalable font is a
-font source from which instances of arbitrary size can be derived.
-A scalable font source might be one or more outlines
-together with zero or more hand-tuned bitmap fonts at specific sizes and
-resolutions, or it might be a programmatic description together with
-zero or more bitmap fonts, or some other format
-(perhaps even just a single bitmap font).
-.LP
-The following definitions are useful for discussing scalable fonts:
-.LP
-\fBWell-formed XLFD pattern\fP
-.IP
-A pattern string containing 14 hyphens, one of which is
-the first character of the pattern.  Wildcard characters are permitted
-in the fields of a well-formed XLFD pattern.
-.LP
-\fBScalable font name\fP
-.IP
-A well-formed XLFD pattern containing no wildcards and containing the
-digit \*Q0\*U in the PIXEL_SIZE, POINT_SIZE, and AVERAGE_WIDTH fields.
-.LP
-\fBScalable fields\fP
-.IP
-The XLFD fields PIXEL_SIZE, POINT_SIZE, RESOLUTION_X,
-RESOLUTION_Y, and AVERAGE_WIDTH.
-.LP
-\fBDerived instance\fP
-.IP
-The result of replacing the scalable fields of a font name
-with values to yield a font name that could actually be
-produced from the font source.  A scaling engine is
-permitted, but not required, to interpret the scalable
-fields in font names to support anamorphic scaling.
-.LP
-\fBGlobal list\fP
-.IP
-The list of names that would be returned by an X server for a
-.PN ListFonts
-protocol request on the pattern \*Q*\*U if there were no protocol
-restrictions on the total number of names returned.
-.sp
-.LP
-The global list consists of font names derived from font sources.
-If a single font source can support multiple character sets (specified
-in the CHARSET_REGISTRY and CHARSET_ENCODING fields), each such character
-set should be used to form a separate font name in the list.
-For a nonscalable font source, the simple font name
-for each character set is included in the global list.
-For a scalable font source, a scalable font name for each character set
-is included in the list.  In addition to the scalable font name,
-specific derived instance names may also be included in the list.
-The relative order of derived instances with respect to the scalable
-font name is not constrained.  Finally, font name aliases may also be included
-in the list.  The relative order of aliases
-with respect to the real font name is not constrained.
-.LP
-The values of the RESOLUTION_X and RESOLUTION_Y fields of a scalable font name
-are implementation dependent,
-but to maximize backward compatibility, they
-should be reasonable nonzero values, for example, a resolution close to that
-provided by the screen (in a single-screen server).
-Because some existing
-applications rely on seeing a collection of point and pixel sizes,
-server vendors are strongly encouraged in the near term to
-provide a mechanism for including, for each scalable font name,
-a set of specific derived instance names.  For font sources that contain
-a collection of hand-tuned bitmap fonts, including names of these instances
-in the global list is recommended and sufficient.
-.LP
-The X protocol request
-.PN OpenFont
-on a scalable font name returns a font corresponding to an
-implementation-dependent derived instance of that font name.
-.LP
-The X protocol request
-.PN ListFonts
-on a well-formed XLFD pattern returns the following.
-Starting with the global list, if the actual pattern argument
-has values containing no wildcards in scalable fields,
-then substitute each such field into the corresponding
-field in each scalable font name in the list.  For each resulting font name,
-if the remaining scalable fields cannot be replaced with values to produce a
-derived instance, remove the font name from the list.  Now take the modified
-list, and perform a simple pattern match against the pattern argument.
-.PN ListFonts
-returns the resulting list.
-.LP
-For example, given the global list:
-.DS
--Linotype-Times-Bold-I-Normal--0-0-100-100-P-0-ISO8859-1
--Linotype-Times-Bold-R-Normal--0-0-100-100-P-0-ISO8859-1
--Linotype-Times-Medium-I-Normal--0-0-100-100-P-0-ISO8859-1
--Linotype-Times-Medium-R-Normal--0-0-100-100-P-0-ISO8859-1
-.DE
-.LP
-a
-.PN ListFonts
-request with the pattern:
-.LP
-.DS
--*-Times-*-R-Normal--*-120-100-100-P-*-ISO8859-1
-.DE
-.LP
-would return:
-.DS
--Linotype-Times-Bold-R-Normal--0-120-100-100-P-0-ISO8859-1
--Linotype-Times-Medium-R-Normal--0-120-100-100-P-0-ISO8859-1
-.DE
-.LP
-.PN ListFonts
-on a pattern containing wildcards that is not a well-formed XLFD
-pattern is only required to return the list obtained by performing
-a simple pattern match against the global list.
-X servers are permitted, but not required,
-to use a more sophisticated matching algorithm.
-.br
-.\" section \n(sP
-.NH 1
-Polymorphic Fonts
-.XS
-\*(SN Polymorphic Fonts
-.XE
-.LP
-Fonts that can be varied in ways other than size or resolution are called
-\fIpolymorphic fonts.\fP  Multiple Master Type 1 font programs are one type of
-a polymorphic font.  Current examples of axes along which the fonts can be
-varied are width, weight, and optical size; others might include formality
-or x-height.
-.LP
-To support polymorphic fonts, special values indicating variability are
-defined for the following XLFD fields:
-.nf
-	WEIGHT_NAME
-	SLANT
-	SETWIDTH_NAME
-	ADD_STYLE_NAME
-.fi
-.LP
-The string \*Q0\*U is the special polymorphic value.  In the
-WEIGHT_NAME, SLANT, or SETWIDTH_NAME field, \*Q0\*U must be the
-entire field.
-There may be multiple polymorphic values
-in the ADD_STYLE_NAME field.
-They are surrounded by \*Q[\*U and \*Q]\*U and separated by a Space,
-as \*Q[0\00]\*U.  The polymorphic values may coexist with
-other data in the field.
-It is recommended that the polymorphic values
-be at the end of the ADD_STYLE_NAME field.
-.LP
-The font-matching algorithms for a font with polymorphic fields are
-identical to the matching algorithms for a font with scalable fields.
-.LP
-There are three new font properties to describe the axes of variation,
-AXIS_NAMES, AXIS_LIMITS, and AXIS_TYPES.  AXIS_NAMES is a list of all the
-names of the axes for the font, separated by a null (0) byte.
-These names are suitable for presentation in
-a user interface.  AXIS_LIMITS is a list of integers, two for each axis,
-giving the minimum and maximum allowable values for that axis.
-AXIS_TYPES is like AXIS_NAMES,
-but can be registered as having specific semantics.
-.LP
-The axes are listed in the properties in the same order as they
-appear in the font name.  They are matched with font name fields by
-looking for the special polymorphic values in the font name.
-.LP
-Examples:
-.LP
-The Adobe Myriad MM font program has width and weight axes.  Weight can
-vary from 215 to 830, and width from 300 to 700.
-.\" indented display
-.ID
-.SM
-Name:
-.ft C
-	-Adobe-Myriad MM-0-R-0--0-0-0-0-P-0-ISO8859-1
-.ft P
-AXIS_NAMES:
-	Weight, Width
-AXIS_LIMITS:
-	215, 830, 300, 700
-AXIS_TYPES:
-	Adobe-Weight, Adobe-Width
-Sample derived instance:
-.ft C
-	-Adobe-Myriad MM-412-R-575--*-120-100-100-P-*-ISO8859-1
-.ft P
-.NL
-.DE                     \" display end
-.LP
-The Adobe Minion MM Italic font program has width, weight, and optical
-size axes.
-.ID
-.SM
-Name:
-.ft C
-	-Adobe-Minion MM-0-I-0-[0]-0-0-0-0-P-0-ISO8859-1
-.ft P
-AXIS_NAMES:
-	Weight, Width, Optical size
-AXIS_LIMITS:
-	345, 620, 450, 600, 6, 72
-AXIS_TYPES:
-	Adobe-Weight, Adobe-Width, Adobe-OpticalSize
-Sample derived instance:
-.ft C
-	-Adobe-Minion MM-550-I-480-[18]-*-180-100-100-P-*-ISO8859-1
-.ft P
-.NL
-.DE
-.LP
-The Adobe Minion MM Swash Italic font program has the same axes and
-values.  This shows how
-\*Q[0]\*U in the ADD_STYLE_NAME field can
-coexist with other words.
-.ID
-.SM
-Name:
-.ft C
-	-Adobe-Minion MM-0-I-0-Swash[0]-0-0-0-0-P-0-ISO8859-1
-.ft P
-AXIS_NAMES:
-	Weight, Width, Optical size
-AXIS_LIMITS:
-	345, 620, 450, 600, 6, 72
-AXIS_TYPES:
-	Adobe-Weight, Adobe-Width, Adobe-OpticalSize
-Sample derived instance:
-.ft C
-	-Adobe-Minion MM-550-I-480-Swash[18]-*-180-100-100-P-*-ISO8859-1
-.ft P
-.NL
-.DE
-.LP
-The XYZ Abc font, a hypothetical font, has optical size and x-height axes.
-This shows how there can be more than one polymorphic value in the
-ADD_STYLE_NAME field.
-.ID
-.SM
-Name:
-.ft C
-	-XYZ-Abc-Medium-R-Normal-[0 0]-0-0-0-0-P-0-ISO8859-1
-.ft P
-AXIS_NAMES:
-	Optical size, X-height
-AXIS_LIMITS:
-	6, 72, 400, 600
-AXIS_TYPES:
-	XYZ-OpticalSize, XYZ-Xheight
-Sample derived instance:
-.ft C
-	-XYZ-Abc-Medium-R-Normal-[14 510]-*-140-100-100-P-*-ISO8859-1
-.ft P
-.NL
-.DE
-.LP
-If an axis allows negative values, a client requests a negative value by
-using \*Q\^~\^\*U (TILDE) as a minus sign.
-.LP
-Axis types can be registered with the X Consortium, along with their
-semantics.
-.LP
-If a font name that contains the polymorphic value or a wildcard in a
-polymorphic field is presented to a font source, the font source is free
-to substitute any value that is convenient.  However, font sources should
-try to use a value that would be considered \fInormal\fP or \fImedium\fP for the
-particular font.  For example, if an optical size variable is unresolved,
-the font source should provide a value appropriate to the size of the
-font.
-.LP
-The result of specifying an out-of-range value for a polymorphic field is
-undefined.  The font source may treat this as a \fBBadName\fP error, treat the
-value as if it were the closest legal value, or extrapolate to try to
-accommodate the value.
-.NH 1
-Affected Elements of Xlib and the X Protocol
-.XS
-\*(SN Affected Elements of Xlib and the X Protocol
-.XE
-.LP
-The following X protocol requests must support the XLFD conventions:
-.IP \(bu 5
-.PN OpenFont
-\- for the name argument
-.IP \(bu 5
-.PN ListFonts
-\- for the pattern argument
-.IP \(bu 5
-.PN ListFontsWithInfo
-\- for the pattern argument
-.LP
-In addition, 
-the following Xlib functions must support the XLFD conventions:
-.IP \(bu 5
-.PN XLoadFont
-\- for the name argument
-.IP \(bu 5
-.PN XListFontsWithInfo
-\- for the pattern argument
-.IP \(bu 5
-.PN XLoadQueryFont
-\- for the name argument
-.IP \(bu 5
-.PN XListFonts
-\- for the pattern argument
-.NH 1
-BDF Conformance
-.XS
-\*(SN BDF Conformance
-.XE
-.LP
-The bitmap font distribution and interchange format adopted by the 
-X Consortium (BDF V2.1) provides a general mechanism for identifying the 
-font name of an X font and a variable list of font properties, 
-but it does not mandate the syntax or semantics of the font name 
-or the semantics of the font properties that might be provided in a BDF font.
-This section identifies the requirements for BDF fonts that conform to XLFD.
-.NH 2
-XLFD Conformance Requirements
-.XS
-\*(SN XLFD Conformance Requirements
-.XE
-.LP
-A BDF font conforms to the XLFD specification if and only if the 
-following conditions are satisfied:
-.IP \(bu 5
-The value for the BDF item \fBFONT\fP conforms to the syntax 
-and semantic definition of a XLFD 
-.PN FontName 
-string.
-.IP \(bu 5
-The 
-.PN FontName 
-begins with the X 
-.PN FontNameRegistry 
-prefix: \*Q\-\*U.
-.IP \(bu 5
-All XLFD 
-.PN FontName 
-fields are defined.
-.IP \(bu 5
-Any FontProperties provided conform in name and semantics to the XLFD 
-.PN FontProperty 
-definitions.
-.LP             
-A simple method of testing for conformance would entail verifying that the 
-.PN FontNameRegistry 
-prefix is the string \*Q\-\*U, 
-that the number of field delimiters in the string and coded field values 
-are valid, 
-and that each font property name either matches a standard XLFD property name 
-or follows the definition of a private property.
-.NH 2
-FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR
-.XS
-\*(SN FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR
-.XE
-.LP
-FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR are provided in the BDF 
-specification as properties that are moved to the 
-.PN XFontStruct 
-by the BDF font compiler in generating the X server-specific 
-binary font encoding.
-If present, 
-these properties shall comply with the following semantic definitions.
-.NH 3
-FONT_ASCENT
-.XS
-\*(SN FONT_ASCENT
-.XE
-.LP
-FONT_ASCENT is an integer value (of type INT32)
-that gives the recommended typographic ascent above the baseline 
-for determining interline spacing.
-Specific glyphs of the font may extend beyond this.
-If the current position point for line \fIn\fP is at [X,Y], 
-then the origin of the next line \fIm = n + 1\fP
-(allowing for a possible font change) is 
-[X, Y + FONT_DESCENTn + FONT_ASCENTm].
-.LP
-FONT_ASCENT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (FONT_ASCENT undefined) then
-   FONT_ASCENT = maximum ascent
-.DE
-where maximum ascent is the maximum ascent (above the baseline)
-in pixels of any glyph in the font.
-.NH 3
-FONT_DESCENT
-.XS
-\*(SN FONT_DESCENT
-.XE
-.LP
-FONT_DESCENT is an integer value (of type INT32)
-that gives the recommended typographic descent below the baseline
-for determining interline spacing.
-Specific glyphs of the font may extend beyond this.
-If the current position point for line \fIn\fP is at [X,Y],
-then the origin of the next line \fIm = n+1\fP
-(allowing for a possible font change) is 
-[X, Y + FONT_DESCENTn + FONT_ASCENTm].
-.LP
-The logical extent of the font is inclusive between the Y-coordinate values: 
-Y \- FONT_ASCENT and Y + FONT_DESCENT + 1.
-.LP
-FONT_DESCENT can be approximated if not provided as a font property, 
-according to the following algorithm:
-.LP
-.DS
-if (FONT_DESCENT undefined) then
-   FONT_DESCENT = maximum descent
-.DE
-where maximum descent is the maximum descent (below the baseline)
-in pixels of any glyph in the font.
-.NH 3
-DEFAULT_CHAR
-.XS
-\*(SN DEFAULT_CHAR
-.XE
-.LP
-The DEFAULT_CHAR is an unsigned integer value (of type CARD32)
-that specifies the index
-of the default character to be used by the X server when an attempt
-is made to display an undefined or nonexistent character in the font.
-(For a font using a 2-byte matrix format,
-the index bytes are encoded in the integer as byte1 * 65536 + byte2.)
-If the DEFAULT_CHAR itself specifies an undefined or nonexistent character 
-in the font, 
-then no display is performed.
-.LP
-DEFAULT_CHAR cannot be approximated if not provided as a font property.
-.\"
-.\" print Table of Contents
-.if o .bp \" blank page to make count even
-.bp 1
-.af PN i
-.PX
diff --git a/specs/XLFD/xlfd.xml b/specs/XLFD/xlfd.xml
new file mode 100644
index 0000000..98686a4
--- /dev/null
+++ b/specs/XLFD/xlfd.xml
@@ -0,0 +1,4124 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<book id="BOOKID">
+
+<bookinfo>
+   <title>X Logical Font Description Conventions</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>Version 1.5</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>Jim</firstname><surname>Flowers</surname>
+         <affiliation><orgname>
+Digital Equipment Corporation
+         </orgname></affiliation>
+         <email>blah@blah.com</email>
+      </author>
+      <othercredit>
+         <contrib>edited by</contrib>
+         <firstname>Stephen </firstname><surname>Gildea</surname>
+      </othercredit>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1988,1994</year><holder>X Consortium</holder></copyright>
+   <copyright>
+      <year>1988,1994</year>
+      <holder>Digital Equipment Corporation</holder>
+   </copyright>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.8</productnumber>
+
+<legalnotice>
+
+<para>
+<emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.
+</para>
+<para>
+Helvetica and Times are registered trademarks of Linotype Company.
+</para>
+<para>
+ITC Avant Garde Gothic is a registered trademark of International
+Typeface Corporation.
+</para>
+<para>
+Times Roman is a registered trademark of Monotype Corporation.
+</para>
+<para>
+Bitstream Amerigo is a registered trademark of Bitstream Inc.
+</para>
+<para>
+Stone is a registered trademark of Adobe Systems Inc.
+</para>
+
+<para>
+Copyright 1988, 1994 X Consortium
+</para>
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+</para>
+<para>
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+</para>
+<para>
+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.
+</para>
+<para>
+Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or
+other dealings in this Software without prior written authorization
+from the X Consortium.
+</para>
+<para>
+Copyright 1988, 1989
+Digital Equipment Corporation, Maynard MA.  All rights reserved.
+</para>
+<para>
+Permission to use, copy, modify, and distribute this documentation
+for any purpose and without fee is hereby granted, provided
+that the above copyright notice and this permission
+notice appear in all copies.
+Digital Equipment Corporation makes no representations
+about the
+suitability for any purpose of the information in this document.
+This documentation is provided as is without express or implied warranty.
+</para>
+
+</legalnotice>
+</bookinfo>
+<chapter>
+<title>TITLE</title>
+<sect1 id="introduction">
+<title>Introduction</title>
+<!-- .XS -->
+<!-- (SN Introduction -->
+<!-- .XE -->
+<para>
+It is a requirement that X client applications must be portable across server
+implementations, with very different file systems, naming conventions, and
+font libraries.
+However, font access requests,
+as defined by the <emphasis remap='I'>X Window System Protocol</emphasis>,
+neither specify server-independent conventions for font names
+nor provide adequate font properties for logically describing typographic fonts.
+</para>
+<para>
+X clients must be able to dynamically determine the fonts available
+on any given server so that understandable information can be presented
+to the user or so that intelligent font fallbacks can be chosen.
+It is desirable for the most common queries to be accomplished
+without the overhead of opening each font and inspecting font properties,
+by means of simple
+<function>ListFonts </function>
+requests.
+For example, if a user selected a Helvetica typeface family,
+a client application should be able to query the server
+for all Helvetica fonts and present only those setwidths, weights, slants,
+point sizes, and character sets available for that family.
+</para>
+<para>
+This document gives a standard logical font description
+(hereafter referred to as XLFD) and the conventions to be used
+in the core protocol so that clients can query and access screen type libraries
+in a consistent manner across all X servers.
+In addition to completely specifying a given font by means of its
+<function>FontName ,</function>
+the XLFD also provides for a standard set of key
+<function>FontProperties</function>
+that describe the font in more detail.
+</para>
+<para>
+<!-- .LP -->
+The XLFD provides an adequate set of typographic font properties,
+such as CAP_HEIGHT, X_HEIGHT,
+and RELATIVE_SETWIDTH,
+for publishing and other applications to do intelligent font matching
+or substitution when handling documents created on some foreign server
+that use potentially unknown fonts.
+In addition,
+this information is required by certain clients
+to position subscripts automatically and determine small capital heights,
+recommended leading, word-space values, and so on.
+</para>
+</sect1>
+
+<sect1 id="requirements_and_goals">
+<title>Requirements and Goals</title>
+<!-- .XS -->
+<!-- (SN Requirements and Goals -->
+<!-- .XE -->
+<para>
+The XLFD meets the short-term and long-term goals to have a
+standard logical font description that:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Provides unique, descriptive font names that support simple pattern
+matching
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Supports multiple font vendors, arbitrary character sets, and encodings
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Supports naming and instancing of scalable and polymorphic fonts
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Supports transformations and subsetting of fonts
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Is independent of X server and operating or file system implementations
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Supports arbitrarily complex font matching or substitution
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Is extensible
+    </para>
+  </listitem>
+</itemizedlist>
+
+<sect2 id="provide_unique_and_descriptive_font_names">
+<title>Provide Unique and Descriptive Font Names</title>
+<!-- .XS -->
+<!-- (SN Provide Unique and Descriptive Font Names -->
+<!-- .XE -->
+<para>
+It should be possible to have font names that are long enough and
+descriptive enough to have a reasonable probability of being unique
+without inventing a new registration organization.
+Resolution and size-dependent font masters, multivendor font libraries,
+and so on must be anticipated and handled by the font name alone.
+</para>
+<para>
+<!-- .LP -->
+The name itself should be structured to be amenable to simple pattern
+matching and parsing, thus allowing X clients to restrict font queries to
+some subset of all possible fonts in the server.
+</para>
+</sect2>
+
+<sect2 id="support_multiple_font_vendors_and_character_sets">
+<title>Support Multiple Font Vendors and Character Sets</title>
+<!-- .XS -->
+<!-- (SN Support Multiple Font Vendors and Character Sets -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The font name and properties should distinguish between fonts
+that were supplied by different font vendors
+but that possibly share the same name.
+We anticipate a highly competitive font market where users will be able to
+buy fonts from many sources according to their particular requirements.
+</para>
+<para>
+<!-- .LP -->
+A number of font vendors deliver each font with all glyphs designed for that
+font, where charset mappings are defined by encoding vectors.
+Some server implementations may force these mappings to proprietary
+or standard charsets statically in the font data.
+Others may desire to perform the mapping dynamically in the server.
+Provisions must be made in the font name
+that allows a font request to specify or identify specific charset mappings
+in server environments where multiple charsets are supported.
+</para>
+</sect2>
+
+<sect2 id="support_scalable_and_polymorphic_fonts">
+<title>Support Scalable and Polymorphic Fonts</title>
+<!-- .XS -->
+<!-- (SN Support Scalable and Polymorphic Fonts -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+If a font source can be scaled to an arbitrary size or varied in other
+ways, it should be possible for an application to determine
+that fact from the font name, and the
+application should be able to construct a font name for any specific
+instance.
+</para>
+</sect2>
+
+<sect2 id="support_transformations_and_subsetting_of_fonts">
+<title>Support Transformations and Subsetting of Fonts</title>
+<!-- .XS -->
+<!-- (SN Support Transformations and Subsetting of Fonts -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+Arbitrary two-dimensional linear transformations of fonts should be
+able to be requested by applications.  Since such transformed fonts
+may be used for special effects requiring a few characters from each
+of many differently transformed fonts, it should be possible to
+request only a few characters from a font for efficiency.
+</para>
+</sect2>
+
+<sect2 id="be_independent_of_x_server_and_operating_or_file_system_implementations">
+<title>Be Independent of X Server and Operating or File System Implementations</title>
+<!-- .XS -->
+<!-- (SN Be Independent of X Server and Operating or File System Implementations -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+X client applications that require a particular font should be able to use
+the descriptive name without knowledge of the file system or other
+repository in use by the server.
+However,
+it should be possible for servers to translate a given font name
+into a file name syntax that it knows how to deal with,
+without compromising the uniqueness of the font name.
+This algorithm should be reversible (exactly how this translation is done is
+implementation dependent).
+</para>
+</sect2>
+
+<sect2 id="support_arbitrarily_complex_font_matching_and_substitution">
+<title>Support Arbitrarily Complex Font Matching and Substitution</title>
+<!-- .XS -->
+<!-- (SN Support Arbitrarily Complex Font Matching and Substitution -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+In addition to the font name,
+the XLFD should define a standard list of descriptive font properties,
+with agreed-upon fallbacks for all fonts.
+This allows client applications to derive font-specific formatting
+or display data and to perform font matching or substitution
+when asked to handle potentially unknown fonts, as required.
+</para>
+</sect2>
+
+<sect2 id="be_extensible">
+<title>Be Extensible</title>
+<!-- .XS -->
+<!-- (SN Be Extensible -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The XLFD must be extensible so that new and/or private descriptive font
+properties can be added to conforming fonts without making existing
+X client or server implementations obsolete.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="x_logical_font_description">
+<title>X Logical Font Description</title>
+<!-- .XS -->
+<!-- (SN X Logical Font Description -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+XLFD is divided into two basic components:
+the
+<function>FontName</function>,
+which gives all font information needed to uniquely identify a font
+in X protocol requests (for example,
+<function>OpenFont</function>,
+<function>ListFonts</function>,
+and so on) and a variable list of optional
+<function>FontProperties</function>,
+which describe a font in more detail.
+</para>
+<para>
+<!-- .LP -->
+The
+<function>FontName </function>
+is used in font queries and is returned as data in certain X protocol requests.
+It is also specified as the data value for the
+<function>FONT</function>
+item in the X Consortium Character Bitmap Distribution Format Standard
+(BDF V2.1).
+</para>
+<para>
+<!-- .LP -->
+The
+<function>FontProperties </function>
+are supplied on a font-by-font basis and are returned
+as data in certain X protocol requests as part of the
+<function>XFontStruct</function>
+data structure.
+The names and associated data values for each of the
+<function>FontProperties </function>
+may also appear as items of the
+<function>STARTPROPERTIES</function>...<function>ENDPROPERTIES</function>list
+in the BDF V2.1 specification. <!-- xref -->
+</para>
+<sect2 id="fontname">
+<title>FontName</title>
+<!-- .XS -->
+<!-- (SN FontName -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+Each
+<function>FontName </function>
+is logically composed of two strings: a
+<function>FontNameRegistry</function>
+prefix that is followed by a
+<function>FontNameSuffix</function>.
+The
+<function>FontName</function>
+uses the ISO 8859-1 encoding.
+The
+<function>FontNameRegistry</function>
+is an
+<!-- .IN x-registered-name -->
+x-registered-name (a name that has been registered with the X Consortium)
+that identifies the registration authority that owns the specified
+<function>FontNameSuffix</function>
+syntax and semantics.
+</para>
+<para>
+<!-- .LP -->
+All font names that conform to this specification are to use a
+<function>FontNameRegistry</function>
+prefix, which is defined to be the string "-"
+(HYPHEN).
+All
+<function>FontNameRegistry </function>
+prefixes of the form: +<emphasis remap='I'>version</emphasis>-,
+where the specified version indicates some future XLFD specification,
+are reserved by the X Consortium for future extensions to XLFD font names.
+If required, extensions to the current XLFD font name shall be constructed
+by appending new fields to the current structure,
+each delimited by the existing field delimiter.
+The availability of other
+<function>FontNameRegistry</function>
+prefixes or fonts that support other registries
+is server implementation dependent.
+</para>
+<para>
+<!-- .LP -->
+In the X protocol specification,
+the
+<function>FontName </function>
+is required to be a string;
+hence, numeric field values are represented in the name as string equivalents.
+All
+<function>FontNameSuffix </function>
+fields are also defined as
+<function>FontProperties ; </function>
+numeric property values are represented as signed or unsigned integers,
+as appropriate.
+</para>
+
+<sect3 id="fontname_syntax">
+<title>FontName Syntax</title>
+<!-- .XS -->
+<!-- (SN FontName Syntax -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The
+<function>FontName </function>
+is a structured, parsable string (of type STRING8)
+whose Backus-Naur Form syntax description is as follows:
+</para>
+<!-- .IN "FontName Syntax" -->
+<!-- .SM -->
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>FontName ::=</entry>
+      <entry>
+XFontNameRegistry XFontNameSuffix |
+PrivFontNameRegistry PrivFontNameSuffix
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>XFontNameRegistry ::=</entry>
+      <entry>XFNDelim | XFNExtPrefix Version XFNDelim</entry>
+    </row>
+    <row rowsep="0">
+      <entry>XFontNameSuffix ::=</entry>
+      <entry>
+FOUNDRY XFNDelim FAMILY_NAME XFNDelim WEIGHT_NAME
+XFNDelim SLANT XFNDelim SETWIDTH_NAME XFNDelim ADD_STYLE_NAME
+XFNDelim PIXEL_SIZE XFNDelim POINT_SIZE
+XFNDelim RESOLUTION_X XFNDelim RESOLUTION_Y XFNDelim
+SPACING XFNDelim AVERAGE_WIDTH XFNDelim CHARSET_REGISTRY
+XFNDelim CHARSET_ENCODING
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>Version ::=</entry>
+      <entry>
+STRING8 - the XLFD version that defines an extension
+to the font name syntax (for example, "1.4")
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>XFNExtPrefix ::=</entry>
+      <entry>OCTET - "+" (PLUS)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>XFNDelim ::=</entry>
+      <entry>OCTET - "-" (HYPHEN)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PrivFontNameRegistry ::=</entry>
+      <entry>STRING8 - other than those strings reserved by XLFD</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PrivFontNameSuffix ::=</entry>
+      <entry>STRING8</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+Field values are constructed as strings of ISO 8859-1 graphic characters,
+excluding the following:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+'-' (HYPHEN), the XLFD font name delimiter character
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+'?' (QUESTION MARK) and "*" (ASTERISK), the X protocol
+font name wildcard characters
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+',' (COMMA), used by Xlib to separate XLFD font names in a font set.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+'"' (QUOTATION MARK), used by some commercial products to quote a
+font name.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+<!-- .LP -->
+Alphabetic case distinctions are allowed but are for human readability
+concerns only.
+Conforming X servers will perform matching on font name query or open requests
+independent of case.
+The entire font name string must have no more than 255 characters.
+It is recommended that clients construct font name query patterns
+by explicitly including all field delimiters to avoid unexpected results.
+Note that SPACE is a valid character of a
+<function>FontName </function>
+field; for example, the string "ITC Avant Garde Gothic" might be a
+FAMILY_NAME.
+</para>
+</sect3>
+
+<sect3 id="fontname_field_definitions">
+<title>FontName Field Definitions</title>
+<!-- .XS -->
+<!-- (SN FontName Field Definitions -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+This section discusses the
+<function>FontName :</function>
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+FOUNDRY field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+FAMILY_NAME field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+WEIGHT_NAME field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+SLANT field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+SETWIDTH_NAME field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+ADD_STYLE_NAME field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+PIXEL_SIZE field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+POINT_SIZE field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+RESOLUTION_X and RESOLUTION_Y fields
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+SPACING field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+AVERAGE_WIDTH field
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+CHARSET_REGISTRY and CHARSET_ENCODING fields
+    </para>
+  </listitem>
+</itemizedlist>
+
+<sect4 id="foundry_field">
+<title>FOUNDRY Field</title>
+<!-- .XS -->
+<!-- (SN FOUNDRY Field -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FOUNDRY is an x-registered-name,
+the name or identifier of the digital type foundry
+that digitized and supplied the font data,
+or if different, the identifier of the organization that last modified
+the font shape or metric information.
+</para>
+<para>
+<!-- .LP -->
+The reason this distinction is necessary is
+that a given font design may be licensed from one source (for example, ITC)
+but digitized and sold by any number of different type suppliers.
+Each digital version of the original design, in general, will be somewhat
+different in metrics and shape from the idealized original font data,
+because each font foundry, for better or for worse, has its own standards
+and practices for tweaking a typeface for a particular generation
+of output technologies or has its own perception of market needs.
+</para>
+<para>
+<!-- .LP -->
+It is up to the type supplier to register with the X Consortium a
+suitable name for this
+<function>FontName </function>
+field according to the registration procedures defined by the Consortium.
+</para>
+<para>
+<!-- .LP -->
+The X Consortium shall define procedures for registering foundry
+and other names and shall maintain and publish,
+as part of its public distribution,
+a registry of such registered names for use in XLFD font names and properties.
+</para>
+<para>
+<!-- .LP -->
+</para>
+</sect4>
+
+<sect4 id="family_name_field">
+<title>FAMILY_NAME Field</title>
+<!-- .XS -->
+<!-- (SN FAMILY_NAME Field -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FAMILY_NAME is a string that identifies the range or family of
+typeface designs that are all variations of one basic typographic style.
+This must be spelled out in full,
+with words separated by spaces, as required.
+This name must be human-understandable and suitable for presentation to a
+font user to identify the typeface family.
+</para>
+<para>
+<!-- .LP -->
+It is up to the type supplier to supply and maintain a suitable string for
+this field and font property, to secure the proper legal title to a given
+name, and to guard against the infringement of other's copyrights or
+trademarks.
+By convention, FAMILY_NAME is not translated.
+FAMILY_NAME may include an indication of design ownership
+if considered a valid part of the
+typeface family name.
+</para>
+<para>
+<!-- .LP -->
+The following are examples of FAMILY_NAME:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Helvetica
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+ITC Avant Garde Gothic
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Times
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Times Roman
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Bitstream Amerigo
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Stone
+    </para>
+  </listitem>
+</itemizedlist>
+</sect4>
+
+<sect4 id="weight_name_field">
+<title>WEIGHT_NAME Field</title>
+<!-- .XS -->
+<!-- (SN WEIGHT_NAME Field -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+WEIGHT_NAME is a string that identifies the font's typographic weight,
+that is, the nominal blackness of the font,
+according to the FOUNDRY's judgment.
+This name must be human-understandable and suitable for presentation to a
+font user.
+The value "0" is used to indicate a polymorphic font (see section \n(sP).
+</para>
+<para>
+<!-- .LP -->
+The interpretation of this field is somewhat problematic
+because the typographic judgment of weight has traditionally
+depended on the overall design of the typeface family in question;
+that is, it is possible that the DemiBold weight of one font could be
+almost equivalent in typographic feel to a Bold font from another family.
+</para>
+<para>
+<!-- .LP -->
+WEIGHT_NAME is captured as an arbitrary string
+because it is an important part of a font's complete human-understandable name.
+However, it should not be used for font matching or substitution.
+For this purpose,
+X client applications should use the weight-related font properties
+(RELATIVE_WEIGHT and WEIGHT) that give the coded relative weight
+and the calculated weight, respectively.
+</para>
+</sect4>
+
+<sect4 id="slant_field">
+<title>SLANT Field</title>
+<!-- .XS -->
+<!-- (SN SLANT Field -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SLANT is a code-string that indicates the overall posture of the
+typeface design used in the font.
+The encoding is as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Code</entry>
+      <entry>English Translation</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>"R"</entry>
+      <entry>Roman</entry>
+      <entry>Upright design</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"I"</entry>
+      <entry>Italic</entry>
+      <entry>Italic design, slanted clockwise from the vertical</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"O"</entry>
+      <entry>Oblique</entry>
+      <entry>Obliqued upright design, slanted clockwise from the vertical</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"RI"</entry>
+      <entry>Reverse Italic</entry>
+      <entry>Italic design, slanted counterclockwise from the vertical</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"RO"</entry>
+      <entry>Reverse Oblique</entry>
+      <entry>Obliqued upright design, slanted counterclockwise from the vertical</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"OT"</entry>
+      <entry>Other</entry>
+      <entry>Other</entry>
+    </row>
+    <row rowsep="0">
+      <entry>numeric</entry>
+      <entry>Polymorphic</entry>
+      <entry>See section 6 on polymorphic font support.</entry> <!-- xref -->
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<para>
+<!-- .LP -->
+The SLANT codes are for programming convenience only and usually are
+converted into their equivalent human-understandable form before being
+presented to a user.
+</para>
+</sect4>
+
+<sect4 id="setwidth_name_field">
+<title>SETWIDTH_NAME Field</title>
+<!-- .XS -->
+<!-- (SN SETWIDTH_NAME Field -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+SETWIDTH_NAME is a string that gives the font's typographic
+proportionate width, that is, the nominal width per horizontal unit of the
+font, according to the FOUNDRY's judgment.
+The value "0" is used to indicate a polymorphic font (see section \n(sP).
+</para>
+<para>
+<!-- .LP -->
+As with WEIGHT_NAME, the interpretation of this field or font property is
+somewhat problematic, because the designer's judgment of setwidth has
+traditionally depended on the overall design of the typeface family in
+question.
+For purposes of font matching or substitution,
+X client applications should either use the RELATIVE_SETWIDTH font property
+that gives the relative coded proportionate width or calculate
+the proportionate width.
+</para>
+<para>
+<!-- .LP -->
+The following are examples of SETWIDTH_NAME:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+Normal
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Condensed
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Narrow
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Double Wide
+    </para>
+  </listitem>
+</itemizedlist>
+</sect4>
+
+<sect4 id="add_style_name_field">
+<title>ADD_STYLE_NAME Field</title>
+<!-- .XS -->
+<!-- (SN ADD_STYLE_NAME Field -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+ADD_STYLE_NAME is a string that identifies additional typographic
+style information that is not captured by other fields but is needed
+to identify the particular font.
+The character "[" anywhere in the field is used to indicate a
+polymorphic font (see section \n(sP).
+</para>
+<para>
+<!-- .LP -->
+ADD_STYLE_NAME is not a typeface classification field
+and is only used for uniqueness.
+Its use, as such, is not limited to typographic style distinctions.
+</para>
+<para>
+<!-- .LP -->
+The following are examples of ADD_STYLE_NAME:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Serif
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Sans Serif
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Informal
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Decorated
+    </para>
+  </listitem>
+</itemizedlist>
+</sect4>
+
+<sect4 id="pixel_size_field">
+<title>PIXEL_SIZE Field</title>
+<!-- .XS -->
+<!-- (SN PIXEL_SIZE Field -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+PIXEL_SIZE
+gives the body size of the font at a particular
+POINT_SIZE and RESOLUTION_Y.
+PIXEL_SIZE is either an integer-string or a string beginning
+with "[".  A string beginning with "[" represents a matrix
+(see section \n(sM).
+PIXEL_SIZE usually incorporates additional vertical spacing
+that is considered part of the font design.
+(Note, however, that this value is not necessarily equivalent to the height
+of the font bounding box.)
+Zero is used to indicate a scalable font (see section \n(sS).
+</para>
+<para>
+<!-- .LP -->
+PIXEL_SIZE usually is used by X client applications that need to
+query fonts according to device-dependent size,
+regardless of the point size or vertical resolution
+for which the font was designed.
+</para>
+</sect4>
+
+<sect4 id="point_size_field">
+<title>SN POINT_SIZE Field</title>
+<!-- .XS -->
+<!-- (SN POINT_SIZE Field -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+POINT_SIZE gives the body size
+for which the font was designed.
+POINT_SIZE is either an integer-string or a string beginning
+with "[".  A string beginning with "[" represents a matrix
+(see section \n(sM).
+This field usually incorporates additional vertical spacing
+that is considered part of the font design.
+(Note, however, that POINT_SIZE is not necessarily equivalent to the height
+of the font bounding box.)
+POINT_SIZE is expressed in decipoints (where points are as defined
+in the X protocol or 72.27 points equal 1 inch).
+Zero is used to indicate a scalable font (see section \n(sS).
+</para>
+<para>
+<!-- .LP -->
+POINT_SIZE and RESOLUTION_Y are used by X clients to query fonts
+according to device-independent size to maintain constant text
+size on the display regardless of the PIXEL_SIZE used for the font.
+</para>
+</sect4>
+
+<sect4 id="resolution_x_and_resolution_y_fields">
+<title>RESOLUTION_X and RESOLUTION_Y Fields</title>
+<!-- .XS -->
+<!-- (SN RESOLUTION_X and RESOLUTION_Y Fields -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+RESOLUTION_X and RESOLUTION_Y are unsigned integer-strings that give
+the horizontal and vertical resolution,
+measured in pixels or dots per inch (dpi),
+for which the font was designed.
+Zero is used to indicate a scalable font (see section \n(sS).
+Horizontal and vertical values are required
+because a separate bitmap font must be designed
+for displays with very different aspect ratios
+(for example, 1:1, 4:3, 2:1, and so on).
+</para>
+<para>
+<!-- .LP  -->
+The separation of pixel or point size and resolution is necessary
+because X allows for servers with very different video characteristics
+(for example, horizontal and vertical resolution, screen and pixel size,
+pixel shape, and so on) to potentially access the same font library.
+The font name, for example, must differentiate between a 14-point font designed
+for 75 dpi (body size of about 14 pixels) or a 14-point font designed
+for 150 dpi (body size of about 28 pixels).
+Further, in servers that implement some or all fonts as continuously scaled
+and scan-converted outlines,
+POINT_SIZE and RESOLUTION_Y will help the server to differentiate
+between potentially separate font masters for text, title,
+and display sizes or for other typographic considerations.
+</para>
+</sect4>
+
+<sect4 id="spacing_field">
+<title>SPACING Field</title>
+<!-- .XS -->
+<!-- (SN SPACING Field -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+SPACING is a code-string that indicates the escapement class of the font,
+that is, monospace (fixed pitch), proportional (variable pitch),
+or charcell (a special monospaced font that conforms to the traditional
+data-processing character cell font model).
+The encoding is as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Code</entry>
+      <entry>English Translation</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>"P"</entry>
+      <entry>Proportional</entry>
+      <entry>
+A font whose logical character widths vary for each glyph.
+Note that no other restrictions are placed on the metrics
+of a proportional font.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>"M"</entry>
+      <entry>Monospaced</entry>
+      <entry>
+A font whose logical character widths are constant
+(that is, every glyph in the font has the same logical width).
+No other restrictions are placed on the metrics of a monospaced font.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>"C"</entry>
+      <entry>CharCell</entry>
+      <entry>
+A monospaced font that follows the standard typewriter character cell model
+(that is, the glyphs of the font can be modeled by X clients as "boxes"
+of the same width and height that are imaged side-by-side
+to form text strings or top-to-bottom to form text lines).
+By definition,
+all glyphs have the same logical character width,
+and no glyphs have "ink" outside of the character cell.
+There is no kerning (that is, on a per-character basis with positive metrics:
+0 &lt;= left-bearing &lt;= right-bearing &lt;= width;
+with negative metrics: width &lt;= left-bearing &lt;= right-bearing &lt;= zero).
+Also, the vertical extents of the font do not exceed the vertical spacing
+(that is, on a per-character basis:
+ascent &lt;= font-ascent and descent &lt;= font-descent).
+The cell height = font-descent + font-ascent, and the width = AVERAGE_WIDTH.
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect4>
+
+<sect4 id="average_width_field">
+<title>AVERAGE_WIDTH Field</title>
+<!-- .XS -->
+<!-- (SN AVERAGE_WIDTH Field -->
+<!-- .XE -->
+<para>
+<!-- .LP  -->
+AVERAGE_WIDTH is an integer-string typographic metric value
+that gives the unweighted arithmetic mean of the absolute value of the
+width of each glyph in the font
+(measured in tenths of pixels), multiplied by -1 if the dominant
+writing direction for the font is right-to-left.
+A leading "~" (TILDE) indicates a negative value.
+For monospaced and character cell fonts,
+this is the width of all glyphs in the font.
+Zero is used to indicate a scalable font (see section \n(sS).
+</para>
+</sect4>
+
+<sect4 id="charset_registry_and_charset_encoding_fields">
+<title>CHARSET_REGISTRY and CHARSET_ENCODING Fields</title>
+<!-- .XS -->
+<!-- (SN CHARSET_REGISTRY and CHARSET_ENCODING Fields -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The character set used to encode the glyphs of the font (and implicitly
+the font's glyph repertoire), as maintained by the X Consortium character
+set registry.
+CHARSET_REGISTRY is an x-registered-name that identifies
+the registration authority that owns the specified encoding.
+CHARSET_ENCODING is a registered name that identifies the coded character set
+as defined by that registration authority
+and, optionally, a subsetting hint.
+</para>
+<para>
+<!-- .LP -->
+Although the X protocol does not explicitly have any knowledge about
+character set encodings,
+it is expected that server implementors will prefer to embed knowledge
+of certain proprietary or standard charsets into their font library
+for reasons of performance and convenience.
+The CHARSET_REGISTRY and CHARSET_ENCODING fields or properties allow
+an X client font request to specify a specific charset mapping
+in server environments where multiple charsets are supported.
+The availability of any particular
+character set is font and server implementation dependent.
+</para>
+<para>
+<!-- .LP -->
+To prevent collisions when defining character set names,
+it is recommended that CHARSET_REGISTRY and CHARSET_ENCODING name pairs
+be constructed according to the following conventions:
+</para>
+<!-- .IN "CHARSET Syntax" -->
+<!-- .SM -->
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>CharsetRegistry ::=</entry>
+      <entry>StdCharsetRegistryName | PrivCharsetRegistryName</entry>
+    </row>
+    <row rowsep="0">
+      <entry>CharsetEncoding ::=</entry>
+      <entry>StdCharsetEncodingName | PrivCharsetEncodingName</entry>
+    </row>
+    <row rowsep="0">
+      <entry>StdCharsetRegistryName ::=</entry>
+      <entry>StdOrganizationId StdNumber | StdOrganizationId StdNumber Dot Year</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PrivCharsetRegistryName ::=</entry>
+      <entry>OrganizationId STRING8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>StdCharsetEncodingName ::=</entry>
+      <entry>STRING8-numeric part number of referenced standard</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PrivCharsetEncodingName ::=</entry>
+      <entry>STRING8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>StdOrganizationId ::=</entry>
+      <entry>STRING8-the registered name or acronym of the referenced standard organization</entry>
+    </row>
+    <row rowsep="0">
+      <entry>StdNumber ::=</entry>
+      <entry>STRING8-referenced standard number</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OrganizationId ::=</entry>
+      <entry>STRING8-the registered name or acronym of the organization</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Dot ::=</entry>
+      <entry>OCTET-"." (FULL STOP)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Year ::=</entry>
+      <entry>STRING8-numeric year (for example, 1989)</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+The X Consortium shall maintain and publish a registry
+of such character set names for use in X protocol font names and properties
+as specified in XLFD.
+</para>
+<para>
+<!-- .LP -->
+The ISO Latin-1 character set shall be registered by the X Consortium as the
+CHARSET_REGISTRY-CHARSET_ENCODING value pair: "ISO8859-1".
+</para>
+<para>
+<!-- .LP -->
+If the CHARSET_ENCODING contains a "[" (LEFT SQUARE BRACKET),
+the "[" and the characters after it up to a "]" (RIGHT SQUARE
+BRACKET) are a
+subsetting hint telling the font source that the client is interested
+only in a subset of the characters of the font.
+The font source can, optionally, return a font that
+contains only those characters or any superset of those characters.  The
+client can expect to obtain valid glyphs and metrics only for those
+characters, and not for any other characters in the font.
+The font properties may optionally be calculated by considering only
+the characters in the subset.
+</para>
+<para>
+<!-- .LP -->
+The BNF for the subsetting hint is
+</para>
+<!-- .SM -->
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>Subset ::=</entry>
+      <entry>LeftBracket RangeList RightBracket</entry>
+    </row>
+    <row rowsep="0">
+      <entry>RangeList ::=</entry>
+      <entry>Range | Range Space RangeList</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Range ::=</entry>
+      <entry>Number | Number Underscore Number</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Number ::=</entry>
+      <entry>"0x" HexNumber | DecNumber</entry>
+    </row>
+    <row rowsep="0">
+      <entry>HexNumber ::=</entry>
+      <entry>HexDigit | HexDigit HexNumber</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DecNumber ::=</entry>
+      <entry>DecDigit | DecDigit DecNumber</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DecDigit ::=</entry>
+      <entry>"0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"</entry>
+    </row>
+    <row rowsep="0">
+      <entry>HexDigit ::=</entry>
+      <entry>DecDigit | "a" | "b" | "c" | "d" | "e" | "f"</entry>
+    </row>
+    <row rowsep="0">
+      <entry>LeftBracket ::=</entry>
+      <entry>"[" (LEFT SQUARE BRACKET)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>RightBracket ::=</entry>
+      <entry>"]" (RIGHT SQUARE BRACKET)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Space ::=</entry>
+      <entry>"\0" (SPACE)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Underscore ::=</entry>
+      <entry>"_" (LOW LINE)</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+Each Range specifies characters that are to be part of the subset
+included in the font.
+A Range containing two Numbers specifies the first and last character,
+inclusively, of a range of characters.
+A Range that is a single Number specifies a single character to be
+included in the font.
+A HexNumber is interpreted as a hexadecimal number.
+A DecNumber is interpreted as a decimal number.
+The font consists of the union of all the Ranges in the
+RangeList.
+</para>
+<para>
+<!-- .LP -->
+For example,
+</para>
+<!-- .br -->
+<!-- .ft C -->
+<!-- .SM -->
+<literallayout class="monospaced">
+     -misc-fixed-medium-r-normal--0-0-0-0-c-0-iso8859-1[65 70 80_90]
+</literallayout>
+<!-- .NL -->
+<!-- .ft P -->
+<!-- .br -->
+<para>
+tells the font source that the client is interested only in characters
+65, 70, and 80-90.
+</para>
+</sect4>
+</sect3>
+
+<sect3 id="examples">
+<title>Examples</title>
+<!-- .XS -->
+<!-- (SN Examples -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The following examples of font names are derived from the screen fonts
+shipped with the X Consortium distribution.
+</para>
+<!-- .\" why is this table so long?  I took out some fonts in v1.5 -->
+<!-- .\" to make the page breaks better. -->
+<!-- .SM -->
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Font</entry>
+      <entry>X FontName</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry><function>75-dpi Fonts</function></entry>
+    </row>
+    <row rowsep="0">
+      <entry>Charter 12 pt</entry>
+      <entry>-Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Charter Bold 12 pt</entry>
+      <entry>-Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Charter Bold Italic 12 pt</entry>
+      <entry>-Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Charter Italic 12 pt</entry>
+      <entry>-Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier 8 pt</entry>
+      <entry>-Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier 10 pt</entry>
+      <entry>-Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier 12 pt</entry>
+      <entry>-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier 24 pt</entry>
+      <entry>-Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier Bold 10 pt</entry>
+      <entry>-Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier Bold Oblique 10 pt</entry>
+      <entry>-Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Courier Oblique 10 pt</entry>
+      <entry>-Adobe-Courier-Medium-O-Normal--10-100-75-75-M-60-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry><function>100-dpi Fonts</function></entry>
+    </row>
+    <row rowsep="0">
+      <entry>Symbol 10 pt</entry>
+      <entry>-Adobe-Symbol-Medium-R-Normal--14-100-100-100-P-85-Adobe-FONTSPECIFIC</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Symbol 14 pt</entry>
+      <entry>-Adobe-Symbol-Medium-R-Normal--20-140-100-100-P-107-Adobe-FONTSPECIFIC</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Symbol 18 pt</entry>
+      <entry>-Adobe-Symbol-Medium-R-Normal--25-180-100-100-P-142-Adobe-FONTSPECIFIC</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Symbol 24 pt</entry>
+      <entry>-Adobe-Symbol-Medium-R-Normal--34-240-100-100-P-191-Adobe-FONTSPECIFIC</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Times Bold 10 pt</entry>
+      <entry>-Adobe-Times-Bold-R-Normal--14-100-100-100-P-76-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Times Bold Italic 10 pt</entry>
+      <entry>-Adobe-Times-Bold-I-Normal--14-100-100-100-P-77-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Times Italic 10 pt</entry>
+      <entry>-Adobe-Times-Medium-I-Normal--14-100-100-100-P-73-ISO8859-1</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Times Roman 10 pt</entry>
+      <entry>-Adobe-Times-Medium-R-Normal--14-100-100-100-P-74-ISO8859-1</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect3>
+</sect2>
+
+<sect2 id="font_properties">
+<title>Font Properties</title>
+<!-- .XS -->
+<!-- (SN Font Properties -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+All font properties are optional but will generally include the
+font name fields and, on a font-by-font basis, any other useful font
+descriptive and use information that may be required to use the font
+intelligently.
+The XLFD specifies an extensive set of standard X font properties,
+their interpretation, and fallback rules when the property is not defined
+for a given font.
+The goal is to provide client applications with enough font information
+to be able to make automatic formatting and display decisions
+with good typographic results.
+</para>
+<para>
+<!-- .LP -->
+Font property names use the ISO 8859-1 encoding.
+</para>
+<para>
+<!-- .LP -->
+Additional standard X font property definitions may be defined in the
+future and private properties may exist in X fonts at any time.
+Private font properties should be defined to conform to the general mechanism
+defined in the X protocol to prevent overlap of name space and ambiguous
+property names, that is, private font property names are of the form:
+"_" (LOW LINE),
+followed by the organizational identifier, followed by "_" (LOW LINE),
+and terminated with the property name.
+</para>
+<para>
+<!-- .LP -->
+The Backus-Naur Form syntax description of X font properties is as follows:
+</para>
+<!-- .IN "Font Properties" "BNF Syntax" -->
+<!-- .SM -->
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <tbody>
+    <row rowsep="0">
+      <entry>Properties ::=</entry>
+      <entry>OptFontPropList</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OptFontPropList ::=</entry>
+      <entry>NULL | OptFontProp OptFontPropList</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OptFontProp ::=</entry>
+      <entry>PrivateFontProp | XFontProp</entry>
+    </row>
+    <row rowsep="0">
+      <entry>PrivateFontProp ::=</entry>
+      <entry>STRING8 | Underscore OrganizationId Underscore STRING8</entry>
+    </row>
+    <row rowsep="0">
+      <entry>XFontProp ::=</entry>
+      <entry>
+FOUNDRY | FAMILY_NAME | WEIGHT_NAME | SLANT | SETWIDTH_NAME | ADD_STYLE_NAME
+| PIXEL_SIZE | POINT_SIZE | RESOLUTION_X | RESOLUTION_Y | SPACING |
+AVERAGE_WIDTH | CHARSET_REGISTRY | CHARSET_ENCODING | QUAD_WIDTH |
+RESOLUTION | MIN_SPACE | NORM_SPACE | MAX_SPACE | END_SPACE | SUPERSCRIPT_X |
+SUPERSCRIPT_Y | SUBSCRIPT_X | SUBSCRIPT_Y | UNDERLINE_POSITION |
+UNDERLINE_THICKNESS | STRIKEOUT_ASCENT | STRIKEOUT_DESCENT | ITALIC_ANGLE
+| X_HEIGHT | WEIGHT | FACE_NAME |
+FULL_NAME | FONT |
+COPYRIGHT | AVG_CAPITAL_WIDTH |
+AVG_LOWERCASE_WIDTH | RELATIVE_SETWIDTH | RELATIVE_WEIGHT | CAP_HEIGHT |
+SUPERSCRIPT_ SIZE | FIGURE_WIDTH | SUBSCRIPT_SIZE | SMALL_CAP_SIZE |
+NOTICE | DESTINATION
+| FONT_TYPE | FONT_VERSION | RASTERIZER_NAME | RASTERIZER_VERSION |
+RAW_ASCENT | RAW_DESCENT | RAW_* | AXIS_NAMES | AXIS_LIMITS |
+AXIS_TYPES</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Underscore ::=</entry>
+      <entry>OCTET-"_" (LOW LINE)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OrganizationId ::=</entry>
+      <entry>STRING8-the registered name of the organization</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<sect3 id="foundry">
+<title>FOUNDRY</title>
+<!-- .XS -->
+<!-- (SN FOUNDRY -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FOUNDRY is as defined in the
+<function>FontName </function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+FOUNDRY cannot be calculated or defaulted if not supplied as a font property.
+</para>
+</sect3>
+
+<sect3 id="family_name">
+<title>FAMILY_NAME</title>
+<!-- .XS -->
+<!-- (SN FAMILY_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FAMILY_NAME is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+FAMILY_NAME cannot be calculated or defaulted if not supplied as a font
+property.
+</para>
+</sect3>
+
+<sect3 id="weight_name ">
+<title>WEIGHT_NAME</title>
+<!-- .XS -->
+<!-- (SN WEIGHT_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+WEIGHT_NAME is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+WEIGHT_NAME can be defaulted if not supplied as a font property, as follows:
+</para>
+
+<literallayout class="monospaced">
+if (WEIGHT_NAME undefined) then
+   WEIGHT_NAME = ATOM("Medium")
+</literallayout>
+</sect3>
+
+<sect3 id="slant">
+<title>SLANT </title>
+<!-- .XS -->
+<!-- (SN SLANT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SLANT is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+SLANT can be defaulted if not supplied as a font property, as follows:
+</para>
+
+<literallayout class="monospaced">
+if (SLANT undefined) then
+   SLANT = ATOM("R")
+</literallayout>
+</sect3>
+
+<sect3 id="setwidth_name">
+<title>SETWIDTH_NAME</title>
+<!-- .XS -->
+<!-- (SN SETWIDTH_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SETWIDTH_NAME is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+SETWIDTH_NAME can be defaulted if not supplied as a font property, as follows:
+</para>
+
+<literallayout class="monospaced">
+if (SETWIDTH_NAME undefined) then
+   SETWIDTH_NAME = ATOM("Normal")
+</literallayout>
+</sect3>
+
+<sect3 id="add_style_name">
+<title>ADD_STYLE_NAME</title>
+<!-- .XS -->
+<!-- (SN ADD_STYLE_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+ADD_STYLE_NAME is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+ADD_STYLE_NAME can be defaulted if not supplied as a font property, as follows:
+</para>
+
+<literallayout class="monospaced">
+if (ADD_STYLE_NAME undefined) then
+   ADD_STYLE_NAME = ATOM("")
+</literallayout>
+</sect3>
+
+<sect3 id="pixel_size">
+<title>PIXEL_SIZE</title>
+<!-- .XS -->
+<!-- (SN PIXEL_SIZE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+PIXEL_SIZE is as defined in the
+<function>FontName</function>
+except that the property type is INT32.
+</para>
+<para>
+<!-- .LP -->
+X clients requiring pixel values for the various typographic fixed
+spaces (em space, en space, and thin space) can use the following
+algorithm for computing these values from other properties specified
+for a font:
+</para>
+
+<literallayout class="monospaced">
+     DeciPointsPerInch = 722.7
+     EMspace = ROUND ((RESOLUTION_X * POINT_SIZE) / DeciPointsPerInch)
+     ENspace = ROUND (EMspace / 2)
+     THINspace = ROUND (EMspace / 3)\fP
+</literallayout>
+
+<para>
+<!-- .LP -->
+where a slash (/) denotes real division,
+an asterisk (*) denotes real multiplication,
+and ROUND denotes a function that rounds its real argument
+<emphasis remap='I'>a</emphasis> up or down
+to the next integer.
+This rounding is done according to X = FLOOR (
+<emphasis remap='I'>a</emphasis> + 0.5),
+where FLOOR is a function that rounds its real argument down to the
+nearest integer.
+</para>
+<para>
+<!-- .LP -->
+PIXEL_SIZE can be approximated if not supplied as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+DeciPointsPerInch = 722.7
+if (PIXEL_SIZE undefined) then
+   PIXEL_SIZE = ROUND ((RESOLUTION_Y * POINT_SIZE) / DeciPointsPerInch)
+</literallayout>
+
+</sect3>
+
+<sect3 id="point_size">
+<title>POINT_SIZE</title>
+<!-- .XS -->
+<!-- (SN POINT_SIZE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+POINT_SIZE is as defined in the
+<function>FontName</function>
+except that the property type is INT32.
+</para>
+<para>
+<!-- .LP -->
+X clients requiring device-independent values for em space,
+en space, and thin space can use the following algorithm:
+</para>
+<literallayout class="monospaced">
+     EMspace = ROUND (POINT_SIZE / 10)
+     ENspace = ROUND (POINT_SIZE / 20)
+     THINspace = ROUND (POINT_SIZE / 30)
+</literallayout>
+
+<para>
+<!-- .LP -->
+Design POINT_SIZE cannot be calculated or approximated.
+</para>
+</sect3>
+
+<sect3 id="resolution_x">
+<title>RESOLUTION_X</title>
+<!-- .XS -->
+<!-- (SN RESOLUTION_X -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RESOLUTION_X is as defined in the
+<function>FontName</function>
+except that the property type is CARD32.
+</para>
+<para>
+<!-- .LP -->
+RESOLUTION_X cannot be calculated or approximated.
+</para>
+</sect3>
+
+<sect3 id="resolution_y">
+<title>RESOLUTION_Y</title>
+<!-- .XS -->
+<!-- (SN RESOLUTION_Y -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RESOLUTION_Y is as defined in the
+<function>FontName </function>
+except that the property type is CARD32.
+</para>
+<para>
+<!-- .LP -->
+RESOLUTION_X cannot be calculated or approximated.
+</para>
+</sect3>
+
+<sect3 id="spacing">
+<title>SPACING</title>
+<!-- .XS -->
+<!-- (SN SPACING -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SPACING is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+SPACING can be calculated if not supplied as a font property,
+according to the definitions given above for the
+<function>FontName .</function>
+</para>
+</sect3>
+
+<sect3 id="average_width">
+<title>AVERAGE_WIDTH</title>
+<!-- .XS -->
+<!-- (SN AVERAGE_WIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AVERAGE_WIDTH is as defined in the
+<function>FontName</function>
+except that the property type is INT32.
+</para>
+<para>
+<!-- .LP -->
+AVERAGE_WIDTH can be calculated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (AVERAGE_WIDTH undefined) then
+     AVERAGE_WIDTH = ROUND (MEAN (ABS (width of each glyph in font)) * 10)
+          * (if (dominant writing direction L-to-R) then 1 else -1)
+</literallayout>
+
+<para>
+<!-- .LP -->
+where MEAN is a function that returns the arithmetic mean of its arguments.
+</para>
+<para>
+<!-- .LP -->
+X clients that require values for the number of characters per inch (pitch)
+of a monospaced font can use the following algorithm using the
+AVERAGE_WIDTH and RESOLUTION_X font properties:
+</para>
+
+<literallayout class="monospaced">
+if (SPACING not proportional) then
+   CharPitch = (RESOLUTION_X * 10) / AVERAGE_WIDTH
+</literallayout>
+</sect3>
+
+<sect3 id="charset_registry">
+<title>CHARSET_REGISTRY</title>
+<!-- .XS -->
+<!-- (SN CHARSET_REGISTRY -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+CHARSET_REGISTRY is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+CHARSET_REGISTRY cannot be defaulted if not supplied as a font property.
+</para>
+</sect3>
+
+<sect3 id="charset_encoding">
+<title>CHARSET_ENCODING</title>
+<!-- .XS -->
+<!-- (SN CHARSET_ENCODING -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+CHARSET_ENCODING is as defined in the
+<function>FontName</function>
+except that the property type is ATOM.
+</para>
+<para>
+<!-- .LP -->
+CHARSET_ENCODING cannot be defaulted if not supplied as a font property.
+</para>
+</sect3>
+
+<sect3 id="min_space">
+<title>MIN_SPACE</title>
+<!-- .XS -->
+<!-- (SN MIN_SPACE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+MIN_SPACE is an integer value (of type INT32)
+that gives the recommended minimum word-space value to be used with this font.
+</para>
+<para>
+<!-- .LP -->
+MIN_SPACE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (MIN_SPACE undefined) then
+   MIN_SPACE = ROUND(0.75 * NORM_SPACE)
+</literallayout>
+</sect3>
+
+<sect3 id="norm_space">
+<title>NORM_SPACE</title>
+<!-- .XS -->
+<!-- (SN NORM_SPACE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+NORM_SPACE is an integer value (of type INT32)
+that gives the recommended normal word-space value to be used with this font.
+</para>
+<para>
+<!-- .LP -->
+NORM_SPACE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+DeciPointsPerInch = 722.7
+if (NORM_SPACE undefined) then
+   if (SPACE glyph exists) then
+      NORM_SPACE = width of SPACE
+   else NORM_SPACE = ROUND((0.33 * RESOLUTION_X * POINT_SIZE)/ DeciPointsPerInch)
+</literallayout>
+</sect3>
+
+<sect3 id="max_space">
+<title>MAX_SPACE</title>
+<!-- .XS -->
+<!-- (SN MAX_SPACE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+MAX_SPACE is an integer value (of type INT32)
+that gives the recommended maximum word-space value to be used with this font.
+</para>
+<para>
+<!-- .LP -->
+MAX_SPACE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (MAX_SPACE undefined) then
+   MAX_SPACE = ROUND(1.5 * NORM_SPACE)
+</literallayout>
+</sect3>
+
+<sect3 id="end_space">
+<title>END_SPACE</title>
+<!-- .XS -->
+<!-- (SN END_SPACE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+END_SPACE is an integer value (of type INT32)
+that gives the recommended spacing at the end of sentences.
+</para>
+<para>
+<!-- .LP -->
+END_SPACE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (END_SPACE undefined) then
+   END_SPACE = NORM_SPACE
+</literallayout>
+</sect3>
+
+<sect3 id="avg_capital_width">
+<title>AVG_CAPITAL_WIDTH</title>
+<!-- .XS -->
+<!-- (SN AVG_CAPITAL_WIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AVG_CAPITAL_WIDTH is an integer value (of type INT32)
+that gives the unweighted arithmetic mean of the absolute value of the
+width of each capital glyph in the font, in tenths of pixels,
+multiplied by -1 if the dominant
+writing direction for the font is right-to-left.
+This property applies to both Latin and non-Latin fonts.
+For Latin fonts,
+capitals are the glyphs A through Z.
+This property is usually used for font matching or substitution.
+</para>
+<para>
+<!-- .LP -->
+AVG_CAPITAL_WIDTH can be calculated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (AVG_CAPITAL_WIDTH undefined) then
+   if (capitals exist) then
+      AVG_CAPITAL_WIDTH = ROUND (MEAN
+           (ABS (width of each capital glyph)) * 10)
+           * (if (dominant writing direction L-to-R) then 1 else -1)
+   else AVG_CAPITAL_WIDTH undefined
+</literallayout>
+</sect3>
+
+<sect3 id="avg_lowercase_width">
+<title>AVG_LOWERCASE_WIDTH</title>
+<!-- .XS -->
+<!-- (SN AVG_LOWERCASE_WIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AVG_LOWERCASE_WIDTH is an integer value (of type INT32)
+that gives the unweighted arithmetic mean width of the absolute value
+of the width of each lowercase glyph in the font in tenths of pixels,
+multiplied by -1 if the dominant
+writing direction for the font is right-to-left.
+For Latin fonts,
+lowercase are the glyphs a through z.
+This property is usually used for font matching or substitution.
+</para>
+<para>
+<!-- .LP -->
+Where appropriate,
+AVG_LOWERCASE_WIDTH can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (AVG_LOWERCASE_WIDTH undefined) then
+   if (lowercase exists) then
+      AVG_LOWERCASE_WIDTH = ROUND (MEAN
+                       (ABS (width of each lowercase glyph)) * 10)
+       * (if (dominant writing direction L-to-R) then 1 else -1)
+   else AVG_LOWERCASE_WIDTH undefined
+</literallayout>
+</sect3>
+
+<sect3 id="quad_width">
+<title>QUAD_WIDTH</title>
+<!-- .XS -->
+<!-- (SN QUAD_WIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+QUAD_WIDTH is an integer typographic metric (of type INT32)
+that gives the width of a quad (em) space.
+</para>
+<note>
+<para>
+<!-- .NT Note -->
+Because all typographic fixed spaces (em, en, and thin) are constant
+for a given font size (that is, they do not vary according to setwidth),
+the use of this font property has been deprecated.
+X clients that require typographic fixed space values are encouraged
+to discontinue use of QUAD_WIDTH and compute these values
+from other font properties (for example, PIXEL_SIZE).
+X clients that require  a font-dependent width value should use either
+the FIGURE_WIDTH or one of the average character width font properties
+(AVERAGE_WIDTH, AVG_CAPITAL_WIDTH or AVG_LOWERCASE_WIDTH).
+</para>
+</note>
+<!-- .NE -->
+</sect3>
+
+<sect3 id="figure_width">
+<title>FIGURE_WIDTH</title>
+<!-- .XS -->
+<!-- (SN FIGURE_WIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FIGURE_WIDTH is an integer typographic metric (of type INT32)
+that gives the width of the tabular figures and the dollar sign,
+if suitable for tabular setting (all widths equal).
+For Latin fonts, these tabular figures are the Arabic numerals 0 through 9.
+</para>
+<para>
+<!-- .LP -->
+FIGURE_WIDTH can be approximated if not supplied as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (numerals and DOLLAR sign are defined &amp; widths are equal) then
+   FIGURE_WIDTH = width of DOLLAR
+else FIGURE_WIDTH property undefined
+</literallayout>
+</sect3>
+
+<sect3 id="superscript_x">
+<title>SUPERSCRIPT_X</title>
+<!-- .XS -->
+<!-- (SN SUPERSCRIPT_X -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUPERSCRIPT_X is an integer value (of type INT32)
+that gives the recommended horizontal offset in pixels
+from the position point to the X origin of synthetic superscript text.
+If the current position point is at [X,Y],
+then superscripts should begin at [X + SUPERSCRIPT_X, Y - SUPERSCRIPT_Y].
+</para>
+<para>
+<!-- .LP -->
+SUPERSCRIPT_X can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SUPERSCRIPT_X undefined) then
+   if (TANGENT(ITALIC_ANGLE) defined) then
+      SUPERSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))
+   else SUPERSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)
+</literallayout>
+
+<para>
+<!-- .LP -->
+where TANGENT is a trigonometric function that returns the tangent of
+its argument, which is in 1/64 degrees.
+</para>
+</sect3>
+
+<sect3 id="superscript_y">
+<title>SUPERSCRIPT_Y</title>
+<!-- .XS -->
+<!-- (SN SUPERSCRIPT_Y -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUPERSCRIPT_Y is an integer value (of type INT32)
+that gives the recommended vertical offset in pixels
+from the position point to the Y origin of synthetic superscript text.
+If the current position point is at [X,Y],
+then superscripts should begin at [X + SUPERSCRIPT_X, Y - SUPERSCRIPT_Y].
+</para>
+<para>
+<!-- .LP -->
+SUPERSCRIPT_Y can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+<literallayout class="monospaced">
+if (SUPERSCRIPT_Y undefined) then
+   SUPERSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)
+</literallayout>
+</sect3>
+
+<sect3 id="subscript_x">
+<title>SUBSCRIPT_X</title>
+<!-- .XS -->
+<!-- (SN SUBSCRIPT_X -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUBSCRIPT_X is an integer value (of type INT32)
+that gives the recommended horizontal offset in pixels
+from the position point to the X origin of synthetic subscript text.
+If the current position point is at [X,Y],
+then subscripts should begin at [X + SUBSCRIPT_X, Y + SUBSCRIPT_Y].
+</para>
+<para>
+<!-- .LP -->
+SUBSCRIPT_X can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SUBSCRIPT_X undefined) then
+   if (TANGENT(ITALIC_ANGLE) defined) then
+      SUBSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))
+   else SUBSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)
+</literallayout>
+</sect3>
+
+<sect3 id="subscript_y">
+<title>SUBSCRIPT_Y</title>
+<!-- .XS -->
+<!-- (SN SUBSCRIPT_Y -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUBSCRIPT_Y is an integer value (of type INT32)
+that gives the recommended vertical offset in pixels
+from the position point to the Y origin of synthetic subscript text.
+If the current position point is at [X,Y],
+then subscripts should begin at [X + SUBSCRIPT_X, Y + SUBSCRIPT_Y].
+</para>
+<para>
+<!-- .LP -->
+SUBSCRIPT_Y can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SUBSCRIPT_Y undefined) then
+   SUBSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)
+</literallayout>
+</sect3>
+
+<sect3 id="superscript_size">
+<title>SUPERSCRIPT_SIZE</title>
+<!-- .XS -->
+<!-- (SN SUPERSCRIPT_SIZE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUPERSCRIPT_SIZE is an integer value (of type INT32)
+that gives the recommended body size of synthetic superscripts
+to be used with this font, in pixels.
+This will generally be smaller than the size of the current font;
+that is, superscripts are imaged from a smaller font
+offset according to SUPERSCRIPT_X and SUPERSCRIPT_Y.
+</para>
+<para>
+<!-- .LP -->
+SUPERSCRIPT_SIZE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SUPERSCRIPT_SIZE undefined) then
+   SUPERSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)
+</literallayout>
+</sect3>
+
+<sect3 id="subscript_size">
+<title>SUBSCRIPT_SIZE</title>
+<!-- .XS -->
+<!-- (SN SUBSCRIPT_SIZE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SUBSCRIPT_SIZE is an integer value (of type INT32)
+that gives the recommended body size of synthetic subscripts
+to be used with this font, in pixels.
+As with SUPERSCRIPT_SIZE,
+this will generally be smaller than the size of the current font;
+that is, subscripts are imaged from a smaller
+font offset according to SUBSCRIPT_X and SUBSCRIPT_Y.
+</para>
+<para>
+<!-- .LP -->
+SUBSCRIPT_SIZE can be approximated if not provided as a font property,
+according to the algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SUBSCRIPT_SIZE undefined) then
+   SUBSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)
+</literallayout>
+</sect3>
+
+<sect3 id="small_cap_size">
+<title>SMALL_CAP_SIZE</title>
+<!-- .XS -->
+<!-- (SN SMALL_CAP_SIZE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+SMALL_CAP_SIZE is an integer value (of type INT32)
+that gives the recommended body size of synthetic small capitals
+to be used with this font, in pixels.
+Small capitals are generally imaged from a smaller font
+of slightly more weight.
+No offset [X,Y] is necessary.
+</para>
+<para>
+<!-- .LP -->
+SMALL_CAP_SIZE can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (SMALL_CAP_SIZE undefined) then
+   SMALL_CAP_SIZE = ROUND(PIXEL_SIZE * ((X_HEIGHT
+                              + ((CAP_HEIGHT - X_HEIGHT) / 3)) / CAP_HEIGHT))
+</literallayout>
+</sect3>
+
+<sect3 id="underline_position">
+<title>UNDERLINE_POSITION </title>
+<!-- .XS -->
+<!-- (SN UNDERLINE_POSITION -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+UNDERLINE_POSITION is an integer value (of type INT32)
+that gives the recommended vertical offset in pixels
+from the baseline to the top of the underline.
+If the current position point is at [X,Y],
+the top of the baseline is given by [X, Y + UNDERLINE_POSITION].
+</para>
+<para>
+<!-- .LP -->
+UNDERLINE_POSITION can be approximated if not provided as a font
+property, according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (UNDERLINE_POSITION undefined) then
+   UNDERLINE_POSITION = ROUND((maximum descent) / 2)
+</literallayout>
+<para>
+where <emphasis remap='I'>maximum descent</emphasis>
+is the maximum descent (below the baseline)
+in pixels of any glyph in the font.
+</para>
+</sect3>
+
+<sect3 id="underline_thickness">
+<title>UNDERLINE_THICKNESS</title>
+<!-- .XS -->
+<!-- (SN UNDERLINE_THICKNESS -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+UNDERLINE_THICKNESS is an integer value (of type INT32)
+that gives the recommended underline thickness, in pixels.
+</para>
+<para>
+<!-- .LP -->
+UNDERLINE_THICKNESS can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+CapStemWidth = average width of the stems of capitals
+if (UNDERLINE_THICKNESS undefined) then
+   UNDERLINE_THICKNESS = CapStemWidth
+</literallayout>
+</sect3>
+
+<sect3 id="strikeout_ascent">
+<title>STRIKEOUT_ASCENT</title>
+<!-- .XS -->
+<!-- (SN STRIKEOUT_ASCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+STRIKEOUT_ASCENT is an integer value (of type INT32)
+that gives the vertical ascent for boxing or voiding glyphs in this font.
+If the current position is at [X,Y] and the string extent is EXTENT,
+the upper-left corner of the strikeout box is at [X, Y - STRIKEOUT_ASCENT]
+and the lower-right corner of the box is at [X + EXTENT, Y + STRIKEOUT_DESCENT].
+</para>
+<para>
+<!-- .LP -->
+STRIKEOUT_ASCENT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (STRIKEOUT_ASCENT undefined)
+   STRIKEOUT_ASCENT = maximum ascent
+</literallayout>
+<para>
+where <emphasis remap='I'>maximum ascent</emphasis>
+is the maximum ascent (above the baseline)
+in pixels of any glyph in the font.
+</para>
+</sect3>
+
+<sect3 id="strikeout_descent">
+<title>STRIKEOUT_DESCENT</title>
+<!-- .XS -->
+<!-- (SN STRIKEOUT_DESCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+STRIKEOUT_DESCENT is an integer value (of type INT32)
+that gives the vertical descent for boxing or voiding glyphs in this font.
+If the current position is at [X,Y] and the string extent is EXTENT,
+the upper-left corner of the strikeout box is at [X, Y - STRIKEOUT_ASCENT]
+and the lower-right corner of the box is at
+[X + EXTENT, Y + STRIKEOUT_DESCENT].
+</para>
+<para>
+<!-- .LP -->
+STRIKEOUT_DESCENT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (STRIKEOUT_DESCENT undefined)
+   STRIKEOUT_DESCENT = maximum descent
+</literallayout>
+
+<para>
+where <emphasis remap='I'>maximum descent</emphasis> is the maximum
+descent (below the baseline)
+in pixels of any glyph in the font.
+</para>
+</sect3>
+
+<sect3 id="italic_angle">
+<title>ITALIC_ANGLE</title>
+<!-- .XS -->
+<!-- (SN ITALIC_ANGLE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+ITALIC_ANGLE is an integer value (of type INT32)
+that gives the nominal posture angle of the typeface design, in 1/64 degrees,
+measured from the glyph origin counterclockwise from the three o'clock position.
+</para>
+<para>
+<!-- .LP -->
+ITALIC_ANGLE can be defaulted if not provided as a font property,
+according to the following algorithm:
+</para>
+<literallayout class="monospaced">
+if (ITALIC_ANGLE undefined) then
+   ITALIC_ANGLE = (90 * 64)
+</literallayout>
+</sect3>
+
+<sect3 id="cap_height">
+<title>CAP_HEIGHT</title>
+<!-- .XS -->
+<!-- (SN CAP_HEIGHT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+CAP_HEIGHT is an integer value (of type INT32)
+that gives the nominal height of the capital letters contained in the font,
+as specified by the FOUNDRY or typeface designer.
+</para>
+<para>
+<!-- .LP -->
+Certain clients require CAP_HEIGHT to compute scale factors and
+positioning offsets for synthesized glyphs where this
+information or designed glyphs are not explicitly provided by the font
+(for example, small capitals, superiors, inferiors, and so on).
+CAP_HEIGHT is also a critical factor in font matching and substitution.
+</para>
+<para>
+<!-- .LP -->
+CAP_HEIGHT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (CAP_HEIGHT undefined) then
+   if (Latin font) then
+      CAP_HEIGHT = XCharStruct.ascent[glyph X]
+   else if (capitals exist) then
+       CAP_HEIGHT = XCharStruct.ascent[some unaccented capital glyph]
+   else CAP_HEIGHT undefined
+</literallayout>
+</sect3>
+
+<sect3 id="x_height">
+<title>X_HEIGHT</title>
+<!-- .XS -->
+<!-- (SN X_HEIGHT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+X_HEIGHT is an integer value (of type INT32)
+that gives the nominal height above the baseline of the lowercase glyphs
+contained in the font,
+as specified by the FOUNDRY or typeface designer.
+</para>
+<para>
+<!-- .LP -->
+As with CAP_HEIGHT,
+X_HEIGHT is required by certain clients to compute scale factors
+for synthesized small capitals where this information is not explicitly
+provided by the font resource.
+X_HEIGHT is a critical factor in font matching and substitution.
+</para>
+<para>
+<!-- .LP -->
+X_HEIGHT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (X_HEIGHT undefined) then
+   if (Latin font) then
+      X_HEIGHT = XCharStruct.ascent[glyph x]
+   else if (lowercase exists) then
+        X_HEIGHT = XCharStruct.ascent[some unaccented lc glyph without an ascender]
+   else X_HEIGHT undefined
+</literallayout>
+</sect3>
+
+<sect3 id="relative_setwidth">
+<title>RELATIVE_SETWIDTH</title>
+<!-- .XS -->
+<!-- (SN RELATIVE_SETWIDTH -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RELATIVE_SETWIDTH is an unsigned integer value (of type CARD32)
+that gives the coded proportionate width of the font,
+relative to all known fonts of the same typeface family,
+according to the type designer's or FOUNDRY's judgment.
+</para>
+<para>
+<!-- .LP -->
+RELATIVE_SETWIDTH ranges from 10 to 90 or is 0 if undefined or unknown.
+The following reference values are defined:
+</para>
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Code</entry>
+      <entry>English Translation</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>0</entry>
+      <entry>Undefined</entry>
+      <entry>Undefined or unknown</entry>
+    </row>
+    <row rowsep="0">
+      <entry>10</entry>
+      <entry>UltraCondensed</entry>
+      <entry>The lowest ratio of average width to height</entry>
+    </row>
+    <row rowsep="0">
+      <entry>20</entry>
+      <entry>ExtraCondensed</entry>
+    </row>
+    <row rowsep="0">
+      <entry>30</entry>
+      <entry>Condensed</entry>
+      <entry>Condensed, Narrow, Compressed, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>40</entry>
+      <entry>SemiCondensed</entry>
+    </row>
+    <row rowsep="0">
+      <entry>50</entry>
+      <entry>Medium</entry>
+      <entry>Medium, Normal, Regular, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>60</entry>
+      <entry>SemiExpanded</entry>
+      <entry>SemiExpanded, DemiExpanded, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>70</entry>
+      <entry>Expanded</entry>
+    </row>
+    <row rowsep="0">
+      <entry>80</entry>
+      <entry>ExtraExpanded</entry>
+      <entry>ExtraExpanded, Wide, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>90</entry>
+      <entry>UltraExpanded</entry>
+      <entry>The highest ratio of average width to height</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+RELATIVE_SETWIDTH can be defaulted if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (RELATIVE_SETWIDTH undefined) then
+   RELATIVE_SETWIDTH = 50
+</literallayout>
+
+<para>
+<!-- .LP -->
+For polymorphic fonts, RELATIVE_SETWIDTH is not necessarily a
+linear function of the font's setwidth axis.
+</para>
+<para>
+<!-- .LP -->
+X clients that want to obtain a calculated proportionate width of the
+font (that is, a font-independent way of identifying the proportionate
+width across all fonts and all font vendors) can use the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+SETWIDTH = AVG_CAPITAL_WIDTH / (CAP_HEIGHT * 10)
+</literallayout>
+
+<para>
+<!-- .LP -->
+where SETWIDTH is a real number with zero being the narrowest
+calculated setwidth.
+</para>
+</sect3>
+
+<sect3 id="relative_weight">
+<title>RELATIVE_WEIGHT</title>
+<!-- .XS -->
+<!-- (SN RELATIVE_WEIGHT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RELATIVE_WEIGHT is an unsigned integer value (of type CARD32)
+that gives the coded weight of the font,
+relative to all known fonts of the same typeface family,
+according to the type designer's or FOUNDRY's judgment.
+</para>
+<para>
+<!-- .LP -->
+RELATIVE_WEIGHT ranges from 10 to 90 or is 0 if undefined or unknown.
+The following reference values are defined:
+</para>
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Code</entry>
+      <entry>English Translation</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>0</entry>
+      <entry>Undefined</entry>
+      <entry>Undefined or unknown</entry>
+    </row>
+    <row rowsep="0">
+      <entry>10</entry>
+      <entry>UltraLight</entry>
+      <entry>The lowest ratio of stem width to height</entry>
+    </row>
+    <row rowsep="0">
+      <entry>20</entry>
+      <entry>ExtraLight</entry>
+    </row>
+    <row rowsep="0">
+      <entry>30</entry>
+      <entry>Light</entry>
+    </row>
+    <row rowsep="0">
+      <entry>40</entry>
+      <entry>SemiLight</entry>
+      <entry>SemiLight, Book, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>50</entry>
+      <entry>Medium</entry>
+      <entry>Medium, Normal, Regular,...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>60</entry>
+      <entry>SemiBold</entry>
+      <entry>SemiBold, DemiBold, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>70</entry>
+      <entry>Bold</entry>
+    </row>
+    <row rowsep="0">
+      <entry>80</entry>
+      <entry>ExtraBold</entry>
+      <entry>ExtraBold, Heavy, ...</entry>
+    </row>
+    <row rowsep="0">
+      <entry>90</entry>
+      <entry>UltraBold</entry>
+      <entry>
+UltraBold, Black, ..., the highest ratio of stem width to height
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+RELATIVE_WEIGHT can be defaulted if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (RELATIVE_WEIGHT undefined) then
+   RELATIVE_WEIGHT = 50
+</literallayout>
+
+<para>
+<!-- .LP -->
+For polymorphic fonts, RELATIVE_WEIGHT is not necessarily a
+linear function of the font's weight axis.
+</para>
+</sect3>
+
+<sect3 id="weight">
+<title>WEIGHT</title>
+<!-- .XS -->
+<!-- (SN WEIGHT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+Calculated WEIGHT is an unsigned integer value (of type CARD32)
+that gives the calculated weight of the font,
+computed as the ratio of capital stem width to CAP_HEIGHT,
+in the range 0 to 1000, where 0 is the lightest weight.
+</para>
+<para>
+<!-- .LP -->
+WEIGHT can be calculated if not supplied as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+CapStemWidth = average width of the stems of capitals
+if (WEIGHT undefined) then
+   WEIGHT = ROUND ((CapStemWidth * 1000) / CAP_HEIGHT)
+</literallayout>
+
+<para>
+<!-- .LP -->
+A calculated value for weight is necessary when matching fonts from
+different families because both the RELATIVE_WEIGHT and the WEIGHT_NAME are
+assigned by the typeface supplier, according to its tradition and practice,
+and therefore, are somewhat subjective.
+Calculated WEIGHT provides a font-independent way of identifying
+the weight across all fonts and all font vendors.
+</para>
+</sect3>
+
+<sect3 id="resolution">
+<title>RESOLUTION</title>
+<!-- .XS -->
+<!-- (SN RESOLUTION  -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RESOLUTION is an integer value (of type INT32)
+that gives the resolution for which this font was created,
+measured in 1/100 pixels per point.
+</para>
+<note><para>
+<!-- .NT Note -->
+As independent horizontal and vertical design resolution components
+are required to accommodate displays with nonsquare aspect ratios,
+the use of this font property has been deprecated,
+and independent RESOLUTION_X and RESOLUTION_Y font name fields/properties
+have been defined (see sections 3.1.2.9 and 3.1.2.10).
+X clients are encouraged to discontinue use of the RESOLUTION property
+and are encouraged to use the appropriate X,Y resolution properties,
+as required.
+<!-- .NE                     \" Note End -->
+</para></note>
+</sect3>
+
+<sect3 id="font">
+<title>FONT</title>
+<!-- .XS -->
+<!-- (SN FONT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT is a string (of type ATOM) that gives the full XLFD name of the
+font-that is, the value can be used to open another
+instance of the same font.
+</para>
+<para>
+<!-- .LP -->
+If not provided, the FONT property cannot be calculated.
+</para>
+</sect3>
+
+<sect3 id="face_name">
+<title>FACE_NAME</title>
+<!-- .XS -->
+<!-- (SN FACE_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FACE_NAME is a human-understandable string (of type ATOM)
+that gives the full device-independent typeface name,
+including the owner, weight, slant, set, and so on
+but not the resolution, size, and so on.
+This property may be used as feedback during font selection.
+</para>
+<para>
+<!-- .LP -->
+FACE_NAME cannot be calculated or approximated if not provided as a font
+property.
+</para>
+</sect3>
+
+<sect3 id="full_name">
+<title>FULL_NAME</title>
+<!-- .XS -->
+<!-- (SN FULL_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FULL_NAME is the same as FACE_NAME.
+Its use is deprecated, but it is found on some old fonts.
+</para>
+</sect3>
+
+<sect3 id="copyright">
+<title>COPYRIGHT</title>
+<!-- .XS -->
+<!-- (SN COPYRIGHT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+COPYRIGHT is a human-understandable string (of type ATOM)
+that gives the copyright information of the legal owner
+of the digital font data.
+</para>
+<para>
+<!-- .LP -->
+This information is a required component of a font
+but is independent of the particular format used to represent it
+(that is, it cannot be captured as a comment that could later
+be thrown away for efficiency reasons).
+</para>
+<para>
+<!-- .LP -->
+COPYRIGHT cannot be calculated or approximated if not provided as a font
+property.
+</para>
+</sect3>
+
+<sect3 id="notice">
+<title>NOTICE</title>
+<!-- .XS -->
+<!-- (SN NOTICE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+NOTICE is a human-understandable string (of type ATOM)
+that gives the copyright information of the legal owner of the font design
+or, if not applicable, the trademark information for the typeface FAMILY_NAME.
+</para>
+<para>
+<!-- .LP -->
+Typeface design and trademark protection laws vary from country to country,
+the USA having no design copyright protection currently
+while various countries in Europe offer both design and typeface family name
+trademark protection.
+As with COPYRIGHT,
+this information is a required component of a font
+but is independent of the particular format used to represent it.
+</para>
+<para>
+<!-- .LP -->
+NOTICE cannot be calculated or approximated if not provided as
+a font property.
+</para>
+</sect3>
+
+<sect3 id="destination">
+<title>DESTINATION</title>
+<!-- .XS -->
+<!-- (SN DESTINATION -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+DESTINATION is an unsigned integer code (of type CARD32)
+that gives the font design destination,
+that is, whether it was designed as a screen proofing font to match
+printer font glyph widths (WYSIWYG), as an optimal video font (possibly with
+corresponding printer font) for extended screen viewing (video text), and so on.
+</para>
+<para>
+<!-- .LP -->
+The font design considerations are very different,
+and at current display resolutions,
+the readability and legibility of these two kinds of screen fonts
+are very different.
+DESTINATION allows publishing clients that use X to model the printed page
+and video text clients, such as on-line documentation browsers,
+to query for X screen fonts that suit their particular requirements.
+</para>
+<para>
+<!-- .LP -->
+The encoding is as follows:
+</para>
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <colspec colname='c3' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Code</entry>
+      <entry>English Translation</entry>
+      <entry>Description</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>0</entry>
+      <entry>WYSIWYG</entry>
+      <entry>
+The font is optimized to match the typographic design and metrics of an
+equivalent printer font.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>1</entry>
+      <entry>Video text</entry>
+      <entry>
+The font is optimized for screen legibility and readability.
+      </entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+</sect3>
+
+<sect3 id="font_type">
+<title>FONT_TYPE</title>
+<!-- .XS -->
+<!-- (SN FONT_TYPE -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT_TYPE is a human-understandable string (of type ATOM) that
+describes the format of
+the font data as they are read from permanent storage by the current font source.
+It is a static attribute of the source data.  It can be used
+by clients to select a type of bitmap or outline font
+without regard to the rasterizer used to render the font.
+</para>
+<para>
+<!-- .LP -->
+Predefined values are as follows:
+</para>
+<informaltable frame="none">
+  <tgroup cols='3' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Value</entry>
+      <entry>When applicable</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>"Bitmap"</entry>
+      <entry>
+Hand-tuned bitmap fonts. Some attempt has been made to optimize the visual
+appearance of the font for the requested size and resolution.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>"Prebuilt"</entry>
+      <entry>
+All bitmap format fonts that cannot be described as "Bitmap", that is,
+handtuned.
+For example, a bitmap format font that was generated mechanically using
+a scalable font rasterizer would be considered "Prebuilt", not "Bitmap".
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>"Type 1"</entry>
+      <entry>Any Type 1 font.</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"TrueType"</entry>
+      <entry>Any TrueType font.</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"Speedo"</entry>
+      <entry>Any Speedo font.</entry>
+    </row>
+    <row rowsep="0">
+      <entry>"F3"</entry>
+      <entry>Any F3 font.</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<para>
+Other values may be registered with the X Consortium.
+</para>
+</sect3>
+
+<sect3 id="font_version">
+<title>FONT_VERSION</title>
+<!-- .XS -->
+<!-- (SN FONT_VERSION -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT_VERSION is a human-understandable string (of type ATOM)
+that describes the formal or informal version of the font.
+<function>None</function> is a valid value.
+</para>
+</sect3>
+
+<sect3 id="rasterizer_name">
+<title>RASTERIZER_NAME</title>
+<!-- .XS -->
+<!-- (SN RASTERIZER_NAME -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RASTERIZER_NAME is a human-understandable string (of type ATOM)
+that is the specific name of the
+rasterizer that has performed some rasterization operation
+(such as scaling from outlines) on this font.
+</para>
+<para>
+<!-- .LP -->
+To define a RASTERIZER_NAME, the following format is
+recommended:
+</para>
+<!-- .SM -->
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <tbody>
+    <row rowsep="0">
+      <entry>RasterizerName ::=</entry>
+      <entry>OrganizationId Space Rasterizer</entry>
+    </row>
+    <row rowsep="0">
+      <entry>OrganizationId ::=</entry>
+      <entry>
+STRING8—the X Registry ORGANIZATION name of the rasterizer
+implementor or maintainer.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>Rasterizer ::=</entry>
+      <entry>
+the case-sensitive, human-understandable product name of the rasterizer.
+Words within this name should be separated by a single SPACE.
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>Space ::=</entry>
+      <entry>OCTET−" " (SPACE)</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+
+<para>
+<!-- .LP -->
+Examples:
+</para>
+
+<literallayout class="monospaced">
+      X Consortium Bit Scaler
+      X Consortium Type 1 Rasterizer
+      X Consortium Speedo Rasterizer
+      Adobe Type Manager
+      Sun TypeScaler
+</literallayout>
+
+<para>
+<!-- .LP -->
+If RASTERIZER_NAME is not defined, or is <function>None</function>, no
+rasterization operation has been applied to the FONT_TYPE.
+</para>
+</sect3>
+
+<sect3 id="rasterizer_version">
+<title>RASTERIZER_VERSION</title>
+<!-- .XS -->
+<!-- (SN RASTERIZER_VERSION -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+RASTERIZER_VERSION is a human-understandable string (of type
+ATOM) that represents the formal or informal version of a
+font rasterizer.
+The RASTERIZER_VERSION should match the corresponding
+product version number known to users, when applicable.
+</para>
+</sect3>
+
+<sect3 id="raw_ascent">
+<title>RAW_ASCENT</title>
+<!-- .XS -->
+<!-- (SN RAW_ASCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+For a font with a transformation matrix, RAW_ASCENT is the font ascent
+in 1000 pixel metrics
+(see section \n(sM.1).
+</para>
+</sect3>
+
+<sect3 id="raw_descent">
+<title>RAW_DESCENT</title>
+<!-- .XS -->
+<!-- (SN RAW_DESCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+For a font with a transformation matrix, RAW_DESCENT is the font
+descent in 1000 pixel metrics
+(see section 4.1). <!-- xref -->
+</para>
+</sect3>
+
+<sect3 id="raw_">
+<title>RAW_*</title>
+<!-- .XS -->
+<!-- (SN RAW_* -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+For a font with a transformation matrix,
+all font properties that represent horizontal or vertical sizes or
+displacements will be accompanied by a new property, named as the
+original except prefixed with "RAW_", that is computed as
+described in section 4.1. <!-- xref -->
+</para>
+</sect3>
+
+<sect3 id="axis_names">
+<title>AXIS_NAMES</title>
+<!-- .XS -->
+<!-- (SN AXIS_NAMES -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AXIS_NAMES is a list of all the
+names of the axes for a polymorphic font, separated by a null (0) byte.
+These names are suitable for presentation in a user interface
+(see section 6).
+</para>
+</sect3>
+
+<sect3 id="axis_limits">
+<title>AXIS_LIMITS</title>
+<!-- .XS -->
+<!-- (SN AXIS_LIMITS -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AXIS_LIMITS is a list of integers, two for each axis,
+giving the minimum and maximum allowable values for that axis of a
+polymorphic font
+(see section \n(sP).
+</para>
+</sect3>
+
+<sect3 id="axis_types">
+<title>AXIS_TYPES</title>
+<!-- .XS -->
+<!-- (SN AXIS_TYPES -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+AXIS_TYPES is like AXIS_NAMES,
+but can be registered as having specific semantics
+(see section 6).
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="built-in_font_property_atoms">
+<title>Built-in Font Property Atoms</title>
+<!-- .XS -->
+<!-- (SN Built-in Font Property Atoms -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The following font property atom definitions were predefined in the initial
+version of the core protocol:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <colspec colname='c1' colsep="0"/>
+  <colspec colname='c2' colsep="0"/>
+  <thead>
+    <row rowsep="0">
+      <entry>Font Property/Atom Name</entry>
+      <entry>Property Type</entry>
+    </row>
+  </thead>
+  <tbody>
+    <row rowsep="0">
+      <entry>MIN_SPACE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>NORM_SPACE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>MAX_SPACE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>END_SPACE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SUPERSCRIPT_X</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SUPERSCRIPT_Y</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SUBSCRIPT_X</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SUBSCRIPT_Y</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>UNDERLINE_POSITION</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>UNDERLINE_THICKNESS</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>STRIKEOUT_ASCENT</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>STRIKEOUT_DESCENT</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>FONT_ASCENT</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>FONT_DESCENT</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>ITALIC_ANGLE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>X_HEIGHT</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>QUAD_WIDTH</entry>
+      <entry>INT32 −<superscript>deprecated</superscript></entry>
+    </row>
+    <row rowsep="0">
+      <entry>WEIGHT</entry>
+      <entry>CARD32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>POINT_SIZE</entry>
+      <entry>INT32</entry>
+    </row>
+    <row rowsep="0">
+      <entry>RESOLUTION</entry>
+      <entry>CARD32 −<superscript>deprecated</superscript></entry>
+    </row>
+    <row rowsep="0">
+      <entry>COPYRIGHT</entry>
+      <entry>ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry>FULL_NAME</entry>
+      <entry>ATOM −<superscript>deprecated</superscript></entry>
+    </row>
+    <row rowsep="0">
+      <entry>FAMILY_NAME</entry>
+      <entry>ATOM</entry>
+    </row>
+    <row rowsep="0">
+      <entry>DEFAULT_CHAR</entry>
+      <entry>CARD32</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<!-- .br -->
+<!-- .\" section \n(sM -->
+</sect2>
+</sect1>
+
+<sect1 id="matrix_transformations">
+<title>Matrix Transformations</title>
+<!-- .XS -->
+<!-- (SN Matrix Transformations -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+An XLFD name presented to the server can have the POINT_SIZE or PIXEL_SIZE
+field begin with the character "[".  If the first character of the field
+is "[", the character must be followed with ASCII representations of
+four floating point numbers and a trailing "]", with white space
+separating the numbers and optional white space separating the numbers
+from the "[" and "]" characters.  Numbers use standard floating point
+syntax but use the character "~" to represent a minus sign in the mantissa
+or exponent.
+</para>
+<para>
+<!-- .LP -->
+The BNF for a matrix transformation string is as follows:
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='2' align='left'>
+  <tbody>
+    <row rowsep="0">
+      <entry>MatrixString ::=</entry>
+      <entry>
+LeftBracket OptionalSpace Float Space Float Space
+Float Space Float OptionalSpace RightBracket
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>OptionalSpace ::=</entry>
+      <entry>"" | Space</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Space ::=</entry>
+      <entry>SpaceChar | SpaceChar Space</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Float ::=</entry>
+      <entry>Mantissa | Mantissa Exponent</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Mantissa ::=</entry>
+      <entry>Sign Number | Number</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Sign ::=</entry>
+      <entry>Plus | Tilde</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Number ::=</entry>
+      <entry>Integer | Integer Dot Integer | Dot Integer</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Integer ::=</entry>
+      <entry>Digit | Digit Integer</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Digit ::=</entry>
+      <entry>
+"0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
+      </entry>
+    </row>
+    <row rowsep="0">
+      <entry>Exponent ::=</entry>
+      <entry>"e" SignedInteger | "E" SignedInteger</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SignedInteger ::=</entry>
+      <entry>Sign Integer | Integer</entry>
+    </row>
+    <row rowsep="0">
+      <entry>LeftBracket ::=</entry>
+      <entry>OCTET − "[" (LEFT SQUARE BRACKET)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>RightBracket ::=</entry>
+      <entry>OCTET − "]" (RIGHT SQUARE BRACKET)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>SpaceChar ::=</entry>
+      <entry>OCTET − " " (SPACE)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Tilde ::=</entry>
+      <entry>OCTET − "˜" (TILDE)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Plus ::=</entry>
+      <entry>OCTET − "+" (PLUS)</entry>
+    </row>
+    <row rowsep="0">
+      <entry>Dot ::=</entry>
+      <entry>OCTET − "." (FULL STOP)</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+The string "[a b c d]" represents a graphical transformation of the glyphs
+in the font by the matrix
+</para>
+
+<informaltable frame="none">
+  <tgroup cols='1' align='left'>
+  <tbody>
+    <row rowsep="0">
+      <entry> [  a  b  0  ]</entry>
+    </row>
+    <row rowsep="0">
+      <entry> [  c  d  0  ]</entry>
+    </row>
+    <row rowsep="0">
+      <entry> [  0  0  1  ]</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<para>
+<!-- .LP -->
+All transformations occur around the origin of the glyph.  The
+relationship between the current scalar values and the matrix
+transformation values is that the scalar value "N" in the POINT_SIZE field
+produces the same glyphs as the matrix "[N/10 0 0 N/10]" in that field,
+and the scalar value "N" in the PIXEL_SIZE field produces the same glyphs
+as the matrix "[N*RESOLUTION_X/RESOLUTION_Y 0 0 N]" in that field.
+</para>
+<para>
+<!-- .LP -->
+If matrices are specified for both the POINT_SIZE and PIXEL_SIZE, they
+must bear the following relationship to each other within an
+implementation-specific tolerance:
+</para>
+<blockquote>
+<para>
+	PIXEL_SIZE_MATRIX = [Sx 0 0 Sy] * POINT_SIZE_MATRIX
+</para>
+</blockquote>
+<para>
+where
+</para>
+<blockquote>
+<para>
+	Sx = RESOLUTION_X / 72.27
+</para>
+<para>
+	Sy = RESOLUTION_Y / 72.27
+</para>
+</blockquote>
+<para>
+<!-- .LP -->
+If either the POINT_SIZE or PIXEL_SIZE field is unspecified (either "0" or
+wildcarded), the preceding formulas can be used to compute one from the
+other.
+</para>
+
+<sect2 id="metrics_and_font_properties">
+<title>Metrics and Font Properties</title>
+<!-- .XS -->
+<!-- (SN Metrics and Font Properties -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+In this section, the phrase "1000 pixel metrics" means the
+metrics that would be obtained if the rasterizer took the base untransformed
+design used to generate the transformed font and scaled it linearly to a
+height of 1000 pixels, with no rotation component.  Note that there may be no
+way for the application to actually request this font since the rasterizer
+may use different outlines or rasterization techniques at that size from the
+ones used to generate the transformed font.
+</para>
+<para>
+<!-- .LP -->
+Notes on properties and metrics:
+</para>
+<para>
+<!-- .LP -->
+The per-char ink metrics (lbearing, rbearing, ascent, and descent)
+represent the ink extent of the transformed glyph around its origin.
+</para>
+<para>
+<!-- .LP -->
+The per-char width is the x component of the transformed character width.
+</para>
+<para>
+<!-- .LP -->
+The font ascent and descent are the y component of the transformed font
+ascent or descent.
+</para>
+<para>
+<!-- .LP -->
+The FONT property returns a name reflecting the matrix being
+used-that is, the name returned can be used to open another
+instance of the same font.  The returned name is not necessarily an
+exact copy of the requested name.  If, for example, the user
+requests
+</para>
+<!-- .br -->
+<!-- .ft C -->
+<!-- .SM -->
+<literallayout class="monospaced">
+   -misc-fixed-medium-r-normal--0-[2e1 0 0.0 +10.0]-72-72-c-0-iso8859-1
+</literallayout>
+<!-- .NL -->
+<!-- .ft P -->
+<!-- .br -->
+<para>
+the resulting FONT property might be
+</para>
+<!-- .br -->
+<!-- .ft C -->
+<!-- .SM -->
+<literallayout class="monospaced">
+   -misc-fixed-medium-r-normal--[19.9 0 0 10]-[20 0 0 10]-72-72-c-0-iso8859-1
+</literallayout>
+<!-- .NL -->
+<!-- .ft P -->
+<!-- .br -->
+<para>
+The FONT property will always include matrices in both the PIXEL_SIZE
+and the POINT_SIZE fields.
+</para>
+<para>
+<!-- .LP -->
+To allow accurate client positioning of transformed characters, the
+attributes field of the XCharInfo contains the width of the character in
+1000 pixel metrics.  This attributes field should be interpreted as a signed
+integer.
+</para>
+<para>
+<!-- .LP -->
+There will always be 2 new font properties defined, RAW_ASCENT and
+RAW_DESCENT, that hold the ascent and descent in 1000 pixel metrics.
+</para>
+<para>
+<!-- .LP -->
+All font properties that represent horizontal widths or displacements
+have as their value the x component of the transformed width or
+displacement.  All font properties that represent vertical heights or
+displacements have as their value the y component of the transformed
+height or displacement.  Each such property will be accompanied by a new
+property, named as the original except prefixed with "RAW_", that gives
+the value of the width, height, or displacement in 1000 pixel metrics.
+</para>
+</sect2>
+</sect1>
+
+<sect1 id="scalable_fonts">
+<title>Scalable Fonts</title>
+<!-- .XS -->
+<!-- (SN Scalable Fonts -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The XLFD is designed to support scalable fonts.  A scalable font is a
+font source from which instances of arbitrary size can be derived.
+A scalable font source might be one or more outlines
+together with zero or more hand-tuned bitmap fonts at specific sizes and
+resolutions, or it might be a programmatic description together with
+zero or more bitmap fonts, or some other format
+(perhaps even just a single bitmap font).
+</para>
+<para>
+<!-- .LP -->
+The following definitions are useful for discussing scalable fonts:
+</para>
+<para>
+<!-- .LP -->
+<function>Well-formed XLFD pattern</function>
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<emphasis role="bold">Well-formed XLFD pattern</emphasis>
+    </para>
+    <para>
+A pattern string containing 14 hyphens, one of which is
+the first character of the pattern.  Wildcard characters are permitted
+in the fields of a well-formed XLFD pattern.
+    </para>
+  </listitem>
+</itemizedlist>
+<itemizedlist>
+  <listitem>
+<para>
+<function>Scalable font name</function>
+</para>
+    <para>
+A well-formed XLFD pattern containing no wildcards and containing the
+digit "0" in the PIXEL_SIZE, POINT_SIZE, and AVERAGE_WIDTH fields.
+    </para>
+  </listitem>
+</itemizedlist>
+<itemizedlist>
+  <listitem>
+<para>
+<function>Scalable fields</function>
+</para>
+    <para>
+The XLFD fields PIXEL_SIZE, POINT_SIZE, RESOLUTION_X,
+RESOLUTION_Y, and AVERAGE_WIDTH.
+    </para>
+  </listitem>
+</itemizedlist>
+<itemizedlist>
+  <listitem>
+<para>
+<function>Derived instance</function>
+</para>
+    <para>
+The result of replacing the scalable fields of a font name
+with values to yield a font name that could actually be
+produced from the font source.  A scaling engine is
+permitted, but not required, to interpret the scalable
+fields in font names to support anamorphic scaling.
+    </para>
+  </listitem>
+</itemizedlist>
+<itemizedlist>
+  <listitem>
+    <para>
+<function>Global list</function>
+    </para>
+    <para>
+The list of names that would be returned by an X server for a
+<function>ListFonts</function>
+protocol request on the pattern "*" if there were no protocol
+restrictions on the total number of names returned.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+<!-- .LP -->
+The global list consists of font names derived from font sources.
+If a single font source can support multiple character sets (specified
+in the CHARSET_REGISTRY and CHARSET_ENCODING fields), each such character
+set should be used to form a separate font name in the list.
+For a nonscalable font source, the simple font name
+for each character set is included in the global list.
+For a scalable font source, a scalable font name for each character set
+is included in the list.  In addition to the scalable font name,
+specific derived instance names may also be included in the list.
+The relative order of derived instances with respect to the scalable
+font name is not constrained.  Finally, font name aliases may also be included
+in the list.  The relative order of aliases
+with respect to the real font name is not constrained.
+</para>
+<para>
+<!-- .LP -->
+The values of the RESOLUTION_X and RESOLUTION_Y fields of a scalable font name
+are implementation dependent,
+but to maximize backward compatibility, they
+should be reasonable nonzero values, for example, a resolution close to that
+provided by the screen (in a single-screen server).
+Because some existing
+applications rely on seeing a collection of point and pixel sizes,
+server vendors are strongly encouraged in the near term to
+provide a mechanism for including, for each scalable font name,
+a set of specific derived instance names.  For font sources that contain
+a collection of hand-tuned bitmap fonts, including names of these instances
+in the global list is recommended and sufficient.
+</para>
+<para>
+<!-- .LP -->
+The X protocol request
+<function>OpenFont</function>
+on a scalable font name returns a font corresponding to an
+implementation-dependent derived instance of that font name.
+</para>
+<para>
+<!-- .LP -->
+The X protocol request
+<function>ListFonts</function>
+on a well-formed XLFD pattern returns the following.
+Starting with the global list, if the actual pattern argument
+has values containing no wildcards in scalable fields,
+then substitute each such field into the corresponding
+field in each scalable font name in the list.  For each resulting font name,
+if the remaining scalable fields cannot be replaced with values to produce a
+derived instance, remove the font name from the list.  Now take the modified
+list, and perform a simple pattern match against the pattern argument.
+<function>ListFonts</function>
+returns the resulting list.
+</para>
+<para>
+For example, given the global list:
+</para>
+<literallayout class="monospaced">
+-Linotype-Times-Bold-I-Normal--0-0-100-100-P-0-ISO8859-1
+-Linotype-Times-Bold-R-Normal--0-0-100-100-P-0-ISO8859-1
+-Linotype-Times-Medium-I-Normal--0-0-100-100-P-0-ISO8859-1
+-Linotype-Times-Medium-R-Normal--0-0-100-100-P-0-ISO8859-1
+</literallayout>
+
+<para>
+a <function>ListFonts</function> request with the pattern:
+</para>
+
+<literallayout class="monospaced">
+-*-Times-*-R-Normal--*-120-100-100-P-*-ISO8859-1
+</literallayout>
+
+<para>
+would return:
+</para>
+
+<literallayout class="monospaced">
+-Linotype-Times-Bold-R-Normal--0-120-100-100-P-0-ISO8859-1
+-Linotype-Times-Medium-R-Normal--0-120-100-100-P-0-ISO8859-1
+</literallayout>
+
+<para>
+<function>ListFonts</function>
+on a pattern containing wildcards that is not a well-formed XLFD
+pattern is only required to return the list obtained by performing
+a simple pattern match against the global list.
+X servers are permitted, but not required,
+to use a more sophisticated matching algorithm.
+<!-- .\" section \n(sP -->
+</para>
+</sect1>
+
+<sect1 id="polymorphic_fonts">
+<title>Polymorphic Fonts</title>
+<!-- .XS -->
+<!-- (SN Polymorphic Fonts -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+Fonts that can be varied in ways other than size or resolution are called
+<emphasis remap='I'>polymorphic fonts.</emphasis>  Multiple Master Type 1 font programs are one type of
+a polymorphic font.  Current examples of axes along which the fonts can be
+varied are width, weight, and optical size; others might include formality
+or x-height.
+</para>
+<para>
+To support polymorphic fonts, special values indicating variability are
+defined for the following XLFD fields:
+</para>
+<blockquote>
+<para>
+<!-- .nf -->
+	WEIGHT_NAME
+</para>
+<para>
+	SLANT
+</para>
+<para>
+	SETWIDTH_NAME
+</para>
+<para>
+	ADD_STYLE_NAME
+</para>
+</blockquote>
+<para>
+<!-- .LP -->
+The string "0" is the special polymorphic value.  In the
+WEIGHT_NAME, SLANT, or SETWIDTH_NAME field, "0" must be the
+entire field.
+There may be multiple polymorphic values
+in the ADD_STYLE_NAME field.
+They are surrounded by "[" and "]" and separated by a Space,
+as "[0\00]".  The polymorphic values may coexist with
+other data in the field.
+It is recommended that the polymorphic values
+be at the end of the ADD_STYLE_NAME field.
+</para>
+<para>
+<!-- .LP -->
+The font-matching algorithms for a font with polymorphic fields are
+identical to the matching algorithms for a font with scalable fields.
+</para>
+<para>
+<!-- .LP -->
+There are three new font properties to describe the axes of variation,
+AXIS_NAMES, AXIS_LIMITS, and AXIS_TYPES.  AXIS_NAMES is a list of all the
+names of the axes for the font, separated by a null (0) byte.
+These names are suitable for presentation in
+a user interface.  AXIS_LIMITS is a list of integers, two for each axis,
+giving the minimum and maximum allowable values for that axis.
+AXIS_TYPES is like AXIS_NAMES,
+but can be registered as having specific semantics.
+</para>
+<para>
+<!-- .LP -->
+The axes are listed in the properties in the same order as they
+appear in the font name.  They are matched with font name fields by
+looking for the special polymorphic values in the font name.
+</para>
+<para>
+<!-- .LP -->
+Examples:
+</para>
+<para>
+<!-- .LP -->
+The Adobe Myriad MM font program has width and weight axes.  Weight can
+vary from 215 to 830, and width from 300 to 700.
+</para>
+<literallayout class="monospaced">
+Name:
+        -Adobe-Myriad MM-0-R-0--0-0-0-0-P-0-ISO8859-1
+AXIS_NAMES:
+        Weight, Width
+AXIS_LIMITS:
+        215, 830, 300, 700
+AXIS_TYPES:
+        Adobe-Weight, Adobe-Width
+Sample derived instance:
+        -Adobe-Myriad MM-412-R-575--*-120-100-100-P-*-ISO8859-1
+</literallayout>
+
+<para>
+The Adobe Minion MM Italic font program has width, weight, and optical
+size axes.
+</para>
+
+<literallayout class="monospaced">
+Name:
+         -Adobe-Minion MM-0-I-0-[0]-0-0-0-0-P-0-ISO8859-1
+AXIS_NAMES:
+         Weight, Width, Optical size
+AXIS_LIMITS:
+         345, 620, 450, 600, 6, 72
+AXIS_TYPES:
+         Adobe-Weight, Adobe-Width, Adobe-OpticalSize
+Sample derived instance:
+         -Adobe-Minion MM-550-I-480-[18]-*-180-100-100-P-*-ISO8859-1
+</literallayout>
+
+<para>
+The Adobe Minion MM Swash Italic font program has the same axes and
+values.  This shows how "[0]" in the ADD_STYLE_NAME field can
+coexist with other words.
+</para>
+
+<literallayout class="monospaced">
+Name:
+        -Adobe-Minion MM-0-I-0-Swash[0]-0-0-0-0-P-0-ISO8859-1
+AXIS_NAMES:
+        Weight, Width, Optical size
+AXIS_LIMITS:
+        345, 620, 450, 600, 6, 72
+AXIS_TYPES:
+        Adobe-Weight, Adobe-Width, Adobe-OpticalSize
+Sample derived instance:
+        -Adobe-Minion MM-550-I-480-Swash[18]-*-180-100-100-P-*-ISO8859-1
+</literallayout>
+
+<para>
+The XYZ Abc font, a hypothetical font, has optical size and x-height axes.
+This shows how there can be more than one polymorphic value in the
+ADD_STYLE_NAME field.
+</para>
+
+<literallayout class="monospaced">
+Name:
+        -XYZ-Abc-Medium-R-Normal-[0 0]-0-0-0-0-P-0-ISO8859-1
+AXIS_NAMES:
+        Optical size, X-height
+AXIS_LIMITS:
+        6, 72, 400, 600
+AXIS_TYPES:
+        XYZ-OpticalSize, XYZ-Xheight
+Sample derived instance:
+        -XYZ-Abc-Medium-R-Normal-[14 510]-*-140-100-100-P-*-ISO8859-1
+</literallayout>
+
+<para>
+If an axis allows negative values, a client requests a negative value by
+using "~" (TILDE) as a minus sign.
+</para>
+<para>
+Axis types can be registered with the X Consortium, along with their
+semantics.
+</para>
+<para>
+If a font name that contains the polymorphic value or a wildcard in a
+polymorphic field is presented to a font source, the font source is free
+to substitute any value that is convenient.  However, font sources should
+try to use a value that would be considered
+<emphasis remap='I'>normal</emphasis> or
+<emphasis remap='I'>medium</emphasis> for the
+particular font.  For example, if an optical size variable is unresolved,
+the font source should provide a value appropriate to the size of the
+font.
+</para>
+
+<para>
+The result of specifying an out-of-range value for a polymorphic field is
+undefined.  The font source may treat this as a
+<function>BadName</function> error, treat the
+value as if it were the closest legal value, or extrapolate to try to
+accommodate the value.
+</para>
+</sect1>
+
+<sect1 id="affected_elements_of_xlib_and_the_x_protocol">
+<title>Affected Elements of Xlib and the X Protocol</title>
+<!-- .XS -->
+<!-- (SN Affected Elements of Xlib and the X Protocol -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The following X protocol requests must support the XLFD conventions:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<function>OpenFont</function>
+- for the name argument
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>ListFonts</function>
+- for the pattern argument
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>ListFontsWithInfo</function>
+- for the pattern argument
+    </para>
+  </listitem>
+</itemizedlist>
+<para>
+<!-- .LP -->
+In addition,
+the following Xlib functions must support the XLFD conventions:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+<function>XLoadFont</function>
+- for the name argument
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>XListFontsWithInfo</function>
+- for the pattern argument
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>XLoadQueryFont</function>
+- for the name argument
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>XListFonts</function>
+- for the pattern argument
+    </para>
+  </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="bdf_conformance">
+<title>BDF Conformance</title>
+<!-- .XS -->
+<!-- (SN BDF Conformance -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The bitmap font distribution and interchange format adopted by the
+X Consortium (BDF V2.1) provides a general mechanism for identifying the
+font name of an X font and a variable list of font properties,
+but it does not mandate the syntax or semantics of the font name
+or the semantics of the font properties that might be provided in a BDF font.
+This section identifies the requirements for BDF fonts that conform to XLFD.
+</para>
+
+<sect2 id="xlfd_conformance_requirements">
+<title>XLFD Conformance Requirements</title>
+<!-- .XS -->
+<!-- (SN XLFD Conformance Requirements -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+A BDF font conforms to the XLFD specification if and only if the
+following conditions are satisfied:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+The value for the BDF item <function>FONT</function> conforms to the syntax
+and semantic definition of a XLFD
+<function>FontName </function>
+string.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+The
+<function>FontName </function>
+begins with the X
+<function>FontNameRegistry </function>
+prefix: "-".
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+All XLFD
+<function>FontName </function>
+fields are defined.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Any FontProperties provided conform in name and semantics to the XLFD
+<function>FontProperty </function>
+definitions.
+    </para>
+  </listitem>
+</itemizedlist>
+<para>
+<!-- .LP              -->
+A simple method of testing for conformance would entail verifying that the
+<function>FontNameRegistry </function>
+prefix is the string "-",
+that the number of field delimiters in the string and coded field values
+are valid,
+and that each font property name either matches a standard XLFD property name
+or follows the definition of a private property.
+</para>
+</sect2>
+
+<sect2 id="font_ascent_font_descent_and_default_char">
+<title>FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR</title>
+<!-- .XS -->
+<!-- (SN FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR are provided in the BDF
+specification as properties that are moved to the
+<function>XFontStruct </function>
+by the BDF font compiler in generating the X server-specific
+binary font encoding.
+If present,
+these properties shall comply with the following semantic definitions.
+</para>
+
+<sect3 id="font_ascent">
+<title>FONT_ASCENT</title>
+<!-- .XS -->
+<!-- (SN FONT_ASCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT_ASCENT is an integer value (of type INT32)
+that gives the recommended typographic ascent above the baseline
+for determining interline spacing.
+Specific glyphs of the font may extend beyond this.
+If the current position point for line <emphasis remap='I'>n</emphasis> is at [X,Y],
+then the origin of the next line <emphasis remap='I'>m = n + 1</emphasis>
+(allowing for a possible font change) is
+[X, Y + FONT_DESCENTn + FONT_ASCENTm].
+</para>
+<para>
+<!-- .LP -->
+FONT_ASCENT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+
+<literallayout class="monospaced">
+if (FONT_ASCENT undefined) then
+   FONT_ASCENT = maximum ascent
+</literallayout>
+<para>
+where maximum ascent is the maximum ascent (above the baseline)
+in pixels of any glyph in the font.
+</para>
+</sect3>
+
+<sect3 id="font_descent">
+<title>FONT_DESCENT</title>
+<!-- .XS -->
+<!-- (SN FONT_DESCENT -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+FONT_DESCENT is an integer value (of type INT32)
+that gives the recommended typographic descent below the baseline
+for determining interline spacing.
+Specific glyphs of the font may extend beyond this.
+If the current position point for line
+<emphasis remap='I'>n</emphasis> is at [X,Y],
+then the origin of the next line <emphasis remap='I'>m = n+1</emphasis>
+(allowing for a possible font change) is
+[X, Y + FONT_DESCENTn + FONT_ASCENTm].
+</para>
+<para>
+The logical extent of the font is inclusive between the Y-coordinate values:
+Y - FONT_ASCENT and Y + FONT_DESCENT + 1.
+</para>
+<para>
+FONT_DESCENT can be approximated if not provided as a font property,
+according to the following algorithm:
+</para>
+<literallayout class="monospaced">
+if (FONT_DESCENT undefined) then
+   FONT_DESCENT = maximum descent
+</literallayout>
+<para>
+where maximum descent is the maximum descent (below the baseline)
+in pixels of any glyph in the font.
+</para>
+</sect3>
+
+<sect3 id="default_char">
+<title>DEFAULT_CHAR</title>
+<!-- .XS -->
+<!-- (SN DEFAULT_CHAR -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The DEFAULT_CHAR is an unsigned integer value (of type CARD32)
+that specifies the index
+of the default character to be used by the X server when an attempt
+is made to display an undefined or nonexistent character in the font.
+(For a font using a 2-byte matrix format,
+the index bytes are encoded in the integer as byte1 * 65536 + byte2.)
+If the DEFAULT_CHAR itself specifies an undefined or nonexistent character
+in the font,
+then no display is performed.
+</para>
+<para>
+<!-- .LP -->
+DEFAULT_CHAR cannot be approximated if not provided as a font property.
+<!-- .\" -->
+<!-- .\" print Table of Contents -->
+<!-- .if o .bp \" blank page to make count even -->
+<!-- .bp 1 -->
+<!-- .af PN i -->
+<!-- .PX -->
+</para>
+</sect3>
+</sect2>
+</sect1>
+</chapter>
+</book>
diff --git a/specs/Xserver/analysis.tex b/specs/Xserver/analysis.tex
deleted file mode 100644
index a2eeabd..0000000
--- a/specs/Xserver/analysis.tex
+++ /dev/null
@@ -1,1528 +0,0 @@
-\documentstyle{article}
-\setlength{\parindent}{0 pt}
-\setlength{\parskip}{6pt}
-
-% $XFree86$
-
-\begin{document}
-
-\title{Analysis of the X Protocol for Security Concerns\\Draft Version 2}
-\author{David P. Wiggins\\X Consortium, Inc.}
-\date{May 10, 1996}
-\maketitle
-
-\begin{abstract}
-
-This paper attempts to list all instances of certain types of security
-problems in the X Protocol.  Issues with authorization are not
-addressed.  We assume that a malicious client has already succeeded in
-connecting, and try to assess what harm it can then do.  We propose
-modifications to the semantics of the X Protocol to reduce these
-risks.
-
-\end{abstract}
-% suppress page number on title page
-\thispagestyle{empty}
-
-\eject
-
-Copyright \copyright 1996 X Consortium, Inc.  All Rights Reserved.
-
-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 OF
-OR OTHER DEALINGS IN THE SOFTWARE.
-
-Except as contained in this notice, the name of the X Consortium shall
-not be used in advertising or otherwise to promote the sale, use or
-other dealings in this Software without prior written authorization
-from the X Consortium.
-
-\eject
-
-\section{Definition of Threats}
-
-We analyze the X protocol for the following threats.
-
-\begin{description}
-
-\item[Theft] occurs when a client gains access to information owned by
-another client without explicit permission from that other client.
-For this analysis, we take a broad view of ownership: any information
-that exists in the server due to the actions of a client is considered
-owned by that client.  Furthermore, the client that has input focus
-owns keyboard events, and the client that owns the window that the
-pointer is in owns mouse events.  This view may reveal certain
-instances of ``theft'' that we don't care to stop, but we think it is
-better to identify all potential candidates up front and cull the list
-later than to do a partial analysis now and plan on reanalyzing for
-remaining holes later.
-
-\item[Denial of service] occurs when a client causes another client or
-the user to lose the ability to perform some operation.
-
-\item[Spoofing] occurs when a client attempts to mimic another client
-with the hope that the user will interact with it as if it really were
-the mimicked client.  A wide variety of requests may be used in a
-spoofing attack; we will only point out a few likely candidates.
-
-\item[Destruction] occurs when a client causes another client to lose
-information in a way that the client or user is likely to notice.
-(This does not count expected forms of destruction, e.g., exposures.)
-
-\item[Alteration] occurs when a client causes another client to lose
-information in a way that the client or user is unlikely to
-notice. e.g., changing one pixel in a drawable.
-
-\end{description}
-
-The line between alteration and destruction is subjective.  Security
-literature does often distinguish between them, though not always
-explicitly.  Alteration is often considered more insidious because its
-effects may not be realized until long after it has occurred.  In the
-intervening time, each time the altered data is used, it can cause
-more damage.
-
-
-
-\section{General security concerns and remedies}
-
-The following sections discuss security problems intrinsic to the X
-Protocol.  A statement of each problem is usually followed by
-potential remedies.  A few words here about possible remedies will
-help frame the specific ones described below.
-
-If a client attempts a threatening operation, the server may take one
-of the following actions, listed roughly in order of severity:
-
-1. Execute the request normally.  This is the right choice when we
-decide that a particlar threat is not serious enough to worry about.
-
-2. Execute the request in some modified form, e.g., substitute
-different values for some of the request fields, or edit the reply.
-
-3. Arrange to ask the user what to do, given some subset of the other
-choices in this list.  This must be used sparingly because of the
-performance impact.
-
-4. Treat the request as a no-op.  If the client will probably not
-notice, or if it seems likely that the intent was benign, this is a
-good choice.
- 
-5. Send a protocol error to the client.  If the client will be
-confused enough by the other options that it will probably crash or
-become useless anyway, or if it seems likely that the intent was
-malicious, this is a good choice.
-
-6. Kill the client.  This might be the right action if there is no
-doubt that the client is hostile.
-
-In most cases we present the one option that seems most appropriate to
-counter the threat, taking into account the seriousness of the threat,
-the implementation difficulty, and the impact on applications.  Our
-initial bias is to err on the side of stronger security, with the
-accompanying tighter restrictions.  As we uncover important operations
-and applications that the new restrictions interfere with, we can apply
-selective loosening to allow the desired functionality.
-
-In some cases we will suggest returning an Access error where the X
-protocol does not explicitly allow one.  These new Access errors arise
-when a client can only perform a (non-empty) subset of the defined
-operations on a resource.  The disallowed operations cause Access
-errors.  The resiource at issue is usually a root window.
-
-
-
-\subsection{Access to Server Resources}
-
-The X protocol allows clients to manipulate resources (objects)
-belonging to other clients or to the server.  Any request that
-specifies a resource ID is vulnerable to some of the above threats.
-Such requests also provide a way for a client to guess resource IDs of
-other clients.  A client can make educated guesses for possible
-resource IDs, and if the request succeeds, it knows it has determined
-a valid resource ID.  We call this ``resource ID guessing'' in the
-list below.
-
-One likely defense against these problems is to have the server send
-an appropriate protocol error to deny the existence of any resource
-specified by a client that doesn't belong to that client.  A variation
-on this policy lets cooperating groups of clients access each other's
-resources, but not those of other groups.  The Broadway project will
-initially use a less general form of this idea by having two groups,
-trusted and untrusted.  Trusted clients can do everything that X
-clients can do today.  They will be protected from untrusted clients
-in ways described below.  Untrusted clients will not be protected from
-each other.  Though this will be the initial design, we need to make
-sure there is a growth path to multiple (more than two) groups.
-
-Most of the time, applications never access server resources that
-aren't their own, so the impact of disallowing such accesses should be
-minimal.  There are a few notable exceptions, most of which will be
-discussed under the relevant protocol requests.  They are: ICCCM
-selection transfer, Motif drag and drop, and server-global resources
-like the root window and default colormap.  Another major exception is
-the window manager, which routinely manipulates windows of other
-applications.  The solution for window managers is to always run them
-as trusted applications.
-
-The implementation difficulty of limiting access to resources should
-not be large.  All resource accesses eventually funnel down to one of
-two functions in dix/resource.c: LookupIDByType() and
-LookupIDByClass().  A few lines of checking at the top of these
-functions will form the heart of this defense.  There is a small
-problem because these functions are not told which client is doing the
-lookup, but that can be solved either by adding a client parameter
-(probably as a new function to preserve compatibility), or by using
-the server global requestingClient.
-
-ISSUE: are we really going to be able to get away with hiding trusted
-resources, or will things like Motif drag and drop force us to expose
-them?  (Either way, the operations that untrusted clients can do to
-trusted resources will have to be limited.)  Is there something in Xt
-or the ICCCM that breaks if you hide resources?
-
-\subsection{Denial of Service}
-
-\subsubsection{Memory Exhaustion}
-
-Any request that causes the server to consume resources (particularly
-memory) can be used in a denial of service attack.  A client can use
-such requests repeatedly until the server runs out of memory.  When
-that happens, the server will either crash or be forced to send Alloc
-errors.  The most obvious candidates are resource creation requests,
-e.g., CreatePixmap, but in reality a large percentage of requests
-cause memory allocation, if only temporarily, depending on the server
-implementation.  For this reason, the list of requests subject to this
-form of denial of service will be necessarily incomplete.
-
-To address this form of denial of service, the server could set
-per-client quotas on memory consumption.  When the limit is surpassed,
-the server could return Alloc errors.  The application impact is
-minimal as long as the application stays within quota.  The
-implementation difficulty is another story.
-
-Conceptually, it seems easy: simply have a way to set the limit, and
-on every memory (de)allocation operation, update the client's current
-usage, and return an error if the client is over the limit.  The first
-problem is something we've already touched on: the allocator functions
-aren't told which client the allocation belongs to.  Unlike resource
-lookups, allocations are done in too many places to consider a new
-interface that passes the client, so using the global requestingClient
-is practically mandatory.
-
-The problems run deeper.  The logical thing for the allocator to do if
-the client is over its limit is to return NULL, indicating allocation
-failure.  Unfortunately, there are many places in the server that will
-react badly if this happens.  Most of these places, but not all, are
-``protected'' by setting the global variable Must\_have\_memory to True
-around the delicate code.  We could help the problem by skipping the
-limit check if Must\_have\_memory is True.  The best solution would be
-to bullet-proof the server against allocation failures, but that is
-beyond the scope of Broadway.  Another consideration is that the
-additional checking may have a measurable performance impact, since
-the server does frequent allocations.
-
-A third problem is that there is no portable way to determine the size
-of a chunk of allocated memory given just a pointer to the chunk, and
-that's all you have inside Xrealloc() and Xfree().  The server could
-compensate by recording the sizes itself somewhere, but that would be
-wasteful of memory, since the malloc implementation also must be
-recording block sizes.  On top of that, the redundant bookkeeping
-would hurt performance.  One solution is to use a custom malloc that
-has the needed support, but that too seems beyond the scope of
-Broadway.
-
-Considering all of this, we think it is advisable to defer solving the
-memory exhaustion problem to a future release.  Keep this in mind when
-you see quotas mentioned as a defense in the list below.
-
-\subsubsection{CPU Monopolization}
-
-Another general way that a client can cause denial of service is to
-flood the server with requests.  The server will spend a large
-percentage of its time servicing those requests, possibly starving
-other clients and certainly hurting performance.  Every request can be
-used for flooding, so we will not bother to list flooding on every
-request.  A variation on this attack is to flood the server with new
-connection attempts.
-
-To reduce the effectiveness of flooding, the server could use a
-different scheduling algorithm that throttles clients that are
-monopolizing the server, or it could simply favor trusted clients over
-untrusted ones.  Applications cannot depend on a particular scheduling
-algorithm anyway, so changing it should not affect them.  The
-Synchronization extension specifies a way to set client priorities,
-and a simple priority scheduler already exists in the server to
-support it, so this should be simple to add.
-
-
-
-\section{Security concerns with specific window attributes}
-
-\subsection{Background-pixmap}
-
-Clients can use windows with the background-pixmap attribute set to
-None (hereafter ``background none windows'') to obtain images of other
-windows.  A background none window never paints its own background, so
-whatever happened to be on the screen when the window was mapped can
-be read from the background none window with GetImage.  This may well
-contain data from other windows.  The CreateWindow and
-ChangeWindowAttributes requests can set the background-pixmap
-attribute set to None, and many window operations can cause data from
-other windows to be left in a background none window, including
-ReparentWindow, MapWindow, MapSubwindows, ConfigureWindow, and
-CirculateWindow.
-
-Background none windows can also be used to cause apparent alteration.
-A client can create a window with background none and draw to it.  The
-drawing will appear to the user to be in the windows below the
-background none window.
-
-To remedy these problems, the server could substitute a well-defined
-background when a client specifies None.  Ideally the substituted
-background would look different enough from other windows that the
-user wouldn't be confused.  A tile depicting some appropriate
-international symbol might be reasonable.  We believe that there are
-few applications that actually rely on background none semantics, and
-those that do will be easy for the user to identify because of the
-distinctive tile.  Implementation should not be a problem either.
-Luckily, the window background cannot be retrieved through the X
-protocol, so we won't have to maintain any illusions about its value.
-
-ISSUE: Some vendors have extensions to let you query the window
-background.  Do we need to accomodate that?
-
-ISSUE: Will this lead to unacceptable application breakage?  Could the
-server be smarter, only painting with the well-defined background when
-the window actually contains bits from trusted windows?
-
-\subsection{ParentRelative and CopyFromParent}
-
-Several window attributes can take on special values that cause them
-to reference (ParentRelative) or copy (CopyFromParent) the same
-attribute from the window's parent.  This fits our definition of theft.
-The window attributes are class, background-pixmap, border-pixmap, and
-colormap.  All of these can be set with CreateWindow; all but class
-can be set with ChangeWindowAttributes.
-
-These forms of theft aren't particularly serious, so sending an error
-doesn't seem appropriate.  Substitution of different attribute values
-seems to be the only reasonable option, and even that is likely to
-cause trouble for clients.  Untrusted clients are already going to be
-prevented from creating windows that are children of trusted clients
-(see CreateWindow below).  We recommend that nothing more be done to
-counter this threat.
-
-
-\subsection{Override-redirect}
-
-Windows with the override-redirect bit set to True are generally
-ignored by the window manager.  A client can map an override-redirect
-window that covers most or all of the screen, causing denial of
-service since other applications won't be visible.
-
-To prevent this, the server could prevent more than a certain
-percentage (configurable) the of screen area from being covered by
-override-redirect windows of untrusted clients.
-
-Override-redirect windows also make some spoofing attacks easier since
-the client can more carefully control the presentation of the window
-to mimic another client.  Defenses against spoofing will be
-given under MapWindow.
-
-\section{Security concerns with specific requests}
-
-To reduce the space needed to discuss 120 requests, most of the
-following sections use a stylized format.  A threat is given, followed
-by an imperative statement.  The implied subject is an untrusted
-client, and the object is usually a trusted client.  Following that,
-another statement starting with ``Defense:'' recommends a
-countermeasure for the preceding threat(s).
-
-Resources owned by the server, such as the root window and the default
-colormap, are considered to be owned by a trusted client.
-
-
-\subsection{CreateWindow}
-
-Alteration: create a window as a child of another client's window,
-altering its list of children.
-
-Defense: send Window error.  Specifying the root window as the parent will
-have to be allowed, though.
-
-Theft: create an InputOnly window or a window with background none on
-top of other clients' windows, select for keyboard/mouse input on that
-window, and steal the input.  The input can be resent using SendEvent
-or an input synthesis extension so that the snooped application
-continues to function, though this won't work convincingly with the
-background none case because the drawing will be clipped.
-
-Defense: send an error if a top-level InputOnly window is created (or
-reparented to the root).  Countermeasures for background none and
-SendEvent are discussed elsewhere.
-
-ISSUE: The Motif drag and drop protocol creates and maps such a window
-(at $-$100,$-$100, size 10x10) to ``cache frequently needed data on
-window properties to reduce roundtrip server requests.''  Proposed
-solution: we could only send an error if the window is visible, which
-would require checking in, MapWindow, ConfigureWindow, and
-ReparentWindow.
-
-Theft: resource ID guessing (parent, background-pixmap, border-pixmap,
-colormap, and cursor).
-
-Defense: send Window, Pixmap, Colormap, or Cursor error.
-
-Denial of service: create windows until the server runs out of memory.
-
-Defense: quotas.
-
-Also see section 3.
-
-
-\subsection{ChangeWindowAttributes}
-
-Alteration: change the attributes of another client's window.
-
-Theft: select for events on another client's window.
-
-Defense for both of the above: send Window error.
-
-ISSUE: The Motif drop protocol states that ``the initiator should
-select for DestroyNotify on the destination window such that it is
-aware of a potential receiver crash.''  This will be a problem if the
-initiator is an untrusted window and the destination is trusted.  Can
-the server, perhaps with the help of the security manager, recognize
-that a drop is in progress and allow the DestroyNotify event selection
-in this limited case?
-
-ISSUE: The Motif pre-register drag protocol probably requires the
-initiator to select for Enter/LeaveNotify on all top-level windows.
-Same problem as the previous issue.
-
-Theft: resource ID guessing (background-pixmap, border-pixmap,
-colormap, and cursor).
-
-Defense: send Pixmap, Colormap, or Cursor error.
-
-Also see section 3.
-
-
-\subsection{GetWindowAttributes}
-
-Theft: get the attributes of another client's window.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-
-\subsection{DestroyWindow, DestroySubwindows}
-
-Destruction: destroy another client's window.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-
-\subsection{ChangeSaveSet}
-
-Alteration: cause another client's windows to be reparented to the
-root when this client disconnects (only if the other client's windows
-are subwindows of this client's windows).
-
-Defense: process the request normally.  The trusted client gives away
-some of its protection by creating a subwindow of an untrusted window.
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-
-\subsection{MapWindow}
-
-Spoofing: map a window that is designed to resemble a window of
-another client.  Additional requests will probably be needed to
-complete the illusion.
-
-Defense:
-
-We consider spoofing to be a significant danger only if the user is
-convinced to interact with the spoof window.  The defense centers on
-providing enough information to enable the user to know where
-keyboard, mouse, and extension device input is going.  To accomplish
-this, the server will cooperate with the security manager, an external
-process.  The server will provide the following facilities to the
-security manager:
-
-1.  A way to create a single window that is unobscurable by any window
-of any other client, trusted or untrusted.  It needs to be
-unobscurable so that it is spoof-proof.
-
-ISSUE: is a weaker form of unobscurability better?  Should the window be
-obscurable by trusted windows, for example?
-
-ISSUE: does unobscurable mean that it is a child of the root that is
-always on top in the stacking order?
-
-2.  A way to determine if a given window ID belongs to an untrusted
-client.
-
-The security manager will need to select for the existing events
-FocusIn, FocusOut, EnterNotify, LeaveNotify, DeviceFocusIn, and
-DeviceFocusOut on all windows to track what window(s) the user's input
-is going to.  Using the above server facilities, it can reliably
-display the trusted/untrusted status of all clients currently
-receiving input.
-
-ISSUE: is it too much to ask the security manager to select for all
-these events on every window?  Do we need to provide new events that
-you select for *on the device* that tell where the device is focused?
-
-None of this should have any application impact.
-
-The unobscurable window may be tricky to implement.  There is already
-some machinery in the server to make an unobscurable window for the
-screen saver, which may help but may also get in the way now that we
-have to deal with two unobscurable windows.
-
-
-
-\subsection{Window Operations}
-
-Specifically, ReparentWindow, MapWindow, MapSubwindows, UnmapWindow,
-UnmapSubwindows, ConfigureWindow, and CirculateWindow.
-
-Alteration: manipulate another client's window.
-
-Theft: resource ID guessing (window, sibling).
-
-Defense for both of the above: send a Window error unless it is a root
-window, in which case we should send an Access error.
-
-
-
-\subsection{GetGeometry}
-
-Theft: get the geometry of another client's drawable.
-
-Theft: resource ID guessing (drawable).
-
-Defense for both of the above: send Drawable error.  However, root
-windows will be allowed.
-
-
-
-\subsection{QueryTree}
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-Theft: discover window IDs that belong to other clients.
-
-Defense: For the child windows, censor the reply by removing window
-IDs that belong to trusted clients.  Allow the root window to be
-returned.  For the parent window, if it belongs to a trusted client,
-return the closest ancestor window that belongs to an untrusted
-client, or if such a window does not exist, return the root window for
-the parent window.
-
-ISSUE: will some applications be confused if we filter out the window
-manager frame window(s), or other windows between the queried window
-and the root window?
-
-ISSUE: the Motif drag protocol (both preregister and dynamic) needs to
-be able to locate other top-level windows for potential drop sites.
-See also section 2.1.
-
-
-\subsection{InternAtom}
-
-Theft: discover atom values of atoms interned by other clients.
-This lets you determine if a specific set of atoms has been
-interned, which may lead to other inferences.
-
-Defense: This is a minor form of theft.  Blocking it will interfere
-with many types of inter-client communication.  We propose to do
-nothing about this threat.
-
-Denial of service: intern atoms until the server runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{GetAtomName}
-
-Theft: discover atom names of atoms interned by other clients.
-This lets you determine if a specific set of atoms has been
-interned, which may lead to other inferences.
-
-Defense: This is a minor form of theft.  We propose to do nothing
-about this threat.
-
-
-
-\subsection{ChangeProperty}
-
-Alteration: change a property on another client's window or one that
-was stored by another client.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-ISSUE: Selection transfer requires the selection owner to change a
-property on the requestor's window.  Does the security manager get us
-out of this?  Does the server notice the property name and window
-passed in ConvertSelection and temporarily allow that window property
-to be written?
-
-ISSUE: should certain root window properties be writable?
-
-Denial of service: store additional property data until the server
-runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{DeleteProperty}
-
-Destruction: delete a property stored by another client.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-
-
-\subsection{GetProperty}
-
-Theft: get a property stored by another client.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-ISSUE: should certain root window properties be readable?  Proposed
-answer: yes, some configurable list.  Do those properties need to be
-polyinstantiated?
-
-ISSUE: Motif drag and drop needs to be able to read the following
-properties: WM\_STATE to identify top-level windows, \_MOTIF\_DRAG\_WINDOW
-on the root window, \_MOTIF\_DRAG\_TARGETS on the window given in the
-\_MOTIF\_DRAG\_WINDOW property, and \_MOTIF\_DRAG\_RECEIVER\_INFO on windows
-with drop sites.  Additionally, some properties are needed that do not
-have fixed names.
-
-
-\subsection{RotateProperties}
-
-Alteration: rotate properties stored by another client.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-
-
-\subsection{ListProperties}
-
-Theft: list properties stored by another client.
-
-Theft: resource ID guessing (window).
-
-Defense for both of the above: send Window error.
-
-ISSUE: should certain root window properties be listable?
-
-
-
-\subsection{SetSelectionOwner}
-
-Theft: Steal ownership of a selection.
-
-Denial of service: do this repeatedly so that no other client can own
-the selection.
-
-Defense for both of the above: have a configurable list of selections
-that untrusted clients can own.  For other selections, treat this
-request as a no-op.
-
-ISSUE: how does the security manager get involved here?  Is it the one
-that has the configurable list of selections instead of the server?
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-
-
-\subsection{GetSelectionOwner}
-
-Theft: discover the ID of another client's window via the owner field
-of the reply.
-
-Defense: if the selection is on the configurable list mentioned above,
-return the root window ID, else return None.
-
-ISSUE: how does the security manager get involved here?
-
-
-
-\subsection{ConvertSelection}
-
-Theft: this initiates a selection transfer (see the ICCCM) which sends
-the selection contents from the selection owner, which may be another
-client, to the requesting client.
-
-Defense: since in many cases ConvertSelection is done in direct
-response to user interaction, it is probably best not to force it to
-fail, either silently or with an error.  The server should rely on the
-security manager to assist in handling the selection transfer.
-
-Theft: resource ID guessing (requestor).
-
-Defense: send Window error.
-
-
-
-\subsection{SendEvent}
-
-A client can use SendEvent to cause events of any type to be sent to
-windows of other clients.  Similarly, a client could SendEvent to one
-of its own windows with propogate set to True and arrange for the
-event to be propogated up to a window it does not own.  Clients can
-detect events generated by SendEvent, but we cannot assume that they
-will.
-
-Defense: ignore this request unless the event being sent is a
-ClientMessage event, which should be sent normally so that selection
-transfer, Motif drag and drop, and certain input methods have a chance
-at working.
-
-ISSUE: does allowing all ClientMessages open up too big a hole?
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-
-
-\subsection{Keyboard and Pointer Grabs}
-
-Specifically, GrabKeyboard, GrabPointer, GrabKey, and GrabButton.
-
-Denial of service/Theft: take over the keyboard and pointer.  This
-could be viewed as denial of service since it prevents other clients
-from getting keyboard or mouse input, or it could be viewed as theft
-since the user input may not have been intended for the grabbing
-client.
-
-Defense: provide a way to break grabs via some keystroke combination,
-and have a status area that shows which client is getting input.
-(See MapWindow.)
-
-Theft: resource ID guessing (grab-window, confine-to, cursor).
-
-Defense: send Window or Cursor error.
-
-
-
-\subsection{ChangeActivePointerGrab}
-
-Theft: resource ID guessing (cursor).
-
-Defense: send Cursor error.
-
-
-
-\subsection{GrabServer}
-
-Denial of service: a client can grab the server and not let go,
-locking out all other clients.
-
-Defense: provide a way to break grabs via some keystroke combination.
-
-
-
-\subsection{QueryPointer}
-
-Theft: A client can steal pointer motion and position, button input,
-modifier key state, and possibly a window of another client with this
-request.
-
-Defense: if the querying client doesn't have the pointer grabbed, and
-the pointer is not in one of its windows, the information can be
-zeroed.
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-
-
-\subsection{GetMotionEvents}
-
-Theft: steal pointer motion input that went to other clients.
-
-Defense: ideally, the server would return only pointer input that was
-not delivered to any trusted client.  The implementation effort to do
-that probably outweighs the marginal benefits.  Instead, we will
-always return an empty list of motion events to untrusted clients.
-
-Theft: resource ID guessing (window).
-
-Defense: send Window error.
-
-
-
-\subsection{TranslateCoordinates}
-
-Theft: discover information about other clients' windows: position,
-screen, and possibly the ID of one of their subwindows.
-
-Defense: send an error if src-window or dst-window do not belong
-to the requesting client.
-
-Theft: resource ID guessing (src-window, dst-window).
-
-Defense: send Window error.
-
-
-
-\subsection{WarpPointer}
-
-A client can cause pointer motion to occur in another client's window.
-
-Denial of service: repeated pointer warping prevents the user from
-using the mouse normally.
-
-Defense for both of the above: if the querying client doesn't have the
-pointer grabbed, and the pointer is not in one of its windows, treat
-the request as a no-op.
-
-Theft: resource ID guessing (src-window, dst-window).
-
-Defense: send Window error.
-
-
-
-\subsection{SetInputFocus}
-
-Theft: a client can use this request to make one of its own windows
-have the input focus (keyboard focus).  The user may be unaware that
-keystrokes are now going to a different window.
-
-Denial of service: repeatedly setting input focus prevents normal use
-of the keyboard.
-
-Defense for both of the above: only allow untrusted clients to
-SetInputFocus if input focus is currently held by another untrusted
-client.
-
-ISSUE: this will break clients using the Globally Active Input model
-described in section 4.1.7 of the ICCCM.
-
-Theft: resource ID guessing (focus).
-
-Defense: send Window error.
-
-
-
-\subsection{GetInputFocus}
-
-Theft: the reply may contain the ID of another client's window.
-
-Defense: return a focus window of None if a trusted client currently
-has the input focus.
-
-
-
-\subsection{QueryKeymap}
-
-Theft: poll the keyboard with this to see which keys are being pressed.
-
-Defense: zero the returned bit vector if a trusted client currently
-has the input focus.
-
-
-
-\subsection{Font Requests}
-
-Specifically, OpenFont, QueryFont, ListFonts, ListFontsWithInfo, and
-QueryTextExtents.
-
-Theft: discover font name, glyph, and metric information about fonts
-that were provided by another client (by setting the font path).
-Whether it is theft to retrieve information about fonts from the
-server's initial font path depends on whether or not you believe those
-fonts, by their existence in the initial font path, are intended to be
-globally accessible by all clients.
-
-Defense:
-
-Maintain two separate font paths, one for trusted clients and one for
-untrusted clients.  They are both initialized to the default font path
-at server reset.  Subsequently, changes to one do not affect the
-other.  Since untrusted clients will not see font path elements added
-by trusted clients, they will not be able to access any fonts provided
-by those font path elements.
-
-Theft: resource ID guessing (font) (QueryFont and QueryTextExtents only).
-
-Defense: send Font error.
-
-Denial of service: open fonts until the server runs out of memory
-(OpenFont only).
-
-Defense: quotas.
-
-
-\subsection{CloseFont}
-
-Destruction: close another client's font.
-
-Defense: send Font error.
-
-
-
-\subsection{SetFontPath}
-
-Denial of service: change the font path so that other clients cannot
-find their fonts.
-
-Alteration: change the font path so that other clients get different
-fonts than they expected.
-
-Defense for both of the above: separate font paths for trusted and
-untrusted clients, as described in the Font Requests section.
-
-ISSUE: the printing project considered per-client font paths and
-concluded that it was very difficult to do.  We should look at this
-aspect of the print server design to see if we can reuse the same
-scheme.  We should also try to reconstruct what was so difficult about
-this; it doesn't seem that hard on the surface.
-
-
-
-\subsection{GetFontPath}
-
-Theft: retrieve font path elements that were set by other clients.
-
-Use knowledge from font path elements to mount other attacks,
-e.g., attack a font server found in the font path.
-
-Defense for both of the above: separate font paths for trusted and
-untrusted clients, as described in the Font Requests section.
-
-
-
-\subsection{CreatePixmap}
-
-Theft: resource ID guessing (drawable).
-
-Defense: send Drawable error.
-
-Denial of service: create pixmaps until the server runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{FreePixmap}
-
-Destruction: destroy another client's pixmap.
-
-Defense: send Pixmap error.
-
-
-\subsection{CreateGC}
-
-Theft: resource ID guessing (drawable, tile, stipple, font, clip-mask).
-
-Defense: send Drawable, Pixmap, or Font error.
-
-Denial of service: create GCs until the server runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{CopyGC}
-
-Theft: copy GC values of another client's GC.
-
-Alteration: copy GC values to another client's GC.
-
-Defense for both of the above: send GC error.
-
-
-
-\subsection{ChangeGC, SetDashes, SetClipRectangles}
-
-Alteration: change values of another client's GC.
-
-Theft: resource ID guessing (gc, tile, stipple, font, clip-mask)
-(last four for ChangeGC only).
-
-Defense for both of the above: send GC error.
-
-
-
-\subsection{FreeGC}
-
-Destruction: destroy another client's GC.
-
-Defense: send GC error.
-
-
-
-\subsection{Drawing Requests}
-
-Specifically, ClearArea, CopyArea, CopyPlane, PolyPoint,
-PolyLine, PolySegment, PolyRectangle, PolyArc, FillPoly,
-PolyFillRectangle, PolyFillArc, PutImage, PolyText8, PolyText16,
-ImageText8, and ImageText16.
-
-Alteration: draw to another client's drawable.
-
-Theft: resource ID guessing:
-	ClearArea - window;
-	CopyArea, CopyPlane - src-drawable, dst-drawable, gc;
-	all others - drawable, gc.
-
-Defense for both of the above: send appropriate error.
-
-ISSUE: The Motif preregister drag protocol requires clients to draw
-into windows of other clients for drag-over/under effects.
-
-Spoofing: draw to a window to make it resemble a window of
-another client.
-
-Defense: see MapWindow.
-
-
-
-\subsection{GetImage}
-
-Theft: get the image of another client's drawable.
-
-Theft: resource ID guessing (drawable).
-
-Defense: send Drawable error.
-
-Theft: get the image of your own window, which may contain pieces of
-other overlapping windows.
-
-Defense: censor returned images by blotting out areas that contain
-data from trusted windows.
-
-
-
-\subsection{CreateColormap}
-
-Theft: resource ID guessing (window).
-
-Defense: send Colormap error.
-
-Denial of service: create colormaps with this request until the server
-runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{FreeColormap}
-
-Destruction: destroy another client's colormap.
-
-Defense: send Colormap error.
-
-
-
-\subsection{CopyColormapAndFree}
-
-Theft: resource ID guessing (src-map).
-
-Defense: send Colormap error.  However, default colormaps will be
-allowed.
-
-ISSUE: must untrusted applications be allowed to use standard colormaps?
-(Same issue for ListInstalledColormaps, Color Allocation Requests,
-FreeColors, StoreColors, StoreNamedColor, QueryColors, and LookupColor.)
-
-Denial of service: create colormaps with this request until the server
-runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{InstallColormap, UninstallColormap}
-
-Theft: resource ID guessing.
-
-Defense: send Colormap error.
-
-Denial of service: (un)install any colormap, potentially preventing
-windows from displaying correct colors.
-
-Defense: treat this request as a no-op.  Section 4.1.8 of the ICCCM
-states that (un)installing colormaps is the responsibility of the window
-manager alone.
-
-ISSUE: the ICCCM also allows clients to do colormap installs if the
-client has the pointer grabbed.  Do we need to allow that too?
-
-
-
-\subsection{ListInstalledColormaps}
-
-Theft: resource ID guessing (window).
-
-Defense: send Colormap error.
-
-Theft: discover the resource ID of another client's colormap
-from the reply.
-
-Defense: remove the returned colormap IDs; only let through default
-colormaps and colormaps of untrusted clients.
-
-
-
-\subsection{Color Allocation Requests}
-
-Specifically, AllocColor, AllocNamedColor, AllocColorCells, and
-AllocColorPlanes.
-
-Alteration/Denial of service: allocate colors in another client's
-colormap.  It is denial of service if the owning client's color
-allocations fail because there are no cells available.  Otherwise it
-is just alteration.
-
-Theft: resource ID guessing (cmap).
-
-Defense for both of the above: send Colormap error.  However, default
-colormaps will be allowed.
-
-
-
-\subsection{FreeColors}
-
-Theft: resource ID guessing (cmap).
-
-Defense: send Colormap error.  However, default colormaps will be
-allowed.
-
-
-
-\subsection{StoreColors, StoreNamedColor}
-
-Alteration: change the colors in another client's colormap.
-
-Theft: resource ID guessing (cmap).
-
-Defense for both of the above: send Colormap error.  However, default
-colormaps will be allowed.
-
-
-
-\subsection{QueryColors, LookupColor}
-
-Theft: retrieve information about the colors in another client's
-colormap.
-
-Theft: resource ID guessing (cmap).
-
-Defense for both of the above: send Colormap error.  However, default
-colormaps will be allowed.
-
-
-
-\subsection{CreateCursor, CreateGlyphCursor}
-
-Theft: resource ID guessing (source, mask or source-font, mask-font).
-
-Defense: send Pixmap or Font error.  However, the default font will be
-allowed.
-
-Denial of service: create cursors until the server runs out of memory.
-
-Defense: quotas.
-
-
-
-\subsection{FreeCursor}
-
-Destruction: free another client's cursor.
-
-Defense: send Cursor error.
-
-
-
-\subsection{RecolorCursor}
-
-Alteration: recolor another client's cursor.
-
-Theft: resource ID guessing (cursor).
-
-Defense for both of the above: send Cursor error.
-
-
-
-\subsection{QueryBestSize}
-
-Theft: resource ID guessing (drawable).
-
-Defense: send Drawable error.
-
-
-
-\subsection{ListExtensions, QueryExtension}
-
-Determine the extensions supported by the server, and use the list to
-choose extension-specific attacks to attempt.
-
-Defense: extensions will have a way to tell the server whether it is
-safe for untrusted clients to use them.  These requests will only
-return information about extensions that claim to be safe.
-
-
-
-\subsection{Keyboard configuration requests}
-
-Specifically, ChangeKeyboardControl, ChangeKeyboardMapping,
-and SetModifierMapping.
-
-Alteration: change the keyboard parameters that were established by
-another client.
-
-Denial of service: with ChangeKeyboardControl, disable auto-repeat,
-key click, or the bell.  With ChangeKeyboardMapping or
-SetModifierMapping, change the key mappings so that the keyboard is
-difficult or impossible to use.
-
-Defense for both of the above: treat these requests as a no-op.
-
-
-
-\subsection{Keyboard query requests}
-
-Specifically, GetKeyboardControl, GetKeyboardMapping, and
-GetModifierMapping.
-
-Theft: get keyboard information that was established by another
-client.
-
-Defense: This is a minor form of theft.  We propose to do nothing
-about this threat.
-
-
-
-\subsection{ChangePointerControl, SetPointerMapping}
-
-Alteration: change the pointer parameters that were established by
-another client.
-
-Denial of service: set the pointer parameters so that the pointer is
-difficult or impossible to use.
-
-Defense for both of the above: treat these requests as a no-op.
-
-
-
-\subsection{GetPointerControl, GetPointerMapping}
-
-Theft: get pointer parameters that were established by another client.
-
-Defense: This is a minor form of theft.  We propose to do nothing
-about this threat.
-
-
-
-\subsection{SetScreenSaver}
-
-Alteration: change the screen saver parameters that were established
-by another client.
-
-Denial of service: set the screen saver parameters so that the screen
-saver is always on or always off.
-
-Defense for both of the above: treat these requests as a no-op.
-
-
-
-\subsection{GetScreenSaver}
-
-Theft: get screen saver parameters that were established by another
-client.
-
-Defense: This is a minor form of theft.  We propose to do nothing
-about this threat.
-
-
-
-\subsection{ForceScreenSaver}
-
-Denial of service: repeatedly activate the screen saver so that the
-user cannot see the screen as it would look when the screen saver
-is off.
-
-Denial of service: repeatedly reset the screen saver, preventing it
-from activating.
-
-Defense for both of the above: treat these requests as a no-op.
-
-
-
-\subsection{ChangeHost}
-
-Most servers already have some restrictions on which clients can use
-this request, so whether the following list applies is implementation
-dependent.
-
-Denial of service: remove a host from the list, preventing clients
-from connecting from that host.
-
-Add a host to the list.  Clients from that host may then launch
-other attacks of any type.
-
-Defense for both of the above: return Access error.
-
-
-\subsection{ListHosts}
-
-Theft: steal host identities and possibly even user identities that
-are allowed to connect.
-
-Launch attacks of any type against the stolen host/user identities.
-
-Defense for both of the above: return only untrusted hosts.
-
-
-
-\subsection{SetAccessControl}
-
-Most servers already have some restrictions on which clients can use
-this request, so whether the following list applies is implementation
-dependent.
-
-Alteration: change the access control value established by some other
-client.
-
-Disable access control, allowing clients to connect who would normally
-not be able to connect.  Those clients may then launch other attacks
-of any type.
-
-Defense for both of the above: return Access error.
-
-
-
-\subsection{SetCloseDownMode}
-
-Denial of service: set the close-down mode to RetainPermanent or
-RetainTemporary, then disconnect.  The server cannot reuse the
-resource-id-base of the disconnected client, or the memory used by the
-retained resources, unless another client issues an appropriate
-KillClient to cancel the retainment.  The server has a limited number
-of resource-id-bases, and when they are exhausted, it will be unable
-to accept new client connections.
-
-Defense: treat this request as a no-op.
-
-
-\subsection{KillClient}
-
-Destruction/Denial of service: kill another currently connected
-client.
-
-Destruction: kill a client that has terminated with close-down mode
-of RetainTemporary or RetainPermanent, destroying all its retained
-resources.
-
-Destruction: specify AllTemporary as the resource, destroying all
-resources of clients that have terminated with close-down mode
-RetainTemporary.
-
-Defense for all of the above: return Value error.
-
-
-
-\subsection{Clean Requests}
-
-Other than denial of service caused by flooding, these requests have
-no known security concerns: AllowEvents, UngrabPointer, UngrabButton,
-UngrabKeyboard, UngrabKey, UngrabServer, NoOperation, and Bell.
-
-
-
-\section{Events}
-
-The only threat posed by events is theft.  Selecting for events on
-another client's resources is always theft.  We restrict further
-analysis by assuming that the client only selects for events on its
-own resources, then asking whether the events provide information
-about other clients.
-
-
-
-\subsection{KeymapNotify}
-
-Theft: the state of the keyboard can be seen when the client does not
-have the input focus.  This is possible because a KeymapNotify is
-sent to a window after every EnterNotify even if the window does not
-have input focus.
-
-Defense: zero the returned bit vector if a trusted client currently
-has the input focus.
-
-
-
-\subsection{Expose}
-
-Theft: discover where other clients' windows overlap your own.  For
-instance, map a full-screen window, lower it, then raise it.  The
-resulting exposes tell you where other windows are.
-
-Defense: about the only thing you could do here is force backing store
-to be used on untrusted windows, but that would probably use too much
-server memory.  We propose to do nothing about this threat.
-
-
-
-\subsection{GraphicsExposure}
-
-Theft: discover where other clients' windows overlap your own.
-For instance, use CopyArea to copy the entire window's area exactly
-on top of itself.  The resulting GraphicsExposures tell you where
-the window was obscured.
-
-Defense: see Expose above.  We propose to do nothing about this
-threat.
-
-
-\subsection{VisibilityNotify}
-
-Theft: this event provides crude positional information about other
-clients, though the receiver cannot tell which other clients.
-
-Defense: The information content of this event is very low.  We
-propose to do nothing about this threat.
-
-
-
-\subsection{ReparentNotify}
-
-Theft: the parent window may belong to some other client (probably
-the window manager).
-
-Defense: If the parent window belongs to a trusted client, return the
-closest ancestor window that belongs to an untrusted client, or if
-such a window does not exist, return the root window for the parent
-window.
-
-ISSUE: what is the application impact?
-
-
-\subsection{ConfigureNotify}
-
-Theft: the above-sibling window may belong to some other client.
-
-Defense: return None for the above-sibling window if it belongs to a
-trusted client.
-
-ISSUE: what is the application impact?
-
-
-\subsection{ConfigureRequest}
-
-Theft: the sibling window may belong to some other client.
-
-Defense: return None for the sibling window if it belongs to a trusted
-client.
-
-ISSUE: what is the application impact?
-
-
-\subsection{SelectionClear}
-
-Theft: the owner window may belong to some other client.
-
-Defense: return None for the owner window if it belongs to a trusted
-client.
-
-
-
-\subsection{SelectionRequest}
-
-Theft: the requestor window may belong to some other client.
-
-Defense: Blocking this event or censoring the window would prevent
-selection transfers from untrusted clients to trusted clients from
-working.  We propose to do nothing in the server about this threat.
-The security manager may reduce the exposure of trusted window IDs
-by becoming the owner of all selections.
-
-
-
-\subsection{MappingNotify}
-
-Theft: discover keyboard, pointer, or modifier mapping information
-set by another client.
-
-Defense: Any tampering with this event will cause clients to have an
-inconsistent view of the keyboard or pointer button configuration,
-which is likely to confuse the user.  We propose to do nothing about
-this threat.
-
-
-\section{Errors}
-
-There appear to be no threats related to procotol errors.
-
-
-
-\section{Future Work}
-
-The next steps are resolve the items marked ISSUE and to decide if the
-defenses proposed are reasonable.  Discussion on the security@x.org
-mailing list, prototyping, and/or starting the implementation should
-help answer these questions.
-
-
-
-\section{References}
-
-Bellcore, ``Framework Generic Requirements for X Window System Security,''
-Technical Advisory FA-STS-001324, Issue 1, August 1992.
-
-Dardailler, Daniel, ``Motif Drag And Drop Protocol,'' unpublished
-design notes.
-
-Kahn, Brian L., ``Safe Use of X WINDOW SYSTEM protocol Across a
-Firewall'', unpublished draft, The MITRE Corporation, 1995.
-
-Rosenthal, David S. H., ``LINX - a Less INsecure X server,'' Sun Microsystems,
-29th April 1989.
-
-Rosenthal, David and Marks, Stuart W., ``Inter-Client Communication
-Conventions Manual Version 2.0,''
-{\tt ftp://ftp.x.org/pub/R6.1/xc/doc/hardcopy/ICCCM/icccm.PS.Z}
-
-Scheifler, Robert W., ``X Window System Protocol,''
-{\tt ftp://ftp.x.org/pub/R6.1/xc/doc/hardcopy/XProtocol/proto.PS.Z}
-
-Treese, G. Winfield and Wolman, Alec, ``X Through the Firewall, and
-Other Application Relays,'' Digital Equipment Corporation Cambridge
-Research Lab, Technical Report Series, CRL 93/10, May 3, 1993.
-
-\end{document}
diff --git a/specs/Xserver/analysis.xml b/specs/Xserver/analysis.xml
new file mode 100644
index 0000000..da6a48c
--- /dev/null
+++ b/specs/Xserver/analysis.xml
@@ -0,0 +1,2217 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
+
+
+<!-- by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)
+xhtml,docbook,html,refcaption
+-->
+
+<book id="analysis">
+
+<bookinfo>
+   <title>Analysis of the X Protocol for Security Concerns</title>
+   <subtitle>Draft Version 2</subtitle>
+   <date>May 10, 1996</date>
+   <authorgroup>
+      <author>
+         <firstname>David</firstname><surname>Wiggins</surname>
+      </author>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1996</year><holder>X Consortium</holder></copyright>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+
+   <othercredit>
+      <firstname>Matt</firstname><surname>Dew</surname>
+      <contrib>conversion from tex to docbook</contrib>
+   </othercredit>
+
+<legalnotice>
+<para>THE SOFTWARE IS PROVIDED &ldquo;AS IS&rdquo;, 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.</para>
+
+<para>Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.</para>
+
+<para>X Window System is a trademark of The Open Group.</para>
+</legalnotice>
+<abstract>
+<para>
+This paper attempts to list all instances of certain types of security
+problems in the X Protocol. Issues with authorization are not addressed.
+We assume that a malicious client has already succeeded in connecting,
+and try to assess what harm it can then do. We propose modifications to
+the semantics of the X Protocol to reduce these risks.
+</para>
+</abstract>
+</bookinfo>
+
+<chapter id="definition_of_threats">
+<title>Definition of Threats</title>
+
+<para>
+We analyze the X protocol for the following threats.
+</para>
+
+<variablelist>
+  <varlistentry>
+    <term>Theft</term>
+    <listitem>
+      <para>
+occurs when a client gains access to information owned by another client
+without  explicit  permission  from  that  other  client.  For  this  analysis,
+we take a broad view of ownership: any information that exists in the
+server due to the actions of a client is considered owned by that client.
+Furthermore, the client that has input focus owns keyboard events, and the
+client that owns the window that the pointer is in owns mouse events. This
+view may reveal certain instances of "theft" that we don't care to stop,
+but we think it is better to identify all potential candidates up front and
+cull the list later than to do a partial analysis now and plan on reanalyzing
+for remaining holes later.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Denial of service</term>
+    <listitem>
+      <para>
+occurs when a client causes another client or the user to lose the ability
+to perform some operation.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Spoofing</term>
+    <listitem>
+      <para>
+occurs when a client attempts to mimic another client with the hope that
+the user will interact with it as if it really were the mimicked client. A
+wide variety of requests may be used in a spoofing attack; we will only
+point out a few likely candidates.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Destruction</term>
+    <listitem>
+      <para>
+occurs when a client causes another client to lose information in a way
+that the client or user is likely to notice. (This does not count expected
+forms of destruction, e.g., exposures.)
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Alteration</term>
+    <listitem>
+      <para>
+occurs when a client causes another client to lose information in a way
+that the client or user is unlikely to notice. e.g., changing one pixel in a
+drawable.
+      </para>
+    </listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The line between alteration and destruction is subjective. Security
+literature does often distinguish between them, though not always
+explicitly. Alteration is often considered more insidious because
+its effects may not be realized until long after it has occurred. In
+the intervening time, each time the altered data is used, it can cause
+more damage.
+</para>
+</chapter>
+
+<chapter id="general_security_concerns_and_remedies">
+<title>General security concerns and remedies</title>
+
+<para>
+The following sections discuss security problems intrinsic to the X
+Protocol. A statement of each problem is usually followed by potential
+remedies. A few words here about possible remedies will help frame the
+specific ones described below.
+</para>
+
+<para>
+If a client attempts a threatening operation, the server may take one of
+the following actions, listed roughly in order of severity:
+</para>
+
+<orderedlist>
+  <listitem>
+    <para>
+Execute the request normally. This is the right choice when we decide that a
+particlar threat is not serious enough to worry about.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Execute the request in some modified form, e.g., substitute different
+values for some of the request fields, or edit the reply.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Arrange to ask the user what to do, given some subset of the other choices
+in this list. This must be used sparingly because of the performance impact.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Treat the request as a no-op. If the client will probably not notice, or
+if it seems likely that the intent was benign, this is a good choice.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Send a protocol error to the client. If the client will be confused enough
+by the other options that it will probably crash or become useless anyway,
+or if it seems likely that the intent was malicious, this is a good choice.
+    </para>
+    <para>
+Kill the client. This might be the right action if there is no doubt
+that the client is hostile.
+    </para>
+  </listitem>
+</orderedlist>
+
+<para>
+In most cases we present the one option that seems most appropriate to
+counter the threat, taking into account the seriousness of the threat, the
+implementation difficulty, and the impact on applications. Our initial bias
+is to err on the side of stronger security, with the accompanying tighter
+restrictions. As we uncover important operations and applications that the new
+restrictions interfere with, we can apply selective loosening to allow
+the desired functionality.
+</para>
+
+<para>
+In some cases we will suggest returning an Access error where the X protocol
+does not explicitly allow one. These new Access errors arise when a client
+can only perform a (non-empty) subset of the defined operations on a
+resource. The disallowed operations cause Access errors. The resiource at
+issue is usually a root window.
+</para>
+
+<sect1 id="access_to_server_resources">
+<title>Access to Server Resources</title>
+<para>
+The X protocol allows clients to manipulate resources (objects) belonging to
+other clients or to the server. Any request that specifies a resource ID is
+vulnerable to some of the above threats. Such requests also provide a way for a
+client to guess resource IDs of other clients. A client can make educated
+guesses for possible resource IDs, and if the request succeeds, it knows it has
+determined a valid resource ID. We call this "resource ID guessing" in the list
+below.
+</para>
+
+<para>
+One likely defense against these problems is to have the server send an
+appropriate protocol error to deny the existence of any resource specified
+by a client that doesn't belong to that client. A variation on this policy
+lets cooperating groups of clients access each other's resources, but not
+those of other groups. The Broadway project will initially use a less general
+form of this idea by having two groups, trusted and untrusted. Trusted
+clients can do everything that X clients can do today. They will be protected
+from untrusted clients in ways described below. Untrusted clients will
+not be protected from each other. Though this will be the initial design,
+we need to make sure there is a growth path to multiple (more than two)
+groups.
+</para>
+
+<para>
+Most of the time, applications never access server resources that aren't
+their own, so the impact of disallowing such accesses should be minimal.
+There are a few notable exceptions, most of which will be discussed under
+the relevant protocol requests. They are: ICCCM selection transfer, Motif
+drag and drop, and server-global resources like the root window and default
+colormap. Another major exception is the window manager, which routinely
+manipulates windows of other applications. The solution for window managers
+is to always run them as trusted applications.
+</para>
+
+<para>
+The implementation difficulty of limiting access to resources should not
+be large. All resource accesses eventually funnel down to one of two
+functions in &lt;dix/resource.c&gt;:
+<function>LookupIDByType</function> and
+<function>LookupIDByClass</function>. A few lines of checking at
+the top of these functions will form the heart of this defense. There is a
+small problem because these functions are not told which client is doing the
+lookup, but that can be solved either by adding a client parameter (probably
+as a new function to preserve compatibility), or by using the server global
+requestingClient.
+</para>
+
+<note>
+<para>
+ISSUE: are we really going to be able to get away with hiding trusted
+resources, or will things like Motif drag and drop force us to expose
+them? (Either way, the operations that untrusted clients can do to
+trusted resources will have to be limited.) Is there something in Xt
+or the ICCCM that breaks if you hide resources?
+</para>
+</note>
+
+</sect1>
+
+<sect1 id="denial_of_service">
+<title>Denial of Service</title>
+
+<sect2 id="memory_exhaustion">
+<title>Memory Exhaustion</title>
+
+<para>
+Any request that causes the server to consume resources (particularly
+memory) can be used in a denial of service attack. A client can use such
+requests repeatedly until the server runs out of memory. When that
+happens, the server will either crash or be forced to send Alloc errors.
+The most obvious candidates are resource creation requests,
+e.g., CreatePixmap, but in reality a large percentage of requests cause
+memory allocation, if only temporarily, depending on the server
+implementation. For this reason, the list of requests subject to this
+form of denial of service will be necessarily incomplete.
+</para>
+
+<para>
+To address this form of denial of service, the server could set
+per-client quotas on memory consumption. When the limit is surpassed,
+the server could return Alloc errors. The application impact is minimal
+as long as the application stays within quota. The implementation difficulty
+is another story.
+</para>
+
+<para>
+Conceptually, it seems easy: simply have a way to set the limit, and on
+every memory (de)allocation operation, update the client's current usage,
+and return an error if the client is over the limit. The first problem
+is something we've already touched on: the allocator functions aren't told
+which client the allocation belongs to. Unlike resource lookups, allocations
+are done in too many places to consider a new interface that passes the
+client, so using the global requestingClient is practically mandatory.
+</para>
+
+<para>
+The problems run deeper. The logical thing for the allocator to do if the
+client is over its limit is to return NULL, indicating allocation failure.
+Unfortunately, there are many places in the server that will react badly
+if this happens. Most of these places, but not all, are "protected" by
+setting the global variable Must_have_memory to True around the delicate
+code. We could help the problem by skipping the limit check if
+Must_have_memory is True. The best solution would be to bullet-proof the
+server against allocation failures, but that is beyond the scope of Broadway.
+Another consideration is that the additional checking may have a measurable
+performance impact, since the server does frequent allocations.
+</para>
+
+<para>
+A third problem is that there is no portable way to determine the size of
+a chunk of allocated memory given just a pointer to the chunk, and that's
+all you have inside <function>Xrealloc</function> and
+<function>Xfree</function>. The server could compensate by recording the
+sizes itself somewhere, but that would be wasteful of memory, since the
+malloc implementation also must be recording block sizes. On top of that, the
+redundant bookkeeping would hurt performance. One solution is to use a custom
+malloc that has the needed support, but that too seems beyond the scope of
+Broadway.
+</para>
+
+<para>
+Considering all of this, we think it is advisable to defer solving the memory
+exhaustion problem to a future release. Keep this in mind when you see quotas
+mentioned as a defense in the list below.
+</para>
+
+</sect2>
+
+
+<sect2 id="cpu_monopolization">
+<title>CPU Monopolization</title>
+
+<para>
+Another general way that a client can cause denial of service is to flood
+the server with requests. The server will spend a large percentage of its
+time servicing those requests, possibly starving other clients and certainly
+hurting performance. Every request can be used for flooding, so we will
+not bother to list flooding on every request. A variation on this attack is
+to flood the server with new connection attempts.
+</para>
+
+<para>
+To reduce the effectiveness of flooding, the server could use a different
+scheduling algorithm that throttles clients that are monopolizing the
+server, or it could simply favor trusted clients over untrusted ones.
+Applications cannot depend on a particular scheduling algorithm anyway,
+so changing it should not affect them. The Synchronization extension
+specifies a way to set client priorities, and a simple priority scheduler
+already exists in the server to support it, so this should be simple to add.
+</para>
+
+</sect2>
+</sect1>
+</chapter>
+
+
+<chapter id="security_concerns_with_specific_window_attributes">
+<title>Security concerns with specific window attributes</title>
+
+<sect1 id="background_pixmap">
+<title>Background-pixmap</title>
+<para>
+Clients can use windows with the background-pixmap attribute set to None
+(hereafter "background none windows") to obtain images of other windows. A
+background none window never paints its own background, so whatever happened
+to be on the screen when the window was mapped can be read from the
+background none window with GetImage. This may well contain data from other
+windows. The CreateWindow and ChangeWindowAttributes requests can set the
+background-pixmap attribute set to None, and many window operations can cause
+data from other windows to be left in a background none window, including
+<function>ReparentWindow</function>,
+<function>MapWindow</function>,
+<function>MapSubwindows</function>,
+<function>ConfigureWindow</function>, and
+<function>CirculateWindow</function>.
+</para>
+
+<para>
+Background none windows can also be used to cause apparent alteration.
+A client can create a window with background none and draw to it. The drawing
+will appear to the user to be in the windows below the background none window.
+</para>
+
+<para>
+To remedy these problems, the server could substitute a well-defined
+background when a client specifies None. Ideally the substituted background
+would look different enough from other windows that the user wouldn't be
+confused. A tile depicting some appropriate international symbol might be
+reasonable. We believe that there are few applications that actually rely on
+background none semantics, and those that do will be easy for the user to
+identify because of the distinctive tile. Implementation should not be a
+problem either. Luckily, the window background cannot be retrieved through
+the X protocol, so we won't have to maintain any illusions about its value.
+</para>
+
+<note>
+<para>
+ISSUE: Some vendors have extensions to let you query the window background. Do
+we need to accomodate that?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: Will this lead to unacceptable application breakage? Could the server be
+smarter, only painting with the well-defined background when the window actually
+contains bits from trusted windows?
+</para>
+</note>
+
+</sect1>
+
+<sect1 id="parentrelative_and_copyfromparent">
+<title>ParentRelative and CopyFromParent</title>
+
+<para>
+Several window attributes can take on special values that cause them to
+reference (ParentRelative) or copy (CopyFromParent) the same attribute from
+the window's parent. This fits our definition of theft. The window
+attributes are class, background-pixmap, border-pixmap, and colormap. All
+of these can be set with <function>CreateWindow</function>; all but class
+can be set with <function>ChangeWindowAttributes</function>.
+</para>
+
+<para>
+These forms of theft aren't particularly serious, so sending an error
+doesn't seem appropriate. Substitution of different attribute values seems
+to be the only reasonable option, and even that is likely to cause trouble
+for clients. Untrusted clients are already going to be prevented from
+creating windows that are children of trusted clients (see CreateWindow
+below). We recommend that nothing more be done to counter this threat.
+</para>
+
+</sect1>
+
+<sect1 id="override_redirect">
+<title>Override-redirect</title>
+<para>
+Windows with the override-redirect bit set to True are generally ignored by
+the window manager. A client can map an override-redirect window that covers
+most or all of the screen, causing denial of service since other applications
+won't be visible.
+</para>
+
+<para>
+To prevent this, the server could prevent more than a certain percentage
+(configurable) the of screen area from being covered by override-redirect
+windows of untrusted clients.
+</para>
+
+<para>
+Override-redirect windows also make some spoofing attacks easier since the
+client can more carefully control the presentation of the window to mimic
+another client.  Defenses against spoofing will be given under
+<link linkend="mapwindow">
+<xref linkend="mapwindow"></xref></link>
+.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="security_concerns_with_specific_requests">
+<title>Security concerns with specific requests</title>
+
+<para>
+To reduce the space needed to discuss 120 requests, most of the following
+sections use a stylized format. A threat is given, followed by an
+imperative statement. The implied subject is an untrusted client, and the
+object is usually a trusted client.  Following that, another statement
+starting with "Defense:" recommends a countermeasure for the preceding
+threat(s).
+</para>
+
+<para>
+Resources owned by the server, such as the root window and the default
+colormap, are considered to be owned by a trusted client.
+</para>
+
+<sect1 id="create_window">
+<title>CreateWindow</title>
+
+<para>
+Alteration: create a window as a child of another client's window, altering
+its list of children.
+</para>
+
+<para>
+Defense: send Window error. Specifying the root window as the parent will
+have to be allowed, though.
+</para>
+
+<para>
+Theft: create an InputOnly window or a window with background none on top
+of other clients' windows, select for keyboard/mouse input on that window,
+and steal the input. The input can be resent using SendEvent or an input
+synthesis extension so that the snooped application continues to function,
+though this won't work convincingly with the background none case because the
+drawing will be clipped.
+</para>
+
+<para>
+Defense: send an error if a top-level InputOnly window is created
+(or reparented to the root). Countermeasures for background none and
+SendEvent are discussed elsewhere.
+</para>
+
+<note>
+<para>
+ISSUE: The Motif drag and drop protocol creates and maps such a window (at
+-100, -100, size 10x10) to "cache frequently needed data on window properties
+to reduce roundtrip server requests." Proposed solution: we could only send an
+error if the window is visible, which would require checking in, MapWindow,
+ConfigureWindow, and ReparentWindow.
+</para>
+</note>
+
+<para>
+Theft: resource ID guessing (parent, background-pixmap, border-pixmap, colormap,
+and cursor).
+</para>
+<para>
+Defense: send Window, Pixmap, Colormap, or Cursor error.
+</para>
+<para>
+Denial of service: create windows until the server runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+<para>
+Also
+<link linkend="security_concerns_with_specific_window_attributes">
+<xref linkend="security_concerns_with_specific_window_attributes"></xref></link>
+</para>
+</sect1>
+
+
+<sect1 id="changewindowattributes">
+<title>ChangeWindowAttributes</title>
+
+<para>
+Alteration: change the attributes of another client's window.
+</para>
+<para>
+Theft: select for events on another client's window.
+</para>
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+<note>
+<para>
+ISSUE: The Motif drop protocol states that "the initiator should select for
+DestroyNotify on the destination window such that it is aware of a potential
+receiver crash." This will be a problem if the initiator is an untrusted
+window and the destination is trusted. Can the server, perhaps with the help
+of the security manager, recognize that a drop is in progress and allow the
+DestroyNotify event selection in this limited case?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: The Motif pre-register drag protocol probably requires the initiator
+to select for Enter/LeaveNotify on all top-level windows. Same problem as
+the previous issue.
+</para>
+</note>
+
+<para>
+Theft: resource ID guessing (background-pixmap, border-pixmap, colormap, and
+cursor).
+</para>
+
+<para>
+Defense: send Pixmap, Colormap, or Cursor error.
+</para>
+<para>
+Also
+<link linkend="security_concerns_with_specific_window_attributes">
+<xref linkend="security_concerns_with_specific_window_attributes"></xref></link>
+</para>
+
+</sect1>
+
+<sect1 id="getwindowattributes">
+<title>GetWindowAttributes</title>
+
+<para>
+Theft: get the attributes of another client's window.
+</para>
+<para>
+Theft: resource ID guessing (window).
+</para>
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+</sect1>
+
+<sect1 id="destroywindow__destroysubwindows">
+<title>DestroyWindow, DestroySubwindows</title>
+
+<para>
+Destruction: destroy another client's window.
+</para>
+<para>
+Theft: resource ID guessing (window).
+</para>
+<para>
+Defense for both of the above: send Window error.
+</para>
+</sect1>
+
+<sect1 id="changesaveset">
+<title>ChangeSaveSet</title>
+
+<para>
+Alteration: cause another client's windows to be reparented to the root when
+this client disconnects (only if the other client's windows are subwindows of
+this client's windows).
+</para>
+
+<para>
+Defense: process the request normally. The trusted client gives away some of
+its protection by creating a subwindow of an untrusted window.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+
+<sect1 id="mapwindow">
+<title>MapWindow</title>
+
+<para>
+Spoofing: map a window that is designed to resemble a window of another client.
+Additional requests will probably be needed to complete the illusion.
+</para>
+
+<para>
+Defense:
+</para>
+
+<para>
+We consider spoofing to be a significant danger only if the user is convinced
+to interact with the spoof window. The defense centers on providing enough
+information to enable the user to know where keyboard, mouse, and extension
+device input is going. To accomplish this, the server will cooperate with the
+security manager, an external process. The server will provide the following
+facilities to the security manager:
+</para>
+
+<para>
+1. A way to create a single window that is unobscurable by any window of any
+other client, trusted or untrusted. It needs to be unobscurable so that it is
+spoof-proof.
+</para>
+
+<note>
+<para>
+ISSUE: is a weaker form of unobscurability better? Should the window be
+obscurable by trusted windows, for example?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: does unobscurable mean that it is a child of the root that is always
+on top in the stacking order?
+</para>
+</note>
+
+<para>
+2. A way to determine if a given window ID belongs to an untrusted client.
+</para>
+
+<para>
+The security manager will need to select for the existing events
+FocusIn, FocusOut, EnterNotify, LeaveNotify, DeviceFocusIn, and
+DeviceFocusOut on all windows to track what window(s) the user's input is
+going to. Using the above server facilities, it can reliably display the
+trusted/untrusted status of all clients currently receiving input.
+</para>
+
+<note>
+<para>
+ISSUE: is it too much to ask the security manager to select for all these
+events on every window? Do we need to provide new events that you select
+for *on the device* that tell where the device is focused?
+</para>
+</note>
+
+<para>
+None of this should have any application impact.
+</para>
+
+<para>
+The unobscurable window may be tricky to implement. There is already some
+machinery in the server to make an unobscurable window for the screen saver,
+which may help but may also get in the way now that we have to deal with two
+unobscurable windows.
+</para>
+
+</sect1>
+
+
+<sect1 id="window_operations">
+<title>Window Operations</title>
+
+<para>
+Specifically, ReparentWindow, MapWindow, MapSubwindows, UnmapWindow,
+UnmapSubwindows, ConfigureWindow, and CirculateWindow.
+</para>
+
+<para>
+Alteration: manipulate another client's window.
+</para>
+
+<para>
+Theft: resource ID guessing (window, sibling).
+</para>
+
+<para>
+Defense for both of the above: send a Window error unless it is a root
+window, in which case we should send an Access error.
+</para>
+
+</sect1>
+
+<sect1 id="getgeometry">
+<title>GetGeometry</title>
+
+<para>
+Theft: get the geometry of another client's drawable.
+</para>
+
+<para>
+Theft: resource ID guessing (drawable).
+</para>
+<para>
+Defense for both of the above: send Drawable error. However, root windows
+will be allowed.
+</para>
+
+</sect1>
+
+<sect1 id="querytree">
+<title>QueryTree</title>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+
+<para>
+Theft: discover window IDs that belong to other clients.
+</para>
+
+<para>
+Defense: For the child windows, censor the reply by removing window IDs that
+belong to trusted clients. Allow the root window to be returned. For the parent
+window, if it belongs to a trusted client, return the closest ancestor window
+that belongs to an untrusted client, or if such a window does not exist,
+return the root window for the parent window.
+</para>
+
+<note>
+<para>
+ISSUE: will some applications be confused if we filter out the window manager
+frame window(s), or other windows between the queried window and the root
+window?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: the Motif drag protocol (both preregister and dynamic) needs to be able
+to locate other top-level windows for potential drop sites. See also
+<link linkend="access_to_server_resources">
+<xref linkend="access_to_server_resources"></xref></link>
+.
+</para>
+</note>
+
+</sect1>
+
+<sect1 id="internatom">
+<title>InternAtom</title>
+
+<para>
+Theft: discover atom values of atoms interned by other clients. This lets you
+determine if a specific set of atoms has been interned, which may lead to other
+inferences.
+</para>
+<para>
+Defense: This is a minor form of theft. Blocking it will interfere with many
+types of inter-client communication. We propose to do nothing about this
+threat.
+</para>
+
+<para>
+Denial of service: intern atoms until the server runs out of memory.
+</para>
+
+<para>
+Defense: quotas.
+</para>
+
+
+</sect1>
+
+<sect1 id="getatomname">
+<title>GetAtomName</title>
+
+<para>
+Theft: discover atom names of atoms interned by other clients. This lets you
+determine if a specific set of atoms has been interned, which may lead to other
+inferences.
+</para>
+
+<para>
+Defense: This is a minor form of theft. We propose to do nothing about this
+threat.
+</para>
+
+</sect1>
+
+<sect1 id="changeproperty">
+<title>ChangeProperty</title>
+
+<para>
+Alteration: change a property on another client's window or one that was
+stored by another client.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+<note>
+<para>
+ISSUE: Selection transfer requires the selection owner to change a property
+on the requestor's window. Does the security manager get us out of this?
+Does the server notice the property name and window passed in
+ConvertSelection and temporarily allow that window property to be written?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: should certain root window properties be writable?
+</para>
+</note>
+
+<para>
+Denial of service: store additional property data until the server
+runs out of memory.
+</para>
+
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+<sect1 id="deleteproperty">
+<title>DeleteProperty</title>
+
+<para>
+Destruction: delete a property stored by another client.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+</sect1>
+
+<sect1 id="getproperty">
+<title>GetProperty</title>
+
+<para>
+Theft: get a property stored by another client.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+<note>
+<para>
+ISSUE: should certain root window properties be readable? Proposed answer: yes,
+some configurable list. Do those properties need to be polyinstantiated?
+</para>
+</note>
+
+<note>
+<para>
+ISSUE: Motif drag and drop needs to be able to read the following properties:
+WM_STATE to identify top-level windows, _MOTIF_DRAG_WINDOW on
+the root window, _MOTIF_DRAG_TARGETS on the window given in the
+_MOTIF_DRAG_WINDOW property, and _MOTIF_DRAG_RECEIVER_INFO on
+windows with drop sites. Additionally, some properties are needed that do not
+have fixed names.
+</para>
+</note>
+
+</sect1>
+
+<sect1 id="rotateproperties">
+<title>RotateProperties</title>
+
+<para>
+Alteration: rotate properties stored by another client.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense for both of the above: send Window error.
+</para>
+</sect1>
+
+<sect1 id="listproperties">
+<title>ListProperties</title>
+
+<para>
+Theft: list properties stored by another client.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense for both of the above: send Window error.
+</para>
+
+<note>
+<para>
+ISSUE: should certain root window properties be listable?
+</para>
+</note>
+</sect1>
+
+<sect1 id="setselectionowner">
+<title>SetSelectionOwner</title>
+
+<para>
+Theft: Steal ownership of a selection.
+</para>
+
+<para>
+Denial of service: do this repeatedly so that no other client can own the
+selection.
+</para>
+
+<para>
+Defense for both of the above: have a configurable list of selections that
+untrusted clients can own. For other selections, treat this request as a no-op.
+</para>
+
+<note>
+<para>
+ISSUE: how does the security manager get involved here? Is it the one that
+has the configurable list of selections instead of the server?
+</para>
+</note>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+<sect1 id="getselectionowner">
+<title>GetSelectionOwner</title>
+
+<para>
+Theft: discover the ID of another client's window via the owner field of the
+reply.
+</para>
+
+<para>
+Defense: if the selection is on the configurable list mentioned above,
+return the root window ID, else return None.
+</para>
+
+<note>
+<para>
+ISSUE: how does the security manager get involved here?
+</para>
+</note>
+</sect1>
+
+<sect1 id="convertselection">
+<title>ConvertSelection</title>
+
+<para>
+Theft: this initiates a selection transfer (see the ICCCM) which sends
+the selection contents from the selection owner, which may be another
+client, to the requesting client.
+</para>
+
+<para>
+Defense: since in many cases ConvertSelection is done in direct response
+to user interaction, it is probably best not to force it to fail, either
+silently or with an error.  The server should rely on the security manager
+to assist in handling the selection transfer.
+</para>
+
+<para>
+Theft: resource ID guessing (requestor).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+
+<sect1 id="sendevent">
+<title>SendEvent</title>
+
+<para>
+A client can use SendEvent to cause events of any type to be sent to windows
+of other clients. Similarly, a client could SendEvent to one of its own
+windows with propogate set to True and arrange for the event to be propogated
+up to a window it does not own. Clients can detect events generated by
+SendEvent, but we cannot assume that they will.
+</para>
+
+<para>
+Defense: ignore this request unless the event being sent is a ClientMessage
+event, which should be sent normally so that selection transfer, Motif drag
+and drop, and certain input methods have a chance at working.
+</para>
+
+<note>
+<para>
+ISSUE: does allowing all ClientMessages open up too big a hole?
+</para>
+</note>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+
+</sect1>
+
+
+<sect1 id="keyboard_and_pointer_grabs">
+<title>Keyboard and Pointer Grabs</title>
+
+<para>
+Specifically, GrabKeyboard, GrabPointer, GrabKey, and GrabButton.
+</para>
+
+<para>
+Denial of service/Theft: take over the keyboard and pointer. This could
+be viewed as denial of service since it prevents other clients from getting
+keyboard or mouse input, or it could be viewed as theft since the user
+input may not have been intended for the grabbing client.
+</para>
+
+<para>
+Defense: provide a way to break grabs via some keystroke combination, and
+have a status area that shows which client is getting input. (See
+<link linkend="mapwindow">
+<xref linkend="mapwindow"></xref></link>
+).
+</para>
+
+<para>
+Theft: resource ID guessing (grab-window, confine-to, cursor).
+</para>
+
+<para>
+Defense: send Window or Cursor error.
+</para>
+
+</sect1>
+
+
+
+<sect1 id="changeactivepointergrab">
+<title>ChangeActivePointerGrab</title>
+
+<para>
+Theft: resource ID guessing (cursor).
+</para>
+
+<para>
+Defense: send Cursor error.
+</para>
+</sect1>
+
+
+<sect1 id="grabserver">
+<title>GrabServer</title>
+
+<para>
+Denial of service: a client can grab the server and not let go, locking
+out all other clients.
+</para>
+
+<para>
+Defense: provide a way to break grabs via some keystroke combination.
+</para>
+</sect1>
+
+
+<sect1 id="querypointer">
+<title>QueryPointer</title>
+
+<para>
+Theft: A client can steal pointer motion and position, button input,
+modifier key state, and possibly a window of another client with this request.
+</para>
+
+<para>
+Defense: if the querying client doesn't have the pointer grabbed, and
+the pointer is not in one of its windows, the information can be zeroed.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+<sect1 id="getmotionevents">
+<title>GetMotionEvents</title>
+
+<para>
+Theft: steal pointer motion input that went to other clients.
+</para>
+
+<para>
+Defense: ideally, the server would return only pointer input that was not
+delivered to any trusted client. The implementation effort to do that
+probably outweighs the marginal benefits. Instead, we will always return
+an empty list of motion events to untrusted clients.
+</para>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+<sect1 id="translatecoordinates">
+<title>TranslateCoordinates</title>
+
+<para>
+Theft: discover information about other clients' windows: position,
+screen, and possibly the ID of one of their subwindows.
+</para>
+
+<para>
+Defense: send an error if src-window or dst-window do not belong to
+the requesting client.
+</para>
+
+<para>
+Theft: resource ID guessing (src-window, dst-window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+<sect1 id="warppointer">
+<title>WarpPointer</title>
+
+<para>
+A client can cause pointer motion to occur in another client's window.
+</para>
+
+<para>
+Denial of service: repeated pointer warping prevents the user from using
+the mouse normally.
+</para>
+
+<para>
+Defense for both of the above: if the querying client doesn't have the pointer
+grabbed, and the pointer is not in one of its windows, treat the request as a
+no-op.
+</para>
+
+<para>
+Theft: resource ID guessing (src-window, dst-window).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+<sect1 id="setinputfocus">
+<title>SetInputFocus</title>
+
+<para>
+Theft: a client can use this request to make one of its own windows have
+the input focus (keyboard focus). The user may be unaware that keystrokes
+are now going to a different window.
+</para>
+
+<para>
+Denial of service: repeatedly setting input focus prevents normal use of the
+keyboard.
+</para>
+
+<para>
+Defense for both of the above: only allow untrusted clients to
+SetInputFocus if input focus is currently held by another untrusted client.
+</para>
+
+<note>
+<para>
+ISSUE: this will break clients using the Globally Active Input model
+described in section 4.1.7 of the ICCCM.
+</para>
+</note>
+
+<para>
+Theft: resource ID guessing (focus).
+</para>
+
+<para>
+Defense: send Window error.
+</para>
+</sect1>
+
+
+<sect1 id="getinputfocus">
+<title>GetInputFocus</title>
+
+<para>
+Theft: the reply may contain the ID of another client's window.
+</para>
+<para>
+Defense: return a focus window of None if a trusted client currently has
+the input focus.
+</para>
+</sect1>
+
+
+<sect1 id="querykeymap">
+<title>QueryKeymap</title>
+
+<para>
+Theft: poll the keyboard with this to see which keys are being pressed.
+</para>
+
+<para>
+Defense: zero the returned bit vector if a trusted client currently has
+the input focus.
+</para>
+</sect1>
+
+<sect1 id="font_requests">
+<title>Font Requests</title>
+
+<para>
+Specifically, OpenFont, QueryFont, ListFonts, ListFontsWithInfo, and
+QueryTextExtents.
+</para>
+
+<para>
+Theft: discover font name, glyph, and metric information about fonts that were
+provided by another client (by setting the font path). Whether it is theft
+to retrieve information about fonts from the server's initial font path
+depends on whether or not you believe those fonts, by their existence in the
+initial font path, are intended to be globally accessible by all clients.
+</para>
+
+<para>
+Defense:
+</para>
+
+<para>
+Maintain two separate font paths, one for trusted clients and one for untrusted
+clients. They are both initialized to the default font path at server reset.
+Subsequently, changes to one do not affect the other. Since untrusted clients
+will not see font path elements added by trusted clients, they will not be
+able to access any fonts provided by those font path elements.
+</para>
+
+<para>
+Theft: resource ID guessing (font) (QueryFont and QueryTextExtents only).
+</para>
+
+<para>
+Defense: send Font error.
+</para>
+
+<para>
+Denial of service: open fonts until the server runs out of memory (OpenFont
+only).
+</para>
+
+<para>
+Defense: quotas.
+</para>
+
+</sect1>
+
+
+<sect1 id="closefont">
+<title>CloseFont</title>
+
+<para>
+Destruction: close another client's font.
+</para>
+<para>
+Defense: send Font error.
+</para>
+</sect1>
+
+<sect1 id="setfontpath">
+<title>SetFontPath</title>
+
+<para>
+Denial of service: change the font path so that other clients cannot
+find their fonts.
+</para>
+
+<para>
+Alteration: change the font path so that other clients get different
+fonts than they expected.
+</para>
+<para>
+Defense for both of the above: separate font paths for trusted and
+untrusted clients, as described in the Font Requests section.
+</para>
+<note>
+<para>
+ISSUE: the printing project considered per-client font paths and concluded
+that it was very difficult to do. We should look at this aspect of the print
+server design to see if we can reuse the same scheme. We should also try to
+reconstruct what was so difficult about this; it doesn't seem that hard on the
+surface.
+</para>
+</note>
+</sect1>
+
+<sect1 id="getfontpath">
+<title>GetFontPath</title>
+
+<para>
+Theft: retrieve font path elements that were set by other clients.
+</para>
+<para>
+Use knowledge from font path elements to mount other attacks, e.g.,
+attack a font server found in the font path.
+</para>
+<para>
+Defense for both of the above: separate font paths for trusted and
+untrusted clients, as described in the Font Requests section.
+</para>
+</sect1>
+
+
+<sect1 id="createpixmap">
+<title>CreatePixmap</title>
+
+<para>
+Theft: resource ID guessing (drawable).
+</para>
+<para>
+Defense: send Drawable error.
+</para>
+<para>
+Denial of service: create pixmaps until the server runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+<sect1 id="freepixma">
+<title>FreePixmap</title>
+
+<para>
+Destruction: destroy another client's pixmap.
+</para>
+<para>
+Defense: send Pixmap error.
+</para>
+</sect1>
+
+<sect1 id="creategc">
+<title>CreateGC</title>
+
+<para>
+Theft: resource ID guessing (drawable, tile, stipple, font, clip-mask).
+</para>
+<para>
+Defense: send Drawable, Pixmap, or Font error.
+</para>
+<para>
+Denial of service: create GCs until the server runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+
+<sect1 id="copygc">
+<title>CopyGC</title>
+
+<para>
+Theft: copy GC values of another client's GC.
+</para>
+<para>
+Alteration: copy GC values to another client's GC.
+</para>
+<para>
+Defense for both of the above: send GC error.
+</para>
+</sect1>
+
+
+<sect1 id="changegc__setdashes__setcliprectangles">
+<title>ChangeGC, SetDashes, SetClipRectangles</title>
+
+<para>
+Alteration: change values of another client's GC.
+</para>
+<para>
+Theft: resource ID guessing (gc, tile, stipple, font, clip-mask)
+(last four for ChangeGC only).
+</para>
+<para>
+Defense for both of the above: send GC error.
+</para>
+</sect1>
+
+<sect1 id="freegc">
+<title>FreeGC</title>
+
+<para>
+Destruction: destroy another client's GC.
+</para>
+<para>
+Defense: send GC error.
+
+</para>
+</sect1>
+
+
+<sect1 id="drawing_requests">
+<title>Drawing Requests</title>
+
+<para>
+Specifically, ClearArea, CopyArea, CopyPlane, PolyPoint, PolyLine, PolySegment,
+PolyRectangle, PolyArc, FillPoly, PolyFillRectangle, PolyFillArc, PutImage,
+PolyText8, PolyText16, ImageText8, and ImageText16.
+</para>
+<para>
+Alteration: draw to another client's drawable.
+</para>
+<para>
+Theft: resource ID guessing: ClearArea - window; CopyArea, CopyPlane -
+src-drawable, dst-drawable, gc; all others - drawable, gc.
+</para>
+<para>
+Defense for both of the above: send appropriate error.
+</para>
+<note>
+<para>
+ISSUE: The Motif preregister drag protocol requires clients to draw
+into windows of other clients for drag-over/under effects.
+</para>
+</note>
+<para>
+Spoofing: draw to a window to make it resemble a window of another client.
+</para>
+<para>
+Defense: see
+<link linkend="mapwindow">
+<xref linkend="mapwindow"></xref></link>
+.
+</para>
+</sect1>
+
+
+<sect1 id="getimage">
+<title>GetImage</title>
+
+<para>
+Theft: get the image of another client's drawable.
+</para>
+<para>
+Theft: resource ID guessing (drawable).
+</para>
+<para>
+Defense: send Drawable error.
+</para>
+<para>
+Theft: get the image of your own window, which may contain pieces of other
+overlapping windows.
+</para>
+<para>
+Defense: censor returned images by blotting out areas that contain data
+from trusted windows.
+</para>
+</sect1>
+
+<sect1 id="createcolormap">
+<title>CreateColormap</title>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+<para>
+Defense: send Colormap error.
+
+</para>
+<para>
+Denial of service: create colormaps with this request until the server
+runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+<sect1 id="freecolormap">
+<title>FreeColormap</title>
+
+<para>
+Destruction: destroy another client's colormap.
+</para>
+<para>
+Defense: send Colormap error.
+</para>
+</sect1>
+
+
+<sect1 id="copycolormapandfree">
+<title>CopyColormapAndFree</title>
+
+<para>
+Theft: resource ID guessing (src-map).
+</para>
+<para>
+Defense: send Colormap error. However, default colormaps will be allowed.
+</para>
+<note>
+<para>
+ISSUE: must untrusted applications be allowed to use standard colormaps?
+(Same issue for ListInstalledColormaps, Color Allocation Requests,
+FreeColors, StoreColors, StoreNamedColor, QueryColors, and LookupColor.)
+</para>
+</note>
+<para>
+Denial of service: create colormaps with this request until the server
+runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+<sect1 id="installcolormap__uninstallcolormap">
+<title>InstallColormap, UninstallColormap</title>
+
+<para>
+Theft: resource ID guessing.
+</para>
+<para>
+Defense: send Colormap error.
+</para>
+<para>
+Denial of service: (un)install any colormap, potentially preventing
+windows from displaying correct colors.
+</para>
+<para>
+Defense: treat this request as a no-op. Section 4.1.8 of the ICCCM states
+that (un)installing colormaps is the responsibility of the window manager
+alone.
+</para>
+
+<note>
+<para>
+ISSUE: the ICCCM also allows clients to do colormap installs if the client
+has the pointer grabbed. Do we need to allow that too?
+</para>
+</note>
+</sect1>
+
+<sect1 id="listinstalledcolormaps">
+<title>ListInstalledColormaps</title>
+
+<para>
+Theft: resource ID guessing (window).
+</para>
+
+<para>
+Defense: send Colormap error.
+</para>
+<para>
+Theft: discover the resource ID of another client's colormap from the reply.
+</para>
+<para>
+Defense: remove the returned colormap IDs; only let through default
+colormaps and colormaps of untrusted clients.
+</para>
+</sect1>
+
+<sect1 id="color_allocation_requests">
+<title>Color Allocation Requests</title>
+
+<para>
+Specifically, AllocColor, AllocNamedColor, AllocColorCells, and
+AllocColorPlanes.
+</para>
+<para>
+Alteration/Denial of service: allocate colors in another client's
+colormap. It is denial of service if the owning client's color allocations
+fail because there are no cells available. Otherwise it is just alteration.
+</para>
+<para>
+Theft: resource ID guessing (cmap).
+</para>
+<para>
+Defense for both of the above: send Colormap error. However, default
+colormaps will be allowed.
+</para>
+</sect1>
+
+<sect1 id="freecolors">
+<title>FreeColors</title>
+
+<para>
+Theft: resource ID guessing (cmap).
+</para>
+<para>
+Defense: send Colormap error. However, default colormaps will be allowed.
+</para>
+</sect1>
+
+<sect1 id="storecolors__storenamedcolor">
+<title>StoreColors, StoreNamedColor</title>
+
+<para>
+Alteration: change the colors in another client's colormap.
+</para>
+<para>
+Theft: resource ID guessing (cmap).
+</para>
+<para>
+Defense for both of the above: send Colormap error. However, default
+colormaps will be allowed.
+</para>
+</sect1>
+
+
+<sect1 id="querycolors__lookupcolor">
+<title>QueryColors, LookupColor</title>
+
+<para>
+Theft: retrieve information about the colors in another client's colormap.
+</para>
+<para>
+Theft: resource ID guessing (cmap).
+</para>
+<para>
+Defense for both of the above: send Colormap error. However, default
+colormaps will be allowed.
+</para>
+</sect1>
+
+<sect1 id="createcursor__createglyphcursor">
+<title>CreateCursor, CreateGlyphCursor</title>
+
+<para>
+Theft: resource ID guessing (source, mask or source-font, mask-font).
+</para>
+<para>
+Defense: send Pixmap or Font error. However, the default font will be allowed.
+</para>
+<para>
+Denial of service: create cursors until the server runs out of memory.
+</para>
+<para>
+Defense: quotas.
+</para>
+</sect1>
+
+<sect1 id="freecursor">
+<title>FreeCursor</title>
+
+<para>
+Destruction: free another client's cursor.
+</para>
+<para>
+Defense: send Cursor error.
+</para>
+</sect1>
+
+<sect1 id="recolorcursor">
+<title>RecolorCursor</title>
+
+<para>
+Alteration: recolor another client's cursor.
+</para>
+<para>
+Theft: resource ID guessing (cursor).
+</para>
+<para>
+Defense for both of the above: send Cursor error.
+</para>
+</sect1>
+
+<sect1 id="querybestsize">
+<title>QueryBestSize</title>
+
+<para>
+Theft: resource ID guessing (drawable).
+</para>
+<para>
+Defense: send Drawable error.
+</para>
+</sect1>
+
+<sect1 id="listextensions__queryextension">
+<title>ListExtensions, QueryExtension</title>
+
+<para>
+Determine the extensions supported by the server, and use the list to choose
+extension-specific attacks to attempt.
+</para>
+<para>
+Defense: extensions will have a way to tell the server whether it is safe
+for untrusted clients to use them. These requests will only return information
+about extensions that claim to be safe.
+</para>
+</sect1>
+
+<sect1 id="keyboard_configuration_requests">
+<title>Keyboard configuration requests</title>
+
+<para>
+Specifically, ChangeKeyboardControl, ChangeKeyboardMapping, and
+SetModifierMapping.
+</para>
+<para>
+Alteration: change the keyboard parameters that were established by another
+client.
+</para>
+<para>
+Denial of service: with ChangeKeyboardControl, disable auto-repeat, key
+click, or the bell. With ChangeKeyboardMapping or SetModifierMapping,
+change the key mappings so that the keyboard is difficult or impossible to
+use.
+</para>
+<para>
+Defense for both of the above: treat these requests as a no-op.
+</para>
+</sect1>
+
+
+<sect1 id="keyboard_query_requets">
+<title>Keyboard query requests</title>
+
+<para>
+Specifically, GetKeyboardControl, GetKeyboardMapping, and GetModifierMapping.
+</para>
+<para>
+Theft: get keyboard information that was established by another client.
+</para>
+<para>
+Defense: This is a minor form of theft. We propose to do nothing about this
+threat.
+</para>
+</sect1>
+
+
+<sect1 id="changepointercontrol__setpointermapping">
+<title>ChangePointerControl, SetPointerMapping</title>
+
+<para>
+Alteration: change the pointer parameters that were established by another
+client.
+</para>
+<para>
+Denial of service: set the pointer parameters so that the pointer is
+difficult or impossible to use.
+</para>
+<para>
+Defense for both of the above: treat these requests as a no-op.
+</para>
+</sect1>
+
+<sect1 id="getpointercontrol__getpointermapping">
+<title>GetPointerControl, GetPointerMapping</title>
+
+<para>
+Theft: get pointer parameters that were established by another client.
+</para>
+<para>
+Defense: This is a minor form of theft. We propose to do nothing about this
+threat.
+</para>
+</sect1>
+
+<sect1 id="setscreensaver">
+<title>SetScreenSaver</title>
+
+<para>
+Alteration: change the screen saver parameters that were established by
+another client.
+</para>
+<para>
+Denial of service: set the screen saver parameters so that the screen saver
+is always on or always off.
+</para>
+<para>
+Defense for both of the above: treat these requests as a no-op.
+</para>
+</sect1>
+
+
+<sect1 id="getscreensaver">
+<title>GetScreenSaver</title>
+
+<para>
+Theft: get screen saver parameters that were established by another client.
+</para>
+<para>
+Defense: This is a minor form of theft. We propose to do nothing about this
+threat.
+</para>
+</sect1>
+
+<sect1 id="forcescreensaver">
+<title>ForceScreenSaver</title>
+
+<para>
+Denial of service: repeatedly activate the screen saver so that the user
+cannot see the screen as it would look when the screen saver is off.
+</para>
+<para>
+Denial of service: repeatedly reset the screen saver, preventing it from
+activating.
+</para>
+<para>
+Defense for both of the above: treat these requests as a no-op.
+</para>
+</sect1>
+
+<sect1 id="changehost">
+<title>ChangeHost</title>
+
+<para>
+Most servers already have some restrictions on which clients can use this
+request, so whether the following list applies is implementation dependent.
+</para>
+<para>
+Denial of service: remove a host from the list, preventing clients from
+connecting from that host.
+</para>
+<para>
+Add a host to the list. Clients from that host may then launch other
+attacks of any type.
+</para>
+<para>
+Defense for both of the above: return Access error.
+</para>
+</sect1>
+
+
+<sect1 id="listhosts">
+<title>ListHosts</title>
+
+<para>
+Theft: steal host identities and possibly even user identities that are
+allowed to connect.
+</para>
+<para>
+Launch attacks of any type against the stolen host/user identities.
+</para>
+<para>
+Defense for both of the above: return only untrusted hosts.
+</para>
+</sect1>
+
+
+<sect1 id="setaccesscontrol">
+<title>SetAccessControl</title>
+
+<para>
+Most servers already have some restrictions on which clients can use this
+request, so whether the following list applies is implementation dependent.
+</para>
+<para>
+Alteration: change the access control value established by some other client.
+</para>
+<para>
+Disable access control, allowing clients to connect who would normally not be
+able to connect. Those clients may then launch other attacks of any type.
+</para>
+<para>
+Defense for both of the above: return Access error.
+</para>
+</sect1>
+
+<sect1 id="setclosedownmode">
+<title>SetCloseDownMode</title>
+
+<para>
+Denial of service: set the close-down mode to RetainPermanent or
+RetainTemporary, then disconnect. The server cannot reuse the
+resource-id-base of the disconnected client, or the memory used by the
+retained resources, unless another client issues an appropriate KillClient
+to cancel the retainment. The server has a limited number of
+resource-id-bases, and when they are exhausted, it will be unable to accept
+new client connections.
+</para>
+<para>
+Defense: treat this request as a no-op.
+</para>
+</sect1>
+
+<sect1 id="killclient">
+<title>KillClient</title>
+
+<para>
+Destruction/Denial of service: kill another currently connected client.
+</para>
+<para>
+Destruction: kill a client that has terminated with close-down mode of
+RetainTemporary or RetainPermanent, destroying all its retained resources.
+</para>
+<para>
+Destruction: specify AllTemporary as the resource, destroying all resources
+of clients that have terminated with close-down mode RetainTemporary.
+</para>
+<para>
+Defense for all of the above: return Value error.
+</para>
+</sect1>
+
+<sect1 id="clean_requests">
+<title>Clean Requests</title>
+
+<para>
+Other than denial of service caused by flooding, these requests have no known
+security concerns: AllowEvents, UngrabPointer, UngrabButton, UngrabKeyboard,
+UngrabKey, UngrabServer, NoOperation, and Bell.
+</para>
+</sect1>
+</chapter>
+
+<chapter id="events">
+<title>Events</title>
+
+<para>
+The only threat posed by events is theft. Selecting for events on another
+client's resources is always theft. We restrict further analysis by
+assuming that the client only selects for events on its own resources,
+then asking whether the events provide information about other clients.
+</para>
+
+<sect1 id="keymapnotify">
+<title>KeymapNotify</title>
+
+<para>
+Theft: the state of the keyboard can be seen when the client does not have
+the input focus. This is possible because a KeymapNotify is sent to a
+window after every EnterNotify even if the window does not have input focus.
+</para>
+<para>
+Defense: zero the returned bit vector if a trusted client currently has the
+input focus.
+</para>
+</sect1>
+
+<sect1 id="expose">
+<title>Expose</title>
+
+<para>
+Theft: discover where other clients' windows overlap your own. For
+instance, map a full-screen window, lower it, then raise it. The resulting
+exposes tell you where other windows are.
+</para>
+
+<para>
+Defense: about the only thing you could do here is force backing store to be
+used on untrusted windows, but that would probably use too much server
+memory. We propose to do nothing about this threat.
+</para>
+</sect1>
+
+<sect1 id="graphicsexposure">
+<title>GraphicsExposure</title>
+
+<para>
+Theft: discover where other clients' windows overlap your own. For instance,
+use CopyArea to copy the entire window's area exactly on top of itself. The
+resulting GraphicsExposures tell you where the window was obscured.
+</para>
+<para>
+Defense: see Expose above. We propose to do nothing about this threat.
+</para>
+</sect1>
+
+<sect1 id="visibilitynotify">
+<title>VisibilityNotify</title>
+
+<para>
+Theft: this event provides crude positional information about other
+clients, though the receiver cannot tell which other clients.
+</para>
+<para>
+Defense: The information content of this event is very low. We propose to
+do nothing about this threat.
+</para>
+</sect1>
+
+<sect1 id="reparentnotify">
+<title>ReparentNotify</title>
+
+<para>
+Theft: the parent window may belong to some other client (probably the
+window manager).
+</para>
+<para>
+Defense: If the parent window belongs to a trusted client, return the
+closest ancestor window that belongs to an untrusted client, or if such a
+window does not exist, return the root window for the parent window.
+</para>
+<note>
+<para>
+ISSUE: what is the application impact?
+</para>
+</note>
+
+</sect1>
+
+
+<sect1 id="configurenotify">
+<title>ConfigureNotify</title>
+
+
+<para>
+Theft: the above-sibling window may belong to some other client.
+</para>
+<para>
+Defense: return None for the above-sibling window if it belongs to a trusted
+client.
+</para>
+<note>
+<para>
+ISSUE: what is the application impact?
+</para>
+</note>
+
+</sect1>
+
+
+<sect1 id="configurerequest">
+<title>ConfigureRequest</title>
+
+<para>
+Theft: the sibling window may belong to some other client.
+</para>
+<para>
+Defense: return None for the sibling window if it belongs to a trusted client.
+</para>
+<para>
+ISSUE: what is the application impact?
+</para>
+</sect1>
+
+
+<sect1 id="selectionclear">
+<title>SelectionClear</title>
+
+<para>
+Theft: the owner window may belong to some other client.
+</para>
+<para>
+Defense: return None for the owner window if it belongs to a trusted client.
+</para>
+</sect1>
+
+<sect1 id="selectionrequest">
+<title>SelectionRequest</title>
+
+<para>
+Theft: the requestor window may belong to some other client.
+</para>
+<para>
+Defense: Blocking this event or censoring the window would prevent selection
+transfers from untrusted clients to trusted clients from working. We propose
+to do nothing in the server about this threat. The security manager may
+reduce the exposure of trusted window IDs by becoming the owner of all
+selections.
+</para>
+</sect1>
+
+
+<sect1 id="mappingnotify">
+<title>MappingNotify</title>
+
+<para>
+Theft: discover keyboard, pointer, or modifier mapping information set
+by another client.
+</para>
+<para>
+Defense: Any tampering with this event will cause clients to have an
+inconsistent view of the keyboard or pointer button configuration, which is
+likely to confuse the user. We propose to do nothing about this threat.
+</para>
+</sect1>
+</chapter>
+
+<chapter id="errors">
+<title>Errors</title>
+
+<para>
+There appear to be no threats related to procotol errors.
+</para>
+
+</chapter>
+
+
+
+
+<chapter id="future_work">
+<title>Future Work</title>
+
+<para>
+The next steps are resolve the items marked ISSUE and to decide if the
+defenses proposed are reasonable. Discussion on the security@x.org mailing list,
+prototyping, and/or starting the implementation should help answer these
+questions.
+</para>
+</chapter>
+
+
+<chapter id="references">
+<title>References</title>
+
+<para>
+Bellcore, "Framework Generic Requirements for X Window System Security,"
+Technical Advisory FA-STS-001324, Issue 1, August 1992.
+</para>
+<para>
+Dardailler, Daniel, "Motif Drag And Drop Protocol," unpublished design
+notes.
+</para>
+<para>
+Kahn, Brian L., "Safe Use of X WINDOW SYSTEM protocol Across a Firewall",
+unpublished draft, The MITRE Corporation, 1995.
+</para>
+<para>
+Rosenthal, David S. H., "LINX - a Less INsecure X server," Sun Microsystems,
+29th April 1989.
+</para>
+<para>
+Rosenthal, David and Marks, Stuart W., "Inter-Client Communication Conventions
+Manual Version 2.0," ftp://ftp.x.org/pub/R6.1/xc/doc/hardcopy/ICCCM/icccm.PS.Z
+
+</para>
+<para>
+Scheifler, Robert W., "X Window System Protocol,"
+ftp://ftp.x.org/pub/R6.1/xc/doc/hardcopy/XProtocol/proto.PS.Z
+</para>
+<para>
+Treese, G. Winfield and Wolman, Alec, "X Through the Firewall, and Other
+Application Relays," Digital Equipment Corporation Cambridge Research Lab,
+Technical Report Series, CRL 93/10, May 3, 1993.
+</para>
+</chapter>
+</book>
diff --git a/specs/Xserver/appgroup.ms b/specs/Xserver/appgroup.xml
index 20d8965..eebf843 100644
--- a/specs/Xserver/appgroup.ms
+++ b/specs/Xserver/appgroup.xml
@@ -1,85 +1,121 @@
-.\" $Xorg: appgroup.ms,v 1.3 2000/08/17 19:42:41 cpqbld Exp $
-.EF 'AppGroup Extension Definition'- % -'October, 1996'
-.OF 'AppGroup Extension Definition'- % -'October, 1996'
-.EH '''
-.OH '''
-.TL
-Description of the Application Group Extension
-Implementation for the X11 Sample Server
-.AU
-Kaleb S. KEITHLEY
-.AI
-X Consortium
-.LP
-.bp
-\&
-.sp 15
-Copyright \(co 1996 X Consortium
-.LP
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<book id="appgroup">
+
+<bookinfo>
+   <title>Description of the Application Group Extension</title>
+   <subtitle>Implementation for the X11 Sample Server</subtitle>
+   <releaseinfo>Version 1.0</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>Kaleb </firstname><surname>KEITHLEY</surname>
+         <affiliation><orgname>FUJITSU Limited.</orgname></affiliation>
+         <email>blah@blah.com</email>
+      </author>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1996</year><holder>X Consortium</holder></copyright>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 7</productnumber>
+
+<abstract>
+<para>
+The following document explains the server side of the Application
+Group Extension.
+</para>
+</abstract>
+
+<legalnotice>
+
+
+<para>
 Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the ``Software''), to deal
+of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
-.LP
+</para>
+
+<para>
 The above copyright notice and this permission notice shall be included in
 all copies or substantial portions of the Software.
-.LP
-THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+</para>
+
+<para>
+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.
-.bp
-.LP
-The following document explains the server side of the Application 
+</para>
+
+<para>
+The following document explains the server side of the Application
 Group Extension.
-.LP
-WindowsNT is a trademark of Microsoft, Inc.  Macintosh and Apple 
-are trademarks of Apple Computer, Inc.  X Window System is a 
+</para>
+
+<para>
+WindowsNT is a trademark of Microsoft, Inc.  Macintosh and Apple
+are trademarks of Apple Computer, Inc.  X Window System is a
 trademark of X Consortium, Inc.
-.LP
-To understand this document and the accompanying source code, you 
+</para>
+</legalnotice>
+</bookinfo>
+
+<chapter>
+<title>TITLE</title>
+<para>
+To understand this document and the accompanying source code, you
 should know the C language, should be familiar with X server
-internals, and should also have a general knowledge of the X 
+internals, and should also have a general knowledge of the X
 Window System.
-.NH 1
-AppGroup Server Public Functions
-.LP
+</para>
+
+<sect1 id="AppGroup_Server_Public_Functions">
+<title>AppGroup Server Public Functions</title>
+<para>
 The AppGroup extension adds seven new functions that are called
-from elsewhere in the server. They are: XagExtensionInit, 
-XagDefaultColormap, XagRootVisual, XagLeader, XagIsControlledRoot, 
+from elsewhere in the server. They are: XagExtensionInit,
+XagDefaultColormap, XagRootVisual, XagLeader, XagIsControlledRoot,
 XagConnectionInfo, XagCallClientStateChange.
-.LP
+</para>
+<para>
 XagExtensionInit is the extension initialization function called
 from InitExtension in mi/miinitext.c. Note that an new resource
 type, RT_APPGROUP, is created, specifying the destructor function
 XagAppGroupFree.
-.LP
+</para>
+<para>
 XagDefaultColormap returns the colormap ID that was specified in
 the creation of the AppGroup. Any time CopyFromParent is specified
 for a top-level window's colormap, i.e. in a CreateWindow or
-ChangeWindowAttributes request, this function is called to see 
-if there is an AppGroup specific colormap to use. If there is 
+ChangeWindowAttributes request, this function is called to see
+if there is an AppGroup specific colormap to use. If there is
 one, its ID is returned, otherwise None is returned.
-.LP
+</para>
+<para>
 XagRootVisual returns the visual ID that was specified in the
 creation of the Appgroup. Like XagDefaultColormap, when CopyFromParent
 is specified for a top-level window's visual in a CreateWindow
 request, this function is called to see if there is an AppGroup
 specific visual to use. If there is one, its ID is returned,
 otherwise 0 (zero) is returned.
-.LP
+</para>
+<para>
 XagLeader returns the ClientPtr of the client that is the AppGroup
 Leader. Normally when an application maps or configures a top-level
-window a MapRequest or ConfigureRequest event is delivered to the 
-client, e.g. a window manager, that has selected SubstructureRedirect 
-on the root window. However, when the application is part of an 
+window a MapRequest or ConfigureRequest event is delivered to the
+client, e.g. a window manager, that has selected SubstructureRedirect
+on the root window. However, when the application is part of an
 AppGroup, the MapRequest and ConfigureRequest events are delivered
 to the AppGroup Leader instead.
-.LP
+</para>
+<para>
 XagIsControlledRoot returns a boolean: True if the window is a
 top-level window of a client in an AppGroup, False otherwise.
 In a combined server, i.e. one that provides both UI and printing,
@@ -90,14 +126,16 @@ member creates and maps a [top-level] window then the window's
 parent [the root window] is tested to determine whether to send
 MapRequest or ConfigureRequest events to the AppGroup Leader to
 to some other client.
-.LP
-In the trivial case XagIsControlledRoot returns True if the parent 
+</para>
+<para>
+In the trivial case XagIsControlledRoot returns True if the parent
 window has no parent itself, i.e. it is a root window. In the case
 where the application is embedded, indicated by the singleScreen
 attribute being True, the parent's drawable ID is compared to the
 AppGroup's root window ID, and if it is the same, True is returned.
 If neither case is true, then False is returned.
-.LP
+</para>
+<para>
 XagConnectionInfo returns an abreviated version of the connection
 setup information. When an embedded AppGroup is created the server
 returns only the information about the [UI] screen that the
@@ -105,27 +143,32 @@ application is embedded within in the connection setup in order to
 prevent the application from creating windows on other screens;
 thus attempting to guarantee that any window that should be embedded
 can be reparented into the AppGroup Leader's window hierarchy.
-.LP
+</para>
+<para>
 XagCallClientStateChange is called to invoke the extension's client
 state change callback additional times as necessary -- currently
 only once, after the auth data becomes available between
-ClientStateInitial and ClientStateConnected. Client state change 
-callbacks were introduced in the Record extension, which specifies 
-when the callbacks are invoked. Unfortunately the points at which 
-they are called are not necessarily the best as far as the AppGroup 
+ClientStateInitial and ClientStateConnected. Client state change
+callbacks were introduced in the Record extension, which specifies
+when the callbacks are invoked. Unfortunately the points at which
+they are called are not necessarily the best as far as the AppGroup
 Extension is concerned. Adding an additional state and calling all
 the callbacks works too, however this seemed unnecessary overkill.
-.NH 1
-AppGroup Server Private APIs
-.LP
-The AppGroup extension adds the following functions which are 
-private to the extension: ProcXagDispatch and SProcXagDispatch, 
+</para>
+</sect1>
+
+<sect1 id="AppGroup_Server_Private_APIs">
+<title>AppGroup Server Private APIs</title>
+<para>
+The AppGroup extension adds the following functions which are
+private to the extension: ProcXagDispatch and SProcXagDispatch,
 ProcXagQueryVersion and SProcXagQueryVersion, ProcXagCreate and
 SProcXagCreate, ProcXagDestroy and SProcXagDestroy,
 ProcGetAttr and SProcGetAttr, ProcXagQuery and SProcXagQuery,
 ProcXagCreateAssoc and SProcXagCreateAssoc, ProcXagDestroyAssoc
 and SProcXagDestroyAssoc, XagResetProc, and XagAppGroupFree.
-.LP
+</para>
+<para>
 The ProcXagDispatch, SProcXagDispatch, and XagResetProc functions
 should be familiar to anyone familiar with X server internals and
 I won't elaborate on them here. Similarly the wrapper functions:
@@ -133,56 +176,73 @@ SProcXagQueryVersion, SProcXagCreate, SProcXagDestroy, SProcXagGetAttr,
 SProcXagQuery, SProcXagCreateAssoc, and SProcXagDestroyAssoc, as
 wrappers which handle swapping integer data into the host's byte
 order will not be explained in any detail.
-.LP
+</para>
+<para>
 ProcXagQueryVersion returns the major and minor versions of the
 AppGroup extension supported by the server.
-.LP
-ProcXagCreate creates an AppGroup. A new record in a linked list 
-of AppGroups is allocated and initialized. The attributes from the 
-request are validated and copied to the AppGroup record. If necessary 
-an abbreviated version of the connection setup information is compiled 
+</para>
+<para>
+ProcXagCreate creates an AppGroup. A new record in a linked list
+of AppGroups is allocated and initialized. The attributes from the
+request are validated and copied to the AppGroup record. If necessary
+an abbreviated version of the connection setup information is compiled
 and also stored in the AppGroup record. The first time an AppGroup
 is created a client-state-change callback is registered and a
 reference count is incremented.
-.LP
+</para>
+<para>
 ProcXagDestroy destroys an AppGroup an AppGroup by calling
 FreeResource specifying the AppGroup ID. This will result in
 the destructor function XagAppGroupFree being called. The
 reference count is decremented and when it reaches zero the
 client-state-change callback is deleted.
-.LP
+</para>
+<para>
 ProcXagGetAttr returns the AppGroup Attributes to the requesting
 client.
-.LP
+</para>
+<para>
 ProcXagQuery returns the AppGroup ID of an arbitrary resource to
 the requesting client.
-.LP
+</para>
+<para>
 ProcXagCreateAssoc creates an association between an X window ID
-and system-specific data. In native X this functionality is 
+and system-specific data. In native X this functionality is
 unnecessary but for various personal computers, e.g. Macintosh,
 OS/2, and MS-Windows it is necessary to associate an X window ID
 with the system's native window identifier so that when the
 AppGroup Leader issues a ReparentWindow request the personal
 computer X server can lookup the system-specific window ID and
 make the necessary function call(s) with it.
-.LP
+</para>
+<para>
 ProcXagDestroyAssoc destroys the association created with
 ProcXagCreateAssoc.
-.LP
+</para>
+<para>
 XagResetProc removes the client-state-change callback, sets the
 reference count to zero, and frees all the AppGroup records in
 the linked list by calling XagAppGroupFree.
-.LP
+</para>
+<para>
 XagAppGroupFree calls CloseDownClient for each client in an
 AppGroup if the AppGroup has a leader, unlinks the AppGroup
 record from the linked list, frees allocated memory referenced
 by the record, and finally frees the record itself.
-.NH 1
-Known Problems in this release.
-.LP
+</para>
+</sect1>
+
+<sect1 id="Known_Problems_in_this_release_">
+<title>Known Problems in this release.</title>
+<para>
 In a combined UI/Print server the connection setup returned to an
 embedded application will not have information about the print
 screens.
-.LP
+</para>
+<para>
 The LBX proxy caches connection setup information and will return
 incorrect connection setup information to an embedded client.
+</para>
+</sect1>
+</chapter>
+</book>
diff --git a/specs/Xserver/ddx.tbl.ms b/specs/Xserver/ddx.tbl.ms
deleted file mode 100644
index be1a8a4..0000000
--- a/specs/Xserver/ddx.tbl.ms
+++ /dev/null
@@ -1,2 +0,0 @@
-This document has been converted to DocBook.
-New location is sgml/core/Xserver-Spec.sgml within this project.
diff --git a/specs/Xserver/secint.tex b/specs/Xserver/secint.tex
deleted file mode 100644
index 56aac6c..0000000
--- a/specs/Xserver/secint.tex
+++ /dev/null
@@ -1,219 +0,0 @@
-\documentstyle{article}
-\setlength{\parindent}{0 pt}
-\setlength{\parskip}{6pt}
-
-% $XFree86$
-
-\begin{document}
-
-\title{Security Extension Server Design\\Draft Version 3.0}
-\author{David P. Wiggins\\X Consortium, Inc.}
-\maketitle
-
-\begin{abstract}
-This paper describes the implementation strategy used to implement
-various pieces of the SECURITY Extension.
-\end{abstract}
-% suppress page number on title page
-\thispagestyle{empty}
-
-\eject
-
-Copyright \copyright 1996 X Consortium, Inc.  All Rights Reserved.
-
-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 OF
-OR OTHER DEALINGS IN THE SOFTWARE.
-
-Except as contained in this notice, the name of the X Consortium shall
-not be used in advertising or otherwise to promote the sale, use or
-other dealings in this Software without prior written authorization
-from the X Consortium.
-
-\eject
-
-\section{GenerateAuthorization Request}
-
-The major steps taken to execute this request are as follows.
-
-Sanity check arguments.  The interesting one is the group, which must
-be checked by some other module(s), initially just the embedding
-extension.  Use a new callback for this.  The callback functions will
-be passed a small structure containing the group ID and a Boolean
-value which is initially false.  If any of the callbacks recognize the
-ID, they should set the boolean to true.  If after the callbacks have
-been called the boolean is false, return an error, since nobody
-recognized it.
-
-Use the existing Xkey library function XkeyGenerateAuthorization to
-generate the new authorization.
-
-Use the existing os layer function AddAuthorization to add the new
-authorization to the server's internal database.
-
-Use the existing os layer function AuthorizationToID to retrieve the
-authorization ID that the os layer assigned to the new authorization.
-
-Change the os layer to use authorization IDs allocated from the
-server's ID range via FakeClientID(0) instead of using a simple
-incrementing integer.  This lets us use the resource database to
-attach additional information to an authorization without needing any
-changes to os data structures.
-
-Add the authorization ID as a server resource.  The structure for an
-authorization resource will contain the timeout, trust-level, and
-group sent in the request, a reference count of how many clients are
-connected with this authorization, a timer pointer, and time-remaining
-counter.
-
-Return the authorization ID and generated auth data to the client.
-
-
-\section{Client connection}
-
-The Security extension needs to be aware of new client connections
-primarily so that it copy the trust-level of the authorization that
-was used to the client structure.  The trust-level is needed in the
-client structure because it will be accessed frequently to make access
-control decisions for the client.  We will use the existing
-ClientStateCallback to catch new client connections.
-
-We also need to copy the authorization ID into the client structure.
-The authorization ID is already stored in an os private hung from the
-client, and we will add a new os function AuthorizationIDOfClient to
-retrieve it.  However, when a client disconnects, this os private is
-already gone before ClientStateCallbacks are called.  We need the
-authorization ID at client disconnect time for reasons described
-below.
-
-Now that we know what needs to be done and why, let's walk through
-the sequnce of events.
-
-When a new client connects, get the authorization ID with
-AuthorizationIDOfClient, store it in the client, then pass that ID to
-LookupIDByType to find the authorization.  If we get a non-NULL
-pointer back, this is a generated authorization, not one of the
-predefined ones in the server's authority file.  In this case,
-increment the authorization's reference count.  If the reference count
-is now 1, cancel the timer for this authorization using the trivial
-new os layer function TimerCancel.  Lastly, copy the trust-level of
-this authorization into the client structure so that it can be reached
-quickly for future access control decisions.
-
-The embedding extension can determine the group to use for a new
-client in the same way that we determined the trust level: get the
-authorization ID, look it up, and if that succeeds, pluck the group
-out of the returned authorization structure.
-
-\section{Client disconnection}
-
-Use the existing ClientStateCallback to catch client disconnections.
-If the client was using a generated authorization, decrement its
-reference count.  If the reference count is now zero, use the existing
-os layer function TimerSet to start a timer to count down the timeout
-period for this authorization.  Record the timer ID for this
-authorization.  When the timer fires, the authorization should be
-freed, removing all traces of it from the server.
-
-There is a slight complication regarding the timeout because the timer
-interface in the server allows for 32 bits worth of milliseconds,
-while the timeout specified in GenerateAuthorization has 32 bits worth
-of seconds.  To handle this, if the specified time is more than the
-timer interface can handle, the maximum possible timeout will be set,
-and time-remaining counter for this authorization will be used to
-track the leftover part.  When the timer fires, it should first check
-to see if there is any leftover time to wait.  If there is, it should
-set another timer to the minimum of (the maximum possible timeout) and
-the time remaining, and not do the revocation yet.
-
-\section{Resource ID security}
-
-To implement the restriction that untrusted clients cannot access
-resources of trusted clients, we add two new functions to dix:
-SecurityLookupIDByType and SecurityLookupIDByClass.  Hereafter we will
-use SecurityLookupID to refer to both functions.  In addition to the
-parameters of the existing LookupID functions, these functions also
-take a pointer to the client doing the lookup, and an access mode that
-conveys a high-level idea of what the client intends to do with the
-resource (currently just read, write, destroy, and unknown).  Passing
-NullClient for the client turns off access checks.  SecurityLookupID
-can return NULL for two reasons: the resource doesn't exist, or it
-does but the client isn't allowed to access it.  The caller cannot
-tell the difference.  Most places in dix call these new lookup
-functions instead of the old LookupID, which continue to do no access
-checking.  Extension ``Proc'' functions should probably use
-SecurityLookupID, not LookupID.  Ddxen can continue to use LookupID.
-
-Inside SecurityLookupID, the function client$->$CheckAccess is called
-passing the client, resource id, resource type/class, resource value,
-and access mode.  CheckAccess returns the resource value if access is
-allowed, else it returns NULL.  The entire resource ID security policy
-of the Security extension can be replaced by plugging in your own
-access decision function here.  This in combination with the access
-mode parameter should be enough to implement a more traditional DAC
-(discretionary access control) policy.
-
-Since we need client and access mode information to do access
-controlled resource lookups, we add (and use) several other macros and
-functions that parallel existing ones with the addition of the missing
-information.  The list includes SECURITY\_VERIFY\_GC,
-SECURITY\_VERIFY\_DRAWABLE, SECURITY\_VERIFY\_GEOMETRABLE,
-SecurityLookupWindow, SecurityLookupDrawable, and dixChangeGC.  The
-dixChangeGC interface is worth mentioning because in addition to a
-client parameter, we introduce a pointer-to-union parameter that
-should let us eliminate the warnings that some compilers give when you
-assign small integers to pointers, as the DoChangeGC interface
-required.  For more details, see the comment preceding dixChangeGC in
-dix/gc.c.
-
-If XCSECURITY is not defined (the Security extension is not being
-built), the server uses essentially the same code as before for
-resource lookups.
-
-\section{Extension security}
-
-A new field in the ExtensionEntry structure, Bool secure, tells
-whether the extension is considered secure.  It is initialized to
-FALSE by AddExtension.  The following new dix function can be used to
-set the secure field:
-
-void DeclareExtensionSecurity(char *extname, Bool secure)
-
-The name of the extension and the desired value of the secure field
-are passed.  If an extension is secure, a call to this function with
-secure = TRUE will typically appear right after the call to
-AddExtension.  DeclareExtensionSecurity should be called during server
-reset.  It should not be called after the first client has connected.
-Passing the name of an extension that has not been initialized has no
-effect (the secure value will not be remembered in case the extension
-is later initialized).
-
-For untrusted clients, ProcListExtensions omits extensions that have
-secure = FALSE, and ProcQueryExtension reports that such extensions
-don't exist.
-
-To prevent untrusted clients from using extensions by guessing their
-major opcode, one of two new Proc vectors are used by untusted
-clients, UntrusedProcVector and SwappedUntrustedProcVector.  These
-have the same contents as ProcVector and SwappedProcVector
-respectively for the first 128 entries.  Entries 128 through 255 are
-initialized to ProcBadRequest.  If DeclareExtensionSecurity is called
-with secure = TRUE, that extension's dispatch function is plugged
-into the appropriate entry so that the extension can be used.  If
-DeclareExtensionSecurity is called with secure = FALSE, the
-appropriate entry is reset to ProcBadRequest.
-
-Now we can explain why DeclareExtensionSecurity should not be called
-after the first client connects.  In some cases, the Record extension
-gives clients a private copy of the proc vector, which it then changes
-to intercept certain requests.  Changing entries in UntrusedProcVector
-and SwappedUntrustedProcVector will have no effect on these copied
-proc vectors.  If we get to the point of needing an extension request
-to control which extensions are secure, we'll need to invent a way to
-get those copied proc vectors changed.
-
-\end{document}
diff --git a/specs/Xserver/secint.xml b/specs/Xserver/secint.xml
new file mode 100644
index 0000000..643d1dc
--- /dev/null
+++ b/specs/Xserver/secint.xml
@@ -0,0 +1,294 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
+
+
+<!--translated from secint.tex, on 2010-06-27 15:38:00,
+by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)
+xhtml,docbook,html,refcaption -->
+
+<book id="secint">
+
+<bookinfo>
+   <title>Security Extension Server Design Draft</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>June 27, 2010</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>David</firstname><surname>Wiggins</surname>
+      </author>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1996</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 3.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 7</productnumber>
+
+<legalnotice>
+<para>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 OF OR OTHER DEALINGS IN THE
+SOFTWARE.
+</para>
+<para>Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or other
+dealings in this Software without prior written authorization from the X
+Consortium.
+</para>
+
+</legalnotice>
+
+<abstract>
+<para>This paper describes the implementation strategy used to implement
+     various pieces of the SECURITY Extension.
+</para>
+</abstract>
+
+</bookinfo>
+
+
+<chapter id="generate_authorization_request">
+<title>Generate Authorization Request</title>
+
+<para>
+The major steps taken to execute this request are as follows.
+</para>
+
+<para>
+Sanity check arguments. The interesting one is the group, which must be
+checked by some other module(s), initially just the embedding extension.
+Use a new callback for this. The callback functions will be passed a small
+structure containing the group ID and a Boolean value which is initially
+false. If any of the callbacks recognize the ID, they should set the boolean
+to true. If after the callbacks have been called the boolean is false, return
+an error, since nobody recognized it.
+</para>
+
+<para>
+Use the existing Xkey library function XkeyGenerateAuthorization to generate
+the new authorization.
+</para>
+
+<para>
+Use the existing os layer function AddAuthorization to add the new
+authorization to the server's internal database.
+</para>
+
+<para>
+Use the existing os layer function AuthorizationToID to retrieve
+the authorization ID that the os layer assigned to the new authorization.
+</para>
+
+<para>Change the os layer to use authorization IDs allocated from the
+server's ID range via FakeClientID(0) instead of using a simple incrementing
+integer. This lets us use the resource database to attach additional
+information to an authorization without needing any changes to os
+data structures.
+</para>
+
+<para>
+Add the authorization ID as a server resource. The structure for an
+authorization resource will contain the timeout, trust-level, and group
+sent in the request, a reference count of how many clients are connected
+with this authorization, a timer pointer, and time-remaining counter.
+</para>
+
+<para>
+Return the authorization ID and generated auth data to the client.
+</para>
+
+</chapter>
+<chapter id="client_connection">
+<title>Client Connection</title>
+
+<para>
+The Security extension needs to be aware of new client connections
+primarily so that it copy the trust-level of the authorization that was
+used to the client structure.  The trust-level is needed in the client
+structure because it will be accessed frequently to make access control
+decisions for the client. We will use the existing ClientStateCallback
+to catch new client connections.
+</para>
+
+<para>
+We also need to copy the authorization ID into the client structure. The
+authorization ID is already stored in an os private hung from the client,
+and we will add a new os function AuthorizationIDOfClient to retrieve it.
+However, when a client disconnects, this os private is already gone before
+ClientStateCallbacks are called. We need the authorization ID at client
+disconnect time for reasons described below.
+</para>
+
+<para>
+Now that we know what needs to be done and why, let's walk through the
+sequnce of events.
+</para>
+
+<para>
+When a new client connects, get the authorization ID with
+AuthorizationIDOfClient, store it in the client, then pass that ID to
+LookupIDByType to find the authorization. If we get a non-NULL pointer
+back, this is a generated authorization, not one of the predefined ones in
+the server's authority file. In this case, increment the authorization's
+reference count. If the reference count is now 1, cancel the timer
+for this authorization using the trivial new os layer function TimerCancel.
+Lastly, copy the trust-level of this authorization into the client structure
+so that it can be reached quickly for future access control decisions.
+</para>
+
+<para>
+The embedding extension can determine the group to use for a new client in
+the same way that we determined the trust level: get the authorization ID,
+look it up, and if that succeeds, pluck the group out of the returned
+authorization structure.
+</para>
+</chapter>
+
+<chapter id="client_disconnection">
+<title>Client disconnection</title>
+
+<para>
+Use the existing ClientStateCallback to catch client disconnections. If the
+client was using a generated authorization, decrement its reference count.
+If the reference count is now zero, use the existing os layer function
+TimerSet to start a timer to count down the timeout period for this
+authorization. Record the timer ID for this authorization. When the timer
+fires, the authorization should be freed, removing all
+traces of it from the server.
+</para>
+
+<para>
+There is a slight complication regarding the timeout because the timer
+interface in the server allows for 32 bits worth of milliseconds, while
+the timeout specified in GenerateAuthorization has 32 bits worth of seconds.
+To handle this, if the specified time is more than the timer interface can
+handle, the maximum possible timeout will be set, and time-remaining counter
+for this authorization will be used to track the leftover part. When the
+timer fires, it should first check to see if there is any leftover
+time to wait. If there is, it should set another timer to the minimum of (the
+maximum possible timeout) and the time remaining, and not do the revocation
+yet.
+</para>
+</chapter>
+
+<chapter id="resource_id_security">
+<title>Resource ID Security</title>
+
+<para>
+To implement the restriction that untrusted clients cannot access resources
+of trusted clients, we add two new functions to dix: SecurityLookupIDByType
+and SecurityLookupIDByClass. Hereafter we will use SecurityLookupID to refer
+to both functions. In addition to the parameters of the existing LookupID
+functions, these functions also take a pointer to the client doing the lookup,
+and an access mode that conveys a high-level idea of what the client intends
+to do with the resource (currently just read, write, destroy, and unknown).
+Passing NullClient for the client turns off access checks. SecurityLookupID can
+return NULL for two reasons: the resource doesn't exist, or it does but the
+client isn't allowed to access it. The caller cannot tell the difference. Most
+places in dix call these new lookup functions instead of the old LookupID,
+which continue to do no access checking. Extension "Proc" functions should
+probably use SecurityLookupID, not LookupID. Ddxen can continue to use
+LookupID.
+</para>
+
+<para>
+Inside SecurityLookupID, the function client -&gt; CheckAccess is called
+passing the client, resource id, resource type/class, resource value, and
+access mode. CheckAccess returns the resource value if access is allowed,
+else it returns NULL. The entire resource ID security policy of the Security
+extension can be replaced by plugging in your own access decision function
+here. This in combination with the access mode parameter should be enough to
+implement a more traditional DAC (discretionary access control) policy.
+</para>
+
+<para>
+Since we need client and access mode information to do access controlled
+resource lookups, we add (and use) several other macros and functions that
+parallel existing ones with the addition of the missing information. The list
+includes SECURITY_VERIFY_GC, SECURITY_VERIFY_DRAWABLE,
+SECURITY_VERIFY_GEOMETRABLE, SecurityLookupWindow,
+SecurityLookupDrawable, and dixChangeGC. The dixChangeGC interface is
+worth mentioning because in addition to a client parameter, we introduce a
+pointer-to-union parameter that should let us eliminate the warnings that some
+compilers give when you assign small integers to pointers, as the DoChangeGC
+interface required. For more details, see the comment preceding dixChangeGC in
+;&lt;dix/gc.c;&gt;.
+</para>
+
+<para>
+If XCSECURITY is not defined (the Security extension is not being built),
+the server uses essentially the same code as before for resource lookups.
+</para>
+
+</chapter>
+<chapter id="extension_security">
+<title>Extension Security</title>
+
+<para>
+A new field in the ExtensionEntry structure, Bool secure, tells whether the
+extension is considered secure. It is initialized to FALSE by AddExtension.
+The following new dix function can be used to set the secure field:
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>DeclareExtensionSecurity</function></funcdef>
+    <paramdef>char <parameter> *extname</parameter></paramdef>
+    <paramdef>Bool <parameter>secure</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+The name of the extension and the desired value of the secure field are
+passed. If an extension is secure, a call to this function with
+secure = TRUE will typically appear right after the call to
+<function>AddExtension</function>.
+<function>DeclareExtensionSecurity</function>
+should be called during server reset. It should not
+be called after the first client has connected. Passing the name of an
+extension that has not been initialized has no effect (the secure value will
+not be remembered in case the extension is later initialized).
+</para>
+
+<para>
+For untrusted clients, <function>ProcListExtensions</function> omits
+extensions that have secure = FALSE, and
+<function>ProcQueryExtension</function> reports that such
+extensions don't exist.
+</para>
+
+<para>
+To prevent untrusted clients from using extensions by guessing their major
+opcode, one of two new Proc vectors are used by untusted clients,
+<function>UntrusedProcVector</function> and
+<function>SwappedUntrustedProcVector</function>. These have the same contents
+as <function>ProcVector</function> and
+<function>SwappedProcVector</function> respectively for the first 128
+entries. Entries 128 through 255 are initialized to ProcBadRequest. If
+<function>DeclareExtensionSecurity</function> is called with secure =
+TRUE, that extension's dispatch function is plugged into the appropriate entry
+so that the extension can be used. If
+<function>DeclareExtensionSecurity</function> is called with secure =
+FALSE, the appropriate entry is reset to ProcBadRequest.
+</para>
+
+<para>
+Now we can explain why <function>DeclareExtensionSecurity</function>
+should not be called after the first client connects. In some cases,
+the Record extension gives clients a private copy of the proc vector,
+which it then changes to intercept certain requests. Changing entries in
+<function>UntrusedProcVector</function> and
+<function>SwappedUntrustedProcVector</function> will have no effect on these
+copied proc vectors. If we get to the point of needing an extension request
+to control which extensions are secure, we'll need to invent a way to
+get those copied proc vectors changed.
+</para>
+</chapter>
+</book>
+
+