summaryrefslogtreecommitdiff
path: root/specs
diff options
context:
space:
mode:
Diffstat (limited to 'specs')
-rw-r--r--specs/fsproto.xml28
1 files changed, 0 insertions, 28 deletions
diff --git a/specs/fsproto.xml b/specs/fsproto.xml
index 28661c9..5cbf614 100644
--- a/specs/fsproto.xml
+++ b/specs/fsproto.xml
@@ -125,7 +125,6 @@ implement a variety of strategies for fine-grained demand-loading of glyphs.
<!-- (SN Architectural Model -->
<!-- .XE -->
<para>
-<!-- .LP -->
In this document, the words <firstterm>client</firstterm> and
<firstterm>server</firstterm> refer to the consumer and
provider of a font, respectively, unless otherwise indicated. It is important
@@ -160,7 +159,6 @@ as printer drivers).
</figure>
<para>
-<!-- .LP -->
Clients communicate with the font server using the request/reply/event model
over any mutually-understood virtual stream connection (such as
<acronym>TCP/IP</acronym>, DECnet,
@@ -175,7 +173,6 @@ 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
@@ -223,7 +220,6 @@ 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
@@ -231,7 +227,6 @@ 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
@@ -287,7 +282,6 @@ that may be requested. For example:
<!-- (SN DECnet Names -->
<!-- .XE -->
<para>
-<!-- .LP -->
The following syntax should be used for DECnet names:
<literallayout class="monospaced">
@@ -318,7 +312,6 @@ requested. For example:
<!-- (SN Protocol -->
<!-- .XE -->
<para>
-<!-- .LP -->
The protocol described below uses the request/reply/error model and is
specified using the same conventions outlined in
<olink targetdoc='x11protocol' targetptr='Syntactic_Conventions'>Section 2
@@ -379,7 +372,6 @@ brackets, as in: [ <structfield>byte1</structfield>: <type>CARD8</type>,
</itemizedlist>
<para>
-<!-- .LP -->
A type with a prefix <quote>LISTof</quote> represents a counted list of
elements of that type, as in: <type>LISTofCARD8</type>
</para>
@@ -1480,13 +1472,11 @@ This structure is padded to 32-bit alignment.
<!-- (SN Requests -->
<!-- .XE -->
<para>
-<!-- .LP -->
This section describes the requests that may be sent by the client and the
replies or errors that are generated in response. Versions of the protocol
with the same major version are required to be upward-compatible.
</para>
<para>
-<!-- .LP -->
Every request on a given connection is implicitly assigned a sequence number,
starting with 1, that is used in replies, error, and events. Servers are
required to generate replies and errors in the order in which the corresponding
@@ -1519,7 +1509,6 @@ is followed by (LENGTH - 1) * 4 bytes of request-specific data. Unless
otherwise specified, unused bytes are not required to be zero.
</para>
<para>
-<!-- .LP -->
If a request packet contains too little or too much data, the server returns
a <link linkend="Errors:Length"><errorname>Length</errorname></link> error. If the server runs out of internal
resources (such as memory) while processing a request, it returns an
@@ -1539,14 +1528,12 @@ is encountered in processing a requests, the choice of which error is returned
is server-dependent.
</para>
<para>
-<!-- .LP -->
Core requests have MAJOR-OPCODE values between 0 and 127, inclusive. Extension
requests have MAJOR-OPCODE values between 128 and 255, inclusive, that are
assigned by by the server. All MINOR-OPCODE values in extension requests are
between 0 and 255, inclusive.
</para>
<para>
-<!-- .LP -->
Each reply is at least 8 bytes long and contains the following fields:
<informaltable frame='none'>
<?dbfo keep-together="always" ?>
@@ -1575,7 +1562,6 @@ fields described above are followed by (LENGTH - 2) * 4 bytes of additional
data.
</para>
<para>
-<!-- .LP -->
Requests that have replies are described using the following syntax:
<blockquote><para>
<emphasis role="bold"><function>RequestName</function></emphasis>
@@ -1609,7 +1595,6 @@ and the CreateAC request, ◀ indicates data sent by the client in response
to data sent by the server.
</para>
<para>
-<!-- .LP -->
The protocol begins with the establishment of a connection over a
mutually-understood virtual stream:
</para>
@@ -1732,7 +1717,6 @@ client (such as a challenge, authentication of the server,
etc.).
</para>
<para>
-<!-- .LP -->
If STATUS is <constant>Success</constant>, the following section of protocol
is omitted. Otherwise, if STATUS is <constant>Continue</constant>, the server expects
more authorization data from the client (i.e. the connection
@@ -1759,7 +1743,6 @@ either accepts (sets STATUS to <constant>Success</constant>) or rejects (sets
STATUS to <constant>Denied</constant> or <constant>Busy</constant>) the connection.
</para>
<para>
-<!-- .LP -->
Once the connection has been accepted and STATUS is <constant>Success</constant>,
an implicit AccessContext is created for the authorization
data and the protocol continues with the following data sent
@@ -1794,7 +1777,6 @@ release of the server in a manufacturer-dependent manner.
</section>
<section><title />
<para>
-<!-- .LP -->
After the connection is established and the setup information has been
exchanged, the client may issue any of requests described below:
</para>
@@ -2922,7 +2904,6 @@ All errors are at least 16 bytes long and contain the following fields:
</tgroup>
</informaltable>
<para>
-<!-- .LP -->
The TYPE field has a value of one. The ERROR-CODE field specifies which error
occurred. Core errors codes are in the range 0 through 127, extension error
codes are in the range 128 through 255. The SEQUENCE-NUMBER field contains the
@@ -2936,7 +2917,6 @@ LENGTH is greater than four, these fields are followed by (LENGTH - 4) * 4
bytes of extra data.
</para>
<para>
-<!-- .LP -->
The following errors are defined for the core protocol:
</para>
@@ -3250,7 +3230,6 @@ Additional errors may be defined by extensions.
<!-- (SN Events -->
<!-- .XE -->
<para>
-<!-- .LP -->
Events may be generated in response to requests or at the server's discretion
after the initial connection setup information has been exchanged. Each event
is at least 12 bytes long and contains the following fields:
@@ -3271,7 +3250,6 @@ is at least 12 bytes long and contains the following fields:
</informaltable>
</para>
<para>
-<!-- .LP -->
The TYPE field contains the value 2. The EVENT-CODE field specifies the number
of the event and is in the range 0-127 for core events or the range 128-255 for
extensions. The SEQUENCE-NUMBER field specifies the least significant 16 bits
@@ -3282,7 +3260,6 @@ specifies the server time when the event occurred. If LENGTH is greater than
three, these fields are followed by (LENGTH - 3) * 4 bytes of additional data.
</para>
<para>
-<!-- .LP -->
Events are described using the following syntax:
<blockquote><para>
<emphasis role="bold"><function>EventName</function></emphasis>
@@ -3307,7 +3284,6 @@ If an event does not provide any extra arguments, the
lines are omitted from the description.
</para>
<para>
-<!-- .LP -->
The core X Font Service protocol defines the following events:
</para>
@@ -3393,7 +3369,6 @@ Additional events may be defined by extensions.
<!-- (SN Protocol Encoding -->
<!-- .XE -->
<para>
-<!-- .LP -->
Numbers that are prefixed with <quote><literal>#x</literal></quote>
are in hexadecimal (base 16). All other
numbers are in decimal. Requests, replies, errors, events, and compound types
@@ -3416,7 +3391,6 @@ field, CONTENTS is the name of the type as given in
this field contains a constant, and NAME is a description of this field.
</para>
<para>
-<!-- .LP -->
Objects containing counted lists use a lowercase single-letter variable (whose
scope is limited to the request, reply, event, or error in which it is found)
to represent the number of objects in the list. These variables, and any
@@ -3425,7 +3399,6 @@ Multiple copies of an object are indicated by CONTENTS prefix
<quote>LISTof</quote>.
</para>
<para>
-<!-- .LP -->
Unused bytes (whose value is undefined) will have a blank CONTENTS field and a
NAME field of <quote>unused</quote>. Zeroed bytes (whose value must be zero)
will have a blank CONTENTS field and a NAME field of <quote>zero</quote>.
@@ -4342,7 +4315,6 @@ other font servers) may conflict with certain license policies.
<appendix id="implementation_suggestions">
<title>Implementation Suggestions</title>
<para>
-<!-- .LP -->
Font server implementations will probably wish to use techniques such as the
following to avoid limits on the number of simultaneous connections:
</para>