x11proto-fonts: Changes to 'upstream-unstable'
.gitignore | 78 -
Makefile.am | 13
README | 25
configure.ac | 21
specs/.gitignore | 5
specs/Makefile.am | 64
specs/fsproto.xml | 4084 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 4271 insertions(+), 19 deletions(-)
New commits:
commit 2fce721a9a0c0ff820f2cbbf7309990c25852f02
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Fri Oct 29 21:29:15 2010 -0700
fontsproto 2.1.1
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index f74105b..1719886 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,6 @@
AC_PREREQ([2.60])
-AC_INIT([FontsProto], [2.1.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([FontsProto], [2.1.1],
+ [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit aa59b49bb7673ba7ae1ddd8f3b182ec6ba95b5e0
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Fri Oct 29 21:26:13 2010 -0700
fsproto.xml: Convert ASCII art figures to UTF-8 line drawings
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/specs/fsproto.xml b/specs/fsproto.xml
index de45f96..95530f1 100644
--- a/specs/fsproto.xml
+++ b/specs/fsproto.xml
@@ -142,20 +142,20 @@ as printer drivers).
</para>
<literallayout class="monospaced">
- +--------+ +---------------+
- | X1 |--------------| |
- | Server | | Font Server |
- +--------+ +-------| 1 |
- | +---------------+
- +--------+ |
- | X2 |------+ +---------------+
- | Server |--------------| |
- +--------+ | Font Server |
- +-------| 2 |
-+---------+ | +---------------+
-| other | |
-| clients |------+
-+---------+
+ ┌────────┐ ┌───────────────┐
+ │ X1 ├──────────────┤ │
+ │ Server │ │ Font Server │
+ └────────┘ ┌───────┤ 1 │
+ │ └───────────────┘
+ ┌────────┐ │
+ │ X2 ├──────┘ ┌───────────────┐
+ │ Server ├──────────────┤ │
+ └────────┘ │ Font Server │
+ ┌───────┤ 2 │
+┌─────────┐ │ └───────────────┘
+│ other │ │
+│ clients ├──────┘
+└─────────┘
</literallayout>
<para>
@@ -185,27 +185,27 @@ Figure 2.2.
</para>
<literallayout class="monospaced">
- +------------+
- | client |
- | (X server) |
- +------------+
- |
+ ┌────────────┐
+ │ client │
+ │ (X server) │
+ └─────┬──────┘
+ │
network
- |
-+--------------------------------------------+
-| |
-| font server 1 |
-| |
-+-----+-----+-----+-----+----+-----+---+-----+
-| bdf | snf | pcf | atm | f3 | dwf | | | ... |
-+-----+-----+-----+-----+----+-----+-|-+-----+
- |
+ │
+┌─────────────────────┴──────────────────────┐
+│ │
+│ font server 1 │
+│ │
+├─────┬─────┬─────┬─────┬────┬─────┬───┬─────┤
+│ bdf │ snf │ pcf │ atm │ f3 │ dwf │ │ │ ... │
+└─────┴─────┴─────┴─────┴────┴─────┴─│─┴─────┘
+ │
network
- |
- +----------+
- | font |
- | server 2 |
- +----------+
+ │
+ ┌─────┴────┐
+ │ font │
+ │ server 2 │
+ └──────────┘
</literallayout>
<para>
commit ddb2392d7a403595a78df46ee952f796a39b54ae
Author: Matt Dew <matt@osource.org>
Date: Mon Aug 9 12:10:20 2010 -0400
specs: convert protocol fsproto from xorg-docs to DocBook XML
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/Makefile.am b/Makefile.am
index c1ff54a..2714762 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,3 +1,5 @@
+SUBDIRS=specs
+
fontsdir = $(includedir)/X11/fonts
fonts_HEADERS = \
font.h \
diff --git a/configure.ac b/configure.ac
index 0bee874..f74105b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,11 +3,16 @@ AC_INIT([FontsProto], [2.1.0], [https://bugs.freedesktop.org/enter_bug.cgi?produ
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
-# Require xorg-macros: XORG_DEFAULT_OPTIONS
+# Require xorg-macros minimum of 1.10 for HAVE_STYLESHEETS in XORG_CHECK_SGML_DOCTOOLS
m4_ifndef([XORG_MACROS_VERSION],
- [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.3)
+ [m4_fatal([must install xorg-macros 1.10 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.10)
XORG_DEFAULT_OPTIONS
+XORG_ENABLE_SPECS
+XORG_WITH_XMLTO(0.0.20)
+XORG_WITH_FOP
+XORG_CHECK_SGML_DOCTOOLS(1.5)
AC_OUTPUT([Makefile
+ specs/Makefile
fontsproto.pc])
diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 0000000..09b6a89
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1,5 @@
+*.html
+*.ps
+*.pdf
+*.txt
+*.css
diff --git a/specs/Makefile.am b/specs/Makefile.am
new file mode 100644
index 0000000..516ece0
--- /dev/null
+++ b/specs/Makefile.am
@@ -0,0 +1,64 @@
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS 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.
+#
+
+if ENABLE_SPECS
+doc_sources = fsproto.xml
+dist_doc_DATA = $(doc_sources)
+
+if HAVE_XMLTO
+doc_DATA = $(doc_sources:.xml=.html)
+
+if HAVE_FOP
+doc_DATA += $(doc_sources:.xml=.ps) $(doc_sources:.xml=.pdf)
+endif
+
+if HAVE_XMLTO_TEXT
+doc_DATA += $(doc_sources:.xml=.txt)
+endif
+
+if HAVE_STYLESHEETS
+XMLTO_FLAGS = -m $(XSL_STYLESHEET)
+
+doc_DATA += xorg.css
+xorg.css: $(STYLESHEET_SRCDIR)/xorg.css
+ $(AM_V_GEN)cp -pf $(STYLESHEET_SRCDIR)/xorg.css $@
+endif
+
+CLEANFILES = $(doc_DATA)
+
+SUFFIXES = .xml .ps .pdf .txt .html
+
+.xml.txt:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) txt $<
+
+.xml.html:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) xhtml-nochunks $<
+
+.xml.pdf:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop pdf $<
+
+.xml.ps:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop ps $<
+
+endif HAVE_XMLTO
+endif ENABLE_SPECS
diff --git a/specs/fsproto.xml b/specs/fsproto.xml
new file mode 100644
index 0000000..de45f96
--- /dev/null
+++ b/specs/fsproto.xml
@@ -0,0 +1,4084 @@
+<?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="fsproto">
+
+<bookinfo>
+ <title>The X Font Service Protocol</title>
+ <subtitle>X Window System Standard</subtitle>
+ <releaseinfo>Version 2.0</releaseinfo>
+ <authorgroup>
+ <author>
+ <firstname>Jim</firstname><surname>Fulton</surname>
+ <affiliation><orgname>
+Network Computing Devices, Inc.
+ </orgname></affiliation>
+ </author>
+ </authorgroup>
+ <corpname>X Consortium Standard</corpname>
+ <copyright><year>1991</year><holder>Network Computing Devices, Inc.</holder></copyright>
+ <copyright><year>1994</year><holder>X Consortium</holder></copyright>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ <productnumber>X Version 11, Release 6.8</productnumber>
+ <edition>Revised May 2, 1994</edition>
+
+<legalnotice>
+
+<para>
+Permission to use, copy, modify, distribute, and sell this
+documentation for any purpose is hereby granted without fee,
+provided that the above copyright notice and this permission
+notice appear in all copies. Network Computing Devices, Inc.
+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>
+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>
+<title>TITLE</title>
+<sect1 id="introduction">
+<title>Introduction</title>
+<para>
+The management of fonts in large, heterogeneous environments is one of the
+hardest aspects of using the X Window System
+<footnote><para>
+<emphasis remap='I'>X Window System</emphasis>
+is a trademark of The Open Group.
+</para></footnote>
+. Multiple formats and the lack of
+a consistent mechanism for exporting font data to all displays on a network
+prevent the transparent use of applications across different display platforms.
+The X Font Service protocol is designed to address this and other issues, with
+specific emphasis on the needs of the core X protocol. Upward-compatible
+changes (typically in the form of new requests) are expected as consensus is
+reached on new features (particularly outline font support).
+</para>
+<para>
+Currently, most X displays use network file protocols such as NFS and TFTP to
+obtain raw font data which they parse directly. Since a common binary format
+for this data doesn't exist, displays must be able to interpret a variety of
+formats if they are to be used with different application hosts. This leads to
+wasted code and data space and a loss of interoperability as displays are used
+in unforeseen environments.
+</para>
+<para>
+By moving the interpretation of font data out of the X server into a separate
+service on the network, these problems can be greatly reduced. In addition,
+new technologies, such as dynamically generating bitmaps from scaled or outline
+fonts, can be provided to all displays transparently. For horizontal text,
+caching techniques and increased processor power can potentially make
+rasterization more efficient on large, centralized hosts than on individual
+displays.
+</para>
+<para>
+Each font server provides sets of fonts that may be listed and queried for
+header, property, glyph extents, and bitmap information. This data is
+transmitted over the network using a binary format (with variations to support
+different bit- and byte-orders) designed to minimize the amount of processing
+required by the display. Since the font server, rather than the display, is
+responsible for parsing the raw font data, new formats can be used by all
+displays by modifying a single font server.
+</para>
+<para>
+From the user's point of view, font servers are simply a new type of name in
+the X font path. Network name services allow descriptive names (such as
+DEPARTMENT-FONTS or APPLICATION-FONTS) to be translated into proper network
+addresses. X displays send requests to and read replies from the font server
+rather than reading directly from files. Since the X Font Service protocol is
+designed to allow subsets of the font data to be requested, displays may easily
+implement a variety of strategies for fine-grained demand-loading of glyphs.
+</para>
+</sect1>
+
+<sect1 id="architectural_model">
+<title>Architectural Model</title>
+<!-- .XS -->
+<!-- (SN Architectural Model -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+In this document, the words "client" and "server" refer to the consumer and
+provider of a font, respectively, unless otherwise indicated. It is important
+to note that in this context, the X server is also a font client.
+</para>
+<para>
+The X Font Service protocol does not require any changes to the core X protocol
+or to any applications. To the user, font servers are simply additional types
+of font path elements. As such, X servers may connect to multiple font
+servers, as shown in Figure 2.1. Although the font protocol is geared towards
+the X Window System, it may be also used by other consumers of font data (such
+as printer drivers).
+</para>
+
+<literallayout class="monospaced">
+ +--------+ +---------------+
+ | X1 |--------------| |
+ | Server | | Font Server |
+ +--------+ +-------| 1 |
+ | +---------------+
+ +--------+ |
+ | X2 |------+ +---------------+
+ | Server |--------------| |
+ +--------+ | Font Server |
+ +-------| 2 |
++---------+ | +---------------+
+| other | |
+| clients |------+
++---------+
+</literallayout>
+
+<para>
+Figure 2.1: Connecting to a Font Server
+</para>
+
+<para>
+<!-- .LP -->
+Clients communicate with the font server using the request/reply/event model
+over any mutually-understood virtual stream connection (such as TCP/IP, DECnet,
+<footnote><para>
+DECnet is a trademark of Digital Equipment Corporation.
+</para></footnote>
+etc.). Font servers are responsible for providing data in the bit and byte
+orders requested by the client. The set of requests and events provided in the
+first version of the X Font Service protocol is limited to supporting the needs
+of the bitmap-oriented core X Window System protocol. Extensions are expected
+as new needs evolve.
+</para>
+<para>
+<!-- .LP -->
+A font server reads raw font data from a variety of sources (possibly
+including other font servers) and converts it into a common format that is
+transmitted to the client using the protocol described in Section 4. New font
+formats are handled by adding new converters to a font server, as shown in
+Figure 2.2.
+</para>
+
+<literallayout class="monospaced">
+ +------------+
+ | client |
+ | (X server) |
+ +------------+
+ |
+ network
+ |
++--------------------------------------------+
+| |
+| font server 1 |
+| |
++-----+-----+-----+-----+----+-----+---+-----+
+| bdf | snf | pcf | atm | f3 | dwf | | | ... |
++-----+-----+-----+-----+----+-----+-|-+-----+
+ |
+ network
+ |
+ +----------+
+ | font |
+ | server 2 |
+ +----------+
+</literallayout>
+
+<para>
+Figure 2.2: Where Font Data Comes From
+</para>
+
+<para>
+The server may choose to provide named sets of fonts called "catalogues."
+Clients may specify which of the sets should be used in listing or opening a
+font.
+</para>
+
+<para>
+An event mechanism similar to that used in the X protocol is provided for
+asynchronous notification of clients by the server.
+</para>
+
+<para>
+<!-- .LP -->
+Clients may provide authorization data for the server to be used in determining
+(according to the server's licensing policy) whether or not access should be
+granted to particular fonts. This is particularly useful for clients whose
+authorization changes over time (such as an X server that can verify the
+identity of the user).
+</para>
+<para>
+<!-- .LP -->
+Implementations that wish to provide additional requests or events may use the
+extension mechanism. Adding to the core font service protocol (with the
+accompanying change in the major or minor version numbers) is reserved to the X
+Consortium.
+</para>
+</sect1>
+
+<sect1 id="font_server_naming">
+<title>Font Server Naming</title>
+<!-- .XS -->
+<!-- (SN Font Server Naming -->
+<!-- .XE -->
+<para>
+Font clients that expose font server names to the user are encouraged to
+provide ways of naming font servers symbolically (e.g. DEPARTMENT-FONTS).
+However, for environments that lack appropriate name services
+transport-specific names are necessary. Since these names do occur in the
+protocol, clients and servers should support at least the applicable formats
+described below. Formats for additional transports may be registered with the
+X Consortium.
+</para>
+
+<sect2 id="tcpip_names">
+<title>TCP/IP Names</title>
+<!-- .XS -->
+<!-- (SN TCP/IP Names -->
+<!-- .XE -->
+<para>
+The following syntax should be used for TCP/IP names:
+</para>
+
+<literallayout class="monospaced">
+ <TCP name> ::= "tcp/" <hostname>":" <ipportnumber> ["/" <cataloguelist>]
+</literallayout>
+
+<para>
+where <hostname> is either symbolic (such as expo.lcs.mit.edu) or numeric
+decimal (such as 18.30.0.212). The <ipportnumber> is the port on
+which the
+font server is listening for connections. The <cataloguelist> string at
+the end is optional and specifies a plus-separated list of catalogues
+that may be requested. For example:
+</para>
+<literallayout class="monospaced">
+ tcp/expo.lcs.mit.edu:8012/available+special
+ tcp/18.30.0.212:7890
+</literallayout>
+</sect2>
+
+<sect2 id="decnet_names">
+<title>DECnet Names</title>
+<!-- .XS -->
+<!-- (SN DECnet Names -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The following syntax should be used for DECnet names:
+</para>
+<literallayout class="monospaced">
+ <DECnet name> ::= "decnet/" <nodename> "::font$" <objname>
+ ["/" <cataloguelist>]
+</literallayout>
+<para>
+where <nodename> is either symbolic (such as SRVNOD) or the
+numeric decimal
+form of the DECnet address (such as 44.70). The <objname> is normal,
+case-insensitive DECnet object name. The <cataloguelist> string
+at the end is
+optional and specifies a plus-separated list of catalogues that may be
+requested. For example:
+</para>
+
+<literallayout class="monospaced">
+ DECNET/SRVNOD::FONT$DEFAULT/AVAILABLE
+ decnet/44.70::font$other
+</literallayout>
+</sect2>
+</sect1>
+
+<sect1 id="protocol">
+<title>Protocol</title>
+<!-- .XS -->
+<!-- (SN Protocol -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The protocol described below uses the request/reply/error model and is
+specified using the same conventions outlined in Section 2 of the core X Window
+System protocol [1]:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+<!-- .IP \(bu 5 -->
+Data type names are spelled in upper case with no word separators,
+as in: FONTID
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IP \(bu 5 -->
+Alternate values are capitalized with no word separators,
+as in: MaxWidth
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IP \(bu 5 -->
+Structure element declarations are in lower case with hyphens
+as word separators, as in: byte-order-msb
+ </para>
+ <note>
+ <para>
+Structure element names are referred to in
+upper case (e.g. BYTE-ORDER-MSB) when used in
+descriptions to set them off from the surrounding
+text. When this document is typeset they will be
+printed in lower case in a distinct font.
+ </para>
+ </note>
+ </listitem>
+ <listitem>
+ <para>
+Type declarations have the form "name: type",
+as in: CARD8: 8-bit byte
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Comma-separated lists of alternate values are enclosed in
+braces, as in: { Min, MaxWidth, Max }
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Comma-separated lists of structure elements are enclosed in
+brackets, as in: [ byte1: CARD8, byte2: CARD8 ]
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+<!-- .LP -->
+A type with a prefix "LISTof" represents a counted list of
+elements of that type, as in: LISTofCARD8
+</para>
+
+<sect2 id="data_types">
+<title>Data Types</title>
+<!-- .XS -->
+<!-- (SN Data Types -->
+<!-- .XE -->
+<para>
+The following data types are used in the core X Font Server protocol:
+</para>
+
+<literallayout class="monospaced">
+ACCESSCONTEXT: ID
+</literallayout>
+<blockquote>
+<para>
+This value is specified in the CreateAC request as the identifier
+to be used when referring to a particular AccessContext resource
+within the server. These resources are used by the server to
+store client-specified authorization information. This
+information may be used by the server to determine whether or not
+the client should be granted access to particular font data.
+</para>
+<para>
+<!-- .sp -->
+In order to preserve the integrity of font licensing being performed by
+the font server, care must be taken by a client to properly represent the
+identity of the true user of the font. Some font clients will in fact
+be servers (for example, X servers) requesting fonts for their own clients.
+Other font clients may be doing work on behalf of a number of different
+users over time (for example, print spoolers).
+</para>
+<para>
+<!-- .sp -->
+<function>AccessContexts </function>
+must be created (with
+<function>CreateAC ) </function>
+and switched among (with
+<function>SetAuthorization )</function>
+to represent all of these "font users" properly.
+ </para>
+</blockquote>
+
+<literallayout class="monospaced">
+ALTERNATESERVER: [ name: STRING8,
+ subset: BOOL ]
+</literallayout>
+
+<blockquote>
+ <para>
+This structure specifies the NAME, encoded in ISO 8859-1 according
+to Section 3, of another font server that may be useful as a
+substitute for this font server. The SUBSET field indicates
+whether or not the alternate server is likely to only contain a
+subset of the fonts available from this font server. This
+information is returned during the initial connection setup and
+may be used by the client to find a backup server in case of
+failure.
+ </para>
+</blockquote>
+
+<literallayout class="monospaced">
+AUTH: [ name: STRING8,
+ data: LISTofBYTE ]
+</literallayout>
+
+<blockquote>
+<para>
+This structure specifies the name of an authorization protocol and
+initial data for that protocol. It is used in the authorization
+negotiation in the initial connection setup and in the CreateAC
+request.
+</para>
+</blockquote>
+
+<literallayout class="monospaced">
+BITMAPFORMAT:
+</literallayout>
+
+<literallayout class="monospaced">
+ CARD32 containing the following fields defined by the
+ sets of values given further below
+ [
+ byte-order-msb: 1 bit,
+ bit-order-msb: 1 bit,
+ image-rect: 2 bits { Min,
+ MaxWidth,
+ Max },
+ zero-pad: 4 bits,
+ scanline-pad: 2 bits { ScanlinePad8,
+ ScanlinePad16,
+ ScanlinePad32,
+ ScanlinePad64 },
+ zero-pad: 2 bits,
+ scanline-unit: 2 bits { ScanlineUnit8,
+ ScanlineUnit16,
+ ScanlineUnit32,
+ ScanlineUnit64 },
+ zero-pad: 2 bits,
+ zero-pad: 16 bits,
+ ]
+</literallayout>
+
+<blockquote>
+<para>
+This structure specifies how glyph images are transmitted in
+response to
+<function>QueryXBitmaps8 </function>
+and
+<function>QueryXBitmaps16 </function>
+requests.
+</para>
+<para>
+<!-- .sp -->
+If the BYTE-ORDER-MSB bit (1 << 0) is set, the Most Significant
+Byte of each scanline unit is returned first. Otherwise, the
+Least Significant Byte is returned first.
+</para>
+<para>
+<!-- .sp -->
+If the BIT-ORDER-MSB bit (1 << 1) is set, the left-most bit in
+each glyph scanline unit is stored in the Most Significant Bit of
+each transmitted scanline unit. Otherwise, the left-most bit is
+stored in the Least Significant Bit.
+</para>
+<para>
+<!-- .sp -->
+The IMAGE-RECT field specifies a rectangle of pixels within the
+glyph image. It contains one of the following alternate values:
+</para>
+
+<literallayout class="monospaced">
+ ImageRectMin (0 << 2)
+ ImageRectMaxWidth (1 << 2)
+ ImageRectMax (2 << 2)
+</literallayout>
+<para>
+For a glyph with extents XCHARINFO in a font with header information
+XFONTINFO, the IMAGE-RECT values have the following meanings:
+</para>
+<para>
+<function>ImageRectMin -</function>
+This refers to the minimal bounding rectangle
+surrounding the inked pixels in the glyph. This is the
+most compact representation. The edges of the rectangle
+are:
+</para>
+<literallayout class="monospaced">
+ left: XCHARINFO.LBEARING
+ right: XCHARINFO.RBEARING
+ top: XCHARINFO.ASCENT
+ bottom: XCHARINFO.DESCENT
+</literallayout>
+<para>
+
+<function>ImageRectMaxWidth - </function>
+This refers to the scanlines between the
+glyph's ascent and descent, padded on the left to the minimum
+left-bearing (or 0, whichever is less) and on the right to
+the maximum right-bearing (or logical-width, whichever is
+greater). All glyph images share a common horizontal
+origin. This is a combination of ImageRectMax in the
+horizontal direction and ImageRectMin in the vertical
+direction. The edges of the rectangle are:
+</para>
+
+<literallayout class="monospaced">
+left: min (XFONTINFO.MIN-BOUNDS.LBEARING, 0)
+right: max (XFONTINFO.MAX-BOUNDS.RBEARING,
+ XFONTINFO.MAX-BOUNDS.WIDTH)
+top: XCHARINFO.ASCENT
+bottom: XCHARINFO.DESCENT
+</literallayout>
+
+<para>
+ImageRectMax - This refers to all scanlines, from the maximum
+ascent (or the font ascent, whichever is greater) to the
+maximum descent (or the font descent, whichever is greater),
+padded to the same horizontal extents as MaxWidth.
+All glyph images have the same sized bitmap and share a
+common origin. This is the least compact representation,
+but may be the easiest or most efficient (particularly for
+character cell fonts) for some clients to use. The edges of
+the rectangle are:
+</para>
+
+<literallayout class="monospaced">
+left: min (XFONTINFO.MIN-BOUNDS.LBEARING, 0)
+right: max (XFONTINFO.MAX-BOUNDS.RBEARING,
+ XFONTINFO.MAX-BOUNDS.WIDTH)
+top: max (XFONTINFO.FONT-ASCENT,
+ XFONTINFO.MAX-BOUNDS.ASCENT)
+bottom: max (XFONTINFO.FONT-DESCENT,
+ XFONTINFO.MAX-BOUNDS.DESCENT)
+</literallayout>
+<para>
+The SCANLINE-PAD field specifies the number of bits (8, 16, 32,
+or 64) to which each glyph scanline is padded before transmitting.
+It contains one of the following alternate values:
+</para>
+<literallayout class="monospaced">
+ ScanlinePad8 (0 << 8)
+ ScanlinePad16 (1 << 8)
+ ScanlinePad32 (2 << 8)
+ ScanlinePad64 (3 << 8)
+</literallayout>
+<para>
+The SCANLINE-UNIT field specifies the number of bits (8, 16, 32,
+or 64) that should be treated as a unit for swapping. This value
+must be less than or equal to the number of bits specified by the
+SCANLINE-PAD. It contains one of the following alternate values:
+</para>
+
+<literallayout class="monospaced">
+ ScanlineUnit8 (0 << 12)
+ ScanlineUnit16 (1 << 12)
+ ScanlineUnit32 (2 << 12)
+ ScanlineUnit64 (3 << 12)
+</literallayout>
+<para>
+BITMAPFORMATs are byte-swapped as CARD32s. All unspecified bits
+must be zero.
+</para>
+<para>
+Use of an invalid BITMAPFORMAT causes a Format error to
+be returned.
+</para>
+</blockquote>
+<para>
+BITMAPFORMATMASK: CARD32 mask
+</para>
+<blockquote>
+<para>
+This is a mask of bits representing the fields in a BITMAPFORMAT:
+</para>
+</blockquote>
+<literallayout class="monospaced">
+ ByteOrderMask (1 << 0)
+ BitOrderMask (1 << 1)
+ ImageRectMask (1 << 2)
+ ScanlinePadMask (1 << 3)
+ ScanlineUnitMask (1 << 4)
+</literallayout>
+<para>
+Unspecified bits are required to be zero or else a Format error
+is returned.
+</para>
+<para>
+BOOL: CARD8
+</para>
+<blockquote>
+<para>
+This is a boolean value containing one of the following alternate
+values:
+</para>
+
+<literallayout class="monospaced">
+ False 0
+ True 1
+</literallayout>
+</blockquote>
+
+<para>
+BYTE: 8-bit value
+</para>
+
+<blockquote>
+<para>
+This is an unsigned byte of data whose encoding
+is determined by the context in which it is used.
+</para>
+</blockquote>
+
+<para>
+CARD8: 8-bit unsigned integer
+</para>
+
+<para>
+CARD16: 16-bit unsigned integer
+</para>
+
+<para>
+CARD32: 32-bit unsigned integer
+</para>
+
+<blockquote>
+<para>
+These are unsigned numbers. The latter two are byte-swapped when
+the server and client have different byte orders.
+</para>
+</blockquote>
+
+<para>
+CHAR2B: [ byte1, byte2: CARD8 ]
+</para>
+<blockquote>
+<para>
+This structure specifies an individual character code within
+either a 2-dimensional matrix (using BYTE1 and BYTE2 as the row
+and column indices, respectively) or a vector (using BYTE1 and
+BYTE2 as most- and least-significant bytes, respectively). This
+data type is treated as a pair of 8-bit values and is never
+byte-swapped. Therefore, the client should always transmit BYTE1
+first.
+</para>
+</blockquote>
+
+<para>
+EVENTMASK: CARD32 mask
+</para>
+
+<blockquote>
+<para>
+This is a mask of bits indicating which of an extension's (or the
+core's) maskable events the client would like to receive. Each
+bit indicates one or more events, and a bit value of one indicates
+interest in a corresponding set of events. The following bits are
+defined for event masks specified for the core protocol (i.e. an
+EXTENSION-OPCODE of zero in
+<function>SetEventMask </function>
+and
+<function>GetEventMask </function>
+requests):
+</para>
+
+<literallayout class="monospaced">
+ CatalogueListChangeMask (1 << 0)
+ FontListChangeMask (1 << 1)
+</literallayout>
+
+<para>
+If
+<function>CatalogueListChangeMask </function>
+is set, client is interested in
+receiving
+<function>CatalogueListNotify </function>
+events. If
+<function>FontListChangeMask </function>
+is set, the client is interested in
+receiving
+<function>FontListNotify </function>
+events.
+</para>
+<para>
+<!-- .sp -->
+Extensions that provide additional events may define their own
+event masks. These event masks have their own scope and may use
+the same bit values as the core or other extensions.
+<!-- .sp -->
+All unused bits must be set to zero. In
+<function>SetEventMask </function>
+requests, if
+any bits are set that are not defined for the extension (or core)
+for which this EVENTMASK is intended (according to the EXTENSION-
+OPCODE given in the
+<function>SetEventMask </function>
+request), an
+<function>EventMask </function>
+error is generated.
+<!-- .sp -->
+This value is swapped as a CARD32.
+ </para>
+</blockquote>
+
+<para>
Reply to: