.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.coopersm...@oracle.com> Date: Fri Oct 29 21:29:15 2010 -0700 fontsproto 2.1.1 Signed-off-by: Alan Coopersmith <alan.coopersm...@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.coopersm...@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.coopersm...@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 <m...@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 <mems...@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> -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1pdqcs-0002vn...@alioth.debian.org