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 
     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. 
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 
     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. 
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. 
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 
     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 
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. 
     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 
              |       | 
              |       | 
              |       | 
--------------|--------------- 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 
     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 
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. 
     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 
     This is the heart of NAPLPS, the graphical drawing 
primitives. There are eight environment codes (RESET, 
BLINK) which set the graphics environment and 6 different 
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 
      2D ARC FILLED 
      2F SET & ARC FILLED 
Rectangles and histograms 
      31 RECT FILLED 
      33 SET & RECT FILLED 
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. 
     This PDI sets the current drawing point to the 
coordinates specified in last one of the following multi- 
value operands. No point is drawn. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     This PDI is the same as ARC OUTLINED except that the 
first multi-value operand sets the current drawing point. 
     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. 
     This PDI draws an unfilled rectangle in the current 
drawing color starting at the current drawing point. 
     This PDI draws a filled rectangle starting at the 
current drawing point. The fill is done with the current 
drawing color and fill pattern. 
     This PDI is the same as RECT OUTLINED except that the 
current drawing point is set by the first multi-value 
     This PDI is the same as RECT FILLED except that the 
current drawing point is set by the first multi-value 
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. 
     This PDI draws a polygon starting at the current 
drawing point. 
     This PDI draws a filled polygon starting at the current 
drawing point. 
     This PDI is the same as POLY OUTLINED except that it 
sets the current drawing point first. 
     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. 
     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 
     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 
              ^    ^  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. 
     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. 
     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 
     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 
    -----    2 x 3 
    |3|4|    Mosaic cell 
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 
     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 
     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 
     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 
     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. 
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 
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 
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 
     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 
     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 
     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. 
     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 
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. 
     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. 
     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 
     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 
     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 
     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. 
     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 
     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. 
     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. 
     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. 
     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. 
     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 
     This terminates reverse video mode and returns to the 
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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     This turns off word wrap and text now breaks between 
characters. This is the default. 
     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. 
     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. 
