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: mpdillon@halcyon.halcyon.com
CIS: >INTERNET:mpdillon@halcyon.halcyon.com
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
--
Michael Dillon Internet: mpdillon@halcyon.halcyon.com
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
