NAPLPS.TXT
Remove Frame
From: MICHAEL DILLON Refer#: 0
Michael Dillon Internet: [email protected]
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
The following is an article which describes the NAPLPS
protocol for on-line graphics in complete technical detail given the
limitations of ASCII. This document is based on the official CSA/ANSI/ISO
specifications documents but attempts to use more normal terminology
and clearer examples.
NAPLPS is a graphics protocol meant to be used over point-to-point links
like modems and is designed to be efficient enough to be useable at
2400 bps. Currently it is used by Videotex services and Prodigy but more
and more BBSes are using it as well. There is not yet any freeware
source code available for a NAPLPS terminal server so I wrote this
document to help interested programmers get started.
X-windows is not normally used over modems because of the overhead in
the protocol. I suspect that the NAPLPS technology could be used to
improve X throughput in an environment where the terminal server
runs on a UNIX host and transmits NAPLPS over a modem link instead of
using a frame buffer on that host. This should provide good performance
as long as bitmaps are not required to be transmitted, so it will not
work for any X-client but it should extend the range of usefullness of X.
I have started a NAPLPS area on SIMTEL20 and over the next month or
so, a variety of MS-DOS shareware supporting NAPLPS will appear there
including 3 shareware terminal programs, 1 shareware drawing program,
1 shareware BBS, and several utilities for image format conversions.
I just checked wuarchive last night and it is in mirrors/msdos/nalps.
Hopefully the spelling will soon be corrected to naplps. This document
will also be going to SIMTEL20.
--
Michael Dillon Internet: [email protected]
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
---
----------------------------------------------------------------------------
Copyright 1993 by Memra Software Inc.
All Rights Reserved
This is the March 1993 release of this document.
written by Michael Dillon
C-4 Powerhouse, RR #2
Armstrong, B.C. V0E 1B0
CANADA
BBS: 1-604-546-2705 - this has NAPLPS shareware and art
Fidonet: 1:353/350
Internet: [email protected]
CIS: >INTERNET:[email protected]
you can mail me questions and errata which will be
answered/fixed in the next release of this document.
------------------------------------------------------------
DISCLAIMER
This document is NOT the NAPLPS standard. The standard is
defined in an ANSI/CSA document which can be purchased from
one of those organizations. If you are creating commercial
products based on NAPLPS, then you should buy those
documents. This document is intended to clarify the
standards document and present the information using a
clearer terminology than in the standard. If there is any
conflict between this document and the standard, then follow
the standard and let me know so I can correct this document.
I take no responsibility whatsoever for any errors,
omissions or opinions in this document. It is NOT intended
as a guideline for creating commercial products, it is only
intended as an educational document for those who are unable
to obtain the standard or unwilling to decipher its
terminology.
------------------------------------------------------------
This is a specification for the on-line graphics format
known as NAPLPS. These specs are based on the ANSI/CSA
standards document that defines NAPLPS which is available
from ANSI (American National Standards Institute) as
document # X3.110-1983. They have offices in many American
cities and their head office is in New York. The identical
document is available from the CSA (Canadian Standards
Association) as document # T500-1983 and supplement # 1-
1991. Note that the supplement (which clarifies
proportionally spaced text among other things) is not
available from ANSI. I have also gleaned information from a
4-part series of articles published in Byte magazine in
February, March, April and May of 1983. There are a total of
55 pages in the 4 articles. I have also used the MGE editor
and PP3 terminal program from Microstar to experiment and
figure out the details of the coding scheme. As far as I
know, PP3 is the only shareware NAPLPS terminal program that
fully implements the NAPLPS spec including DRCS (redefinable
fonts) and bitmaps.
My knowledge of NAPLPS comes from many sources. I first
read about Telidon in 1979 or 1980. I was able to use
Telidon demo systems several times including one short
layover at Vancouver International airport in 1982 when I
spent 3 hours playing with a public Telidon terminal. It
would have been a boring 3 hours without that system. I also
have the official CSA specs. I have used the MGE editor and
used it to create test images to poke around in with DEBUG.
I have some Japanese utilities to print out a text version
of NAPLPS codes and reassemble into NAPLPS from the text
specs. I have the BYTE articles. I have used the PP3
terminal program and CTLINK and Turmodem. And I have a
collection of images from Japanese ham radio operators and
Montreal schoolchildren and from various NAPLPS services.
You should note that this spec is NOT the definitive
spec. I am writing it for electronic distribution in order
to encourage more people to produce software that supports
NAPLPS graphics. I hope that some of you will use it to
create NAPLPS utilities, write NAPLPS doors for BBSes, add
NAPLPS support to your terminal programs or BBS software,
etc. At the end of this document is a resource list with
phone numbers and Fidonet addresses where you can get more
info and samples of NAPLPS art.
Overview
NAPLPS
NAPLPS (North American Presentation Layer Protocol Syntax)
is a communications protocol that extends ASCII to allow for
the EFFICIENT transmission of picture and text information
over telecommunications channels such as modems. It does not
contain the commonly used ANSI protocol but it does include
similar capabilities and it could be used simultaneously
with ANSI although most NAPLPS terminal programs do not
currently support ANSI.
A NAPLPS image is transmitted in a manner that is
independent of the resolution and color capabilities of the
receiving display. There are NAPLPS terminal programs
available for Amiga, Macintosh and PC's with CGA, Herc
monochrome, EGA, VGA and other display resolutions.
This is accomplished by sending instructions to the
terminal program that tell it how to draw the required
pictures and text. Even bitmap pictures are transmitted in a
scalable fashion.
OSI
The OSI (Open Systems Interconnect) model of data
communications divides up the various aspects of an
electronic conversation into 7 layers. NAPLPS is a protocol
to be used at level 6 which is the presentation layer. Such
things as error-control are handled at lower layers and user
interaction is handled at level 7 (Application Layer).
APPLICATION - this is the interface provided by the
actual application program or BBS system.
PRESENTATION - this layer encodes, transmits and
decodes data in such a way as to
preserve its meaning. Examples are
ASCII, ANSI, NAPLPS
SESSION - this layer establishes and maintains a
communications session. This is the process
of logging in and presenting a password.
TRANSPORT - This layer provides a virtual circuit
from terminal to host. Data could travel
across several different networks in lower
layers.
NETWORK - This is the layer where routing, switching,
bridging and gating occur.
DATA LINK - This layer handles flow control, error
detection and correction.
PHYSICAL - This is the layer where you find cables
carrying electrical or optical signals
Telidon
NAPLPS is an extension of the experimental Telidon system
that was used in Canada in the late 1970's and early 1980's.
For more info, look up a book called Gutenberg Two. It also
includes mosaic bitmap capabilities from early European
Teletext systems.
The Basics
NAPLPS uses the 128 7-bit ASCII codes in such a way as
to be 100% compatible with any system which transmits pure
ASCII. It adds additional functions by making use of the 128
high-ASCII codes which are used on PC's for graphics
characters. This means that NAPLPS terminal programs can't
display high-ASCII unless the high-ASCII symbols are defined
as a downloadable character set and font selection codes are
transmitted prior to use of high-ASCII. In this, it is much
like Microsoft Windows which also does not use high-ASCII
for much the same reasons.
The additional capabilities include color mapping, 24-
bit color spec, line, box, circle, arc, polyline, polygon,
spline curve, bitmaps, downloadable fonts, macros, input
fields, line patterns, fill patterns, etc. All this is
accomplished in very compact manner so that reasonably
complex NAPLPS images are usually around 5 K bytes. The most
complex image I have seen is 22 K bytes and contains a
detailed picture of a mountain range, some trees, a horse
with a native rider wearing a Hudsons Bay jacket. This spec
is efficient enough to make it reasonable at 2400 bps if
complex images are limited to Art Galleries. At 9600 bps and
above, performance is not an issue.
ISO (International Standards Organization)
NAPLPS was designed to fit in with and be compatible
with other coding schemes that are ISO standards such as 7-
bit ASCII and the various Latin based alphabetical character
sets. For more info, read up on MS-Windows character sets
or HP Laserjet character sets as these are also designed for
ISO compatibility.
There is currently a modification to the spec to
include JPEG compressed bitmaps in the standard but that has
not yet been approved by ANSI or ISO. I will include that
info in this document as soon as I know more.
General Architecture
Character Codes
All NAPLPS info can be transmitted using either 7-bit
or eight bit codes. This allows NAPLPS to be transmitted
over links that require a parity bit. When 7-bit codes are
used, then the extended codes are selected by shifting the
extended codes into the 7-bit ASCII code table. This is
similar to a keyboard shifting between upper and lower case
letters. They are different symbols, but shifting (and Ctrl
and Alt) allows the same key to be used.
In fact there are several different code sets that can
be shifted in. The Primary code set is 7-bit ASCII. Then
there is the PDI (Picture Description Instruction) set, the
Supplementary set which contains accented characters and
other symbols, the Mosaic set which supports the old
Teletext bitmap format, the Macro set which invokes
predefined macros, and the DRCS or Dynamically Redefinable
Character Set which is used for non-Latin languages such as
Russian, Thai, Inuktitut. When using 8-bit codes, things are
simplified somewhat since two of these code tables are
accessible without shifting.
Whenever the numeric value of a character code is given
in this document, it will be in hexadecimal.
Coordinates
All pictures are drawn and positioned using Cartesian
(X,Y) coordinates within the Unit Screen. This is the upper
right quadrant of the Cartesian plane between (0,0) and
(1,1)
|-------|(1,1)
| |
| |
| |
--------------|--------------- X axis
|
|
|
|
Y axis
It is possible to specify 3 dimensional (X,Y,Z) coordinates
but at the current time, Z coordinates are to be ignored.
On most video displays the aspect ratio is 4:3,
therefore drawings should be restricted to a Y coordinate
between 0 and .75. Anything extending beyond either the unit
screen or the actual display screen should be clipped. So,
the physical display screen extends from (0,0) in the lower
left hand corner to (1,.75) in the upper right hand corner.
NAPLPS terminal programs must always ensure that the entire
display is visible to the user. In resizable windowing
environments (MAC, Amiga, Windows) this means that when the
display window is resized the terminal program should
maintain the 4:3 aspect ratio and scale the current image.
These coordinates are specified as binary fractions.
For instance, if 8 bits of precision are available, then the
binary number .10000000 is equal to 1/2. This is just
another way of saying that the binary number 10000000 (128
decimal) is 1/2 way between 0 and the maximum representation
in 8 bits namely 11111111 (255 decimal). If the precision is
widened to 16 bits then zeroes are added on the right so
that .1000 0000 0000 0000 still means 1/2 even though it now
represents the number 16,384 in the range of 0 to 32,768.
Stream of Data
The NAPLPS codes are a stream of data coming into the
terminal program and should be acted on in sequence. Each
graphical object is drawn on top of those already visible.
Composite pictures and alphabetic characters can be created
by superimposing multiple characters and/or images.
The specification is very flexible as far as PDI
operands is concerned. If the NAPLPS stream does not supply
the number of bits of precision that the receiving terminal
expects (less than defined DOMAIN), it simply pads the
binary fractions with zeroes on the right. This has the
effect of drawing the pictures with shorter operands using a
coarser grid. If there is more precision than the terminal
program is capable of using (defined DOMAIN is more precise
than the current display), it truncates the rightmost bits
of the binary fractions which has the effect of rounding the
more precise drawing specs to the grid size that the display
driver is capable of using.
On the other hand, if the NAPLPS stream contains more
operands than would be expected with the currently defined
DOMAIN, then the drawing operation is repeated in some form,
i.e. lines become polylines, rectangles become bar charts,
arcs become spline curves.
Code Sets
Overview
A sequence of NAPLPS codes is initiated by the 3
character sequence ESC 25 41 and is terminated by the
sequence ESC 25 40. Outside of this bracketing, all NAPLPS
terminal programs will support ASCII codes. Other support
such as VT100 and ANSI escape sequences is out of the scope
of the NAPLPS standard.
The 128 possible 7-bit codes are divided into 32
character C-sets and 96 character G-sets. The two C-sets are
codes that perform control operations. C0 is the familiar
ASCII set of control characters, and C1 is a set of codes
that do cursor positioning, macro defining, etc.
There are two types of G-sets, 94 character and 96
character. A 94 character G-set is really just a 96
character G-set in which the codes 20 and 7F are used for
<space> and <del>. The <space> code is therefore available
in both the ASCII and supplementary character sets. The
<del> code is treated as a null, i.e. discarded. G-sets are
selected in a two stage fashion. There are 6 possible G-
sets, but only 4 G-sets are current. The current G-sets are
named G0, G1, G2 and G3. In the default state, G0 is the
primary character set (ASCII), G1 is the PDI set, G2 has the
supplementary characters, and G3 the mosaics.
Shift and Escape Codes
Five of the normal ASCII control characters are used in
code sequences that shift G-sets and C-sets in and out of
the active state. They are ESC (1B), SI (0F), SO (0E), SS2
(19) and SS3 (1D) or ESCAPE, SHIFT-IN, SHIFT-OUT, SINGLE-
SHIFT 2 and SINGLE SHIFT 3. The single shift codes are used
to temporarily escape the immediately following character.
The normal control character set is always available.
The C1 set is accessed by setting the bit 8 if operating
over an 8-bit link, or by ESCaping the code and setting bit
7 on a 7-bit link. For instance, DEF MACRO is 80 when eight
bits are used, but it is ESC 40 when 7-bits are used. This
means that on an eight-bit link, the C1 set ranges from 80
through 9F, but on a seven-bit link it ranges from 40
through 5F. There are two sequences for activating the
control sets. C0 is activated by ESC 21 4B and C1 is
activated by ESC 22 46. These are somewhat redundant as
there are only two control sets at present.
G-sets are a bit more complex. Firstly, there are two
positions in the code table that can hold a G-set, the lower
128 positions or G-left (GL) and the upper 128 positions or
G-right (GR). In a 7-bit environment, GL is the only active
G-set. If the 256 possible codes are arranged as 16 columns
of 16 rows, then the C and G sets are laid out as follows
with 2 columns (32 chars) for the C-sets and 6 columns (96
chars) for the G-sets.
C0 GL C1 GR
--- ----------- --- ---------
| | | | | | | | | | | | | | |
By default GL contains G0 (ASCII) and GR contains G1
(PDI). G2 is the supplementary characters and G3 defaults to
the mosaics. You can activate G0 - G3 by selecting them into
the GL area as follows:
0F (SI) selects G0
0E (SO) selects G1
ESC 6E selects G2
ESC 6F selects G3
This works in both 7-bit and 8-bit mode. A single character
from G2 or G3 can also be selected by using SS2 or SS3, e.g.
19 selects the 1 following char from G2
1D selects the 1 following char from G3
In 8-bit mode, you can activate GR as follows:
ESC 7E selects G1 (also ESC 6B)
ESC 7D selects G2 (also ESC 6C)
ESC 7C selects G3 (also ESC 6D)
The 6B, 6C, and 6D codes should be supported by terminal
programs for backward compatibility, but should not be used
in new image coding. ASCII codes cannot be selected into GR.
While the G0-G3 sets have 4 default settings, the
actual G-sets in each of them can also be selected by a code
sequence. For the 94 character sets (ASCII and
supplementary) the code sequence is:
ESC 28 42 selects ASCII into G0
ESC 28 7C selects supplementary into G0
The code 28 could be one of:
28 represents G0
29 represents G1
2A represents G2
2B represents G3
If you are selecting one of the 96 character G-sets, use the
following sequence:
ESC 2D 57 selects PDI's into G1
ESC 2D 7D selects mosaics into G1
ESC 2D 20 7A selects the macros into G1
ESC 2D 20 7B selects the DRCS into G1
The code 2D could be one of:
2D represents G1
2E represents G2
2F represents G3
If you are writing a terminal program you should also
support some older code sequences for backwards
compatibility. For 96 character G-sets the codes 29, 2A and
2B should be accepted as well as 2D, 2E and 2F. In addition
the single byte code 7A should be accepted as equivalent to
20 7A for macros and 7B should be accepted as equivalent to
20 7B for DRCS.
If an unknown terminating code is received for a
sequence, then the entire sequence should be discarded.
If a given G0, G1, G2 or G3 set is currently invoked
into either GL or GR, then the new contents of that set take
effect immediately. For instance, if you have invoked the
default G2 (supplementary) into GL via ESC 6E and you then
designate the macro set as the new contents of G2 via the
sequence ESC 2E 20 7A then it is NOT necessary to re-invoke
G2 by another ESC 6E.
G-Sets
The 94 symbols of the primary character set are
identical to ASCII. The actual font used is implementation
dependent but it must be scalable. There is no guarantee
that a font is legible at all resolutions. The cursor is
automatically advanced when a character from this set is
displayed, according to the current TEXT settings. Note that
characters that are overprinted do NOT wipe out the image of
the original character as in most text mode displays. Both
characters remain visible.
The 94 symbols of the supplementary character set are
not ASCII and therefore must be described in this document.
Again, these are scalable and the font used is
implementation dependent. The codes from 21 through 3F and
from 51 through 7E are displayed in the same way as ASCII,
namely, the cursor is advanced after they are displayed. The
codes from 41 through 4F are non-spacing accent character
used to create composite characters. Normally, a composite
character is formed by first displaying the non-spacing
accent, and the letter. The best way to see these is to get
MGE and display them at a reasonably large size to see
details on some of the weird ones. They are also displayed
in the standard documents and in the 1st article in the
February 1983 issue of BYTE.
Supplementary Character Set
---------------------------
21 upside down exclamation as in Spanish
22 cents symbol
23 British pound symbol
24 dollar sign ASCII 24
25 Japanese yen symbol
26 number sign ASCII 23
27 subsection symbol PC code 15
28 generic currency symbol like X with o in middle
29 left single quote
2A left double quote
2B left guillemot like << PC code AE
2C left arrow like <- PC code 1B
2D up arrow PC code 18
2E right arrow like -> PC code 1A
2F down arrow PC code 19
30 degree symbol PC code F8
31 plus or minus PC code F1
32 superscript 2 PC code FD
33 superscript 3
34 times symbol like x
35 greek mu PC code E6
36 paragraph mark PC code 14
37 centered dot PC code F9
38 division PC code F6
39 right single quote
3A right double quote
3B right guillemot like >> PC code AF
3C looks like 1/4
3D looks like 1/2
3E looks like 3/4
3F upside down question mark as in Spanish
The following 16 codes are non-spacing accents
40 vector overbar (a right-pointing vector arrow
just above the top of capitals)
41 grave accent
42 acute accent
43 circumflex accent
44 tilde
45 macron or overbar
46 breve like a ) laying on its side with points up
47 dot positioned over a letter
48 diaresis or umlaut
49 overprinting slash /
4A small ring or circle positioned over a letter
4B cedille as in French garcon
4C underscore
4D double acute accent
4E ogonek (mirror image of cedille)
4F caron (little v above a letter)
50 em dash
51 superscript 1
52 registered trademark R in a circle
53 copyright C in a circle
54 TM superscripted
55 musical eighth note PC code 0D
56 horizontal box drawing line PC code C4
57 vertical box drawing line PC code B3
58 / from bottom left to upper right of char field
59 \ from top left to bottom right of char field
5A filled triangle below code 58
5B filled triangle below code 59
5C looks like 1/8
5D looks like 3/8
5E looks like 5/8
5F looks like 7/8
60 greek Omega PC code EA
61 AE ligature
62 Icelandic eth D with - through the vertical
63 feminine ordinal PC code A6
64 H with horizontal stroke at 3/4 height
65 crossbar box drawing character PC code C5
66 IJ ligature
67 L with a dot centered vertically and horizontally
68 L with a short / through the vertical
69 O with a /
6A OE ligature
6B masculine ordinal PC code A7
6C Icelandic thorn like P with extended vertical
6D T with short horizontal stroke
6E Lappish capital eng looks like nj
6F looks like 'n
70 greek kappa
71 small ae ligature
72 small 62
73 mirror image of 6 with stroke
74 small 64
75 i with no dot
76 small 66
77 small 67
78 small 68
79 small 69
7A small 6A
7B German esset similar too greek beta but not same
7C small 6C
7D small 6D
7E small 6E
The PDI set
Overview
This is the heart of NAPLPS, the graphical drawing
primitives. There are eight environment codes (RESET,
DOMAIN, TEXT, TEXTURE, SET COLOR, WAIT, SELECT COLOR and
BLINK) which set the graphics environment and 6 different
object types (POINT, LINE, ARC, RECTANGLE, POLYGON,
INCREMENTALS). Each type of object has 4 different forms in
which it can be drawn. These codes take up the first 32
positions in the PDI set. The other 64 positions are used to
encode parameters and co-ordinates for these primitives. The
PDI set is not really a character set, but a set of function
calls with parameters.
A PDI (Picture Description Instruction) begins with a
code selecting one of the primitives. These codes can all be
distinguished by the fact that bit 7 is equal to zero. This
code is then followed by one or more codes containing
parameter data. The PDI is terminated whenever a code that
is not data is encountered, i.e. another PDI or any code
outside of the PDI's G-set. The exceptions are the control
codes 00 through 06, and 10 through 17 which do not affect
the OSI presentation layer and are therefore ignored if
encountered. Also, macro invocation does not terminate a PDI
so macros can be used to provide all or some of the
parameter codes. In certain cases, invalid data will require
that the PDI and all data bytes up to the termination of the
PDI are to be discarded with no action taken.
There are 4 types of parameters. Fixed format
parameters are specific to the PDI which uses them.
Bitstrings are also specific to a PDI which uses them but
they are encoded in bits 6 through 1 of a string of
characters. Single value operands take up from 1 to 4 bytes
of data depending on the current DOMAIN setting. They are
unsigned integers of 6, 12, 18, or 24 bits with the most
significant bits being received first. Multi-value operands
are from 1 to eight bytes of data depending on the current
DOMAIN setting. These are primarily used for Cartesian
coordinates but can also encode color information. The
coordinates are signed integers encoded as follows:
X Y X Y Z
8 7|6 5 4|3 2 1| 8 7|6 5|4 3|2 1|
----------------- -----------------
|?|1|S| | |S| | | |?|1|S| |S| |S| |
----------------- -----------------
|?|1| | | | | | | |?|1| | | | | | |
----------------- -----------------
. . . . . .
----------------- -----------------
|?|1| | | | | | | |?|1| | | | | | |
----------------- -----------------
In the normal 2 dimensional case, the first byte contains
the sign bit and the 2 most significant data bits. Second
and subsequent bytes contain 3 data bits. Therefore these
coordinates can range from 3 bit to 24 bit signed integers.
These integers are fractions of the unit screen. For
example, if the DOMAIN setting specified 3 bytes for multi-
value operands then the unit screen would range from 0 (000
000 000) to 256 (011 111 111) units in width. Negative
coordinates would be clipped as they are not on the screen.
They are also used to specify relative coordinates from the
current drawing point.
When a multivalue operand is used to represent a color,
it is coded as follows:
G R B G R B
8 7|6 5 4|3 2 1|
-----------------
|?|1| | | | | | |
-----------------
|?|1| | | | | | |
-----------------
. . .
-----------------
|?|1| | | | | | |
-----------------
The color value is decoded by concatenating the bits for
each of the Green, Red and Blue values. This color value is
again treated as a binary fraction so that with DOMAIN
settings for 3 bytes the range of color values would be from
0% (00 00 00) to 100% (11 11 11).
There are two special colors: nominal white is the
palette entry 011...11 and has a color value of all ones;
nominal black is palette entry 0 and has a color value of
all zeroes. Note that this places the color white in the
middle of the palette.
Whenever the required number of data bytes are not
received, the receiving system should pad the data with zero
bits to the correct length. This gives transmitting systems
an opportunity to make transmission more efficient by not
transmitting the trailing zero bits on data operands. Zero
bits would look like this (1 000 000) in 7 bit form. On the
other hand, if more data bytes are received than required,
the receiving system should assume that the current PDI is
to be repeated with a new set of data bytes unless otherwise
specified for a particular PDI.
The PDI primitives are as follows:
20 RESET - selective reset
21 DOMAIN - sets graphical environment
22 TEXT - sets default text attributes
23 TEXTURE - sets line and fill patterns
24 POINT SET ABS
25 POINT SET REL
26 POINT ABS
27 POINT REL
Lines and Polylines
28 LINE ABS
29 LINE REL
2A SET & LINE ABS
2B SET & LINE REL
Arcs, Circles, Splines
2C ARC OUTLINED
2D ARC FILLED
2E SET & ARC OUTLINED
2F SET & ARC FILLED
Rectangles and histograms
30 RECT OUTLINED
31 RECT FILLED
32 SET & RECT OUTLINED
33 SET & RECT FILLED
Polygons
resulting from the first blink process. Some complex side
effects can be created this way.
The first set of data bytes following BLINK are a
single value operand defining the blink-to color as a
palette entry. The same rules apply as for SELECT COLOR. The
blink-from color is defined to be the current drawing color
and therefore is not explicitly included in the BLINK PDI.
Following the single value operand are 3 fixed format
bytes defining the ON interval, OFF interval and START DELAY
for the blink processes. Each interval is defined in 10ths
of a second and, of course, only bits 6 through 1 are used.
This means the minimum interval is .1 seconds and the
maximum interval is 6.3 seconds. If the START DELAY is not
transmitted then it is assumed to be 0. A start delay is
ignored if there are no currently active blink processes. If
either the ON interval or the OFF interval are zero, then
any currently active blink process for the specified blink-
from and blink-to colors is terminated. There can be only
one blink process at a time for a given pair of colors. If a
blink PDI is issued with no data bytes following it then all
blink processes using the current drawing color as the blink-
from color will be terminated. When all blink processes for
a given blink-from color are terminated, then the original
blink-from color will be restored.
If there are additional data bytes after the start
delay byte, then another blink command is started
implicitly. This new blink command will automatically
increment the palette entry number to use as the blink-from
color using the same algorithm as SET COLOR uses for
incrementing palette indexes. This incrementing does not
affect the drawing color.
The number of blink processes simultaneously active is
implementation dependent but should be at least 16.
POINT SET ABS - 24
This PDI sets the current drawing point to the
coordinates specified in last one of the following multi-
value operands. No point is drawn.
POINT SET REL - 25
This PDI sets the drawing point to the current drawing
point plus the displacement specified in the following multi-
value operand. This operation may be repeated for multiple
multi-value operands. No point is drawn.
POINT ABS - 26
This PDI sets the drawing point to the coordinates
specified in the following multi-value operand and draws a
logical pel at that point in the current drawing color.
Multiple points may be specified by transmitting more
coordinate pairs.
POINT REL - 27
This PDI sets the drawing point to the current drawing
point plus a displacement specified in the following multi-
value operand and draws a logical pel at that point in the
current drawing color. Multiple points may be specified by
transmitting more X,Y displacements.
LINE ABS - 28
This PDI draws a line in the current color from the
current drawing point to the end point specified in the
following multi-value operand. If more than one operand is
transmitted, lines will be drawn until there are no more
data bytes. The current drawing point is set to the last end
point. The thickness of the line is determined by the
logical pel size since the logical pel is used as a brush to
draw the line as in the example below.
_
/\/\
/ /\ \
/ / \ \
/ / \ \
|_/ \_|
LINE REL - 29
This PDI draws a line in the current color from the
current drawing point to a point specified by the X,Y
displacement in the following multi-value operand. If more
than one operand is transmitted, lines will be drawn until
there are no more displacements. The current drawing point
is set to the last end point.
SET & LINE ABS - 2A
This PDI is similar to LINE ABS except that the first
multivalue operand after the PDI is used to set the current
drawing point before drawing commences.
SET & LINE REL - 2B
This PDI is similar to LINE REL except that the first
multivalue operand after the PDI is used to set the current
drawing point before drawing commences.
Arc Drawing
The ARC PDI's are used to draw circles, circle segments
and curvilinear splines. Arcs are drawn from a start point,
through an intermediate point to an end point. The start and
end points are the same point, then the intermediate point
defines the diameter of a circle and a circle is drawn. If
more than 3 points are specified, then a curvilinear spline
is drawn. The minimal acceptable implementation according to
the standard is a straight line connecting all the end
points, but in this day and age a B-spline should be used. B-
splines are used in TrueType font outlines and can readily
be drawn using CAD programs, so B-spline support would be
useful for converting display typefaces and CAD drawings to
NAPLPS format. The maximum number of points in a spline is
implementation dependent but should be at least 256.
If the 3 points specified for an arc are collinear,
then a line is drawn from the start point to the end point.
If the end point is omitted, it is assumed to be the same as
the start point and a circle is drawn. After drawing the
arc, the current drawing point is set to the end point.
If an arc is filled, then the area between the arc and
the chord specified by the start and end points is filled
with the current colors and current fill pattern. The line
width of the chord is affected by the logical pel size, but
if the arc is outlined, the chord is NOT outlined.
There is a good reason why the chord is filled rather
that the pie segment and why only the circular portion of
the arc is outlined and not the chord. Firstly, a pie
segment is easily composed of a filled arc and a triangle
which have the chord line in common. It is possible to
construct curved objects more efficiently by drawing several
end-to-end filled arcs and an interior polygon which
connects the chords of those arcs (see cloud in the BYTE
sample). If this object is to be outlined, you would not
want the chord lines to be visible but you would want the
curved portions to be visible. The alternative is to draw a
polygon with many short line segments to approximate the
curves but that takes many more bytes and is less efficient.
Remember, most of the world still runs on 2400 bps modems.
Well designed NAPLPS images can be transmitted quite
reasonably at that speed.
ARC OUTLINED - 2C
This PDI draws an unfilled arc in the current drawing
color. The start point is the current drawing point. Only
the intermediate and end points are specified in the
following multi-value operands.
ARC FILLED - 2D
This PDI is the same as ARC OUTLINED except that the
start and end points are joined by a chord in the current
drawing color and the arc is filled with the current color
and fill pattern. If the TEXTURE settings specified that
outlines should be drawn, only the curved part of the arc is
drawn in the background color.
SET & ARC OUTLINED - 2E
This PDI is the same as ARC OUTLINED except that the
first multi-value operand sets the current drawing point.
SET & ARC FILLED - 2F
This PDI is the same as ARC FILLED except that the
first multi-value operand sets the current drawing point.
Rectangle Drawing
The rectangle commands draw rectangles of a specified
width and height. After the rectangle is drawn the endpoint
is displaced from the starting point by the width only. This
facilitates drawing bar charts along a baseline. If
additional data bytes follow a rectangle command, they are
interpreted as additional width and height specifications
for additional rectangles.
RECT OUTLINED - 30
This PDI draws an unfilled rectangle in the current
drawing color starting at the current drawing point.
RECT FILLED - 31
This PDI draws a filled rectangle starting at the
current drawing point. The fill is done with the current
drawing color and fill pattern.
SET & RECT OUTLINED - 32
This PDI is the same as RECT OUTLINED except that the
current drawing point is set by the first multi-value
operand.
SET & RECT FILLED - 33
This PDI is the same as RECT FILLED except that the
current drawing point is set by the first multi-value
operand.
Polygon Drawing
The polygon command is used to draw filled and unfilled
polygons. The polygon is defined as a series of
displacements from a starting point. The last point in a
polygon is implicitly the same as the starting point to
ensure that it is closed. The drawing point is unchanged
after drawing a polygon.
The number of vertices allowed in a polygon is
implementation dependent but should be at least 256.
POLY OUTLINED - 34
This PDI draws a polygon starting at the current
drawing point.
POLY FILLED - 35
This PDI draws a filled polygon starting at the current
drawing point.
SET & POLY OUTLINED - 36
This PDI is the same as POLY OUTLINED except that it
sets the current drawing point first.
SET & POLY FILLED- 37
This PDI is the same as POLY FILLED except that it sets
the current drawing point first.
FIELD - 38
This PDI defines the active field position and
dimensions. The active field is used for displaying and
scrolling columnar or wordwrapped text, for setting up
unprotected input fields and for displaying bitmapped
images. If there is already an active field, it will be
replaced by this new active field.
The first parameter after the PDI is the origin of the
field in absolute coordinates. The second multi-value
operand, gives the width and height of the field. If the
width or height are negative, then the origin point of the
field will not be in the lower left corner. This is handled
the same way as the logical pel size under the DOMAIN PDI.
The current drawing point is set to the field origin point.
If there are no multivalue operands after the FIELD PDI,
then the active field is set to the default setting of the
full unit screen with the origin at (0,0). If there is only
one multi-value operand, then it is used as the field
dimensions and the current drawing point will be used as the
origin point.
INCREMENTAL POINT - 39
This PDI displays a color bitmap within the active
field. Each pixel specified in the bitmap is drawn by one
logical pel using the color specified in the bitmap. In
color mode 0, the colors are explicitly specified as RGB
values. In modes 1 and 2, they are palette entries. The
color settings or selections caused by the incremental point
command have exactly the same effect on the graphics
environment as a SET COLOR (mode 0) or SELECT COLOR (mode 1
& 2) command including side effects dealing with palette
entries.
The active field is important as it bounds the bitmap
and determines the number of pixels or pels per line in the
bitmap. Pels are displayed starting at the current drawing
point. After drawing the pel, the drawing point is displaced
in the X direction by an amount equal to the width of the
logical pel. Positive widths move right, and negative ones
move left. At this point, if the new position of the logical
pel causes it to overlap the active field boundaries, then
two things happen. First, any remaining bits in the current
data byte are discarded. Then, if there are any more data
bytes, the drawing point is repositioned at the boundary
opposite the overlapping one (like a carriage return). If it
is possible to displace the logical pel in the Y direction
without overlapping the field boundary, then this is done,
otherwise, the Y position is unchanged but the entire field
contents are scrolled in the opposite direction. Positive
pel heights move up but scroll down, negative heights
reverse the directions. After the repositioning is
completed, the next pel is drawn.
Once the last pel has been drawn, the current drawing
point is set back to the field origin.
The first byte following the INCREMENTAL POINT PDI is a
fixed format parameter that describes the number of bits per
pixel that are used to specify the pixel color or the
palette entry. This number ranges from 1 to 48. If it is 0
or if it is greater than 48, then the entire PDI is
discarded. The following data bytes are a bitstring
consisting of bits 6 through 1 of each data byte. In color
mode 0 the number of bits equal to the packing count are
arranged GRBGRBG...BGRB. These are to be extracted and
interpreted as RGB colors in the same way as the multi-value
color operands used by SET COLOR. Note that if the packing
count is not a multiple of 3, then there will not be the
same number of bits for each of the three primary colors.
For instance, with a packing count of 5, the bit string
would be GRBGRGRBGRGRBGR...
^ ^ note that Blue is not specified
In modes 1 and 2, the bitstring consists of palette
indexes concatenated together.
In some cases it will be necessary to rescale either
the logical pel dimensions and the active field dimensions
in order to ensure that both of them are integer multiples
or integer fractions of the physical pixel dimensions. If
this scaling is done, then the original unscaled values for
both the active field and the logical pel are restored after
the INCREMENTAL POINT PDI has completed. This scaling must
ensure that the resulting bitmap image is guaranteed to lie
within the ORIGINAL active field and that skewing of the
image does not occur. This means that the new dimensions
must display the same number of pels per line as the
original ones. It also means that the rescaled bitmap will
be smaller than the actual specified field size.
If any portion of the logical pel for the initial
drawing point lies outside the active field, then the entire
PDI is discarded. If either width or height of the current
logical pel is equal to zero, then for the duration of the
INCREMENTAL POINT PDI, it is set to the smallest value
possible within the current DOMAIN.
INCREMENTAL LINE - 3A
This PDI defines a scribble which is an efficient
representation for certain types of polylines such as a
signature. The line segments in the scribble are drawn with
the current color and line texture.
The first operand is a multi-value operand which
specifies the step-size as separate x and y displacements
referred to as dx and dy. Following this, the data bytes
define a bitstring consisting of a series of 2 bit opcodes
as follows:
00 makes the following opcode one of:
00 toggle the draw flag
01 reverse the sign of dx
10 reverse the sign of dy
11 reverse the sign of dx and dy
01 move the drawing point dx in the x direction
10 move the drawing point dy in the y direction
11 move the drawing point dx in the x direction
and dy in the y direction
If the draw flag is on, each of the move instructions causes
a line segment to be drawn from the current point to the new
point. When the INCREMENTAL LINE starts, the draw flag is on
unless it is turned off explicitly. The current drawing
point is set to the last point in the scribble.
INCREMENTAL POLY FILLED - 3B
This PDI is almost identical to the INCREMENTAL LINE,
except as follows:
1. The scribble is filled with the current colors and
fill pattern.
2. the draw flag is always on
3. If an opcode to turn off the draw flag is
encountered, it is skipped.
4. The final drawing point is implicitly the same
as the starting point to ensure closure.
5. the maximum number of nodes allowed is the same
as for the polygon PDI's.
The Mosaic set
Overview
This G-set consists of 65 2x3 block mosaic characters
and 31 <space> characters. The mosaic range from 20 to 3F
and from 60 to 7F and a special one at 5F. The bit pattern
of the character code determines the bit pattern of the
mosaic character:
7 6 5 4 3 2 1
---------------
| |1| | | | | | data byte
---------------
-----
|1|2|
----- 2 x 3
|3|4| Mosaic cell
-----
|5|7|
-----
One bits in the data byte cause the corresponding mosaic
cell to be visible. If you want to see what they look like,
use MGE or get a copy of the official standards document or
look in the February 1983 issue of BYTE magazine.
Mosaic characters are normally displayed in contiguous
mode so as to create the effect of a monochrome bitmap.
However, when text underline mode is on, they are displayed
as separated with no actual underscore. In contiguous mode,
the mosaic cell size is determined by dividing the character
field into six equal rectangles. In separated mode, the
character field size is reduced in width by the width of a
logical pel and reduced in height by the height of a logical
pel before subdividing into six equal rectangular parts. The
scaled down mosaic characters are left and bottom justified
within the character field. If either dimension of the
logical pel is greater than the corresponding character
field dimension, then the mosaics are invisible in separated
mode.
Mosaic code 20 is not subject to underlining and
mosaics are never proportionally spaced. The mosaic
displayed by code 5F is the same as 7F
The Macro Set
Overview
This set contains 96 codes which can be used to define
and invoke macro. A macro is simply a stream of NAPLPS bytes
that are captured by the terminal program and assigned to a
code in the macro set. They may be buffered in RAM or on
disk as desired by the implementor. Once the macro is
defined, it can be recalled by invoking the macro set and
transmitting the single byte code for the macro. Macros can
also be recalled within the definition of another macro, so
it is necessary for the terminal program to beware of
infinite macro loops.
There are three control codes which define a macro (DEF
MACRO, DEFP MACRO, and DEFT MACRO). Any of these macros may
be linked to a user input such as a function key or mouse
click so that it may be activated or transmitted by the
user.
Macro expansion can occur in odd places, such as in the
middle of a PDI's data bytes, so be careful.
Dynamically Redefinable Character Set
Overview
This G-set is a character set that may be defined and
redefined by the host system transmitting the NAPLPS codes.
This could be used simply for a different looking font, or
it could be used to enable use of NAPLPS with a non-Latin
based language such as Russian, Thai or Inuktitut. The 96
codes in the DRCS are treated as <space> until they are
explicitly defined by a DEF DRCS control command. When these
codes are displayed they are subject to the same features
and limitations as alphanumeric text.
Character Field Layout
When defining characters for a DRCS, one should take
certain factors into consideration when planning the
character field layout. Remember, that the entire character
shape must lie 100% within the character field including
descenders and accents. The characters should be designed
with a baseline that is offset far enough from the bottom of
the character field to leave room for descenders and the
underline which is drawn at the bottom of the character
field. Approximately 20% of the character field height is a
good starting point. Similarly, the maximum character height
should be offset below the top of the character field to
leave enough room for accents to be placed on the
characters. Approximately 10% of the character field height
is a good starting point. In addition, a small allowance
should be made on the left and right of the character field
to provide an intercharacter spacing. If it is not possible
to leave space on both sides, then put the space on the
right of the character. Of course, there may be times when
some or all of these rules may be broken, but they should be
understood first, and then only broken for a reason.
C-Sets
C0 Control Set
These are the normal ASCII control characters. Note
that this specification defines what happens when the codes
are received in the NAPLPS data stream. This is not
necessarily the same behavior as when these codes are
received from the keyboard, and in fact, it is up to the
implementor to decide how to handle keystrokes. Keystrokes
are not part of the NAPLPS spec.
Any specifications that deal with what to do with the
character field and cursor position and the active field,
when the active field boundaries are crossed, only take
place if the character field in it's original position is
wholly within the active field. If it is not wholly within
the active field, then the same processing takes place, but
with reference to the entire display area.
Backspace - 08
This code moves the cursor a parallel to the character
path but in a direction opposite from the normal character
advance and by a displacement equal to the normal character
advance. If the new cursor position is wholly or partially
outside of the active field or the display area, then the
cursor is moved to the opposite edge of the field and a
<vertical tab> is executed.
Tab - 09
This moves the cursor in an opposite direction but in a
similar manner to <backspace>.
Line Feed - 0A
This moves the cursor perpendicular to the character
path and by a displacement equal to the interrow spacing. If
the new character field position is wholly or partially
outside of the active field, then one of two things happens.
If scroll mode is active, the character field stays at its
old position and the active field is scrolled in a direction
opposite to the intended cursor movement. If scroll mode is
off, then the character field is positioned at the opposite
boundary of the active field.
Cursor Position - 1C
The two bytes following this control code represent a
row and column address to which the cursor is positioned.
The row address is decoded by taking bits 7 through 1 of the
first byte and subtracting 32. The column address is
obtained from the second byte in the same way. This gives a
range from 0 through 95 inclusive. If either of the 2 bytes
following the 1C is from the C0 or C1 sets, then the entire
sequence is discarded. NOTE that row 0, column 0 is in the
lower left corner of the display screen (Cartesian
coordinates).
Vertical Tab - 0B
This moves the cursor in an opposite direction but in a
similar manner to <linefeed>.
Clear Screen - 0C
This moves the cursor to the upper left character
position on the display and clears the screen. In color
modes 0 and 1, the screen is cleared to nominal black, in
mode 2 it is cleared to the background color.
Carriage Return - 0D
This moves the to the first character position in the
active field that is on the character path.
Home - 1E
This moves the cursor to the upper left character
position on the display.
Shift-Out - 0E
This invokes the G1 set into the GL which makes it
available as ASCII codes 20 through 7F.
Shift-In - 0F
This invokes the G0 set into the GL which makes it
available as ASCII codes 20 through 7F.
Single-Shift-2 - 19
This invokes the G2 set into the GL which makes it
available as ASCII codes 20 through 7F. This shift only
affects the byte immediately following the 19 code after
which the GL is restored to its former contents.
Single-Shift-3 - 1D
This invokes the G3 set into the GL which makes it
available as ASCII codes 20 through 7F. This shift only
affects the byte immediately following the 19 code after
which the GL is restored to its former contents.
Escape - 1B
This code is used to start various escape sequences
which are documented elsewhere.
Transmission Control
The codes SOH(01), STX(02), ETX(03), EOT(04), ENQ(05),
ACK(06), DLE(10), NAK(15), SYN(16), and ETB(17) are reserved
for use at other layers of the OSI model. If they do make it
through to the presentation layer, then they are ignored and
have no effect whatsoever. In the OSI model, these codes
would be used in lower layers to implement error-free
transmission of data packets with some type of network
handshaking protocol.
Device Control
The codes DC1(11), DC2(12), DC3(13), and DC4(14) are
also reserved for use of other layers of the OSI model. They
are ignored if they appear in the NAPLPS data stream.
Null - 00
This code is used at other layers of the OSI model. It
is ignored if encountered in the NAPLPS data stream.
Bell - 07
This code is used to beep or make some other audible
sound which is implementation dependent.
Cancel - 18
This code is used to terminate the processing of all
currently executing macros. Execution resumes at the next
code following the terminated macro call. The CAN code is
not queued, it has an immediate effect even if there are
other NAPLPS codes in a buffer which have not yet been
processed.
Service Delimiter - 1A
This code is discarded if encountered in the NAPLPS
data stream. It is intended to act as a delimiter for the
transmission of unprotected field contents back to the host
system. The full format is as follows:
NSR - begins the transmission
DOMAIN - only required if the domain settings are
different from the default.
FIELD - marks the beginning of the field contents. The
field coordinates are used to identify the
field.
TEXT - only required if the text size is different
from the default
POINT SET - only if required to locate the first
character position in the field.
SELECT COLOR - only when the text color changes. If
mode 0, then use SET COLOR.
Character codes including code set changes to use
supplementary, mosaics, DRCS. May also include control
codes for cursor positioning and repeat codes.
END - marks the end of each field.
The sequence between FIELD and END is repeated for
each unprotected field being transmitted.
POINT SET - tell the host where the current drawing
point is.
Service Delimiter - marks the end of transmission
This facility is akin to a dialog box. The host uses
NAPLPS to draw the screen and define unprotected fields. The
host can also transmit text into the unprotected fields and
the terminal program should store that text and allow the
user to edit it. Then upon receiving some keystroke or mouse
click, the terminal program will transmit the edited
contents of all unprotected fields back to the host. The
only characters guaranteed to be transmitted are those in
the ASCII, supplementary, mosaic and DRCS sets. This
facility is modeled upon that provided by block-mode
terminals.
If the terminal program allows arbitrary NAPLPS
sequences to be entered into unprotected fields, then that
facility can be used to implement graphical e-mail. The user
uses a mouse to draw images in the unprotected field along
with any text they type. The entire sequence of NAPLPS codes
required to redraw the same image on another person's screen
is recorded and transmitted back to the host system when the
user requests the fields to be sent by pressing a key or
clicking somewhere. If the user has a pen input device such
as a graphics tablet, they could even create handwritten
messages using the NAPLPS scribble PDI (INCREMENTAL LINE).
Unprotected fields which have NOT been changed, need
not be transmitted back to the host. If no fields are
changed and the transmission is initiated, then the minimum
transmission consists of the NSR, DOMAIN, POINT SET, and
Service Delimiter. Users can only edit unprotected fields
when the text cursor is on (visible).
NSR - 1F
Non-Selective Reset is used to reset most of the
environment settings to their default state as follows:
The G0, G1, G2, G3, C0 and C1 sets are reset to have
their default initial contents and the GL and GR are also
reset to their initial state.
The DOMAIN parameters are set to the default as
specified earlier in this document.
Any text settings from the TEXT PDI or from the C1 set
are reset to the default. In addition the active field is
set to the default of the unit screen.
Any TEXTURE parameters are set to the default, but the
programmable fill patterns are NO cleared.
The color mode is set to mode 0 and the current drawing
color is set to nominal white, however the color palette is
NOT cleared
If the two bytes immediately after 1F are between 40
and 7F, then the cursor is repositioned. The row number is
taken from bits 6 through 1 of the first byte, the column
address is from bits 6 through 1 of the second byte. Row 0,
column 0 is the upper left corner of the display. The actual
character position is constrained to be within the display
area even if the row column address extends beyond this
area.
NOTE: cursor positioning by the NSR code is NOT THE
SAME as cursor positioning via the CURSOR POSITION code 1C.
They use a different origin, and the NSR positioning takes
place AFTER the text parameters are reset to the default.
Because of this it is usually NOT POSSIBLE for NSR character
positioning to register properly with that of code 1C.
C1 Control Set
These are additional control codes which are used for
NAPLPS specific operations. There is a bit of complexity
involving the use of the C1 set in 7-bit mode. Because of
the need to ensure that the normal ASCII control characters
are still available (some are used outside of NAPLPS), it is
not possible to replace the C0 set with the C1 set.
Therefore, in 7 bit mode, the C1 set is placed in the middle
of the GL area from 40 through 5F and a C1 code is invoked
by preceding it with an ESC (1B) code. This means that the
GL area can still be used as normal for PDI's, ASCII text or
whatever, since C1 codes must be escaped. In 8 bit mode,
there is no conflict as the C1 set is always available at
the beginning of the upper 128 character codes from 80
through 9F. There is no shifting or escaping required in 8
bit mode.
In this section, the eight bit codes are given for the
C1 set. They can be converted to 7 bit codes by swapping
bits 8 and 7.
DEF MACRO - 80
This code is used to begin macro definition. The byte
following the DEF MACRO must be between 20 and 7F. It is the
macro number which is being defined or replaced. If the
second byte is not within this range, then the two bytes are
discarded and decoding begins with the next byte.
All characters after the macro number are recorded but
not executed up to the macro termination. The termination is
indicated by receipt of another DEF MACRO or one of DEFP
MACRO, DEFT MACRO, DEF DRCS, DEF TEXTURE, or END. The
terminating control character is NOT stored and neither is
the preceding ESC which is transmitted on a 7-bit link.
If a macro reference is encountered during macro
definition, then the reference is stored as is. It is NOT
expanded at definition time. If the macro definition is
null, i.e. no definition bytes before the terminator, then
any existing macro with that number is deleted. All macros
are deleted by the RESET PDI.
It is NOT necessary to have the macro G-set currently
invoked in order to define a macro.
These macros (and DEFP macros) may be associated with a
keystroke or mouse click to be initiated by the user, but if
so, they are only available to be activated when the cursor
is on. Because the execution of these macros could place the
terminal program in an undetermined state, it is the
responsibility of the host system to restore the state of
the terminal program to a known state after the cursor is
turned off. The terminal program must ensure that any such
macro is executed to completion without being interleaved
with any incoming NAPLPS codes.
DEFP MACRO - 81
This command is the same as DEF MACRO except that the
stream of characters making up the macro definition are
executed as well as recorded. If a DEFP MACRO contains a
reference to the macro number that is being recorded, then
that reference should be treated as an undefined macro. This
also applies to nested references, i.e. while defining macro
1 with the DEFP MACRO, a reference to macro 2 is
encountered. Upon expanding macro 2 a reference to macro 1
is encountered. Because the definition of macro 1 is not yet
complete, macro 1 is treated as an undefined macro.
DEFT MACRO - 82
This command defines a transmit macro. This is a string
of bytes which is intended to be transmitted back to the
host computer. The data bytes in a DEFT MACRO are not
executed and are not necessarily NAPLPS data. They are only
useful if the terminal program provides some means of
causing the macro to be transmitted back to the host when a
function key or mouse click event occurs. This is similar to
defining a programmable function key except that the NAPLPS
spec doesn't deal directly with the keys. It would be up to
the terminal program to allow the user to associate a given
macro with a given key combination. The transmit macros must
always be available to the user for transmission, even when
the cursor is off.
The transmit macros use the same pool of 96 macro
numbers as do other macros. There is only 1 macro set.
Macros linked to keystrokes should be defined starting
with code 20 and macros that are not linked should be
defined in reverse order starting with code 7F. The terminal
program should provide at least 8 macros associated to
keystrokes. In my opinion, 12 is a better number for PC's as
there are 12 function keys available. In fact, the cluster
of INS,DEL,HOME,END,PGUP,PGDN and the 4 arrow keys should
also be associated with transmit macros.
DEF DRCS - 83
This command is used to define a DRCS character shape
in a manner similar to macro definition. If the byte
following DEF DRCS is between 20 and 7F it is used as the
code for the DRCS character to define or redefine. If the
code is not within the range then the DEF DRCS code and the
incorrect code are discarded.
Next comes a stream of NAPLPS data which is used to
define the shape of the DRCS character. This stream is
terminated by one of END, DEF MACRO, DEFP MACRO, DEFT MACRO,
DEF TEXTURE, or another DEF DRCS. The standard states that
the NAPLPS stream defining the character should be executed
as it is received, but is NOT displayed on the screen. It is
instead used to modify an in-memory bitmap which is used
later to display the DRCS character. It should also be
possible to store the NAPLPS stream as is done with macros,
and execute the stream at the time the DRCS character is to
be displayed. This would provide far better scalability of
the characters. You could also convert the NAPLPS stream
into a scalable format that is native to the graphical
environment you are using. This would allow somewhat faster
display when the DRCS is used. Note that you can use macros
and other DRCS characters as part of the definition
sequence.
All NAPLPS code received during DRCS definition will
have its usual effect on the state of the terminal program,
except that any drawing operations do NOT affect the display
area. However, things like palette changes WILL still be
visible as they are part of the global state. All these
state changes will remain in effect after DRCS definition is
finished.
When rendering the NAPLPS code into the in-memory
bitmap, the aspect ratio of the bitmap will be the same as
the character field dimensions in effect at the time the DEF
DRCS was received. The lower left corner of the bitmap will
correspond to the lower left corner of the unit screen. The
larger of the X and Y dimensions of the bitmap will be
considered to be equal to 1 unit (the full extent of the
unit screen in that dimension). Any changes to the character
field dimensions within a DRCS definition will not affect
this sizing but will effect the next DEF DRCS command. The
in-memory bitmap is a monochrome bitmap that is initially
all black. All drawing commands will be drawn in white on
the bitmap unless they are drawn with a nominal black color.
The actual resolution of this bitmap is implementation
independent. Although the standard does not suggest this, I
would think that on today's computer equipment, this
rendering should be delayed until the DRCS characters are
actually used, at which point the bitmap size should be
equal to the current character field size, and bitmap
characters should be cached for reuse.
Once the DRCS definition is completed, the unit screen
once again corresponds to the physical screen and the
current drawing point is set to (0,0).
If the DRCS definition is terminated by another DEF
DRCS command, then the character code to be defined is NOT
transmitted. It is calculated by incrementing the previous
character code and wrapping around so that 7F increments to
20. If a DEF DRCS command is terminated with no character
definition, then the character definition for that code is
reset to the default <space> character. The entire DRCS can
be cleared with the RESET PDI.
When a DRCS character is displayed, the rendered bitmap
is scaled to the current character filed dimensions and the
white portions of the bitmap are to be displayed in the
current drawing color. In color mode 2, the black portions
of the bitmap will also be displayed but in the current
background color. DRCS characters are subject to all the
attributes of text just as the ASCII set and supplementary
set.
I have gone a little further than the standard in
suggesting that the scaled bitmap method of displaying DRCS
characters is really not appropriate on today's computer
equipment. Since the ordinary text character shapes for the
ASCII and supplementary sets are not specified, most systems
will provide fully scalable fonts for those characters. If
the DRCS characters are not also handled in an equivalent
scalable manner, then they will not look very good.
DEF TEXTURE - 84
This defines or redefines one of the four programmable
pattern fills. The pattern mask A, B, C, or D is selected by
the byte following the DEF TEXTURE which must be one of 41,
42, 43 or 44. If the code is not one of these four, then the
2 bytes are discarded.
Next comes a stream of NAPLPS data which defines the
pattern mask in the same way as the DEF DRCS except that the
mask size defined in the TEXTURE PDI is used instead of the
character field size. The command is terminated by END, DEF
MACRO, DEFP MACRO, DEFT MACRO, DEF DRCS, or another DEF
TEXTURE.
If the INCREMENTAL POINT command is used in defining
the pattern, then be aware that the active field may be
rescaled as specified under the INCREMENTAL POINT PDI. This
rescaling will cause the actual area drawn by INCREMENTAL
POINT to be smaller than that specified.
If there is no data after the mask number, then the
specified mask is reset to its default state. At the end of
the DEF TEXTURE command, the unit screen is set back to the
physical display and the current drawing point is set back
to (0,0).
While the standard assumes that these pattern masks
will be stored as bitmaps and scaled as needed, I think it
would be useful to record them in the same scalealble manner
as I have suggested for the DRCS characters.
END - 85
This command terminates a DEF MACRO, DEFP MACRO, DEFT
MACRO, DEF DRCS or DEF TEXTURE. It is also used in
transmitting protected field data back to the host system.
UNPROTECT - 9F
This command turns the current active field into an
unprotected field. This makes the field area available for
the user to enter and edit data for transmission back to the
host system. The actual methods/keystrokes for entering and
editing data is implementation dependent. The default state
of the unit screen is protected, so no entry of data may
occur until an UNPROTECT is issued. If the UNPROTECT command
is received when the active field overlaps an already
unprotected field, then the unprotected field is changed to
protected before the active field is unprotected. This
ensures that unprotected fields never overlap. Changes in
the protection status do not affect the visible display.
The number of unprotected fields that may be defined is
implementation dependent but should be at least 40.
If the host transmits data into an unprotected field
that data will be recorded by the terminal program and will
be made available for the user to edit. Editing can only
take place if the unprotected field is also the active
field. The user can transmit the edited data back to the
host system by an implementation dependent keystroke or
mouse click. Details of the transmission format are defined
under "Service Delimiter" in the C0 set. When more than one
unprotected field is transmitted, they are transmitted from
left to right, top to bottom, using the field origin
coordinates to determine which is leftmost or topmost. The
transmission of data is to be handled independently of the
receiving of data, including any state changes made by the
user to text colors, character set, etc.
It is allowed to have other methods of user input that
are independent of the unprotected fields and that do not
affect the state of unprotected fields.
PROTECT - 90
This command causes any unprotected fields that overlap
the active field to be changed to a protected state. The
RESET PDI can be used to protect all unprotected fields.
REPEAT - 86
This command gets a repeat count from bits 6 through 1
of the byte following the REPEAT code and repeats the byte
preceding the REPEAT code, by that number of times. This
code can only be used to repeat <space> characters and any
spacing characters from the ASCII, supplementary, DRCS or
mosaic sets. This means that the non-spacing accents in the
supplementary set cannot be repeated. If the preceding
character is not one of those allowed, then the REPEAT code
and the count byte are discarded. If bits 7 through 1 of the
repeat count fall outside the range from 40 through 7F, then
the REPEAT code is discarded and the count byte is
interpreted as a normal NAPLPS code.
REPEAT TO EOL - 87
This command repeats the preceding byte as many times
as is required to reach the end of the current character
path if it is one of the allowed characters as for REPEAT.
Otherwise, the REPEAT TO EOL is discarded. If the character
field position lies wholly within the active field when this
command is received, then the character path will be
considered to end when it reaches (but does not pass) the
active field boundary.
REVERSE VIDEO - 88
This causes any following text from the ASCII,
supplementary, DRCS and mosaic sets to be drawn reversed. In
color modes 0 and 1, the pixels of the character shape are
not draw, only the background pixels are drawn using the
current drawing color. In color mode 2, the foreground and
background colors used are swapped. This will require
special handling to ensure that composite characters are
displayed correctly. Composite characters are composed of a
non-spacing accent followed by another character from the
ASCII set. The composite character codes must always be
transmitted in that order, accent first, then ASCII
character.
NORMAL VIDEO - 89
This terminates reverse video mode and returns to the
default.
Text Sizes
Text sizes can be set by the following commands or by
the TEXT PDI. The following commands effect only the
character field dimensions. All other text attributes remain
constant. The screen sizes quoted assume the default
rotation and character path is in effect.
SMALL TEXT - 8A
This sets the dimensions of the character field to 1/80
in the X dimension and 5/128 in the Y dimension. This
corresponds to an 80 by 19 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
MEDIUM TEXT - 8B
This sets the dimensions of the character field to 1/32
in the X dimension and 3/64 in the Y dimension. This
corresponds to a 32 by 15 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
NORMAL TEXT - 8C
This sets the dimensions of the character field to 1/40
in the X dimension and 5/128 in the Y dimension. This
corresponds to a 40 by 19 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
DOUBLE HEIGHT - 8D
This sets the dimensions of the character field to 1/40
in the X dimension and 5/64 in the Y dimension. This
corresponds to a 40 by 9 screen when accounting for the fact
that only 3/4 of the Y dimension is visible.
DOUBLE SIZE - 8F
This sets the dimensions of the character field to 1/20
in the X dimension and 5/64 in the Y dimension. This
corresponds to a 20 by 9 screen when accounting for the fact
that only 3/4 of the Y dimension is visible.
WORD WRAP ON - 95
Any text received after this code is word wrapped when
the line reaches the end of the character path. If the text
is being displayed in the active field, then word wrapping
takes place when the character path meets the active field
boundary. If a <space> character is the last character on
the line and the <space> character does not fit, then it is
simply discarded. A word is defined as a string of
characters between <space> characters. If one of the
following list of special characters is embedded within the
word (i.e. not at the beginning or end) then the word may be
broken AFTER the special character in order to fill the line
as much as possible.
! " $ % ( ) [ ] < > { } ^ * + - / , . : ; = ? _ ~
A word is also terminated when a mosaic character is
encountered or when any C set character (except SI, SO, SS2
, SS3) is encountered. If the word fills the line with no
spaces or special characters, then it is broken at the end
of the line anyway.
WORD WRAP OFF - 96
This turns off word wrap and text now breaks between
characters. This is the default.
SCROLL ON - 97
This turns on scroll mode. In this mode any <linefeed>
or <vertical tab> that would otherwise cause the character
field to move partially or wholly outside the display area,
triggers scrolling. The display scrolls in a direction
opposite to the direction of the <linefeed> or <vertical
tab> and only scrolls far enough so that the current
position of the character field is now wholly within the
display area. If the cursor movement command takes place
within the active field, then only the area within the
active field is scrolled. The blank area that scrolls into
view is nominal black in color modes 0 and 1, or the
background color in color mode 2.
Any buffering of data that is scrolled off the display
is implementation dependent.
SCROLL OFF - 98
This command turns off scrolling mode. If the text
cursor is advanced beyond the bounds of the display area (or
active field) by a <linefeed> or <vertical tab> then it
simply wraps to the opposite boundary.
UNDERLINE START - 99
` This command turns on underline mode. In this mode all
ASCII, supplementary, and DRCS characters and any <space>
character are displayed with a line. This line is drawn from
the character field origin across the entire width of the
character field but it does not go across the gaps created
by 5/4 and 3/2 character spacing. Its thickness is the
height of the logical pel. Mosaic characters are not
underlined, but are instead displayed in separated mode as
defined under the section "The Mosaic Set".
The underscore is then rotated along with the rest of
the character field if a rotation is specified.
UNDERLINE STOP - 9A
This terminates underline mode. In this mode, mosaics
are displayed contiguously so as to form a monochrome
bitmap.
FLASH CURSOR - 9B
This cause the cursor to blink. It also may enable user
input if the active field is in an unprotected field.
STEADY CURSOR - 9C
This cause the cursor to be displayed with no blinking.
It also may enable user input if the active field is in an
unprotected field.
CURSOR OFF - 9D
This sets the cursor to its default invisible mode. The
cursor still exists and can be positioned. This may also
disable user input, but that is implementation dependent.
BLINK START - 8E
This creates a simple blink process using the current
drawing color as the blink-from color and nominal black (the
background color in mode 2) as the blink-to color. The on
and off intervals are implementation dependent and the start
delay is zero. This is intended to provide a facility
similar to the ANSI graphics blinking found on PC's.
BLINK STOP - 9E
This terminates any blink process using the current
drawing color as the blink-from color.
EDC1, EDC2, EDC3, EDC4 - 91, 92, 93, 94
These codes are reserved for future use. At the present
time they should be discarded.
Proportional Spacing of Text
Overview
In order to guarantee the placement of text and the
positioning of line breaks on varying implementations of
NAPLPS at varying display resolutions, it is necessary to
have some guidelines as to how to produce proportionally
spaced text. If a terminal program adheres to these
guidelines, then a host system can place proportionally
spaced text onto the screen in a predictable manner.
An algorithm is provided which defines how far to move
the cursor if the character field width is parallel to the
character path. If it is not parallel, then proportional
spacing is not possible and the spacing is always based on
the full height of the character field. The spacing for the
widest characters is always equal to the character field
width, while the spacing for other characters is arranged so
that the visible gaps between characters are identical. The
algorithm is arranged so that normal size text will be
spaced identically on both low and high resolution
terminals.
Algorithms
The following tables classify the ASCII and
supplementary sets into 10 different width classes.
Characters in a given class are spaced according to the same
algorithm over the range of font sizes.
ASCII Width Classes
2 3 4 5 6 7
------------------------
0 9 5 9 5 1 5
1 0 1 5 6 5 5
2 4 5 5 5 5 5
3 6 5 5 5 5 5
4 9 5 5 9 5 2
5 9 5 5 5 5 5
6 9 5 5 9 5 9
7 0 5 8 9 5 9
8 1 5 5 9 5 9
9 1 5 2 9 0 5
A 9 0 5 9 4 5
B 9 3 5 4 5 5
C 3 5 5 9 0 0
D 5 8 9 4 9 5
E 0 5 5 2 5 9
F 9 8 9 9 5
Supplementary Width Classes
2 3 4 5 6 7
--------------------------------
0 9 4 9 5 6 9
1 0 9 2 1 9 9
2 9 4 2 9 6 6
3 5 4 2 9 5 5
4 9 7 9 9 9 6
5 9 6 5 6 9 0
6 9 9 5 9 9 4
7 6 0 0 9 5 4
8 9 9 4 9 9 7
9 1 1 9 9 9 9
A 6 6 1 9 9 9
B 8 8 7 9 5 6
C 9 9 9 9 5 4
D 7 9 4 9 9 2
E 9 9 8 9 6 5
F 7 8 2 9 9
The width class of an accented character is the maximum
width of the two components. Note that the <space> character
is always in the maximum width class. In proportional mode
<tab> and <backspace> are always considered to be in the
maximum width class (same as <space>) when they are received
from the host system.
The algorithm that determines the actual width of a
character is based upon the width class and the width of the
current fixed character field. This algorithm is intended to
make the interfont gap between all characters identical, so
when designing your implementation dependent font, you
should take this algorithm into consideration. The algorithm
is structured to ensure that smaller sizes of text appear
spaced identically in both low and high resolution video
displays.
TEXT SIZES up to (but not including) 12/256 wide
------------------------------------------------
width 0 1 2 3 4 5 6 7 8 9
------------------------------------------------
6 2 3 4 3 4 5 6 4 5 6
7 3 4 5 4 5 6 7 5 6 7
8 2 3 4 4 5 6 7 6 7 8
9 3 4 5 5 6 7 8 7 8 9
10 4 5 6 6 7 8 9 8 9 10
11 3 4 6 6 7 8 10 8 10 11
------------------------------------------------
12 6 5 4 4 3 2 1 2 1 0
The above table contains the cursor displacement to be
applied to characters in each width class at various
different character field widths. To determine which row to
use, take the character field width (which is a binary
fraction), multiply by 256 to get a number n.m/256, then
truncate the fractional portion of the number to find n. If
this result is less than 12, then use the corresponding row
in the table and scale the character displacement. For
instance, if the character field width is 15/512, then
multiply by 256 to get 8.5/256. Truncate to 8, therefore use
row 8 in the table. If the width class is 0 then the
character displacement is 2/256 which is the same as 2/8 of
the full displacement.
If the scaling result is greater than or equal to 12
then the 12 row is first scaled to determine the amount to
adjust the character displacement.
1. The character field width is truncated to DOMAIN 3
leaving the 8 most significant bits. Call this n.
2. Multiply n by 11/13 being careful to avoid overflow.
3. Subtract 1/256 from the result, then bitwise OR the
result with 1/256 and again subtract 1/256 from the
result. Truncate this final result to DOMAIN 3, i.e.
to 8 bits. This is the scale factor f. This step
causes the font patterns for the widest character
class to be scaled to an odd width.
4. Get the unit spacing number from the 12 row for the
appropriate width class.
5. Multiply this unit spacing by f.
6. Divide the result by 6, then add 1/512 for rounding,
then truncate to DOMAIN 3 leaving the 8 most
significant bits. Subtract this result from n to get
the actual cursor displacement amount.
For example, a character in width class 0 using a character
field with of 12/256.
1. 12/256 is already an 8-bit value so it is n.
2. Multiply by 11 and divide by 13 to get a 16 bit
number = 2599.
3. Result 2087 scaled down to 8 bits = 8.
4. Use 6.
5. 6 * 8 = 48, divide by 6 to get 8, add .5 and round
down to 8. Subtract 8 from 12 to get a displacement
of 4/256.
Similarly, if the field width is 24/256, then the
displacement would be 6/256. This is a very tricky part of
the standard to follow and it leaves a lot to be assumed
such as 8 bit numbers being multiplied or divided into a 16
bit register. I hope that I got it right.
Ideas and Implementations
Terminal Programs
I have come across several terminal programs that
support NAPLPS on the PC and one that supports NAPLPS on
Amiga and Macintosh computers.
PP3 (Personality Plus III) SHAREWARE
This is the only terminal program I know that fully supports
all of NAPLPS including bitmaps and DRCS characters. It is
available in English and French versions which use a user
customizable language file so it is easy to provide support
for other languages. Supports CGA, Herc mono, EGA, MCGA,
VGA, ET4000-256, TARGA-16. Basic registration fee is $25
while $40 gets you a printed manual and info on other NAPLPS
products and services.
CTLINK
Hmmm. I seem to have deleted this one. I had some problems
with it (which may have been the modem) but I remember that
it was really oriented as a terminal for commercial videotex
services. I read some comments from Dave Hughes that
indicated it is not a complete implementation, but if you
see it around, why not try it for yourself.
Tam Tam COMMERCIAL
This program is available from MacGregor Inc. in Montreal
for the Amiga and the Macintosh in both English and French
versions. The price was $79-$99 depending on which version
but I have lost my info sheet. Just call directory
assistance to get a hold of them. They do speak English just
fine, so don't be shy.
Drawing Programs
To date, I know of only one shareware drawing program
that supports NAPLPS. There are other commercial programs
but I don't yet have any info on them. In addition, I have
written a program to convert Windows 3 icons to NAPLPS
format and have a beta version of a program to convert
metafiles created by CorelDraw into NAPLPS format. The Memra
logo in the sample file MEMRA2.NAP was converted from an
original CorelDraw image.
MGE (Microstar Graphics Editor) SHAREWARE
This is an object oriented drawing (not painting) program
from Microstar Inc. that uses NAPLPS as its file format. It
can draw all the basic objects as well as providing control
over text. It can define macros, fields and blinks. If using
the VGA 16 or 256 color drivers, you can customize the
palette. This is an important feature of NAPLPS. It is not
restricted to the default DOS/Windows 16 color palette. On a
standard VGA you can display any 16 out of the 262,000
shades it is capable of displaying. Notable omissions are
NAPLPS bitmaps and DRCS characters. Microsoft compatible
mouse required (or a graphics tablet that emulates a
Microsoft mouse). This is a good program that is often
criticized because its interface is not 100% the same as
Windows, however if you do PRINT OUT the README.MGE file and
keep it by your side while you draw, you will find that this
program is every bit as effective as CorelDraw and a much
better deal. Supports CGA, Herc mono, EGA, MCGA, VGA, ET4000-
256, TARGA-16. Basic registration fee is $50 while $75 will
get you a printed copy of the manual and info on other
NAPLPS products and services.
Teledraw COMMERCIAL
This program is being developed by Dave Hughes in
conjunction with a team of programmers in Russia. He has
working beta versions and is expected to release the program
by the end of April 1993. This program will provide full
NAPLPS support including the design and use of DRCS
characters such as the Russian characters used in
SAIL.NAP. This program is a combination drawing/terminal
program that will decode NAPLPS images in electronic mail on
the fly and will allow you to draw or edit images and
transmit them in electronic mail messages.
NAPICO SHAREWARE
This program from Memra Software Inc. is intended to enhance
NAPLPS images created with MGE by adding Windows icons to
the image. The icon positions are marked with a small
rectangle and NAPICO takes a list of Windows 3 .ICO files
and inserts the icon bitmap into those marked positions. The
use of SMALL bitmaps like these icons can really enhance a
NAPLPS image. A $10 registration fee is requested from those
who can afford it.
NAPWMF SHAREWARE
This program from Memra Software Inc. converts Windows
metafiles that are created using CorelDraw's File Export
function. It does not necessarily work with metafiles from
other programs, although full .WMF support will be included
in a future version. This makes it possible to add a wide
range of clipart images and True Type fonts to a NAPLPS
image. See the Memra logo in MEMRA2.NAP that was produced by
a beta version of this program. The images produced by
version 1.0 won't be quite as big.
TURSHOW SHAREWARE
This program doesn't fit under either category. It simply
displays the NAPLPS images on your CGA, EGA or VGA screen.
Clip Art libraries
I would like to see people put together libraries of
non-copyrighted clipart for use by others. Note that this
means the images must be original art, not converted from a
commercial clipart library. As soon as I get NAPWMF
released, I will be creating a library of electrical symbols
for use in drawing circuits.
ANSI compatibility
It should be possible for a terminal program to
simultaneously support both NAPLPS and the ANSI-BBS protocol
simultaneously. Because of a conflict with the FLASH CURSOR
command, it is not possible to arbitrarily interleave ANSI
and NAPLPS data streams but it should be possible to support
both code systems in a non-interleaved manner. The NAPLPS
spec uses the 3 character sequence ESC 25 41 to indicate
that NAPLPS decoding is to be turned ON and the sequence ESC
25 40 turns OFF the NAPLPS decoding. Outside of this
bracketing, it should be possible to support ANSI escape
sequences. It is fairly straightforward for sysops to ensure
that the ON/OFF sequences are transmitted, especially if
they are using Microstar's SHOWPLP utility.
User Interaction
Although NAPLPS provides facilities for user
interaction in the form of unprotected fields, the cursor
and transmit macros, it does not require that those
facilities be used when there is an application layer
protocol for handling such things. I would like to suggest
that the general BBS and NAPLPS community should agree on a
standard way for handling such user interactions that would
allow mouse and keyboard support in a non hardware dependent
manner.
As for mice and other pointing devices, I would like to
suggest that the terminal program transmit a POINT SET ABS
(code 24) PDI to the BBS using the currently set domain co-
ordinates to indicate a mouse click followed by some code to
indicate whether it was a button-down or button-up event and
which button it was. A POINT SET REL could be transmitted to
indicate a mouse move event.
For keyboard events (key-up and key-down) a form of the
PC scan-codes could be transmitted. These codes are also
used by certain UNIX terminals and similar events are
generated by Macintosh keyboards and X-Windows keyboards so
the only thing about these codes that is specific to the PC
is the actual code numbers.
There should probably be some indicator code
transmitted to distinguish between transmission of
unprotected fields and transmission of an event. Transmit
macros could, of course, be programmed to emulate either
events or unprotected field transmittal or anything else.
I would like comments on these ideas, please.
Level 6 vs. Level 7
It is important to remember that NAPLPS exists at the
presentation layer which is the 6th of the 7 OSI networking
levels. It is intended to be used as the foundation for
interactive on-line real-time graphical applications, which
are at the 7th OSI level. NAPLPS does not do everything and
it is not intended to do everything. I feel that it is
important for BBS operators and users to start discussions
on an overall standard for graphical BBS interchange, and I
would like to see NAPLPS as the foundation for the
presentation layer of that interchange. I would also like to
see any overall standards maintain the OSI division into 6
independent layers.
It may be appropriate to extend NAPLPS to include
additional G-sets and I know that there is already a JPEG
extension to NAPLPS being prepared for public release. Since
the BBS community is likely to be the major user of NAPLPS
over the next few years, we need to maintain a discussion of
this protocol and its implementations and suggestions for
extensions.
Resource List
I have put a lot of work into writing this document and
getting it widely distributed (worldwide). If you find it to
be of use and can afford to, I would appreciate receiving
$20 to help me continue to work on NAPLPS support.
Star Valley BBS 1-604-546-2705
- speeds up to v.32bis
- NAPLPS art galleries including some bitmaps
- look in file areas DOS.BBS and ART.NAP
- downloading available on the 1st call
- author of NAPICO and NAPWMF utilities
- Fidonet address 1:353/350
FREQ NAPLPS - This document
NAPICO - convert Windows 3 icons to NAPLPS
NAPWMF - convert CorelDraw images to NAPLPS
MGESHARE - Microstar Graphics Editor
PP3SHARE - Personality Plus 3 term program
SHOWPLP - door to add NAPLPS to your BBS
TURBOARD - BBS program with built-in NAPLPS
PC Atlanta 1-404-395-6327
- speeds up to v.32bis/HST
- home of Turboard BBS software
- full NAPLPS, ANSI, ASCII support
- sysop Shawn Rhoads
- Fidonet address 1:133/904
FREQ TB114.EXE - latest Turboard ver 1.14
Russell Country BBS 1-406-423-5433
- v.32bis
- home of Native American Share-Art
- sysop Cynthia Denton
- wonderful online art galleries
- Fidonet 1:3400/7
Microstar Support BBS 1-614-727-5272
- speeds up to v.32bis (I can only connect at 9600 bps)
- samples from many NAPLPS systems
- interactive NAPLPS game like Tetris
- the authors of MGE and PP3 and SHOWPLP
- NAPLPS message area
- Fidonet 1:163/537
Old Colorado City 1-719-632-2658
- David Hughes ([email protected]) operates an
Internet/BITNET/Fidonet NAPLPS mailing list
- about to release Teledraw a combination NAPLPS
drawing and terminal program
Le Muse 1-514-984-1297
- 2400 bps
- an experimental electronic gallery
- text in French
- includes a selection of children's art
The Gadget Zone 1-604-946-5815
- speeds up to v.32bis
- home of the ONLINE_GRAPHICS echo message area
- many NAPLPS related files
- Fidonet address 1:153/951
Harris Technology Associates BBS 1-508-877-7233
- NAPLPS software for TBBS systems
- many NAPLPS menus
- several NAPLPS games
- illustrated electronic books
Hi Res BBS 1-306-782-6820
- some sample bitmaps converted to NAPLPS with a
commercial .PCX conversion program
- full NAPLPS support (running Turboard)
- sysop Warren Zatwarniski
- Fidonet 1:140/111
Online Acess magazine
the Summer 1992 has an article about several on-line
NAPLPS art galleries. It includes several wonderful
photos of sample NAPLPS artwork captured from a low-
resolution 16-color video display
BoardWatch magazine
The December 1992 issue has an article on NAPLPS
support by several BBS systems. It includes 6 color
photos of NAPLPS screens.
Byte magazine
There was a series of 4 articles (55 pages in total)
explaining much of the NAPLPS coding system and
discussing the potential for NAPLPS. These articles
were in the February, March, April and May 1983 issues.
In the 2nd article, a small NAPLPS image is decoded and
explained in detail. To recreate that image, cut out
the following lines between the dashed ones and place
in a file named BYTE.SCR. Then type DEBUG <BYTE.SCR
This will create the image in a file called BYTE.NAP.
If you are not using a PC, then you will have to find
some other means of entering the hex codes into a
document file. Note the picture will display in PP3 but
is not editable in MGE. If you create BPREF.NAP and
prepend it to the image by typing:
COPY BPREF.NAP+BYTE.NAP BEDIT.NAP
then you will create an editable version of the same
image which will actually look more like the original
as far as line thickness and line texture.
---------8X----cut here-------------BYTE.SCR follows---
E 100 E 3C 49 20 50 3C 64 23
E 108 40 37 49 60 40 48 60 40
E 110 48 42 40 46 46 40 60 40
E 118 40 40 46 47 40 6A 60 3C
E 120 52 23 44 24 48 57 44 31
E 128 40 7C 40 25 78 44 60 3C
E 130 40 35 40 61 47 47 66 41
E 138 25 47 55 64 F 48 6F 75
E 140 73 65 E 3C 6D 24 42 68
E 148 47 F 42 49 52 44 53 E
E 150 2F 41 77 50 47 47 64 47
E 158 47 54 2D 40 40 54 40 40
E 160 76 23 40 25 40 49 4A 2D
E 168 47 47 64 47 47 54 2D 40
E 170 40 54 40 40 76 24 52 70
E 178 3C 7F 2D 78 78 66 40 48
E 180 5B 2D 40 48 47 47 47 75
E 188 2D 40 51 49 47 45 44 2D
E 190 7F 6F 5B 78 68 7B 35 40
E 198 41 79 40 48 74 47 56 4D
E 1A0 25 78 62 54 F 43 4C 4F
E 1A8 55 44 E 3C 6D 25 47 44
E 1B0 6A 23 42 29 7F 75 74 25
E 1B8 40 52 62 23 41 29 7F 75
E 1C0 74 23 40 25 40 52 67 29
E 1C8 7F 75 74 25 40 52 60 22
E 1D0 4C F 52 41 49 4E E 22
E 1D8 40 3C 40 24 40 40 40 35
E 1E0 50 46 42 40 51 66 40 50
E 1E8 60 7F 6D 76 77 62 72 24
E 1F0 50 42 44 F 52 4F 41 44
E 1F8 E 22 40 40 40 4A 64 24
E 200 4A 45 47 F 46 69 67 75
E 208 72 65 20 31 E 3C 76 24
E 210 42 7E 78 F 46 69 67 75
E 218 72 65 20 31 0
N byte.nap
RCX
11E
W
Q
---------8X----cut here-------BPREF.SCR follows----
E 100 E 20 7F 4F 21 48 40 40
E 108 49 3E
N bpref.nap
RCX
A
W
Q
------------8X---cut here-----uuencoded----------------------
begin 600 memra2.nap
M&!LB1H4?0$"@_\^AS<#`R<"^X,"\^/___[[DP+S2TM+2ONC`O.CMZ,6^[,"\
MR<G)R;[TP+SAZO'TOOC`O,WHS<&^_,"\^,#`P+[;T+[;T-O0H-#`H\#`TL#`
MOOC`P,"WT>K>Y,#`P.C`P,#PP,#`Z,?'Q_;'Q\?NQ\?'[L?'Q^7'Q\?LQ\?'
MW<?'Q]W'Q\?<Q\?'TL?'Q]C'Q\?0Q\?&S<?'QLSX\.CPQ\?'R<?'Q\O'Q\?:
MQ\?'V\?'Q]7'Q\?EQ\?'WL?'Q^?'Q\?FQ\?'Y\#`P.#`P,#@P,#`VL#`P-G`
MP,#9P,#`TL#`P-G`P,#3P,#`TL#`P-/'Q][/____\____^3____M____W/__
M_^7____=____Y?___]W____/____UOCX^,#X^/C(^/CXR?CX^,KX^/C+^/CX
MT_CX^-SX^/CC^/CX[?CX^.3X^/CE^/CX]?CX^/7X^/CU^/CY\<#`P<+`P,'"
MP,#!TL#`P=G`P,#?P,#!Z,#`P/_`P,#1P,#`T\#`P-C`P,#;P,#`T,#`P-K`
MP,#9P,#`T<#`P.'`P,#AP,#`V+?9XO[?P,#`Z,#`P/#`P,#HP,#`Z,?'Q_;'
MQ\?OQ\?'[L?'Q^W'Q\?>Q\?'W<?'Q^7'Q\?5Q\?'T\?'Q]7'Q\?,Q\?'Q,?'
MP,K'Q\?'Q\?'Q\#`P,C'Q\?'P,#0P,?'Q,3X^,CHP,#!P/___]7____5____
MSO___\_____.^/CXP/CX^-+X^/C2^/CXXOCX^.KX^/CI^/CX]/CX^.KX^/C[
M^/CX\_CX^/+X^/GJ^/CY^\#`P='`P,'AP,#`[L#`P.3`P,#\P,#`\\#`P/K`
MP,#PP,#(P,#`P/#'Q\??Q\?'U\#`P-C'Q\?7Q\?'U\#`P,C`P,#8P,#`T,#`
MP-_`P,#.P,#`Q?CX^.WX^/CK^/CXZOCX^.KX^/CB^/CXZ?CX^.'X^/C8____
MW______X^/CP^/CXZ/____;____W____[_____;____V^/CHP\#`P-W`P,#;
MP,#`U,#`P./`P,#CP,#`Z\#`P.'`P,#JP,#`V,#`P-+`P,#1P,#`T,#`P-#`
MP,#8P,#`T+[;T,#`M]GA_?3`P,#8P,#`V,#`P-#'Q\??Q\?'UL#`P-#'Q\?6
MQ\?'U\?'Q\O'Q\?$Q\?'P_____3____N____[O___^_____F^/CXX/CX^.#X
M^/C@^/CXZOCX^.KX^/CK^/CX^_CX^/K`P,#%P,#`S,#`P,O`P,#:P,#`VL#`
MP-K`P,#AOOC`P,"WT-?PQ\#`P,7`P,#,P,#`S<#`P-7`P,#3P,#`W<#`P-O`
MP,#;P,#`T<#`P-'`P,#)P,#`V<#`P-#`P,#9P,#`T,#`P-C`P,#0P,#`T,?'
MQ]_`P,#0Q\?'W\?'Q]?'Q\?/Q\?'U\?'Q^7'Q\?=Q\?'T\?'Q]7'Q\?3Q\?'
MR\?'Q\3'Q\?+____^\?'Q\3____\____\_____3____T____[?___^7____V
M^/CX^/CX^/#____O____]_CX^.CX^/CP^/CX\/CX^.CX^/CP^/CXZ/CX^/'X
M^/CI^/CX^/CX^/#X^/CR^/CXZ_CX^.OX^/CL^/CX]/CX^/7X^/C\^/CX_*'-
MP,#`V[[;T,#`M]#?P<+'Q\?%Q\?'S<?'Q\W'Q\?&Q\?'SL?'Q\W'Q\?6Q\?'
MSL?'Q]['Q\?7P,#`V,#`P-C`P,#@P,#`T,#`P-'`P,#:P,#`VL#`P,+`P,#3
MP,#`P\#`P,K`P,#"P,#`P\#`P,/`P,##P,#`PL#`P,/X^/CZP,#`P_CX^//`
MP,#!^/CXZOCX^.KX^/CQ^/CX\/CX^.#X^/CP^/CX\/CX^/#____W____]___
M_______W_____O____S____\____^Z'-P,#)P+[XP,#`M]#VYO?`P,##P,#`
MT\#`P,K`P,#"P,#`RL#`P-+`P,#2P,#`T<#`P.+`P,#8P,#`XL#`P.'`P,#(
MP,#`T,#`P,C`P,#8P,#`T,#`P-#`P,#0P,#`T<#`P,G`P,#1P,#`R,#`P-'`
MP,#)P,#`R<#`P,+`P,#"P,#`P_CX^/KX^/CZ^/CX\OCX^.KX^/CQ^/CXZ/CX
M^.'X^/C@____[____^_____N_____O____[____]_____?CX\/#`P,##P,#`
MPL#`P,O`P,#+P,#`TL#`P-/`P,#:P,#`V<#`P-K`P,#9P,#`Z<#`P.#`P,#@
MP,#`V,?'Q]_'Q\?GQ\?'U\?'Q]_'Q\?6Q\?'U\?'Q]W'Q\?%Q\?'S<?'Q\W'
MQ\+'Q\?'Q\?'Q\;'Q\?&Q\?'Q\#`P-#`P,#(P,#`R,#`P,G`P,#(Q\?'P/CX
M^/#____W^/CX\/CX^-GX^/CI^/CXZ_CX^/S____V____[O___^[____O____
M[____^?X^/CH^/CXX/CX^.CX^/CH^/CXZ/CX^/'X^/CQ^/CXZ_CX^/+X^/CR
M^/CX^OCX^/KX^/C[P,#`PL#`P,&WV,[6S\#`R.#'Q\?'__________[____]
M____]?____7____N____]O____?X^/CP______CX^/#____O^/CXZ/CX^.CX
M^/CH^/CXV/CX^.CX^/CI^/CXX?CX^.GX^/CJ^/CX\_CX^//X^/CM^/CX]?CX
M^/?`P,#&P,#`Q<#`P,7`P,#,P,#`U,#`P,S`P,#3P,#`T\#`P-O`P,#:P,#`
MTL#`P-K`P,#2P,#`V<#`P-C`P,#9P,#`V,#`P-C'Q\?7P,#`V,?'Q]?'Q\?7
MQ\?'W\?'Q]?'Q\?5Q\?'U\?'Q\['Q\?6Q\?'UL?'Q]+'Q\?1Q\?'P<?'Q\GX
M^,CHQ\?'RL?'Q\/'Q\?4Q\?'U,?'Q]W'Q\?GQ\?'W\#`P.C`P,#8P,#`T,#`
MP-'`P,#1P,#`T<#`P-+`P,#)P,#`RL#`P,G`P,#*P,#`R+?1TN;$P,#`X,#`
MP-C'Q\?FQ\?'Y\?'Q]W'Q\?=Q\?'UL?'Q]W`P,#TP,#`[,#`P//`P,#RP,#`
M\<#`P/+`P,#XQ\?']L#`P.C'Q\?>Q\?'Y<?'Q]['Q\;XQ\?%X<?'Q,['Q\3'
MP,#`R,?'Q\?'Q\?'P,#(Z,?'Q,[X^,CPP,'#P_CX^.3X^/CB^/CXXOCX^.'_
M___G____Y____^_X^/CP____[?____7____]_____<?'P,?'Q\?'Q\?'S\#`
MP-#'Q\__Q\?$Q_CXR.C`P<+#P,#`P_CX^/SX^/CR^/CXZOCX^/+X^/CI^/CX
MX?CX^.#____G____Y____^7____MQ\?`P<?'Q\?'Q\?/P,#`T<?'S_?'Q\3'
M^/#XX,#`P\+`P,CHP,#`R<#`P,C`P,#!P,'`Q<#`P,'X^/CZ^/CX^/CX\-C`
MP,+'P,#PT,?'Q]'`P,#@P,#`V<#`P-K`P,#BP,#`V<#`P-'`P,#9P,#`V<#`
MP-#`P,#8P,#`V+?9PL[<P,#`X,#`P.#'Q\?>Q\?'Y\?'Q^7'Q\?=Q\?'UL?'
MQ]W`P,#TP,#`[,#`P//`P,#JP,#`^<#`P/+`P,#PQ\?'_L#`P.#'Q\?FQ\?'
MY<?'Q]['Q\;XQ\?%X<?'Q,;'Q\3'P,#`R,?'Q\_'Q\?'P,#(\,?'Q,;X^,CH
MP,'#P_CX^.SX^/CB^/CXXOCX^.'____?____[____^_X^/CP____[?____7_
M___U_____<?'P,?'Q\?'Q\?'S\#`P,C`P,#(Q\?7Q\?'Q,?X^,C@P,'"P\#`
MP,/`P,#$^/CX\OCX^.KX^/CJ^/CX\?CX^.+X^/C8____Y____^?____M____
M]?__^/C'Q\?'Q\?'S\#`P,G`P,CXQ\?$QOCP^.#`P,/"P,#(Z,#`P,G`P,#!
MP,#`R,#!P,7X^/CYP,#`POCX^/CX^/#8P,#"Q\#`\,C'Q\?9P,#`V,#`P.'`
MP,#:P,#`VL#`P-G`P,#9P,#`V<#`P-'`P,#8P,#`V,#`P-"^V]#`P+?1ZO/#
MQ\?'W,?'Q]S'Q\?3Q\?'R?CXT-#`P,#5P,#`UL#`P-[`P,#CP,#`VL#`P-G`
MP,#@P,#`V<#`P-C'Q\?GQ\?'W[[XP,#`M]G:]MS'Q\/&^/CXV/___][____6
M____YO___]W____<____Y/____/___[N___^]<?'QL7'Q\;$P,#8P<?'Q,7X
M\/#0P,##PL#`T,#`P<'`^/CPP,#`P\#`P/#8Q\?$Q\#`P._`P,#<P,#`U,#`
MP-/`P,#2P,#`V\#`P-'`P,#9P,#`T<#`P-'`P,#0P,#`T<#`P.G`P,#8P,#`
MV+?8[NS<P,#!QL#`R/C'Q\;"M]CGX<7`P,#-P,#`S<#`P-/`P,#4P,#`U,#`
MP-K`P,#:P,#`T\#`P.+`P,#AP,#`X<#`P.#`P,#@P,#`V,?'Q]_'Q\?7Q\?'
MWL?'Q]_'Q\?>Q\?'U<?'Q]7'Q\?,Q\?'S,?'Q\OX^/#H^/CX],#`P,/X^/CS
M^/CX\OCX^/'X^/CR^/CXX/CX^.CX^/C8____YO___^W____M____]/____O_
M___Z____^<?'Q\O'Q\?+Q\?'T\?'Q]3'Q\?5Q\?'Y\?'Q]_`P,#@P,#`V,#`
MP-G`P,#9P,#`V\#`P-+`P,#2P,#`Q,#`P-3`P,C8_____/____S____\____
M]?____7____U____[O___^_____O____[_CX^.#X^/C@^/CX\/CX^/#X^/CH
M^/CX\?CX^/#X^/CI^/CXZ?CX^/+X^/CJ^/CX\OCX^/3X^/C[^/CX]/CX^/WX
M^/C]P,#`Q<#`P,+`P,#"P,#`P[?8WMS4P,'`Q\#`R-C'Q\;%P,#`PL#`P,'`
MP,#1P,#`RL#`P-#`P,#+P,#`T,#`P-+`P,#9P,#`V<#`P-C`P,#0P,#`X,?'
MQ^?'Q\??Q\?'W\?'Q]?'Q\?=Q\?'SL?'Q]W'Q\?.Q\?'S,?'Q\7'Q\?#Q\?"
MP?CX\.#`P,7$P,#`P\#`P,3X^/C[^/CX^_CX^//X^/CI^/CXZ?CX^.CX^/CH
M^/CXX/____;X^/CH____]O____?____V_____O____3'Q\?&Q\?'Q<?'Q\7'
MQ\+'M]G8P.['QL/&^/CPV,#!Q,*AS<#`P-N^V]#`P+?8Q_+BP,#8\,#`P,+`
MP,#$^/CX\_CX^/OX^/CS^/CXZ?CX^.CX^/C@^/CX\/CX^/#X^/CX____]___
M__;____W_____O____[____VQ\?'Q<?'Q\:AS<#`R<"^^,#`P+?0_OS$P,'`
MQ\#`R-#'Q\;#P,#`U,#`P-+`P,#2P,#`V\#`P-G`P,#9P,#`Z<#`P.#'Q\;$
M^/CX\/CX^.C____W____]____^_X^/CP__________?____M____]?____S'
MQ\?$Q\?"QZ'-P,#`P+[;T,#`M]#_T>CX^/CP____]_CX^/#____O____[_CX
M^.#____O____]____^_X^/CH____]L?'Q\;'Q\?&Q\?'Q<?'Q\;'Q\?5Q\?'
MYL#`P.#`P,#0P,#`V,#`P-#`P,#0P,#`TL#`P-G`P,#2P,#`R,#`P-+`P,#"
MP,#`PL#`P,*AS<#`R<"^^,#`P+?0[N3<^/CPX/CYZ-_`P,CHQ\?([\#`S_'`
MP,CPQ\?(]\#`S^G`P,C@__[OX?CX\.#X^/;/M]#FY?/`P,;%^/CP^,#`P</`
MP,C(P,#"Q,#`R-C'Q\7$P,#(V,?'QL7X^/#HQ\?"PL?'Q\?'Q\?-P,#`R,?'
MQ\[`P,#(Q\?'S\#`P,C`P,#0P,#`R<#`P-#'Q\;&^/CX\/CX^/#X^/CP^/CX
M^/CX^.#X^/CP^/CXZ?CX^/'X^/CY^/CX\OCX^/FWT.;$U,#`Q\7X^/#PP,#!
MPL#`R-#`P,'$P,#`S<#`P,/`P,#+P,#`TL#`P-'`P,#:P,#`V<#`P-C`P,#(
MP,#`R,?'Q]_`P,#8Q\?&Q?CX^-CX^/CX^/CX\/_________^^/CX^/____W'
MQ\?&Q\?&Q\#`R.#'Q\;&^/CPX,?'P,.WT-?ER?CX\.#`P,##^/CX^_CX^/SX
M^/CZ^/CX\OCX^/+X^/CI^/CXZOCX^/#X^/CH^/CXZ?CX^.CX^/C@____Y_CX
M^.#____E____[O____;'Q\?#_____,?'Q\O'Q\?5Q\?'W<?'Q_?'Q\?FQ\?'
MY\#`P.C'Q\?>P,#`X,?'Q]_`P,#0Q\?'U\?'Q^['Q\?NQ\?'Y<?'Q]7'Q\?=
MQ\?'T\?'Q\W'Q\?"Q\?'P_____O____T____[/____7____F____YO___^__
M___O^/CX\/CX^/#____W^/CX\/CX^.CX^/CP^/CXZ/CX^.#X^/C8^/CXX?CX
M^.#X^/CJ^/CXZ/CX^.KX^/CI^/CXYOCX^.WX^/COP,#!P<#`R.#'Q\?$Q\?'
MS<?'Q\S'Q\?5Q\?'UL?'Q]['Q\?>Q\?'U\?'Q^?'Q\??P,#`V,#`P-C`P,#8
MP,#`V,#`P-G`P,#9P,#`T,#`P-G`P,#2P,#`T<#`P-+`P,#+P,#`R\#`P,/`
MP,#"P,#`POCX^/K`P,#!^/CX^OCX^/'X^/CR^/CX\?CX^/'X^/CI^/CXZ?CX
M^.'X^/CA^/CXX?CX^.CX^/CI^/CXX?CX^.GX^/C@^/CX\_CX^.GX^/CJ^/CX
M\OCX^/+X^/C[^/CX\_CX^/O`P,#$P,#`Q,#`P,S`P,#3P,#`S,#`P-/`P,#3
MP,#`V\#`P-K`P,#1P,#`V,#`P-'`P,#1P,#`V,#`P-#`P,#9P,#`V,#`P.#'
MQ\??P,#`V,#`P.#'Q\?6P,#`V,?'Q]?'Q\?6Q\?'YL?'Q]['Q\?<Q\?'S<?'
MQ]7'Q\?,Q\?'Q;?;Z/SH^/CQW/#8V,#'Q\7`R.#HP/CX\>3`P-C(P,#!Q+?9
MZ_''P,#)[<'%P,3X^.#XQL+'Q,#`R>3'Q\3'P,#(Z+?1P_ODQ\?.X\C@Z,#`
MP,/!\-C8P,?'SNSX^.#XQ\?&P[?3R,W$___VY,;"Q\3`P-C(P<7`Q/__]MS`
MP,/`^/CPX+[;T,#`M]+!]<K`P.OAQ\?`^___U-:WV??!]/CXRO#__O_RQ\?V
MS+[XP,#`M]'NV]'____N____[O___]S____2____T____]S____D____]_CX
MZ?/X^/',^/CQU_CX\NCX^/+Y^/CZPOCX^N/X^/KS^/CY\<#`P<+`P,'!P,#!
MR<#`P,[`P,#.P,#`S<#`P,[`P,'8P,#`W\#`P=C`P,#?P,#`Y\#`P.?`P,#F
MP,#`Y\#`P,'X^/CY^/CXTOCX^,GX^/C0^/CXR?___]?X^/C`^/CXT/CX^,C_
M___O^/CXZ/___^_X^/CH____Y_CX^/#X^/C@____[___]_[___?V___W_O__
M]_3___?]___W_O__]_W___?\___W_?___\7___?]___W_/___\7____#___W
M_/___\S____$___W_/___\O____#____Q?___\3____+____Q,#`P-/`P,#;
MP,#`VL#`P-+`P,#;P,#`VL#`P./`P,#:P,#)T,#`R-?`P,C?P,#(W\#`R-_`
MP,C?P,#(U\#`R-_`P,C>P,#(WL#`R.?`P,CDP,#(YL#`R-W`P,CLP,#(Y,#`
MR,/`P,C"P,#(R<#`R,G`P,C*P,#(P,#`R,C`P,C`P,#`^,#`P/#`P,#PQ\?'
M]\?'Q__'Q\?OQ\?']\?'Q_;'Q\?NQ\?'Y\?'Q^;'Q\?NQ\?'WL?'Q^;'Q\?E
MQ\?'W<?'Q\;'Q\?'Q\?'QL?'Q\;___?Z___W\O__]_G___?Z___W^?___L__
M__[6___^[/___>''Q\7`Q\?%V,?'Q?''Q\;TQ\?&_,?'SL7'Q\[/Q\?.S\?'
MS]C'Q\_9M]'E_\W`P,#)P,#`Y,#`P.S`P,#MP,#`]L#`P.O`P,#CP,#`X<?'
MS];'Q\_&Q\?/U\?'S\['Q\_/Q\?/S\?'S\_`P,C(P,#(T,#`R,C`P,C(P,#(
MR,#`R,G`P,C*P,#(R<#`R,K`P,#9P,#`V<#`P-G`P,#@P,#`VL#`P-G`P,#9
MP,#`V,#`R,/`P,C#P,#(PL#`R,+`P,C#P,#(PL#`R,/`P,#ZP,#(RL#`P/O`
MP,C"P,#(PL#`R,+`P,C#P,#(PL#`R,G`P,#ZP,#`^<#`P/G`P,C"P,#(P,#`
MP/'`P,C"P,#(P,#`P/C`P,#YP,#`^<#`R,#`P,#XP,#`^,#`R,#`P,#XP,#`
M\,?'Q_?`P,#PQ\?']\#`P/#`P,#HP,#`\,?'Q^_'Q\_FP,#(V,?'S^;'Q\_>
MQ\?/WL?'S^7'Q\_?Q\?/WL?'S^7'Q\_>Q\?/WL?'S]W'Q\_?Q\?/WL?'S^7`
MP,C8P,#`R,?'Q\;'Q\?'____]O____?X^/CP____]_CX^.C____O____]_CX
M^.C___?^___W__CX\/CX^/#X^/CP^/CX\/CX^/C"^/CP^?CX^,KX^/C1^/CX
MROCX^,GX^/C*^/CXT?CX^,+X^/C1^/CPZ_CX\.KX^/#J^/CP\?CX\.GX^/#Q
M^/CPZ/CX\/#X^/C(^/CXT/CX^-C____7^/CXT/___\_____7^/CXV/___^__
M___G____Y____^?X^/C@____Y_CX^.#X^/CH___WUO__]\W___?,___WU/__
M]]S___?-___WT___]\O___?=___WT___]]S___?3___WT___]\W___?5___W
MW/___\[X^/C8____S____]?____7____U_CX^,CX^/C0____U_CX^-#X^/C0
M^/CXR/CX^-GX^/C0^/CXR?CX^-'X^/C2^/CXT?CX^-+X^/C2^/CXTOCX^-KX
M^/C3M]K*R,+X^/G\^/CY^_CX^>OX^/GB^/CYXOCX^='X^/G1^/CYR/CX^,_X
M^/#^^/CP]OCX\/WX^/#T^/CPZ_CX\/'X^/#AQ\?$Q\?'S]?'Q\_'Q\?/QL?'
MS\7'Q\?\Q\?'_,?'Q_O'Q\?JQ\?'\<?'Q^K'Q\?JQ\?&W\?'Q]G'Q\;7Q\?&
MS\?'QL^WTOC:T<#`R.#`P,C3P,#(VL#`R-3`P,C-P,#(U<#`R,_`P,#_P,#!
M^,#`P?'`P,'QP,#!X\#`P>+`P,';P,#!R\#`P<OX^.C`___^______C___[W
M____Z/___^C____9____V?___]/____9____R____\O____-____Q?___\?_
M___&___W][?2ZNCRQ\?&Q<?'QM7'Q\;=Q\?&YL?'QN7'Q\;OQ\?&_\?'Q_C'
MQ\_!Q\?/P<?'S\/'Q\_;Q\?/U,?'S];'Q\_5P,#(V,#`P\'X^/C!^/CXPOCX
M^,'X^/#[^/CXR_CX^,WX^/C5^/CXU_CX^-7X^/CG^/CXW_CX^>CX^/GH^/CY
M\?CX^?CX^/GYM]+[WM/___?O___W]___]_7___?T___WZ____\+____"____
MP?___\C___[/___^W____N;___[F___^[?___O7'Q\;$P,#8P,#`P<G`P,')
MP,#!T<#`P-_`P,'9P,#`[L#`P.;`P,#WP,#`]L#`P/7`P,#\P,#`_,#`R,O`
MP,C"P,#(P<#`R,&^],#;T*+`P,#!_>&XR/CMVLC\_^L*#U=I;F1O=W,@<')O
M9W)A;7,-"B`J("H@1V%M97,@*B`J#0I'<F%P:&EC<R!S;V9T=V%R9:'-P,#)
M[:/$OM+0\,"SR_#MPO7(Z,JAS<#`R<"CP+[LP-+0HO#`P,#F];C"RM+ZR.7>
MVPH/365M<F$@4V]F='=A<F4@26YC+B!W87,-"F9O=6YD960@:6X@,3DX-B!B
M>2!-:6-H865L#0I$:6QL;VX@86YD($UA<F=A<F5T($-L87!P:7-O;BX-"E1H
M92!F:7)S="!S:&%R97=A<F4@<')O9W)A;0T*<F5L96%S960@:6X@,3DY,R!W
M87,@82!U=&EL:71Y#0IT;R!A9&0@5VEN9&]W<R!I8V]N<R!T;R!A#0I.05!,
M4%,@9')A=VEN9RZAS<#`P.2^X,#2T+C!S]3<P-+!P;G$P,#`P,#`P,#`P,#`
MP,#`P,#`P,#`P,#`P,CBR.+(XLCBP,#`P,#`P,#`P,#`P,#`XLCBR.+(XL#\
MP,#`P,#`P,#`P,#`P,+`P,#`P,#`__#`P,#`P,#`P,#`P,#`R,'WW??=\/__
MP,#`P,#`P,#`P,#`P,#@Q]S'W?#___S`P,#`P,#`P,#`P,#`PL#=\-WP____
M\,#`P,#`P,#`P,#`P,#(P??!\/_____`P,#`P,#`P,#`P,#`P,#'W?#_____
M_,#`P,#`P,#`P,#`P,#`P,#`_______PP,#`P,#`P,#`P,#`P,#`P/S`____
M_\#`P,#`P,#`P,#`P,#`P,#\Q\/____\P,#`P,#`P,#`P,#`P,#`_,?#____
M_,#`P,#`P,#`P,#`P,#`P/S'P_____S`P,#`P,#`P,#`P,#`P,#\Q\/____\
MP,#`P,#`P,#`P,#`P,#(_,?#_____,#`P,#`P,#`P,#`P,#`S^#'P_____S`
MP,#`P,#`P,#`P,#`PLC\Q\/____\P,#`P,#`P,#`P,#`P.+(X,?#_____,#`
MP,#`P,#`P,#`P,?BR.#'P_____S`P,#`P,#`P,#`P-WXWLC@Q\+/___\P,#`
MP,#`P,#`P_CA]^'XX,G#^/___,#`P,#`P,#`P,#/XL?>Q^#)Y,_C__S`P,#`
MP,#`P,#`P/[(W?C<R>;0_L_\P,#`P,#`P,#`P,##^.'WX,GFT./X_,#`P,#`
MP,#`P,#`P,_BQ]S)YM#BS^#`P,#`P,#`P,#`P,#`_LC<R>;0XLC`P,#`P,#`
MP,#`P,#`P,/XX?#FT.+(P,#`P,#`P,#`P,#`P,#`S^+'PM#BP,#`P,#`P,#`
MP,#`P,#`P,#^R-S`W,#`P,#`P,#`P,#`P,#`P,#`P,CA\,#`P,#`P,#`P,#`
MP,#`P,#`P,#`P,#`P,#`P,"XP=_\Y,#2P<&YQ,#`P,#`P,#`P,#`P,#`P,#`
MP,/PP,#`S\/PP,#`P,#`P,#\S\/P_,_`S\#`_,#`P/S/P_#`P,#`P,#`P,#`
MP,#`P,#`P,#`P,#`_,_#\,#`P,##\,/PP,#`P,#`P,#`P,#`P,#`P,#`P?_`
MP,#`P,#`P,#`P,#`P,#`P,#!]]S'_,#`P,#`P,#`P,#`P,#`P,#`W?#?\-WP
MP,#`P,#`P,#`P,#`P,#`Q]S'P__!\,#`P,#`P,#`P,#`P,#`P,?!\/S/P?#`
MP,#`P,#`P,#`P,#`P,#'W,?#_\'PP,#`P,#`P,#`P,#`WL#`P-WP__#=\,#`
MP,#`P,#`P,#!]\'XP_##__S'W,#`P,#`P,#`P,#`PL?<P,#/P,#!]\+`P,#`
MP,#`P,#`Q]S'WL#`P/___?#BP,#`P,#`P,#`P,?=\-[`P,?`P,#`XL#`P,#`
MP,#`P,'PW?C`P,'PXLCBP.+`P,#`P,#`P,#!]\'XP,#<R-WWW?#=\,#`P,#`
MP,#`P,?@P,#'PL?=]]WPW?#`P,#`P,#`P,#`P,#!\.'WW??=\-WPP,#`P,#`
MP,#\Q]WXP,#!]]WWW,#=\,#`P,#`P,#/P,?=^.#'W??=]]S`W?#`P,#`P,#`
MQ_S`P??=]]WWW?#`P,#`P,#`P,#'W?#?\-S'W??=]\#`P,#`P,#`P,#!]]W_
MP??`P,#`P,#`P,#`P,#`P,#`W??#__S'P,#`P,#`P,#`P,#`P,#`P-WPW,_\
MQ\#`P,#`P,#`P,#`P,#`P,#=]\/__,?`P,#`P,#`P,#`P,#`P,#`P??__\'W
MP,#`P,#`P,#`P,#`P,#`P,#/__#=\,#`P,#`P,#`P,#`P,#`P,#`P,#'W,#`
MP,#`P,#`P,#`P,#`P,#`P__]]\#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`
MP,#`P,#`P,#`P,#`N,'WY-S`TL'!N<3__\'WW??=]]WWW?##\-WWW??=]]WP
MW__\Q]WWW??=]]WP_L_!]]WWW??=\-W___#=]]WWW??<S^+/_,?=]]WWW?#=
M]__PP??=]]WWP_CC___PW??=]]WPW??<P/S'W??=\/[(_??__\'WW??=\-WW
MW,_C\-WWW,_BS]WWW__\Q]WWW?#=]\/XX__!]\/XX_?=]]W___#=]]WPW?#^
MR/___,#"R/WWW??=]___P??=\-S/XL_=___PPL_=]\#'W???_\#'W?##^./W
MW??__\/WW??!\-WWW?##\-WP_LC]]]WWW__\Q]S'P??=]]WP_L_!\.+/W?#=
M]]W___#=\,'WW??<S^+/_,#C]]S'W??=]__PP??=]]WWP_CC___P_??!\-S'
MW??<P/S'W??=\/[(_??_\,'WP??!]]WWW,_C\-WWW,_BS]WWW_#\Q]S`W??=
M]\/XX__!]\/XX_?=]]WP_,#=]]WWW?#^R/___,#"R/WWP??=\,#/P??=]]S/
MXL_=___PPL_=]\'WW?##^/S'W??#^./WW??__\/WW,#`P-WP_LC_\-WP_LC]
M]]WWW__\Q]WWP??=\.+/___`P.+/W??!]]W___#=]\'WW?#C]]___,#C]]S'
MW,?=]__PP??=]]WP_??=___P_??!\-S'W??<P/S'W??=\-WWW??__\'WP??!
M]]WWW,_C\-WWW,#=]]WWW__\Q]S'W??=]\/XX__!]\/PW,#=]]W__,#=]]WW
MW?#^R/___,#"P,'PW??=]\#/P??=]]S/XL_=___PPL#=\,#'W??#^/S'W??#
M^./WW??__\#`W??<Q]WP_LC_\-WP_LC]]\'WW__\P-WWP??<S^+/___`P.+/
MW?#<Q]W___#=]\'WP_CC]]___,#C]]S'W,?=]__PW??=\/[(_??=___P_??!
M]]S'W???\+C)S\S-P-+!P;G$P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`
MP,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`
MP,#_____P,#`P,#`P,#`P,#`P,#`P/__XLCBS___P,#`P,#`P,#`P,#`P,_B
MR.#/X,____S`P,#`P,#`P,#`P,#(X,_@S^#/_,_\P,#`P,#`P,#`P,#`R.#/
MX,_@S_S/_,#`P,#`P,#`P,#`P,C@S^#/X,_\S_S`P,#`P,#`P,#`P,+(X,_@
MS^#/__#_\,#`P,#`P,#`P,#"R,/XP,_@P/_P__#`P,#`P,#`P,#`PLC#^,/X
MXL#_\/_PP,#`P,#`P,#`P,+(P_C#^.+`__#_\,#`P,#`P,#`P,#BR,+(P_CB
MP/__P__`P,#`P,#`P,#`XL#^R,/XXL#__\/_P,#`P,#`P,#`P.+`_LC#\.+`
M_,_#_\#`P,#`P,#`P,#BP/[(P,#BP,#/P__`P,#`P,#`P,#`X,_"R.+(XLC_
M_\/_P,#`P,#`P,#`R.#`XLC________\S_S`P,#`P,#`P,CBR/__P,#`P/__
M__#\P,#`P,#`P,#(___`P.+(XL_`P/___,#`P,#`P,#`S\#`XLC`P,#`___`
MP/S`P,#`P,#`P,#BR,#`XLCBR,#`___`P,#`P,#`P,#(X,#BR.+(XLCBR,#/
M_,#`P,#`P,#"R,+(XLCBR.+(XLCBP/_PP,#`P,#`PL#BR.#`_____\#(XLC#
M\,#`P,#`P,#(XLC@P,#`P,#`R.+(X,#`P,#`P,#`P,+(XL#"R.+`PLCBP,#`
MP,#`P,#`P,#`P.+(P,#`P.+(P,#`P,#`P,#`P,#`P,#`R.+(XLC@P,#`P,#`
MP,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`
MP,"XR=_TS<#2P<&YQ,#`_________________________,#`S___________
M_______________PP,#`P,#`P,#`P,#`P,#`P,#`P,__\,#(XLCBP/______
M____PLC@R.+`__#"R.+(XL#_\,#`_____\+(X,CBP/_PPLCBR.+`__#BP/__
M___"R.#(XL#_\,+(XLCBP/_PXL#_____PLC@R.+`__#"R.+(XL#_\.+`____
M_\+(X,CBP/_PPLCBR.+`__#BP/_____"R.#(XL#_\,+(XLCBP/_PP,#_____
MPLC@R.+`__#"R.+(XL#__________\+(X,CBP/_PPLCBR.+`P,#`P,#`P,#`
MP,#(XL#_\,+(XLCBR.+(XLCBR.+(XLCBR.+`__#"R.+(XLCBR.+(XLCBR.+(
MXLCBP/_PPLCBR.+(XLCBR.+(XLCBR.+(XL#_\,+(X__________________^
MR.+`__#"R.+(XLCBR.+(XLCBR.+(X_CBP/_PPLCA^.+(XLCBR.+(XLCBR./X
MXL#_\,+(XLCBR.+(XLCBR.+(XLCC^.+`__#"R.'XXLCBR.+(XLCBR.+(X_CB
MP/_PPLCBR.+(XLCBR.+(XLCBR./XXL#_\,+(X?CBR.+(XLCBR.+(XLCC^.+`
M__#"R.+(XLCBR.+(XLCBR.+(X_CBP/_PPLCA^.+(XLCBR.+(XLCBR./XXL#_
M\,+(XLCBR.+(XLCBR.+(XLCC^.+`__#"R.'XXLCBR.+(XLCBR.+(X_CBP/_P
MPLCBR.+(XLCBR.+(XLCBR./XXL#_\,+(X?CBR.+(XLCBR.+(XLCC^,+`__#"
MR.+(XLCBR.+(XLCBR.+(X_C"P/_PPLCA^.+(XLCBR.+(XLCBR./XXL#\P,+(
MXLCBR.+(XLCBR.+(XLCC^.+`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`ONS`
MTM"XP,_)[\CGZ]T*#U=E(&%R92!A;'-O('=O<FMI;F<@;VX@80T*=71I;&ET
M>2!T;R!C;VYV97)T(%=I;F1O=W,-"FUE=&%F:6QE<R!I;G1O($Y!4$Q04R!D
M<F%W:6YG<PT*<W5C:"!A<R!T:&4@;&]G;R!F;W(@365M<F$N#0I4:&ES(&QO
M9V\@=V%S(&1R87=N(&EN#0I#;W)E;$1R87<L(&5X<&]R=&5D('1O("Y7348-
M"F9O<FUA="!A;F0@8V]N=F5R=&5D('1O#0I.05!,4%,@=VET:"!T:&4@8F5T
M82!T97-T#0IV97)S:6]N(&]F('1H92!U=&EL:71Y+KC`R\3RR./J_`H/06YD
M(&QA<W0L(&)U="!N;W0@;&5A<W0L('=E#0IA<F4@=V]R:VEN9R!O;B!A(%=I
M;F1O=W,-"F=A;64@9F]R(&-H:6QD<F5N('1H870@<VAO=6QD#0IB92!R96QE
M87-E9"!B>2!M:60M07!R:6P@,3DY,RZ^Y,#HP*+PP,#!].NDP,G;_P\@3&]N
19R!L:79E($Y!4$Q04R$:&AH`
`
end
------------8X---cut here--------uuencoded-------------------
begin 600 sail.nap
M#B)`0$!)278A3$!20$`;0R$Y04!`0$!`0$!`0$!P0$!P0$!`0$!`0$!P0$!P
M0$!P0$!P0$!P0$!P0$!P0$!P0$!`0!M%&T,B.4%`0$!`0$!`0$!!?$!#1D!&
M0T!`04!`04!`04!`7T!`04!`04!&0T!#1D!!?$!`0$`;11M#(SE!0$!`0$!`
M0$!`0T9`0T9`3W]`3W]`0T9`0T9`1W]@1W]@06-`06-`0$!`0$!`0$!`&T4;
M0R0Y04!`0$!`0$!P0$!80$!80$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!80$!8
M0$!`0$!`0!M%&T,E.4%`0$!`0$!`0$!`0$!`6$!`6$!`0$!`0$!`0$!`0$!`
M0$!`0$!`6$!`6$!`0$!`0$`;11M#)CE!0$!`0$!`0$!`0%A`0%A`0$!`0$!`
M0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`&T4;0R<Y04!`0$!`0$!`0$!X
M0$%\0$!&0$!&0$!^0$!&0$!&0$%\0$!X0$!`0$!`0$!`0$!`0!M%&T,H.4%`
M0$!`0$!`0$!`1$!`3$!`6$!`6$!`6$!`6$!`6$!`6$!`6$!`6$!`3$!`1$!`
M0$`;11M#*3E!0$!`0$!`0$!`0&!`0'!`0%A`0%A`0%A`0%A`0%A`0%A`0%A`
M0%A`0'!`0&!`0$!`&T4;0RHY04!`0$!`0$!`0$!`0$!`0$-;0$-;0$%^0$!\
M0$!\0$%^0$-;0$-;0$!`0$!`0$!`0!M%&T,K.4%`0$!`0$!`0$!`0$!`0$!`
M6$!`6$!`6$!#?T!#?T!`6$!`6$!`6$!`0$!`0$!`0$`;11M#+#E!0$!`0$!`
M0$!`0WQ`0WY`0T=`0T-`0T=`0WY`0WQ`0T!`0T!`0T!`0WQ`0WQ`0$!`&T4;
M0RTY04!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$=_8$=_8$!`0$!`0$!`0$!`
M0$!`0$!`0!M%&T,N.4%`0$!`0$!`0$!,7T!,7T!,<6!,<6!/<6!/<6!,<6!,
M<6!,7T!,7T!`0$!`0$!`0$`;11M#+SE!0$!`0$!`0$!`3$!`1D!`0T!`06!`
M0'!`0%A`0$Q`0$9`0$-`0$%@0$!P0$!`0$!`&T4;0S`Y04!`0$!`0$!`0$%^
M0$-_0$-#0$-C0$-S0$-[0$-?0$-/0$-'0$-#0$-_0$%^0$!`0!M%&T,Q.4%`
M0$!`0$!`0$!`6$!`6$!`6$!`6$!`6$!`6$!!>$!!>$!`>$!`>$!`6$!`6$!`
M0$`;11M#,CE!0$!`0$!`0$!`0W]`0W]`0T!`0W!`0'Q`0$]`0$-`0$-`0T-`
M0T-`07Y`07Y`0$!`&T4;0S,Y04!`0$!`0$!`0$%^0$%^0$-#0$-#0$!#0$!.
M0$!.0$!#0$-#0$-#0$%^0$%^0$!`0!M%&T,T.4%`0$!`0$!`0$!`1D!`1D!`
M1D!`1D!#?V!#?V!#1D!#1D!#1D!#1D!#1D!#1D!`0$`;11M#-3E!0$!`0$!`
M0$!`0'Y`07]`06-`0$-`0$-`0$-`07]`07Y`06!`06!`07Y`07Y`0$!`&T4;
M0S8Y04!`0$!`0$!`0$!\0$-_0$-#0$-#0$-#0$-_0$-\0$-`0$-`0$-@0$%\
M0$!\0$!`0!M%&T,W.4%`0$!`0$!`0$!!8$!!8$!!8$!!<$!`>$!`7$!`3D!`
M1T!`0T!`0T!!?T!!?T!`0$`;11M#.#E!0$!`0$!`0$!`07Q`0WY`0T9`0T9`
M0T9`0T9`07Q`07Q`0T9`0T9`0WY`07Q`0$!`&T4;0SDY04!`0$!`0$!`0$-^
M0$-^0$!&0$!&0$!&0$-^0$-^0$-&0$-&0$-&0$-^0$-^0$!`0!M%&T,Z.4%`
M0$!`0$!`0$!,6'!,67!&66!'6T!#6T!!?D!!?D!#6T!'6T!&66!,67!,6'!`
M0$`;11M#.SE!0$!`0$!`0$!`1EE@1EE@1EE@1EE@0W]`0W]`1EE@1EE@1EE@
M0$!`0$!`0$!`0$!`&T4;0SPY04!`0$!`0$!`0$%\0$-^0$-&0$-&0$-^0$%\
M0$%`0$%X0$!\0$!&0$!"0$!`0$!`0!M%&T,].4%`0$!`0$!`0$!`0$!`0$!#
M?T!#?T!`0$!`0$!`0$!#?T!#?T!`0$!`0$!`0$!`0$`;11M#/CE!0$!`0$!`
M0$!`1D]@1E]P1EAP1EAP1EAP1WAP1WAP1EAP1EAP1EAP1E]P1D]@0$!`&T4;
M0S\Y04!`0$!`0$!`0$!80$!80$!`0$!`0$!80$!<0$!.0$!&0$%F0$%F0$%^
M0$!\0$!`0!M%&T-`.4%`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`
M0$!`0$!#3$!!9D!!9D!`0$`;11M#03E!0$!`0$!`0%A`0%A`0W]`1W]@1EE@
M1EE@1EE@1EE@1EE@1EE@1W]@0W]`0%A`0%A`&T4;0T(Y04!`0$!`0$!`0$9!
M8$9!8$=!8$=A8$=Q8$9Y8$9=8$9/8$9'8$9#8$9!8$9!8$!`0!M%&T-#.4%`
M0$!`0$!`0$!!?D!#?T!#0T!#0T!#0$!#0$!#0$!#0$!#0T!#0T!#?T!!?D!`
M0$`;11M#1#E!0$!`0$!`0$!`0WQ`0WY`0T9`0T9`0T9`0T9`0WY`0WQ`0TQ`
M0TQ`0WQ`0WA`0$!`&T4;0T4Y04!`0$!`0$!`0$%\0$%^0$!&0$!&0$!^0$%^
M0$%F0$%F0$-F0$-&0$-&0$-&0$!`0!M%&T-&.4%`0$!`0$!`0$!#0T!#0T!#
M0T!#?T!#?T!#0T!#0T!#0T!#0T!#0T!!?D!!?D!`0$`;11M#1SE!0$!`0$!`
M0$!`0T-`0T-`0T-`0T-`0T-`0T-`0T-`0T-`0T-`0T-`0W]`0W]`0$!`&T4;
M0T@Y04!`0$!`0$!`0$-`0$-`0$-`0$-`0$-`0$-^0$-_0$-#0$-#0$-#0$-_
M0$-^0$!`0!M%&T-).4%`0$!`0$!`0$!/?W!/?W!,6'!,6'!,6'!,6'!,6'!,
M6'!,6'!,6'!,6'!,6'!`0$`;11M#2CE!0$!`0$!`0$!`07]`0W]@0T%@0T%@
M0T%@0T%@0T%@0T%@0T%@0T%@0W]@07]`0$!`&T4;0TLY04!`0$!`0$!`0$=C
M0$=C0$%C0$%C0$%C0$%C0$%C0$%C0$%C0$%C0$%_0$!_0$!`0!M%&T-,.4%`
M0$!`0$!`0$!'?V!'?V!!9D!!9D!!9D!!9D!!9D!!9D!!9D!!9D!!?D!`?D!`
M0$`;11M#33E!0$!`0$!`0$!`0WY`0W]`0T-`0T-`0T-`0T-`0W]`0WY`0T!`
M0T!`0T!`0T!`0$!`&T4;0TXY04!`0$!`0$!`0$!80$!80$!80$!80$!80$!8
M0$!80$!80$!80$!80$-_0$-_0$!`0!M%&T-/.4%`0$!`0%A`0%A/?WA/?WA,
M<T!,<T!,<T!,<T!,<T!,<T!,<T!,<T!,<T!,<T!`0$`;11M#4#E!0$!`0$!`
M0$!`0WQ`0W]`0$-`0$-`0$-`0$-`0WY`0WY`0$-`0$-`0W]`0WY`0$!`&T4;
M0U$Y04!`0$!`0$!`0$9#0$9#0$=#0$=C0$=S0$9[0$9?0$9/0$9'0$9#0$9#
M0$9[0$!X0!M%&T-2.4%`0$!`0$!`0$!#0V!#0V!#0V!#3D!#3D!#?$!#?$!#
M3D!#3D!#0V!#0V!#0V!`0$`;11M#4SE!0$!`0$!`0$!`3W%@3WE@3%E@3%E@
M3%E@3%E@3WE@3W%@3$%@3$%@3$%@3$%@0$!`&T4;0U0Y04!`0$!`0$!`0$-^
M0$-^0$-`0$-`0$-`0$-`0$-\0$-\0$-`0$-`0$-^0$-^0$!`0!M%&T-5.4%`
M0$!`0$!`0$!!8$!!8$!!8$!!8$!!8$!!8$!!8$!!8$!!8$!!8$!!?T!!?T!`
M0$`;11M#5CE!0$!`0$!`0$!`3%AP3%AP3%AP3'QP3'QP37YP369P3V=P3T-P
M3T-P3D%P3D%P0$!`&T4;0U<Y04!`0$!!8$!!8$=_8$=_8$9&0$9&0$9&0$9&
M0$9&0$9&0$9&0$9&0$9&0$9&0$!`0!M%&T-8.4%`0$!`0$!`0$!`0T!`0T!`
M0T!`0T!!?T!#?T!#0T!#0T!#0T!#0T!#0T!#0T!`0$`;11M#63E!0$!`0$!`
M0$!`1D%@1D%@1D%@1D%@1D%@1W]@1W]@1D%@1D%@1D%@1D%@1D%@0$!`&T4;
M0UHY04!`0$!`0$!`0$-S0$-S0$!S0$!S0$!S0$%_0$-_0$-#0$-#0$-#0$-_
M0$%_0$!`0!M%&T-;.4%`0$!`0$!`0$!&0T!&0T!#1D!#1D!!?$!!?$!#1D!'
M1T!&0T!`0$!`0$!`0$!`0$`;11M#7#E!0$!`0$!`0$!`0W!`0W!`0T!`0T!`
M0T!`0T!`0T!`0T!`0T!`0T!`0W!`0W!`0$!`&T4;0UTY04!`0$!`0$!`0$!`
M0$%_0$-_0$-`0$-_0$-_0$-#0$-_0$%^0$!`0$%F0$%F0$!`0!M%&T->.4%`
M0$!`0$!`<$!`6$!`6$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`
M0$`;11M#7SE!0$!`0$!`0$!`1W]@1W]@0$!`0$!`0$!`0$!`0$!`0$!`0$!`
M0$!`0$!`0$!`0$!`&T4;0V`Y04!`0$!`0$!`0$!`0$!_0$!_8$!Q8$!Q8$!_
M8$!_0$-P0$-P0$!`0$!`0$!`0$!`0!M%&T-A.4%`0$!`6$!`6$!`6$!#?T!'
M?V!&66!&66!&66!&66!'?V!#?T!`6$!`0$!`0$!`0$`;11M#8CE!0$!`0$!`
M0$!`0$!`07M`07M`0T]`0T]`0T-`0T-`0T-`0T-`0$!`0$!`0$!`0$!`&T4;
M0V,Y04!`0$!`0$!`0$!`0$%\0$-^0$-&0$-`0$-`0$-&0$-^0$%\0$!`0$!`
M0$!`0$!`0!M%&T-D.4%`0$!`0$!`0$!`0$!!?$!!9D!!9D!!9D!!?$!!9D!!
M9D!!?$!`0$!`0$!`0$!`0$`;11M#93E!0$!`07Y`07]`0$-`0$-`0$-`0']`
M07]`06-`0V-`0T-`0T-`0$!`0$!`0$!`0$!`&T4;0V8Y04!`0$!`0$!`0$!`
M0$%]8$-_8$-#8$-#8$%_8$!#8$!#8$%_0$!`0$!`0$!`0$!`0!M%&T-G.4%`
M0$!`0$!`0$!`0$!!9D!!9D!!9D!!9D!!9D!!9D!!?D!!?D!`0$!`0$!`0$!`
M0$`;11M#:#E!0$!`06!`06!`06!`06!`07Y`07]`06-`06-`06-`07]`07Y`
M0$!`0$!`0$!`0$!`&T4;0VDY04!`0$!`0$!`0$!`0$=_8$=_8$998$998$99
M8$998$998$998$!`0$!`0$!`0$!`0!M%&T-J.4%`0$!`0$!`0$!`0$!!?D!#
M?T!#0T!#0T!#0T!#0T!#?T!!?D!`0$!`0$!`0$!`0$`;11M#:SE!0$!`0$!`
M0$!`0$!`1V9`1V9`069`069`069`069`07Y`0'Y`0$!`0$!`0$!`0$!`&T4;
M0VPY04!`0$!`0$!`0$9!8$=_8$=_8$%F0$%F0$%F0$%F0$%^0$!^0$!`0$!`
M0$!`0$!`0!M%&T-M.4%`0$!`0$!`0$!`0$!`?T!`?V!`<6!`<6!`?V!`?T!`
M<$!`<$!`0$!`0$!`0$!`0$`;11M#;CE!0$!`0$!`0$!`0$!`0%A`0%A`0%A`
M0%A`0%A`0%A`0W]`0W]`0$!`0$!`0$!`0$!`&T4;0V\Y04!`0$!`0$!`0$!`
M<$=_<$=_<$998$998$998$998$998$998$!`0$!`0$!`0$!`0!M%&T-P.4%`
M0$!`0$!`0$!`0$!!?$!`1D!`1D!`1D!`?$!`1D!`1D!!?$!`0$!`0$!`0$!`
M0$`;11M#<3E!0$!`0$!`0$!`0$!`07M`07M`0T]`0T]`0T-`0T-`0T-`0T-`
M0$!`0%A`0$!`0$!`&T4;0W(Y04!`0$!`0$!`0$!`0$%C0$%G0$%F0$%\0$%\
M0$%F0$%G0$%C0$!`0$!`0$!`0$!`0!M%&T-S.4%`0$!`0$!`0$!`0$!'<6!'
M>6!&66!&66!'>6!'<6!&06!&06!`0$!`0$!`0$!`0$`;11M#=#E!0$!`0$!`
M0$!`0$!`0WY`1WY`1D!`1WY`1WY`1D9`1WY`0WQ`0$!`0$!`0$!`0$!`&T4;
M0W4Y04!`0$!`0$!`0$!`0$!P0$!P0$!P0$!P0$!P0$!P0$!_0$!_0$!`0$!`
M0$!`0$!`0!M%&T-V.4%`0$!`0$!`0$!`0$!&06!&06!&06!&66!&66!'?V!'
M9V!'0V!`0$!`0$!`0$!`0$`;11M#=SE!0$!`0$!`0$!`0$%@07]@07]@06-`
M06-`06-`06-`06-`06-`0$!`0$!`0$!`0$!`&T4;0W@Y04!`0$!`0$!`0$!`
M0$!&0$!&0$!&0$%^0$%^0$%F0$%F0$%F0$!`0$!`0$!`0$!`0!M%&T-Y.4%`
M0$!`0$!`0$!`0$!!9D!!9D!!9D!!?D!!?D!!9D!!9D!!9D!`0$!`0$!`0$!`
M0$`;11M#>CE!0$!`0$!`0$!`0$!`069`069`069`0'Y`069`069`07Y`0'Y`
M0$!`0$!`0$!`0$!`&T4.(4Q`0$!)(T!`0$!`/EQ`/EQ`#B%,0$!`22-`0$!`
M0#Y<0!]`0`XA3$!`0$DB0$!`0&91($)"#B%,0$!`22-`0$!`0#Y<0#A"1T!V
M76I&02)`0$!)1$$*#R`@("`@("!!;B!%>&5R8VES92!I;@H-("`@("`@(%!R
M97-E;G1I;F<@0VQA<W-I8PH-("`@("`@(%)U<W-I86X@4&]E=')Y(&EN"@T@
M("`@("`@=&AE(&]R:6=I;F%L+"!O;FQI;F4N"@T*#2`@("`@("!!<G)A;F=E
M9"!B>2`*#2`@("`@("!$+B!(=6=H97,*#2`@("`@("!)+B!+;W-T87)N;W8*
M#0H-("`@("`@(%5S:6YG(%1R;VEK82U496QE9')A=PH-("`@("`@($9R;VT@
M3VQD($-O;&]R861O($-I='D*#2`@("`@("!#;VUM=6YI8V%T:6]N<PH-"@T@
M("`@("`@("`@($UA<F-H+"`Q.3DS"@T.#B%,0$!`22-`0$!`0#Y<0#U<?#U<
M7@PX0D)A0UYP3W\B0$!`06IH"@].;W1E.B!4:&ES(&ES(&$@<W1A;F1A<F0@
M3D%03%!3(&9I;&4L(&UA9&4*#75S:6YG('1H92!$4D-3('1A8FQE(&9U;F-T
M:6]N<R!O9B!.05!,4%,N"@U4:&4@0WER:6QL:6,@4G5S<VEA;B!C:&%R86-T
M97(@9F]N="!I<R`*#7-T;W)E9"!I;B!A($120U,@9FEL92UT86)L92!I;F-L
M=61E9"!A="!T:&4*#6AE860@;V8@=&AI<R!F:6QE+B!)="!W:6QL(&QO860@
M9FER<W0L(&%N9`H-;6%Y('1A:V4@,34@;W(@;6]R92!S96-O;F1S(&%T(#(T
M,#`@8F%U9"X*#0H-5&AE;B!T:&4@16YG;&ES:"!A;F0@4G5S<VEA;B!W:6QL
M(&%P<&5A<BX*#0H-268@>6]U<B!.05!,4%,@5&5R;6EN86P@<')O9W)A;2!D
M;V5S(&YO=`H-<W5P<&]R="!.05!,4%,@<W1A;F1A<F0@1%)#4RP@>6]U('=I
M;&P@;VYL>0H-<V5E('1H92!%;F=L:7-H('1E>'0@86YD(&EL;'5S=')A=&EO
M;G,N"@T./5Q\/5Q\##A"1D!"1V1N9R)`0$!347`*#R`@"@T..$-`0T!7>5UG
M(D!`0%-1<`H;+WL;;R`@("!'9FAE8T`*#0H-#CA"1E-$3TQ>1R)`0$!347`*
M&R][&V\@("!`"@T./5Q4&!LB1AM%'P\.(5%`0$!)0"-`0$!`0$D^?$!`0#=*
M0%5:0']_15%`>'AH6$!_=W)W0$='0T)`1T=4=D!'1VUI0$='9GQ`0$!0<$!`
M2%!X0$!`8'A`0$!92$!'3U9G0$!(<'Q`0$!8;$!`0&!80$!`4$!`1T]V8$!`
M0'A40$!(4%M`0$!P8$!'1V=$0$!(2%=`0$!8:$!`2$A00$!(:U5`0$!26D!X
M>%U/0'AX3$5`>'!C54!X<'%30$!`8W5`0$!Q>T!X>$!H0']O?W-`>'A)>T!P
M<'A@0']_9E%`?W]>?$!_?WUA0']W:D=`/E]P0$`W2FA?1$!'3E-%0$!!3VA`
M/D!`-TIH5V!`0$!`0$`W2FA7;$!`2%IV0#=*<4M-0$='1G!`0$!`4$!X>'AH
M0$='1TQ`0$!`64!X>'I*0#=)=VY30$!`0$!`-TEW;DI`0$!`0$`W27=M7T!'
M1T5U0$='1U)`0$!`44!X>'-Y0#=*<7)20$!`0$!`-TIQ<F!`1T9):4!`0$!(
M0'AY=EY`-TIQ2TU`0$!`<$!'1T=F0$!`0%!`1T='5D!'1T]*0'AX<&)`>'AX
M0D`W26]T2T!`0$!80#=);W5Q0$='3WA`1T='5$!'1T]D0$='7G]`1T=?2T!`
M0$AH0$!`2%A`0$!`5$!X>'!?0'AX<&5`>'AP3$!X>&A]0'AX>'!`?W]^=$!X
M>'%/0'AX:%1`>'AH<T!X>'!00']_?W9`1T=':4!'1T=T0#=);V1U0$='1VM`
M1T=/<T!'1U]!0$='5V-`>'A344!_?W=20#=)=U)O0$='1V1`1T=/8T!'1U]S
M0'AX:7%`>'A@6T`W27=:3T!'1T],0#=)=WEL0$!`2$!`-TEW6G1`0$!`:$!`
M0$!(0#=)=WEZ0$!`6%!`>'AP;$`W26]E14!'1TU40$='1WQ`1T='?4!'1T=Q
M0$!`0&A`1T=74T!`0$A`0$='3UI`1T=?2D!'1U=.0$!`2'M`0$!!6$`W27]A
M7T!'1T9$0']_=T9`>'AY5$`C1#Y;4$!`-TE'65Y`0$!`0$`.#PXA3$!`0$DC
M0$!`0$`^7$`]7%0X04-/259V3&<B0$!`241\"ALO>QMO("`@("`@5EX^7B!+
M=&AV:GEN:F0*#0H-("`@("`@5FIC<F1F7B!(:F-C8GH*#0H-("`@("`@("`@
M("`Q.#,R"@T*#0X]7'(,.$)'0UM?2UI+(D!`0$IZ;@H;+WL;;R`@(`\B5&AE
M(%-A:6PB"@T*#0X]7%0X0D-+259S2V<B0$!`241\"@\@("`@("`@("`@("!B
M>0H-"@T@("`@("!-+EDN($QE<FUO;G1O=@H-"@T@("`@("!-;W-C;W<L(%)U
M<W-I80H-"@T@("`@("`@("`@(#$X,S(*#0H-#CU<7CA`1T%S7W-.8R)`0$!!
M:%,*#R!/<FEG:6YA;"!T<F%N<VQA=&EO;B!B>2!)<FEN82!::&5L97IN;W9A
M+@H-($UO9&EF:65D(&)Y($1A=FED($AU9VAE<RX@3D%03%!3('!R97-E;G1A
M=&EO;@H-($-O<'ER:6=H="P@1&%V:60@2'5G:&5S+"!#;VQO<F%D;R!3<')I
M;F=S+`H-($-O;&]R861O+"`Q.3DS+@H-#CU<?#U<5`P.(4Q`0$!)(T!`0$!`
M/EQ`.$)'='-7=DMC(D!`0$E$?`H;+WL;;RQT:W1T;B!G9FAE8R!J;&)J<FIQ
M"@T..$)-0%M?5F]W(D!`0$%H:`H/02!L;VYE('=H:71E('-A:6P@<VAO=W,@
M9F]R(&%N(&EN<W1A;G0*#0X]7&@X0D)^;5].8TLB0$!`241\"ALO>QMO1"!N
M979F>70@=FIH9B!U:FME/&IV)"T*#0XX0D![<5]5;W<B0$!`06AH"@]7:&5R
M92!G;&5A;7,@=&AE('-E82P@86X@87IU<F4@<W1R96%K+@H-"@T./5QH.$%.
M04-?7FM.(D!`0$%\:0H;+WL;;UAN:B!B;W1N(&IY(&0@8VYH9GET(&QF:W1R
M:G$_"@T..$%+1EI?5D=,(D!`0$%H:PH/5VAA="!L969T(&ET(&EN(&ET<R!H
M;VUE;&%N9"!D:7-T86YT/PH-#CU<:#A!251%7UY#1B)`0$!)1$$*&R][&V]8
M;FH@<F)Y96L@:GD@9"!R:&8N(&AJ;'EJ=C\*#0XX0$]A1%=^3V\B0$!`06AH
M"@]);B!A;&EE;B!L86YD<R!W:&%T(&1O97,@:70@<V5E:S\*#0X]7'P.(4Q`
M0$!)(T!`0$!`/EQ`#B%,0$!`22-`0$!`0#Y<0#U<7@P.(4Q`0$!)(T!`0$!`
M/EQ`.$-(2$A?9G-S(D!`0$E$?`H;+WL;;T)U:&8N;B!D:FMY<RUD=&YT:"!C
M9&)O=&Y>"@T..$)&<4-?;6=1(D!`0$%H:PH/26X@8FEL;&]W<R!P;&%Y+"!T
M:&4@;6%S="!B96YD<RP@8W)E86MI;F<L"@T*#0X]7%0X0DQ(25]6:T,B0$!`
M241\"ALO>QMO0G9X;F8@=7ET8WH@8B!C<FAS9V)N)B8F"@T..$)!?6E?7E]?
M(D!`0$%H:`H/5&AE('=I;F0L(&EM<&%T:65N="P@;6]A;G,@86YD('-I9VAS
M+BXN"@T./5Q4.$%/2DQ?5FM#(D!`0$E$?`H;+WL;;T5D<R$@:GD@8WAF8VYB
M>B!Y="!B;W1N7@H-#CA!35!>5WY/;R)`0$!!:&@*#TET(&ES(&YO="!J;WD@
M=&AA="!I="!I<R!S965K:6YG+`H-#CU<5#A!2UA37TYC2R)`0$!)1'P*&R][
M&V]"('ET(&IN(&-X9F-N8GH@/'0[>6XA+0H-#CA!2%ML5WU/;R)`0$!!:&@*
M#TYO<B!I<R=T(&9R;VT@:&%P<&EN97-S(&ET(&9L:65S+@H-"@T./5Q\#B%,
M0$!`22-`0$!`0#Y<0`XA3$!`0$DC0$!`0$`^7$`]7&@,#B%,0$!`22-`0$!`
M0#Y<0#A"1U9L7VY[:R)`0$!)1'P*&R][&V]#;FAE9B!G:FP@>6)V(&-D=&MT
M<2!K9B=E:&(*#0XX0D5E6U]V3W\B0$!`06AH"@]4:&4@8FQU92!W879E<R!D
M86YC92QT:&5Y(&1A;F-E(&%N9"!T<F5M8FQE"@T./5Q>.$)#9$1?;GMK(D!`
M0$E$?`H;+WL;;UEF;"!Y8G8@:V5X(&-J:WEW9B`G:FMJ;FIQ)0H-#CA"06IO
M7U9O=R)`0$!!:&@*#U1H92!S=6XG<R!B<FEG:'0@<F%Y<R!C87)E<W,@=&AE
M('-E87,L"@T./5Q>.$%':6Q?;GMK(D!`0$E$?`H;+WL;;T8@:GE>('9Z;G0[
M(&9O<B!S=&]R;2!I="!B96=S+"!T:&4@<F5B96P*#0X]7%XX04)2<%]N<T,B
M0$!`241D"ALO>QMO4F9R(#QE;&YJ(&0@/&5H>EL@=&-N;2!G:G)J<0H-#CA`
M1VI+7U5'3R)`0$!!:&@*#T%S(&EF(&EN('-T;W)M(&QU<FME9"!C86QM(&%N
M9"!P96%C92$*#0H-#@XA3$!`0$DC0$!`0$`^7$`.(4Q`0$!)(T!`0$!`/EQ`
B/5QH/GQ`*TAC9'5`4%AP*TAL8'U_?F]&*TAT0$U_?F=J&MS`
`
end
------------8X---cut here------------------------------------