`    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. 
     This terminates underline mode. In this mode, mosaics 
are displayed contiguously so as to form a monochrome 
     This cause the cursor to blink. It also may enable user 
input if the active field is in an unprotected field. 
     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. 
     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. 
     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. 
     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 
     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 
     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 
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. 
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 
     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 
 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: 
     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 

---------8X----cut here-------BPREF.SCR follows---- 
E 100 E 20 7F 4F 21 48 40 40 
E 108 49 3E 
N bpref.nap 
------------8X---cut here-----uuencoded---------------------- 
begin 600 memra2.nap 
M^/[email protected]^/CXZOCX^.KX^/CK^/CX^_CX^/K`P,#%P,#`S,#`P,O`P,#:P,#`VL#` 
M^.'X^/[email protected]____[____^_____N_____O____[____]_____?CX\/#`P,##P,#` 
M___U_____<?'P,?'Q\?'Q\?'S\#`P,C`P,#(Q\?7Q\?'Q,?X^,[email protected],'"P\#` 
M]?____7____U____[O___^_____O____[_CX^.#X^/[email protected]^/CX\/CX^/#X^/CH 
MP,#$^/CX\_CX^/OX^/CS^/CXZ?CX^.CX^/[email protected]^/CX\/CX^/#X^/CX____]___ 
MP,CPQ\?(]\#`S^G`P,[email protected]__[OX?CX\.#X^/;/M]#FY?/`P,;%^/CP^,#`P</` 
M^/CZ^/CX\OCX^/+X^/CI^/CXZOCX^/#X^/CH^/CXZ?CX^.CX^/[email protected]____Y_CX 
M^.'X^/CA^/CXX?CX^.CX^/CI^/CXX?CX^.GX^/[email protected]^/CX\_CX^.GX^/CJ^/CX 
MZ_''P,#)[<'%P,3X^.#XQL+'Q,#`R>3'Q\3'P,#(Z+?1P_ODQ\?.X\[email protected],#` 
M___O^/CXZ/___^_X^/CH____Y_CX^/#X^/[email protected]____[___]_[___?V___W_O__ 
M___G____Y____^?X^/[email protected]____Y_CX^.#X^/CH___WUO__]\W___?,___WU/__ 
M9W)A;7,-"B`J("[email protected]%M97,@*B`J#0I'<F%P:&EC<R!S;V9T=V%R9:'-P,#) 
MVPH/365M<[email protected]]F='=A<[email protected]+B!W87,-"[email protected]:[email protected],3DX-B!B 
M>2!-:6-H865L#0I$:6QL;[email protected]($UA<F=A<F5T($-L87!P:7-O;BX-"E1H 
M92!F:7)S="!S:&%R97=A<[email protected]<')O9W)A;0T*<F5L96%[email protected]:[email protected],3DY,R!W 
M87,@82!U=&EL:71Y#0IT;R!A9&[email protected]&]W<R!I8V]N<R!T;R!A#0I.05!, 
MP,#`P,#`P,#`P,?BR.#'P_____S`P,#`P,#`P,#`[email protected]\+/___\P,#` 
MP,#`P,[email protected],#'PL?=]]WPW?#`P,#`P,#`P,#`P,#!\.'WW??=\-WPP,#`P,#` 
MR.#/X,____S`P,#`P,#`P,#`P,#(X,[email protected]^#/_,_\P,#`P,#`P,#`P,#`R.#/ 
MX,[email protected]_S/_,#`P,#`P,#`P,#`P,[email protected]^#/X,_\S_S`P,#`P,#`P,#`P,+(X,[email protected] 
MS^#/__#_\,#`P,#`P,#`P,#"R,/XP,[email protected]/_P__#`P,#`P,#`P,#`PLC#^,/X 
M\,#`P,#`P,#([email protected],#`P,#`R.+(X,#`P,#`P,#`P,+(XL#"R.+`PLCBP,#` 
MP,#`P,#`P,#`P.+(P,#`P.+(P,#`P,#`P,#`P,#`P,#`R.+([email protected],#`P,#` 
[email protected]+`__#"R.+(XL#_\,#`_____\+(X,CBP/_PPLCBR.+`__#BP/__ 
M___"R.#(XL#_\,+(XLCBP/_PXL#[email protected]+`__#"R.+(XL#_\.+`____ 
[email protected]+`__#"R.+(XL#__________\+(X,CBP/_PPLCBR.+`P,#`P,#`P,#` 
MTM"XP,_)[\CGZ]T*#U=E(&%R92!A;'-O('=O<FMI;F<@;[email protected]*=71I;&ET 
M<F%W:6YG<PT*<W5C:"!A<R!T:&[email protected];&]G;R!F;W(@365M<F$N#0I4:&ES(&QO 
M"F9O<FUA="!A;[email protected]]N=F5R=&5D('1O#0I.05!,4%,@=VET:"!T:&[email protected] 
M(&QA<W0L(&)U="!N;[email protected];&5A<W0L('=E#0IA<[email protected]=V]R:VEN9R!O;B!A(%=I 
M;F1O=W,-"F=A;[email protected]]R(&-H:6QD<F5N('[email protected]<VAO=6QD#0IB92!R96QE 
M87-E9"!B>2!M:60M07!R:[email protected],3DY,RZ^Y,#HP*+PP,#!].NDP,G;_P\@3&]N 
------------8X---cut here--------uuencoded------------------- 
begin 600 sail.nap 
M0S8Y04!`0$!`0$!`0$!\0$-_0$-#0$-#0$-#0$-_0$-\0$-`0$-`[email protected]$%\ 
M0$`;11M#.SE!0$!`0$!`0$!`[email protected]@[email protected]@0W]`0W]`[email protected]@[email protected] 
M0$!`0$!#3$!!9D!!9D!`0$`;11M#03E!0$!`0$!`0%A`0%A`0W]`1W]@[email protected] 
[email protected]@[email protected]@[email protected]]@0W]`0%A`0%A`&T4;0T(Y04!`0$!`0$!`0$9! 
[email protected]!`0$!`0$!`0$-`0$-`0$-`0$-`0$-`0$-^0$-_0$-#0$-#0$-#0$-_ 
M3D!#3D!#0V!#0V!#0V!`0$`;11M#4SE!0$!`0$!`0$!`3W%@[email protected]%[email protected]%[email protected] 
M3%[email protected]%[email protected]@3W%@3$%@3$%@3$%@3$%@0$!`&T4;0U0Y04!`0$!`0$!`0$-^ 
M06-`06-`06-`06-`06-`0$!`0$!`0$!`0$!`&T4;[email protected]!`0$!`0$!`0$!` 
M97-E;G1I;F<@0VQA<W-I8PH-("`@("`@(%)U<[email protected]&]E=')Y(&EN"@[email protected] 
M#0H-("`@("`@(%5S:6YG(%1R;VEK82U496QE9')A=PH-("`@("`@($9R;[email protected] 
M3VQD($-O;&]R861O($-I='D*#2`@("`@("!#;VUM=6YI8V%T:6]N<PH-"@[email protected] 
[email protected])A0UYP3W\B0$!`06IH"@].;W1E.B!4:&ES(&ES(&[email protected]<W1A;F1A<[email protected] 
M:6]N<R!O9B!.05!,4%,N"@U4:&[email protected]:6QL:6,@4G5S<VEA;B!C:&%R86-T 
M=61E9"!A="!T:&4*#[email protected];[email protected]=&AI<R!F:6QE+B!)="!W:6QL(&[email protected] 
M9FER<W0L(&%N9`H-;6%Y('1A:[email protected],[email protected];W(@;6]R92!S96-O;F1S(&%T(#(T 
M,#`@8F%U9"X*#0H-5&AE;B!T:&[email protected];&ES:"!A;[email protected]<VEA;B!W:6QL 
M(&%P<&5A<BX*#[email protected]>6]U<B!.05!,4%,@5&5R;[email protected]<')O9W)A;2!D 
M;V5S(&YO=`H-<W5P<&]R="!.05!,4%,@<W1A;F1A<[email protected]%)#[email protected]>6]U('=I 
M;&[email protected];VYL>0H-<V5E('1H92!%;F=L:7-H('1E>'[email protected](&EL;'5S=')A=&EO 
M<'[email protected]']_9E%`?W]>?$!_?WUA0']W:D=`/E]P0$`W2FA?1$!'3E-%0$!!3VA` 
M0'AX:7%`>'[email protected]`W27=:3T!'1T],0#=)=WEL0$!`2$!`-TEW6G1`0$!`:$!` 
M>0H-"@[email protected]("`@("!-+EDN($QE<FUO;[email protected]"@[email protected]("`@("!-;W-C;W<L(%)U 
M<W-I80H-"@[email protected]("`@("`@("`@(#$X,S(*#0H-#CU<7CA`1T%S7W-.8R)`0$!! 
[email protected]($UO9&EF:65D(&)Y($1A=FED($AU9VAE<[email protected]%03%!3('!R97-E;G1A 
M=&EO;@H-($-O<'ER:6=H="[email protected]&%V:[email protected]'5G:&5S+"!#;VQO<F%D;R!3<')I 
M;F=S+`H-($-O;&]R861O+"`[email protected]#CU<?#U<5`P.(4Q`0$!)(T!`0$!` 
M"@T..$)-0%M?5F]W(D!`0$%H:`H/02!L;VYE('=H:71E('-A:[email protected]<VAO=W,@ 
M979F>[email protected]=FIH9B!U:FME/&IV)"T*#0XX0D![<5]5;W<B0$!`06AH"@]7:&5R 
M92!G;&5A;7,@=&AE('[email protected]@87IU<[email protected]<W1R96%[email protected]"@T./5QH.$%. 
M04-?7FM.(D!`0$%\:0H;+WL;;UAN:B!B;W1N(&IY(&[email protected](&QF:W1R 
M;[email protected]<F)[email protected]:[email protected]"!R:&8N(&AJ;'EJ=C\*#0XX0$]A1%=^3V\B0$!`06AH 
M"@]);B!A;&EE;B!L86YD<R!W:&%T(&1O97,@:[email protected]<V5E:S\*#0X]7'P.(4Q` 
M0$!)(T!`0$!`/EQ`#B%,0$!`22-`0$!`0#Y<0#U<[email protected](4Q`0$!)(T!`0$!` 
M9&)O=&Y>"@T..$)&<4-?;6=1(D!`0$%H:PH/[email protected];&]W<R!P;&%Y+"!T 
M:&[email protected];6%S="!B96YD<[email protected])E86MI;F<L"@T*#0X]7%0X0DQ(25]6:T,B0$!` 
M241\"ALO>QMO0G9X;[email protected][email protected]!C<FAS9V)N)B8F"@T..$)!?6E?7E]? 
M(D!`0$%H:`H/5&AE('=I;F0L(&EM<&%T:65N="[email protected];6]A;G,@86YD('-I9VAS 
M+BXN"@T./5Q4.$%/2DQ?5FM#(D!`0$E$?`H;+WL;;T5D<[email protected]:[email protected] 
M>B!Y="!B;[email protected]#CA!35!>5WY/;R)`0$!!:&@*#TET(&ES(&YO="!J;[email protected] 
M&V]"('ET(&IN(&[email protected]/'0[>6XA+0H-#CA!2%ML5WU/;R)`0$!!:&@* 
M#TYO<B!I<R=T(&9R;[email protected]:&%P<&EN97-S(&ET(&9L:[email protected]"@T./5Q\#B%, 
M0#Y<0#A"1U9L7VY[:R)`0$!)1'P*&R][&V]#;FAE9B!G:[email protected]>6)V(&-D=&MT 
M<2!K9B=E:&(*#0XX0D5E6U]V3W\B0$!`06AH"@]4:&[email protected]!W879E<R!D 
M0$E$?`H;+WL;;UEF;"[email protected]:V5X(&-J:WEW9B`G:FMJ;FIQ)0H-#CA"06IO 
M7U9O=R)`0$!!:&@*#U1H92!S=6XG<R!B<FEG:'[email protected]<F%Y<R!C87)E<W,@=&AE 
M('-E87,L"@T./5Q>.$%':6Q?;GMK(D!`0$E$?`H;+WL;;[email protected]:GE>('9Z;G0[ 
M(&9O<B!S=&]R;2!I="!B96=S+"!T:&[email protected]<F5B96P*#0X]7%XX04)2<%]N<T,B 
M0$!`241D"ALO>QMO4F9R(#QE;&YJ(&[email protected]/&5H>[email protected]=&-N;2!G:G)J<0H-#CA` 

------------8X---cut here------------------------------------