informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/programming/FORMATS/naplps.asc

2680 lines
119 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Copyright 1993 by Memra Software Inc.
All Rights Reserved
This is the March 1993 release of this document.
written by Michael Dillon
C-4 Powerhouse, RR #2
Armstrong, B.C. V0E 1B0
CANADA
BBS: 1-604-546-2705 - this has NAPLPS shareware and art
Fidonet: 1:353/350
Internet: mpdillon@halcyon.halcyon.com
CIS: >INTERNET:mpdillon@halcyon.halcyon.com
you can mail me questions and errata which will be
answered/fixed in the next release of this document.
------------------------------------------------------------
DISCLAIMER
This document is NOT the NAPLPS standard. The standard is
defined in an ANSI/CSA document which can be purchased from
one of those organizations. If you are creating commercial
products based on NAPLPS, then you should buy those
documents. This document is intended to clarify the
standards document and present the information using a
clearer terminology than in the standard. If there is any
conflict between this document and the standard, then follow
the standard and let me know so I can correct this document.
I take no responsibility whatsoever for any errors,
omissions or opinions in this document. It is NOT intended
as a guideline for creating commercial products, it is only
intended as an educational document for those who are unable
to obtain the standard or unwilling to decipher its
terminology.
------------------------------------------------------------
This is a specification for the on-line graphics format
known as NAPLPS. These specs are based on the ANSI/CSA
standards document that defines NAPLPS which is available
from ANSI (American National Standards Institute) as
document # X3.110-1983. They have offices in many American
cities and their head office is in New York. The identical
document is available from the CSA (Canadian Standards
Association) as document # T500-1983 and supplement # 1-
1991. Note that the supplement (which clarifies
proportionally spaced text among other things) is not
available from ANSI. I have also gleaned information from a
4-part series of articles published in Byte magazine in
February, March, April and May of 1983. There are a total of
55 pages in the 4 articles. I have also used the MGE editor
and PP3 terminal program from Microstar to experiment and
figure out the details of the coding scheme. As far as I
know, PP3 is the only shareware NAPLPS terminal program that
fully implements the NAPLPS spec including DRCS (redefinable
fonts) and bitmaps.
My knowledge of NAPLPS comes from many sources. I first
read about Telidon in 1979 or 1980. I was able to use
Telidon demo systems several times including one short
layover at Vancouver International airport in 1982 when I
spent 3 hours playing with a public Telidon terminal. It
would have been a boring 3 hours without that system. I also
have the official CSA specs. I have used the MGE editor and
used it to create test images to poke around in with DEBUG.
I have some Japanese utilities to print out a text version
of NAPLPS codes and reassemble into NAPLPS from the text
specs. I have the BYTE articles. I have used the PP3
terminal program and CTLINK and Turmodem. And I have a
collection of images from Japanese ham radio operators and
Montreal schoolchildren and from various NAPLPS services.
You should note that this spec is NOT the definitive
spec. I am writing it for electronic distribution in order
to encourage more people to produce software that supports
NAPLPS graphics. I hope that some of you will use it to
create NAPLPS utilities, write NAPLPS doors for BBSes, add
NAPLPS support to your terminal programs or BBS software,
etc. At the end of this document is a resource list with
phone numbers and Fidonet addresses where you can get more
info and samples of NAPLPS art.
Overview
NAPLPS
NAPLPS (North American Presentation Layer Protocol Syntax)
is a communications protocol that extends ASCII to allow for
the EFFICIENT transmission of picture and text information
over telecommunications channels such as modems. It does not
contain the commonly used ANSI protocol but it does include
similar capabilities and it could be used simultaneously
with ANSI although most NAPLPS terminal programs do not
currently support ANSI.
A NAPLPS image is transmitted in a manner that is
independent of the resolution and color capabilities of the
receiving display. There are NAPLPS terminal programs
available for Amiga, Macintosh and PC's with CGA, Herc
monochrome, EGA, VGA and other display resolutions.
This is accomplished by sending instructions to the
terminal program that tell it how to draw the required
pictures and text. Even bitmap pictures are transmitted in a
scalable fashion.
OSI
The OSI (Open Systems Interconnect) model of data
communications divides up the various aspects of an
electronic conversation into 7 layers. NAPLPS is a protocol
to be used at level 6 which is the presentation layer. Such
things as error-control are handled at lower layers and user
interaction is handled at level 7 (Application Layer).
APPLICATION - this is the interface provided by the
actual application program or BBS system.
PRESENTATION - this layer encodes, transmits and
decodes data in such a way as to
preserve its meaning. Examples are
ASCII, ANSI, NAPLPS
SESSION - this layer establishes and maintains a
communications session. This is the process
of logging in and presenting a password.
TRANSPORT - This layer provides a virtual circuit
from terminal to host. Data could travel
across several different networks in lower
layers.
NETWORK - This is the layer where routing, switching,
bridging and gating occur.
DATA LINK - This layer handles flow control, error
detection and correction.
PHYSICAL - This is the layer where you find cables
carrying electrical or optical signals
Telidon
NAPLPS is an extension of the experimental Telidon system
that was used in Canada in the late 1970's and early 1980's.
For more info, look up a book called Gutenberg Two. It also
includes mosaic bitmap capabilities from early European
Teletext systems.
The Basics
NAPLPS uses the 128 7-bit ASCII codes in such a way as
to be 100% compatible with any system which transmits pure
ASCII. It adds additional functions by making use of the 128
high-ASCII codes which are used on PC's for graphics
characters. This means that NAPLPS terminal programs can't
display high-ASCII unless the high-ASCII symbols are defined
as a downloadable character set and font selection codes are
transmitted prior to use of high-ASCII. In this, it is much
like Microsoft Windows which also does not use high-ASCII
for much the same reasons.
The additional capabilities include color mapping, 24-
bit color spec, line, box, circle, arc, polyline, polygon,
spline curve, bitmaps, downloadable fonts, macros, input
fields, line patterns, fill patterns, etc. All this is
accomplished in very compact manner so that reasonably
complex NAPLPS images are usually around 5 K bytes. The most
complex image I have seen is 22 K bytes and contains a
detailed picture of a mountain range, some trees, a horse
with a native rider wearing a Hudsons Bay jacket. This spec
is efficient enough to make it reasonable at 2400 bps if
complex images are limited to Art Galleries. At 9600 bps and
above, performance is not an issue.
ISO (International Standards Organization)
NAPLPS was designed to fit in with and be compatible
with other coding schemes that are ISO standards such as 7-
bit ASCII and the various Latin based alphabetical character
sets. For more info, read up on MS-Windows character sets
or HP Laserjet character sets as these are also designed for
ISO compatibility.
There is currently a modification to the spec to
include JPEG compressed bitmaps in the standard but that has
not yet been approved by ANSI or ISO. I will include that
info in this document as soon as I know more.
General Architecture
Character Codes
All NAPLPS info can be transmitted using either 7-bit
or eight bit codes. This allows NAPLPS to be transmitted
over links that require a parity bit. When 7-bit codes are
used, then the extended codes are selected by shifting the
extended codes into the 7-bit ASCII code table. This is
similar to a keyboard shifting between upper and lower case
letters. They are different symbols, but shifting (and Ctrl
and Alt) allows the same key to be used.
In fact there are several different code sets that can
be shifted in. The Primary code set is 7-bit ASCII. Then
there is the PDI (Picture Description Instruction) set, the
Supplementary set which contains accented characters and
other symbols, the Mosaic set which supports the old
Teletext bitmap format, the Macro set which invokes
predefined macros, and the DRCS or Dynamically Redefinable
Character Set which is used for non-Latin languages such as
Russian, Thai, Inuktitut. When using 8-bit codes, things are
simplified somewhat since two of these code tables are
accessible without shifting.
Whenever the numeric value of a character code is given
in this document, it will be in hexadecimal.
Coordinates
All pictures are drawn and positioned using Cartesian
(X,Y) coordinates within the Unit Screen. This is the upper
right quadrant of the Cartesian plane between (0,0) and
(1,1)
|-------|(1,1)
| |
| |
| |
--------------|--------------- X axis
|
|
|
|
Y axis
It is possible to specify 3 dimensional (X,Y,Z) coordinates
but at the current time, Z coordinates are to be ignored.
On most video displays the aspect ratio is 4:3,
therefore drawings should be restricted to a Y coordinate
between 0 and .75. Anything extending beyond either the unit
screen or the actual display screen should be clipped. So,
the physical display screen extends from (0,0) in the lower
left hand corner to (1,.75) in the upper right hand corner.
NAPLPS terminal programs must always ensure that the entire
display is visible to the user. In resizable windowing
environments (MAC, Amiga, Windows) this means that when the
display window is resized the terminal program should
maintain the 4:3 aspect ratio and scale the current image.
These coordinates are specified as binary fractions.
For instance, if 8 bits of precision are available, then the
binary number .10000000 is equal to 1/2. This is just
another way of saying that the binary number 10000000 (128
decimal) is 1/2 way between 0 and the maximum representation
in 8 bits namely 11111111 (255 decimal). If the precision is
widened to 16 bits then zeroes are added on the right so
that .1000 0000 0000 0000 still means 1/2 even though it now
represents the number 16,384 in the range of 0 to 32,768.
Stream of Data
The NAPLPS codes are a stream of data coming into the
terminal program and should be acted on in sequence. Each
graphical object is drawn on top of those already visible.
Composite pictures and alphabetic characters can be created
by superimposing multiple characters and/or images.
The specification is very flexible as far as PDI
operands is concerned. If the NAPLPS stream does not supply
the number of bits of precision that the receiving terminal
expects (less than defined DOMAIN), it simply pads the
binary fractions with zeroes on the right. This has the
effect of drawing the pictures with shorter operands using a
coarser grid. If there is more precision than the terminal
program is capable of using (defined DOMAIN is more precise
than the current display), it truncates the rightmost bits
of the binary fractions which has the effect of rounding the
more precise drawing specs to the grid size that the display
driver is capable of using.
On the other hand, if the NAPLPS stream contains more
operands than would be expected with the currently defined
DOMAIN, then the drawing operation is repeated in some form,
i.e. lines become polylines, rectangles become bar charts,
arcs become spline curves.
Code Sets
Overview
A sequence of NAPLPS codes is initiated by the 3
character sequence ESC 25 41 and is terminated by the
sequence ESC 25 40. Outside of this bracketing, all NAPLPS
terminal programs will support ASCII codes. Other support
such as VT100 and ANSI escape sequences is out of the scope
of the NAPLPS standard.
The 128 possible 7-bit codes are divided into 32
character C-sets and 96 character G-sets. The two C-sets are
codes that perform control operations. C0 is the familiar
ASCII set of control characters, and C1 is a set of codes
that do cursor positioning, macro defining, etc.
There are two types of G-sets, 94 character and 96
character. A 94 character G-set is really just a 96
character G-set in which the codes 20 and 7F are used for
<space> and <del>. The <space> code is therefore available
in both the ASCII and supplementary character sets. The
<del> code is treated as a null, i.e. discarded. G-sets are
selected in a two stage fashion. There are 6 possible G-
sets, but only 4 G-sets are current. The current G-sets are
named G0, G1, G2 and G3. In the default state, G0 is the
primary character set (ASCII), G1 is the PDI set, G2 has the
supplementary characters, and G3 the mosaics.
Shift and Escape Codes
Five of the normal ASCII control characters are used in
code sequences that shift G-sets and C-sets in and out of
the active state. They are ESC (1B), SI (0F), SO (0E), SS2
(19) and SS3 (1D) or ESCAPE, SHIFT-IN, SHIFT-OUT, SINGLE-
SHIFT 2 and SINGLE SHIFT 3. The single shift codes are used
to temporarily escape the immediately following character.
The normal control character set is always available.
The C1 set is accessed by setting the bit 8 if operating
over an 8-bit link, or by ESCaping the code and setting bit
7 on a 7-bit link. For instance, DEF MACRO is 80 when eight
bits are used, but it is ESC 40 when 7-bits are used. This
means that on an eight-bit link, the C1 set ranges from 80
through 9F, but on a seven-bit link it ranges from 40
through 5F. There are two sequences for activating the
control sets. C0 is activated by ESC 21 4B and C1 is
activated by ESC 22 46. These are somewhat redundant as
there are only two control sets at present.
G-sets are a bit more complex. Firstly, there are two
positions in the code table that can hold a G-set, the lower
128 positions or G-left (GL) and the upper 128 positions or
G-right (GR). In a 7-bit environment, GL is the only active
G-set. If the 256 possible codes are arranged as 16 columns
of 16 rows, then the C and G sets are laid out as follows
with 2 columns (32 chars) for the C-sets and 6 columns (96
chars) for the G-sets.
C0 GL C1 GR
--- ----------- --- ---------
| | | | | | | | | | | | | | |
By default GL contains G0 (ASCII) and GR contains G1
(PDI). G2 is the supplementary characters and G3 defaults to
the mosaics. You can activate G0 - G3 by selecting them into
the GL area as follows:
0F (SI) selects G0
0E (SO) selects G1
ESC 6E selects G2
ESC 6F selects G3
This works in both 7-bit and 8-bit mode. A single character
from G2 or G3 can also be selected by using SS2 or SS3, e.g.
19 selects the 1 following char from G2
1D selects the 1 following char from G3
In 8-bit mode, you can activate GR as follows:
ESC 7E selects G1 (also ESC 6B)
ESC 7D selects G2 (also ESC 6C)
ESC 7C selects G3 (also ESC 6D)
The 6B, 6C, and 6D codes should be supported by terminal
programs for backward compatibility, but should not be used
in new image coding. ASCII codes cannot be selected into GR.
While the G0-G3 sets have 4 default settings, the
actual G-sets in each of them can also be selected by a code
sequence. For the 94 character sets (ASCII and
supplementary) the code sequence is:
ESC 28 42 selects ASCII into G0
ESC 28 7C selects supplementary into G0
The code 28 could be one of:
28 represents G0
29 represents G1
2A represents G2
2B represents G3
If you are selecting one of the 96 character G-sets, use the
following sequence:
ESC 2D 57 selects PDI's into G1
ESC 2D 7D selects mosaics into G1
ESC 2D 20 7A selects the macros into G1
ESC 2D 20 7B selects the DRCS into G1
The code 2D could be one of:
2D represents G1
2E represents G2
2F represents G3
If you are writing a terminal program you should also
support some older code sequences for backwards
compatibility. For 96 character G-sets the codes 29, 2A and
2B should be accepted as well as 2D, 2E and 2F. In addition
the single byte code 7A should be accepted as equivalent to
20 7A for macros and 7B should be accepted as equivalent to
20 7B for DRCS.
If an unknown terminating code is received for a
sequence, then the entire sequence should be discarded.
If a given G0, G1, G2 or G3 set is currently invoked
into either GL or GR, then the new contents of that set take
effect immediately. For instance, if you have invoked the
default G2 (supplementary) into GL via ESC 6E and you then
designate the macro set as the new contents of G2 via the
sequence ESC 2E 20 7A then it is NOT necessary to re-invoke
G2 by another ESC 6E.
G-Sets
The 94 symbols of the primary character set are
identical to ASCII. The actual font used is implementation
dependent but it must be scalable. There is no guarantee
that a font is legible at all resolutions. The cursor is
automatically advanced when a character from this set is
displayed, according to the current TEXT settings. Note that
characters that are overprinted do NOT wipe out the image of
the original character as in most text mode displays. Both
characters remain visible.
The 94 symbols of the supplementary character set are
not ASCII and therefore must be described in this document.
Again, these are scalable and the font used is
implementation dependent. The codes from 21 through 3F and
from 51 through 7E are displayed in the same way as ASCII,
namely, the cursor is advanced after they are displayed. The
codes from 41 through 4F are non-spacing accent character
used to create composite characters. Normally, a composite
character is formed by first displaying the non-spacing
accent, and the letter. The best way to see these is to get
MGE and display them at a reasonably large size to see
details on some of the weird ones. They are also displayed
in the standard documents and in the 1st article in the
February 1983 issue of BYTE.
Supplementary Character Set
---------------------------
21 upside down exclamation as in Spanish
22 cents symbol
23 British pound symbol
24 dollar sign ASCII 24
25 Japanese yen symbol
26 number sign ASCII 23
27 subsection symbol PC code 15
28 generic currency symbol like X with o in middle
29 left single quote
2A left double quote
2B left guillemot like << PC code AE
2C left arrow like <- PC code 1B
2D up arrow PC code 18
2E right arrow like -> PC code 1A
2F down arrow PC code 19
30 degree symbol PC code F8
31 plus or minus PC code F1
32 superscript 2 PC code FD
33 superscript 3
34 times symbol like x
35 greek mu PC code E6
36 paragraph mark PC code 14
37 centered dot PC code F9
38 division PC code F6
39 right single quote
3A right double quote
3B right guillemot like >> PC code AF
3C looks like 1/4
3D looks like 1/2
3E looks like 3/4
3F upside down question mark as in Spanish
The following 16 codes are non-spacing accents
40 vector overbar (a right-pointing vector arrow
just above the top of capitals)
41 grave accent
42 acute accent
43 circumflex accent
44 tilde
45 macron or overbar
46 breve like a ) laying on its side with points up
47 dot positioned over a letter
48 diaresis or umlaut
49 overprinting slash /
4A small ring or circle positioned over a letter
4B cedille as in French garcon
4C underscore
4D double acute accent
4E ogonek (mirror image of cedille)
4F caron (little v above a letter)
50 em dash
51 superscript 1
52 registered trademark R in a circle
53 copyright C in a circle
54 TM superscripted
55 musical eighth note PC code 0D
56 horizontal box drawing line PC code C4
57 vertical box drawing line PC code B3
58 / from bottom left to upper right of char field
59 \ from top left to bottom right of char field
5A filled triangle below code 58
5B filled triangle below code 59
5C looks like 1/8
5D looks like 3/8
5E looks like 5/8
5F looks like 7/8
60 greek Omega PC code EA
61 AE ligature
62 Icelandic eth D with - through the vertical
63 feminine ordinal PC code A6
64 H with horizontal stroke at 3/4 height
65 crossbar box drawing character PC code C5
66 IJ ligature
67 L with a dot centered vertically and horizontally
68 L with a short / through the vertical
69 O with a /
6A OE ligature
6B masculine ordinal PC code A7
6C Icelandic thorn like P with extended vertical
6D T with short horizontal stroke
6E Lappish capital eng looks like nj
6F looks like 'n
70 greek kappa
71 small ae ligature
72 small 62
73 mirror image of 6 with stroke
74 small 64
75 i with no dot
76 small 66
77 small 67
78 small 68
79 small 69
7A small 6A
7B German esset similar too greek beta but not same
7C small 6C
7D small 6D
7E small 6E
The PDI set
Overview
This is the heart of NAPLPS, the graphical drawing
primitives. There are eight environment codes (RESET,
DOMAIN, TEXT, TEXTURE, SET COLOR, WAIT, SELECT COLOR and
BLINK) which set the graphics environment and 6 different
object types (POINT, LINE, ARC, RECTANGLE, POLYGON,
INCREMENTALS). Each type of object has 4 different forms in
which it can be drawn. These codes take up the first 32
positions in the PDI set. The other 64 positions are used to
encode parameters and co-ordinates for these primitives. The
PDI set is not really a character set, but a set of function
calls with parameters.
A PDI (Picture Description Instruction) begins with a
code selecting one of the primitives. These codes can all be
distinguished by the fact that bit 7 is equal to zero. This
code is then followed by one or more codes containing
parameter data. The PDI is terminated whenever a code that
is not data is encountered, i.e. another PDI or any code
outside of the PDI's G-set. The exceptions are the control
codes 00 through 06, and 10 through 17 which do not affect
the OSI presentation layer and are therefore ignored if
encountered. Also, macro invocation does not terminate a PDI
so macros can be used to provide all or some of the
parameter codes. In certain cases, invalid data will require
that the PDI and all data bytes up to the termination of the
PDI are to be discarded with no action taken.
There are 4 types of parameters. Fixed format
parameters are specific to the PDI which uses them.
Bitstrings are also specific to a PDI which uses them but
they are encoded in bits 6 through 1 of a string of
characters. Single value operands take up from 1 to 4 bytes
of data depending on the current DOMAIN setting. They are
unsigned integers of 6, 12, 18, or 24 bits with the most
significant bits being received first. Multi-value operands
are from 1 to eight bytes of data depending on the current
DOMAIN setting. These are primarily used for Cartesian
coordinates but can also encode color information. The
coordinates are signed integers encoded as follows:
X Y X Y Z
8 7|6 5 4|3 2 1| 8 7|6 5|4 3|2 1|
----------------- -----------------
|?|1|S| | |S| | | |?|1|S| |S| |S| |
----------------- -----------------
|?|1| | | | | | | |?|1| | | | | | |
----------------- -----------------
. . . . . .
----------------- -----------------
|?|1| | | | | | | |?|1| | | | | | |
----------------- -----------------
In the normal 2 dimensional case, the first byte contains
the sign bit and the 2 most significant data bits. Second
and subsequent bytes contain 3 data bits. Therefore these
coordinates can range from 3 bit to 24 bit signed integers.
These integers are fractions of the unit screen. For
example, if the DOMAIN setting specified 3 bytes for multi-
value operands then the unit screen would range from 0 (000
000 000) to 256 (011 111 111) units in width. Negative
coordinates would be clipped as they are not on the screen.
They are also used to specify relative coordinates from the
current drawing point.
When a multivalue operand is used to represent a color,
it is coded as follows:
G R B G R B
8 7|6 5 4|3 2 1|
-----------------
|?|1| | | | | | |
-----------------
|?|1| | | | | | |
-----------------
. . .
-----------------
|?|1| | | | | | |
-----------------
The color value is decoded by concatenating the bits for
each of the Green, Red and Blue values. This color value is
again treated as a binary fraction so that with DOMAIN
settings for 3 bytes the range of color values would be from
0% (00 00 00) to 100% (11 11 11).
There are two special colors: nominal white is the
palette entry 011...11 and has a color value of all ones;
nominal black is palette entry 0 and has a color value of
all zeroes. Note that this places the color white in the
middle of the palette.
Whenever the required number of data bytes are not
received, the receiving system should pad the data with zero
bits to the correct length. This gives transmitting systems
an opportunity to make transmission more efficient by not
transmitting the trailing zero bits on data operands. Zero
bits would look like this (1 000 000) in 7 bit form. On the
other hand, if more data bytes are received than required,
the receiving system should assume that the current PDI is
to be repeated with a new set of data bytes unless otherwise
specified for a particular PDI.
The PDI primitives are as follows:
20 RESET - selective reset
21 DOMAIN - sets graphical environment
22 TEXT - sets default text attributes
23 TEXTURE - sets line and fill patterns
24 POINT SET ABS
25 POINT SET REL
26 POINT ABS
27 POINT REL
Lines and Polylines
28 LINE ABS
29 LINE REL
2A SET & LINE ABS
2B SET & LINE REL
Arcs, Circles, Splines
2C ARC OUTLINED
2D ARC FILLED
2E SET & ARC OUTLINED
2F SET & ARC FILLED
Rectangles and histograms
30 RECT OUTLINED
31 RECT FILLED
32 SET & RECT OUTLINED
33 SET & RECT FILLED
Polygons
34 POLY OUTLINED - polyline
35 POLY FILLED - polgon
36 SET & POLY OUTLINED - polyline
37 SET & POLY FILLED - polygon
38 FIELD - define bitmap field or input field
39 INCREMENTAL POINT - color bitmap
3A INCREMENTAL LINE - scribble
3B INCREMENTAL POLY FILLED - filled scribble
3C SET COLOR - specify an RGB color
3D WAIT - timed pause
3E SELECT COLOR - set color mode
3F BLINK - palette animation
Default graphics environment
The following setting are the default upon starting the
program or immediately after receiving an NSR (non-selective
Reset).
- GL contains the G0 set
- in 8-bit mode, GR contains the G1 set
- G0 contains the ASCII set
- G1 contains the PDI set
- G2 contains the supplementary set
- G3 contains the mosaic set
- drawing color is nominal white
- color mode is 0
- single value operands are 1 byte
- multi-value operands are 3 bytes
- multi-value co-ordinates are 2 dimensional with Z=0
- logical pel is 0 wide and 0 high with origin
point at the lower left. This makes the logical
pel size equivalent to 1 physical pixel.
- text rotation is 0 degrees (horizontal)
- character path moves to the right
- intercharacter spacing is 1
- interrow spacing is 1
- cursor and drawing point move together
- cursor style is underscore and is invisible
- character field is 1/40 wide and 5/128 high
- line texture is solid
- no outlines are drawn on filled objects
- fill pattern is solid
- fill pattern mask is 1/40 wide and 5/128 high
- the active field corresponds to the unit screen
- underlining is off
- word wrap is off
- scrolling is off
- reverse video is off
The following conditions are found at startup but are NOT
created by receipt of an NSR:
- palette is in default condition (see SET COLOR PDI)
1/2 evenly spaced grey scale
1/2 evenly spaced hues
- blinking is off
- no macros are defined
- no DRCS characters are defined (all <spaces>)
- no programmable fill masks are defined
- no unprotected fields are defined
RESET - 20
This PDI can selectively reset parts of the graphics
environment their default values. It is followed by two
fixed format bytes which specify what is to be reset. The
resets are to be performed in the following order:
DOMAIN - If bit 1 of the first byte is 1, the domain
parameters are reset.
COLOR - specified by bits 3 and 2 of the first byte
0 0 nothing
0 1 set color mode 0, reset to default
palette and set drawing color to white
1 0 set color mode and reset to default
palette. If current color mode is 0
then treat same as 1 1
1 1 set color mode 1, reset to default
palette and set drawing color to white
SCREEN - specified by bits 6, 5 and 4 of the first byte
0 0 0 nothing
0 0 1 clear screen to nominal black
0 1 0 clear screen to current drawing color
0 1 1 set border to nominal black
1 0 0 set border to current drawing color
1 0 1 clear screen/border to drawing color
1 1 0 clear screen to drawing color and set
border to nominal black
1 1 1 clear screen/border to nominal black
Note that most modern video displays do not
allow manipulation of the border or overscan.
TEXT - If bit 1 of the second byte is 1, then the
cursor is sent home to the top left of the
display area and all text parameters from the
TEXT PDI, the C1 set and the active field are
reset to their defaults.
BLINK - If bit 2 of the second byte is 1 then all blink
processes are terminated.
FIELDS - If bit 3 of the second byte is 1 then all
unprotected fields are changed to protected
and all field definitions except the active
field are lost. The display is not changed. If
the terminal program has any internal data
structures for editing and transmitting field
contents, they should be cleared as well.
TEXTURE - If bit 4 of the second byte is 1 then all
line texture and pattern fill attributes are
set to the default. The four programmable
pattern masks are not changed.
MACRO - If bit 5 of the second byte is 1 all macros are
cleared including transmit macros.
DRCS - If bit 6 of the second byte is 1 then all DRCS
characters are cleared by setting all DRCS
characters to be equivalent to the <space>
character.
If one or more of the data bytes are missing, then the RESET
will proceed as if it had been received with all zero bits.
If extra bytes are received, they will be discarded.
DOMAIN - 21
This command sets the precision of single and multi-
value parameter data, the number of Cartesian coordinates
and the logical pel size. The first parameter is fixed
format and that is followed by a multi-value operand to set
the logical pel size.
If bit 6 is 0, then X,Y coordinates are transmitted, if
1 then X,Y,Z coordinates are transmitted. The default
setting is X,Y. If 3-dimensional X,Y,Z is selected, then the
Z coordinates should be ignored at the present time.
The length of a multi-value operand is encoded in bits
5, 4 and 3 as follows:
0 0 0 1 byte
0 0 1 2 bytes
0 1 0 3 bytes (the default)
0 1 1 4 bytes
1 0 0 5 bytes
1 0 1 6 bytes
1 1 0 7 bytes
1 1 1 8 bytes
The length of a single value operand is encoded in bits
2 and 1 as follows
0 0 1 byte (the default)
0 1 2 bytes
1 0 3 bytes
1 1 4 bytes
The multi-value data following the fixed format byte is
used to define the width and height of the logical pel which
is the basic brush used in all the drawing operations. The
logical pel will always be at least 1 real pixel in size,
but may be larger. The width and height of the logical pel
must be rounded UP to the nearest real pixel size. For
instance, if the unit coordinates map to 1.3 real pixels in
width, then the logical pel should be 2 pixels wide. The
default size is 0,0 which makes the logical pel 1 physical
pixel in both width and height. The logical pel cannot
become invisible.
Unlike many graphical environments that draw pictures
with a logical brush, the logical pel is NOT centered on the
current drawing point. Instead the current drawing point is
located as follows:
+,- ------- -,-
| |
| |
+,+ ------- -,+
For instance, if the width is .01 and the height is -.01
then the upper left corner of the logical pel is always
aligned with the drawing point. To see this graphically,
draw a circle in MGE with a larger pel size. Then copy it
and use "Edit To" to change the copy to a smaller pel size
and a contrasting color.
The data bytes defining the logical pel are interpreted
according to the multi-value operand settings in the fixed
format byte immediately preceding them. Any additional data
bytes after the logical pel size are to be ignored. If there
are no data bytes after the fixed format byte, then the
logical pel size is unchanged.
TEXT - 22
This command sets up the current parameters which
affect how text is displayed. This includes ASCII,
supplementaries, DRCS characters and mosaics. The parameters
are two fixed format bytes followed by a multi-value
character field size.
Bits 6 and 5 of the first byte determine how far to
move the cursor after displaying a character or after a
<space>, <backspace> or <tab> character. The cursor is
always moved parallel to the character path and the distance
is a multiple of the height or width of the character field,
depending on which one is parallel to the character path.
This intercharacter spacing is defined as follows:
0 0 1 (the default)
0 1 5/4 i.e. 1.25
1 0 3/2 i.e. 1.5
1 1 proportional spacing
When the intercharacter spacing is 1, the following
character field touches the previous one, but in 5/4 and 3/2
spacing there is a gap. This would be visible in color mode
2 if the current background color contrasted with the
underlying image. Proportional spacing is defined later in
this document.
Bits 4 and 3 of the first byte define the character
path as follows:
0 0 Right (the default)
0 1 Left
1 0 Up
1 1 Down
After a character is displayed, the cursor moves in the
direction specified by the character path. This is
independent of the character rotation setting.
Bits 2 and 1 of the first byte define the character
field rotation as follows:
0 0 0 degrees (the default)
0 1 90 degrees
1 0 180 degrees
1 1 360 degrees
The character field rotates about it's origin which is the
lower left hand corner regardless of the sign of the
character field dimensions. The rotation affects all 4
character G-sets as well as the cursor and the underline
produced in underline mode.
Bits 6 and 5 of the second byte define the cursor style
as follows:
0 0 Underscore (the default)
0 1 Block
1 0 Cross-hair
1 1 Custom
The underscore is the full width of the character field at
the bottom of the field. The block cursor fills the entire
character field. The cross-hair is a vertical line and a
horizontal line that intersect at the center of the
character field. The custom cursor shape is implementation
dependent. When the underscore and block cursors are used,
the current drawing point aligns itself with the lower left
hand corner. When the cross-hair and custom cursors are
used, it aligns itself with the center of the character
field.
Bits 4 and 3 of the second byte define how the
graphical drawing point is related to the text cursor as
follows:
0 0 Move together (the default)
0 1 Cursor leads
1 0 Drawing point leads
1 1 Move independently.
When the cursor and the drawing point move together, then
every text character displayed causes the drawing point to
be repositioned, and every graphical drawing primitive
causes the text cursor to be repositioned. The actual
alignment between cursor and drawing point is determined by
the cursor type. If the cursor leads, then the drawing point
follows it, but it does NOT follow the drawing point. If the
drawing point leads, then the cursor follows it bit it does
NOT follow the cursor. Whenever the cursor is repositioned
in such a way that part of the character field would fall
outside the unit screen, it is automatically repositioned so
that the entire character field is within the unit screen.
Bits 2 and 1 of the second byte define the interrow
spacing as follows:
0 0 1 (the default)
0 1 5/4 i.e. 1.25
1 0 3/2 i.e. 1.5
1 1 2
These are interpreted as multiples of the character field
height or width, whichever is perpendicular to the character
path. Whenever <linefeed> or <vertical tab> is executed, the
new line position is calculated according to this spacing.
Note that the default single spacing causes the character
fields of the two rows to meet exactly, whereas 5/4, 3/2 and
double spacing leave a gap. Whenever a text character is
displayed, if the subsequent cursor movement would cause
part of the character field to be outside the unit screen or
outside the active field, then an automatic <carriage
return> <linefeed> is executed. If, by chance, a <carriage
return> <linefeed> is received right after that, then it is
ignored so that only one line positioning takes place.
The character field dimensions are defined by the
multivalue operands following the two fixed format bytes. If
the width of the character field is negative, then the
characters are mirrored around the vertical center axis of
the character field. If the height is negative, then they
are mirrored around the horizontal center axis of the
character field. If no data bytes are received, then the
character field dimensions are not changed. The default
width of the character field is 1/40 of the unit screen and
the default height is 5/128 of the unit screen. This is like
saying that by default, the unit screen is 40 chars by 25
lines (although only 3/4 of the lines are visible, i.e. 19
lines).
TEXTURE - 23
This command sets the line textures, fill patterns and
the outlining of filled areas. It is a fixed format byte
followed by a multi-value operand.
Bits 6, 5 and 4 define the fill pattern as follows:
0 0 0 Solid (the default)
0 0 1 Vertical hatching
0 1 0 Horizontal hatching
0 1 1 Vertical and horizontal cross-hatching
1 0 0 programmable mask A
1 0 1 programmable mask B
1 1 0 programmable mask C
1 1 1 programmable mask D
The hatching lines are one logical pel wide (or high) and
are spaced one logical pel apart. The hatching patterns
should maintain registration from one object to the next if
the pel size for those objects is the same. Even when the
logical pel size is (0,0), the solid fill is still drawn.
The programmable fill masks are defined with the DEF TEXTURE
command. By default, they cause no fill in color modes 0 and
1, and a background color fill in color mode 2.
Bit 3 defines whether or not to draw the outline of
filled objects. If it is 1 then filled objects are outlined
with a solid line (independent of the line texture) using
the current pel size. In color modes 0 and 1, the outline is
black; in color mode 2, the background color is used. The
default is 0 for no outline.
Bits 2 and 1 define the line texture as follows:
0 0 Solid (the default)
0 1 Dotted
1 0 Dashed
1 1 Dot-Dash
This sets the texture of lines drawn by the LINE, ARC,
RECTANGLE, POLYGON, and INCREMENTAL LINE PDI's. The size of
a dot and the gap size is equal to the logical pel size. In
horizontal lines the dashes are 3 logical pels wide, in
vertical lines they are 3 logical pels high. In angled lines
the visual effect of dots and dashes should be consistent
with that of the specified horizontal and vertical lines.
All end points of lines and arcs and all vertices should be
drawn regardless of the line texture. When the pel width is
0, all non-vertical lines are solid. When the pel height is
0, all non-horizontal lines are solid.
The multi-value operand following the fixed format byte
defines the mask size used in pattern fills for the
programmable masks A, B, C and D. The pattern is scaled to
the mask size, then tiled over the object with reference to
the screen origin to maintain registration. In color mode 2
both the foreground and background colors are used to draw
the pattern fill. The default mask size is 1/40 wide and
5/128 high. Negative mask sizes mirror the pattern the same
way text characters are mirrored. If there is no multi-value
operand, then the mask size is unchanged.
SET COLOR - 3C
This command is used to modify the color palette and is
subject to the color mode set by SELECT COLOR. In color mode
0, drawing colors are explicitly specified as RGB triples
and the palette is modified implicitly. In color modes 1 and
2, the color is specified as a palette entry. For example,
when displaying text in color mode 0, the drawing color is
specified directly and only affects the foreground pixels in
the text character. In color mode 1, the color is selected
from the palette and also is used to draw only the
foreground pixels. In color mode 2, both foreground and
background colors are chosen from the palette and both
foreground and background pixels are drawn in the
appropriate colors.
In order to use a color in modes 1 and 2, you must
first specify the color to be placed in the palette using
SET COLOR, and then you must select the palette entry to use
with SELECT COLOR. Any changes to the palette are
immediately reflected on the display. When a color is
specified directly in mode 0, the palette is checked. If the
color is already there, then the drawing color is set to the
lowest palette entry with that same color. If it is not
already there, mode 0 looks for the lowest palette entry
that has not been used by SET COLOR or SELECT COLOR since
the last RESET that has reset the palette. The palette
entries for nominal black and nominal white are not used.
Once an unused entry is found, it is defined and the drawing
color is set to use that palette entry. If there are no
available palette entries, then the drawing color is set in
an implementation dependent manner.
In mode 0 the multi-value operand specifies the actual
RGB color value where bits 6 through 1 of each data byte
represent GRBGRB. For instance, to set the value of the
green portion concatenate bits 6 and 3 from each byte as
follows 6363..., for Red use bits 5 and 2 5252... and for
blue use bits 4 and 1 4141... The drawing color is in effect
until another SET COLOR command changes it or it is reset by
a RESET or NSR. The default drawing color is white.
In modes 1 and 2, the SET COLOR command puts colors
into the palette. The palette entry used is the one which is
the current drawing color. It can be changed by using SELECT
COLOR. Whenever the data bytes specify more bits than the
palette can handle, the least significant bits are
discarded. If the palette entry can handle more bits than
the data bytes provide, then trailing zero bytes are added.
If there are additional data bytes after the multi-value
operand size, then an implicit SET COLOR command is assumed
with a new palette entry. The new palette entry is
determined as follows:
Take the palette entry number, change the most
significant zero to a one, then change all ones to
the left of it to zeroes. For example, 010100
would be incremented to 110100 which would be
incremented to 001100. This palette entry
determination does not affect the current drawing
color. The incrementing stops when a palette entry
of all ones is reached. This algorithm allows an
image to be viewed on a device with more palette
entries than are specified in the image. Carefully
placing similar colors in adjacent palette entries
will also allow the image to be viewed reasonably
on a device with fewer palette entries than the
original image.
If there are no multi-value data bytes, then the transparent
color is used. If transparency is not implemented, then the
transparent color is shown as black.
The default palette is determined by the following
algorithm:
N = number of bits in a palette entry number
i.e. 4 bits for 16 color VGA, 8 bits for 256 color
2 ^ n = the number of palette entries, i.e. 2^4 = 16
M = number of bits in the colour values, e.g. 24 bit
M >= 3 * (N - 1) This is a required relationship
The first half of the palette stores a uniformly spaced
greyscale where R = G = B. If M = 3 * (N - 1) then
there should be exactly (2^N)/2 grey levels including
black and white.
The second half of the palette stores a full rang of
hues spaced equally around the perimeter of the hue
circle with Blue at 0 degrees, Red at 120 degrees and
Green at 240 degrees. The algorithm for mixing colors
to obtain a desired hue is:
h = desired hue
ang(h) = the angle of h
P1 = the closest primary to h
ang (P1) = the angle of P1
P2 = the second closest primary to h
ang(P2) = the angle of P2
P3 = the farthest primary from h
Then the color values to give h will be:
P1 = 100% (all one bits)
P2 = |ang(h) - ang(P1)|
------------------
60 degrees
P3 = 0%
WAIT - 3D
This command produces a timed pause. If the terminal
program has not yet finished displaying previously received
PDI's, then the pause interval is not started until the
drawing is completed. The byte following the WAIT PDI is a
fixed format byte containing 1011100 in bits 7 through 1. If
any other byte follows the WAIT PDI, then the entire
sequence is discarded.
The 3rd and subsequent bytes specify wait intervals in
bytes 6 through 1. There can be any number of wait intervals
specified to add up to the required pause time. A wait
interval of zero is anywhere between 0 and .1 seconds long.
SELECT COLOR - 3E
This command sets the color mode. For modes 1 and 2 it
selects the palette entry to use for the foreground or
drawing color. For mode 2 it also sets the palette entry for
the background color. It can have 0, 1 or 2 single value
operands. Any additional data bytes are discarded.
If there are no data bytes, then color mode 0 is set.
If there are data bytes for 1 single value operand, mode 1
is set and if there are data bytes for 2 single value
operands, mode 2 is set. The most significant bits of the
single value operands are used to determine the palette
entry to use. If the single value operand has less bits than
palette entry numbers, then trailing 0 bits are added.
The first single value specifies the drawing color. The
second single value (if available) specifies the background
color. If both operands specify the same palette entry, then
the drawing color is NOT changed, only the background color.
The background color is used to fill the character field in
which characters are displayed. It also draws the outlines
of filled objects, the spaces in line textures and the
backgrounds in all pattern fills.
BLINK - 3F
This command is used to set up palette animation by
creating a blink process. This process runs on a 1/10th of a
second timer and periodically modifies palette entries. The
palette entry to be changed is the blink-from color and the
new contents of the blink-from color come from the palette
entry specified by the blink-to color. The time interval
that each of the two colors is visible is definable. The ON
interval is when the blink-to color is visible and the OFF
interval is when the blink-from color is visible.
A starting delay can be specified to synchronize
multiple blink processes. The starting delay is ignored if
there are currently no blink processes active. The delay is
relative to the beginning of the ON interval of the most
recently defined blink process. A start delay of 0 causes
the ON interval of the new blink process to start at the
same time as the ON interval of the previously defined blink
process.
When the ON or OFF intervals, for more than one blink
process, end simultaneously, they are processed starting
with the first defined blink process. This means that the
second and subsequent blink processes use the color map
resulting from the first blink process. Some complex side
effects can be created this way.
The first set of data bytes following BLINK are a
single value operand defining the blink-to color as a
palette entry. The same rules apply as for SELECT COLOR. The
blink-from color is defined to be the current drawing color
and therefore is not explicitly included in the BLINK PDI.
Following the single value operand are 3 fixed format
bytes defining the ON interval, OFF interval and START DELAY
for the blink processes. Each interval is defined in 10ths
of a second and, of course, only bits 6 through 1 are used.
This means the minimum interval is .1 seconds and the
maximum interval is 6.3 seconds. If the START DELAY is not
transmitted then it is assumed to be 0. A start delay is
ignored if there are no currently active blink processes. If
either the ON interval or the OFF interval are zero, then
any currently active blink process for the specified blink-
from and blink-to colors is terminated. There can be only
one blink process at a time for a given pair of colors. If a
blink PDI is issued with no data bytes following it then all
blink processes using the current drawing color as the blink-
from color will be terminated. When all blink processes for
a given blink-from color are terminated, then the original
blink-from color will be restored.
If there are additional data bytes after the start
delay byte, then another blink command is started
implicitly. This new blink command will automatically
increment the palette entry number to use as the blink-from
color using the same algorithm as SET COLOR uses for
incrementing palette indexes. This incrementing does not
affect the drawing color.
The number of blink processes simultaneously active is
implementation dependent but should be at least 16.
POINT SET ABS - 24
This PDI sets the current drawing point to the
coordinates specified in last one of the following multi-
value operands. No point is drawn.
POINT SET REL - 25
This PDI sets the drawing point to the current drawing
point plus the displacement specified in the following multi-
value operand. This operation may be repeated for multiple
multi-value operands. No point is drawn.
POINT ABS - 26
This PDI sets the drawing point to the coordinates
specified in the following multi-value operand and draws a
logical pel at that point in the current drawing color.
Multiple points may be specified by transmitting more
coordinate pairs.
POINT REL - 27
This PDI sets the drawing point to the current drawing
point plus a displacement specified in the following multi-
value operand and draws a logical pel at that point in the
current drawing color. Multiple points may be specified by
transmitting more X,Y displacements.
LINE ABS - 28
This PDI draws a line in the current color from the
current drawing point to the end point specified in the
following multi-value operand. If more than one operand is
transmitted, lines will be drawn until there are no more
data bytes. The current drawing point is set to the last end
point. The thickness of the line is determined by the
logical pel size since the logical pel is used as a brush to
draw the line as in the example below.
_
/\/\
/ /\ \
/ / \ \
/ / \ \
|_/ \_|
LINE REL - 29
This PDI draws a line in the current color from the
current drawing point to a point specified by the X,Y
displacement in the following multi-value operand. If more
than one operand is transmitted, lines will be drawn until
there are no more displacements. The current drawing point
is set to the last end point.
SET & LINE ABS - 2A
This PDI is similar to LINE ABS except that the first
multivalue operand after the PDI is used to set the current
drawing point before drawing commences.
SET & LINE REL - 2B
This PDI is similar to LINE REL except that the first
multivalue operand after the PDI is used to set the current
drawing point before drawing commences.
Arc Drawing
The ARC PDI's are used to draw circles, circle segments
and curvilinear splines. Arcs are drawn from a start point,
through an intermediate point to an end point. The start and
end points are the same point, then the intermediate point
defines the diameter of a circle and a circle is drawn. If
more than 3 points are specified, then a curvilinear spline
is drawn. The minimal acceptable implementation according to
the standard is a straight line connecting all the end
points, but in this day and age a B-spline should be used. B-
splines are used in TrueType font outlines and can readily
be drawn using CAD programs, so B-spline support would be
useful for converting display typefaces and CAD drawings to
NAPLPS format. The maximum number of points in a spline is
implementation dependent but should be at least 256.
If the 3 points specified for an arc are collinear,
then a line is drawn from the start point to the end point.
If the end point is omitted, it is assumed to be the same as
the start point and a circle is drawn. After drawing the
arc, the current drawing point is set to the end point.
If an arc is filled, then the area between the arc and
the chord specified by the start and end points is filled
with the current colors and current fill pattern. The line
width of the chord is affected by the logical pel size, but
if the arc is outlined, the chord is NOT outlined.
There is a good reason why the chord is filled rather
that the pie segment and why only the circular portion of
the arc is outlined and not the chord. Firstly, a pie
segment is easily composed of a filled arc and a triangle
which have the chord line in common. It is possible to
construct curved objects more efficiently by drawing several
end-to-end filled arcs and an interior polygon which
connects the chords of those arcs (see cloud in the BYTE
sample). If this object is to be outlined, you would not
want the chord lines to be visible but you would want the
curved portions to be visible. The alternative is to draw a
polygon with many short line segments to approximate the
curves but that takes many more bytes and is less efficient.
Remember, most of the world still runs on 2400 bps modems.
Well designed NAPLPS images can be transmitted quite
reasonably at that speed.
ARC OUTLINED - 2C
This PDI draws an unfilled arc in the current drawing
color. The start point is the current drawing point. Only
the intermediate and end points are specified in the
following multi-value operands.
ARC FILLED - 2D
This PDI is the same as ARC OUTLINED except that the
start and end points are joined by a chord in the current
drawing color and the arc is filled with the current color
and fill pattern. If the TEXTURE settings specified that
outlines should be drawn, only the curved part of the arc is
drawn in the background color.
SET & ARC OUTLINED - 2E
This PDI is the same as ARC OUTLINED except that the
first multi-value operand sets the current drawing point.
SET & ARC FILLED - 2F
This PDI is the same as ARC FILLED except that the
first multi-value operand sets the current drawing point.
Rectangle Drawing
The rectangle commands draw rectangles of a specified
width and height. After the rectangle is drawn the endpoint
is displaced from the starting point by the width only. This
facilitates drawing bar charts along a baseline. If
additional data bytes follow a rectangle command, they are
interpreted as additional width and height specifications
for additional rectangles.
RECT OUTLINED - 30
This PDI draws an unfilled rectangle in the current
drawing color starting at the current drawing point.
RECT FILLED - 31
This PDI draws a filled rectangle starting at the
current drawing point. The fill is done with the current
drawing color and fill pattern.
SET & RECT OUTLINED - 32
This PDI is the same as RECT OUTLINED except that the
current drawing point is set by the first multi-value
operand.
SET & RECT FILLED - 33
This PDI is the same as RECT FILLED except that the
current drawing point is set by the first multi-value
operand.
Polygon Drawing
The polygon command is used to draw filled and unfilled
polygons. The polygon is defined as a series of
displacements from a starting point. The last point in a
polygon is implicitly the same as the starting point to
ensure that it is closed. The drawing point is unchanged
after drawing a polygon.
The number of vertices allowed in a polygon is
implementation dependent but should be at least 256.
POLY OUTLINED - 34
This PDI draws a polygon starting at the current
drawing point.
POLY FILLED - 35
This PDI draws a filled polygon starting at the current
drawing point.
SET & POLY OUTLINED - 36
This PDI is the same as POLY OUTLINED except that it
sets the current drawing point first.
SET & POLY FILLED- 37
This PDI is the same as POLY FILLED except that it sets
the current drawing point first.
FIELD - 38
This PDI defines the active field position and
dimensions. The active field is used for displaying and
scrolling columnar or wordwrapped text, for setting up
unprotected input fields and for displaying bitmapped
images. If there is already an active field, it will be
replaced by this new active field.
The first parameter after the PDI is the origin of the
field in absolute coordinates. The second multi-value
operand, gives the width and height of the field. If the
width or height are negative, then the origin point of the
field will not be in the lower left corner. This is handled
the same way as the logical pel size under the DOMAIN PDI.
The current drawing point is set to the field origin point.
If there are no multivalue operands after the FIELD PDI,
then the active field is set to the default setting of the
full unit screen with the origin at (0,0). If there is only
one multi-value operand, then it is used as the field
dimensions and the current drawing point will be used as the
origin point.
INCREMENTAL POINT - 39
This PDI displays a color bitmap within the active
field. Each pixel specified in the bitmap is drawn by one
logical pel using the color specified in the bitmap. In
color mode 0, the colors are explicitly specified as RGB
values. In modes 1 and 2, they are palette entries. The
color settings or selections caused by the incremental point
command have exactly the same effect on the graphics
environment as a SET COLOR (mode 0) or SELECT COLOR (mode 1
& 2) command including side effects dealing with palette
entries.
The active field is important as it bounds the bitmap
and determines the number of pixels or pels per line in the
bitmap. Pels are displayed starting at the current drawing
point. After drawing the pel, the drawing point is displaced
in the X direction by an amount equal to the width of the
logical pel. Positive widths move right, and negative ones
move left. At this point, if the new position of the logical
pel causes it to overlap the active field boundaries, then
two things happen. First, any remaining bits in the current
data byte are discarded. Then, if there are any more data
bytes, the drawing point is repositioned at the boundary
opposite the overlapping one (like a carriage return). If it
is possible to displace the logical pel in the Y direction
without overlapping the field boundary, then this is done,
otherwise, the Y position is unchanged but the entire field
contents are scrolled in the opposite direction. Positive
pel heights move up but scroll down, negative heights
reverse the directions. After the repositioning is
completed, the next pel is drawn.
Once the last pel has been drawn, the current drawing
point is set back to the field origin.
The first byte following the INCREMENTAL POINT PDI is a
fixed format parameter that describes the number of bits per
pixel that are used to specify the pixel color or the
palette entry. This number ranges from 1 to 48. If it is 0
or if it is greater than 48, then the entire PDI is
discarded. The following data bytes are a bitstring
consisting of bits 6 through 1 of each data byte. In color
mode 0 the number of bits equal to the packing count are
arranged GRBGRBG...BGRB. These are to be extracted and
interpreted as RGB colors in the same way as the multi-value
color operands used by SET COLOR. Note that if the packing
count is not a multiple of 3, then there will not be the
same number of bits for each of the three primary colors.
For instance, with a packing count of 5, the bit string
would be GRBGRGRBGRGRBGR...
^ ^ note that Blue is not specified
In modes 1 and 2, the bitstring consists of palette
indexes concatenated together.
In some cases it will be necessary to rescale either
the logical pel dimensions and the active field dimensions
in order to ensure that both of them are integer multiples
or integer fractions of the physical pixel dimensions. If
this scaling is done, then the original unscaled values for
both the active field and the logical pel are restored after
the INCREMENTAL POINT PDI has completed. This scaling must
ensure that the resulting bitmap image is guaranteed to lie
within the ORIGINAL active field and that skewing of the
image does not occur. This means that the new dimensions
must display the same number of pels per line as the
original ones. It also means that the rescaled bitmap will
be smaller than the actual specified field size.
If any portion of the logical pel for the initial
drawing point lies outside the active field, then the entire
PDI is discarded. If either width or height of the current
logical pel is equal to zero, then for the duration of the
INCREMENTAL POINT PDI, it is set to the smallest value
possible within the current DOMAIN.
INCREMENTAL LINE - 3A
This PDI defines a scribble which is an efficient
representation for certain types of polylines such as a
signature. The line segments in the scribble are drawn with
the current color and line texture.
The first operand is a multi-value operand which
specifies the step-size as separate x and y displacements
referred to as dx and dy. Following this, the data bytes
define a bitstring consisting of a series of 2 bit opcodes
as follows:
00 makes the following opcode one of:
00 toggle the draw flag
01 reverse the sign of dx
10 reverse the sign of dy
11 reverse the sign of dx and dy
01 move the drawing point dx in the x direction
10 move the drawing point dy in the y direction
11 move the drawing point dx in the x direction
and dy in the y direction
If the draw flag is on, each of the move instructions causes
a line segment to be drawn from the current point to the new
point. When the INCREMENTAL LINE starts, the draw flag is on
unless it is turned off explicitly. The current drawing
point is set to the last point in the scribble.
INCREMENTAL POLY FILLED - 3B
This PDI is almost identical to the INCREMENTAL LINE,
except as follows:
1. The scribble is filled with the current colors and
fill pattern.
2. the draw flag is always on
3. If an opcode to turn off the draw flag is
encountered, it is skipped.
4. The final drawing point is implicitly the same
as the starting point to ensure closure.
5. the maximum number of nodes allowed is the same
as for the polygon PDI's.
The Mosaic set
Overview
This G-set consists of 65 2x3 block mosaic characters
and 31 <space> characters. The mosaic range from 20 to 3F
and from 60 to 7F and a special one at 5F. The bit pattern
of the character code determines the bit pattern of the
mosaic character:
7 6 5 4 3 2 1
---------------
| |1| | | | | | data byte
---------------
-----
|1|2|
----- 2 x 3
|3|4| Mosaic cell
-----
|5|7|
-----
One bits in the data byte cause the corresponding mosaic
cell to be visible. If you want to see what they look like,
use MGE or get a copy of the official standards document or
look in the February 1983 issue of BYTE magazine.
Mosaic characters are normally displayed in contiguous
mode so as to create the effect of a monochrome bitmap.
However, when text underline mode is on, they are displayed
as separated with no actual underscore. In contiguous mode,
the mosaic cell size is determined by dividing the character
field into six equal rectangles. In separated mode, the
character field size is reduced in width by the width of a
logical pel and reduced in height by the height of a logical
pel before subdividing into six equal rectangular parts. The
scaled down mosaic characters are left and bottom justified
within the character field. If either dimension of the
logical pel is greater than the corresponding character
field dimension, then the mosaics are invisible in separated
mode.
Mosaic code 20 is not subject to underlining and
mosaics are never proportionally spaced. The mosaic
displayed by code 5F is the same as 7F
The Macro Set
Overview
This set contains 96 codes which can be used to define
and invoke macro. A macro is simply a stream of NAPLPS bytes
that are captured by the terminal program and assigned to a
code in the macro set. They may be buffered in RAM or on
disk as desired by the implementor. Once the macro is
defined, it can be recalled by invoking the macro set and
transmitting the single byte code for the macro. Macros can
also be recalled within the definition of another macro, so
it is necessary for the terminal program to beware of
infinite macro loops.
There are three control codes which define a macro (DEF
MACRO, DEFP MACRO, and DEFT MACRO). Any of these macros may
be linked to a user input such as a function key or mouse
click so that it may be activated or transmitted by the
user.
Macro expansion can occur in odd places, such as in the
middle of a PDI's data bytes, so be careful.
Dynamically Redefinable Character Set
Overview
This G-set is a character set that may be defined and
redefined by the host system transmitting the NAPLPS codes.
This could be used simply for a different looking font, or
it could be used to enable use of NAPLPS with a non-Latin
based language such as Russian, Thai or Inuktitut. The 96
codes in the DRCS are treated as <space> until they are
explicitly defined by a DEF DRCS control command. When these
codes are displayed they are subject to the same features
and limitations as alphanumeric text.
Character Field Layout
When defining characters for a DRCS, one should take
certain factors into consideration when planning the
character field layout. Remember, that the entire character
shape must lie 100% within the character field including
descenders and accents. The characters should be designed
with a baseline that is offset far enough from the bottom of
the character field to leave room for descenders and the
underline which is drawn at the bottom of the character
field. Approximately 20% of the character field height is a
good starting point. Similarly, the maximum character height
should be offset below the top of the character field to
leave enough room for accents to be placed on the
characters. Approximately 10% of the character field height
is a good starting point. In addition, a small allowance
should be made on the left and right of the character field
to provide an intercharacter spacing. If it is not possible
to leave space on both sides, then put the space on the
right of the character. Of course, there may be times when
some or all of these rules may be broken, but they should be
understood first, and then only broken for a reason.
C-Sets
C0 Control Set
These are the normal ASCII control characters. Note
that this specification defines what happens when the codes
are received in the NAPLPS data stream. This is not
necessarily the same behavior as when these codes are
received from the keyboard, and in fact, it is up to the
implementor to decide how to handle keystrokes. Keystrokes
are not part of the NAPLPS spec.
Any specifications that deal with what to do with the
character field and cursor position and the active field,
when the active field boundaries are crossed, only take
place if the character field in it's original position is
wholly within the active field. If it is not wholly within
the active field, then the same processing takes place, but
with reference to the entire display area.
Backspace - 08
This code moves the cursor a parallel to the character
path but in a direction opposite from the normal character
advance and by a displacement equal to the normal character
advance. If the new cursor position is wholly or partially
outside of the active field or the display area, then the
cursor is moved to the opposite edge of the field and a
<vertical tab> is executed.
Tab - 09
This moves the cursor in an opposite direction but in a
similar manner to <backspace>.
Line Feed - 0A
This moves the cursor perpendicular to the character
path and by a displacement equal to the interrow spacing. If
the new character field position is wholly or partially
outside of the active field, then one of two things happens.
If scroll mode is active, the character field stays at its
old position and the active field is scrolled in a direction
opposite to the intended cursor movement. If scroll mode is
off, then the character field is positioned at the opposite
boundary of the active field.
Cursor Position - 1C
The two bytes following this control code represent a
row and column address to which the cursor is positioned.
The row address is decoded by taking bits 7 through 1 of the
first byte and subtracting 32. The column address is
obtained from the second byte in the same way. This gives a
range from 0 through 95 inclusive. If either of the 2 bytes
following the 1C is from the C0 or C1 sets, then the entire
sequence is discarded. NOTE that row 0, column 0 is in the
lower left corner of the display screen (Cartesian
coordinates).
Vertical Tab - 0B
This moves the cursor in an opposite direction but in a
similar manner to <linefeed>.
Clear Screen - 0C
This moves the cursor to the upper left character
position on the display and clears the screen. In color
modes 0 and 1, the screen is cleared to nominal black, in
mode 2 it is cleared to the background color.
Carriage Return - 0D
This moves the to the first character position in the
active field that is on the character path.
Home - 1E
This moves the cursor to the upper left character
position on the display.
Shift-Out - 0E
This invokes the G1 set into the GL which makes it
available as ASCII codes 20 through 7F.
Shift-In - 0F
This invokes the G0 set into the GL which makes it
available as ASCII codes 20 through 7F.
Single-Shift-2 - 19
This invokes the G2 set into the GL which makes it
available as ASCII codes 20 through 7F. This shift only
affects the byte immediately following the 19 code after
which the GL is restored to its former contents.
Single-Shift-3 - 1D
This invokes the G3 set into the GL which makes it
available as ASCII codes 20 through 7F. This shift only
affects the byte immediately following the 19 code after
which the GL is restored to its former contents.
Escape - 1B
This code is used to start various escape sequences
which are documented elsewhere.
Transmission Control
The codes SOH(01), STX(02), ETX(03), EOT(04), ENQ(05),
ACK(06), DLE(10), NAK(15), SYN(16), and ETB(17) are reserved
for use at other layers of the OSI model. If they do make it
through to the presentation layer, then they are ignored and
have no effect whatsoever. In the OSI model, these codes
would be used in lower layers to implement error-free
transmission of data packets with some type of network
handshaking protocol.
Device Control
The codes DC1(11), DC2(12), DC3(13), and DC4(14) are
also reserved for use of other layers of the OSI model. They
are ignored if they appear in the NAPLPS data stream.
Null - 00
This code is used at other layers of the OSI model. It
is ignored if encountered in the NAPLPS data stream.
Bell - 07
This code is used to beep or make some other audible
sound which is implementation dependent.
Cancel - 18
This code is used to terminate the processing of all
currently executing macros. Execution resumes at the next
code following the terminated macro call. The CAN code is
not queued, it has an immediate effect even if there are
other NAPLPS codes in a buffer which have not yet been
processed.
Service Delimiter - 1A
This code is discarded if encountered in the NAPLPS
data stream. It is intended to act as a delimiter for the
transmission of unprotected field contents back to the host
system. The full format is as follows:
NSR - begins the transmission
DOMAIN - only required if the domain settings are
different from the default.
FIELD - marks the beginning of the field contents. The
field coordinates are used to identify the
field.
TEXT - only required if the text size is different
from the default
POINT SET - only if required to locate the first
character position in the field.
SELECT COLOR - only when the text color changes. If
mode 0, then use SET COLOR.
Character codes including code set changes to use
supplementary, mosaics, DRCS. May also include control
codes for cursor positioning and repeat codes.
END - marks the end of each field.
The sequence between FIELD and END is repeated for
each unprotected field being transmitted.
POINT SET - tell the host where the current drawing
point is.
Service Delimiter - marks the end of transmission
This facility is akin to a dialog box. The host uses
NAPLPS to draw the screen and define unprotected fields. The
host can also transmit text into the unprotected fields and
the terminal program should store that text and allow the
user to edit it. Then upon receiving some keystroke or mouse
click, the terminal program will transmit the edited
contents of all unprotected fields back to the host. The
only characters guaranteed to be transmitted are those in
the ASCII, supplementary, mosaic and DRCS sets. This
facility is modeled upon that provided by block-mode
terminals.
If the terminal program allows arbitrary NAPLPS
sequences to be entered into unprotected fields, then that
facility can be used to implement graphical e-mail. The user
uses a mouse to draw images in the unprotected field along
with any text they type. The entire sequence of NAPLPS codes
required to redraw the same image on another person's screen
is recorded and transmitted back to the host system when the
user requests the fields to be sent by pressing a key or
clicking somewhere. If the user has a pen input device such
as a graphics tablet, they could even create handwritten
messages using the NAPLPS scribble PDI (INCREMENTAL LINE).
Unprotected fields which have NOT been changed, need
not be transmitted back to the host. If no fields are
changed and the transmission is initiated, then the minimum
transmission consists of the NSR, DOMAIN, POINT SET, and
Service Delimiter. Users can only edit unprotected fields
when the text cursor is on (visible).
NSR - 1F
Non-Selective Reset is used to reset most of the
environment settings to their default state as follows:
The G0, G1, G2, G3, C0 and C1 sets are reset to have
their default initial contents and the GL and GR are also
reset to their initial state.
The DOMAIN parameters are set to the default as
specified earlier in this document.
Any text settings from the TEXT PDI or from the C1 set
are reset to the default. In addition the active field is
set to the default of the unit screen.
Any TEXTURE parameters are set to the default, but the
programmable fill patterns are NO cleared.
The color mode is set to mode 0 and the current drawing
color is set to nominal white, however the color palette is
NOT cleared
If the two bytes immediately after 1F are between 40
and 7F, then the cursor is repositioned. The row number is
taken from bits 6 through 1 of the first byte, the column
address is from bits 6 through 1 of the second byte. Row 0,
column 0 is the upper left corner of the display. The actual
character position is constrained to be within the display
area even if the row column address extends beyond this
area.
NOTE: cursor positioning by the NSR code is NOT THE
SAME as cursor positioning via the CURSOR POSITION code 1C.
They use a different origin, and the NSR positioning takes
place AFTER the text parameters are reset to the default.
Because of this it is usually NOT POSSIBLE for NSR character
positioning to register properly with that of code 1C.
C1 Control Set
These are additional control codes which are used for
NAPLPS specific operations. There is a bit of complexity
involving the use of the C1 set in 7-bit mode. Because of
the need to ensure that the normal ASCII control characters
are still available (some are used outside of NAPLPS), it is
not possible to replace the C0 set with the C1 set.
Therefore, in 7 bit mode, the C1 set is placed in the middle
of the GL area from 40 through 5F and a C1 code is invoked
by preceding it with an ESC (1B) code. This means that the
GL area can still be used as normal for PDI's, ASCII text or
whatever, since C1 codes must be escaped. In 8 bit mode,
there is no conflict as the C1 set is always available at
the beginning of the upper 128 character codes from 80
through 9F. There is no shifting or escaping required in 8
bit mode.
In this section, the eight bit codes are given for the
C1 set. They can be converted to 7 bit codes by swapping
bits 8 and 7.
DEF MACRO - 80
This code is used to begin macro definition. The byte
following the DEF MACRO must be between 20 and 7F. It is the
macro number which is being defined or replaced. If the
second byte is not within this range, then the two bytes are
discarded and decoding begins with the next byte.
All characters after the macro number are recorded but
not executed up to the macro termination. The termination is
indicated by receipt of another DEF MACRO or one of DEFP
MACRO, DEFT MACRO, DEF DRCS, DEF TEXTURE, or END. The
terminating control character is NOT stored and neither is
the preceding ESC which is transmitted on a 7-bit link.
If a macro reference is encountered during macro
definition, then the reference is stored as is. It is NOT
expanded at definition time. If the macro definition is
null, i.e. no definition bytes before the terminator, then
any existing macro with that number is deleted. All macros
are deleted by the RESET PDI.
It is NOT necessary to have the macro G-set currently
invoked in order to define a macro.
These macros (and DEFP macros) may be associated with a
keystroke or mouse click to be initiated by the user, but if
so, they are only available to be activated when the cursor
is on. Because the execution of these macros could place the
terminal program in an undetermined state, it is the
responsibility of the host system to restore the state of
the terminal program to a known state after the cursor is
turned off. The terminal program must ensure that any such
macro is executed to completion without being interleaved
with any incoming NAPLPS codes.
DEFP MACRO - 81
This command is the same as DEF MACRO except that the
stream of characters making up the macro definition are
executed as well as recorded. If a DEFP MACRO contains a
reference to the macro number that is being recorded, then
that reference should be treated as an undefined macro. This
also applies to nested references, i.e. while defining macro
1 with the DEFP MACRO, a reference to macro 2 is
encountered. Upon expanding macro 2 a reference to macro 1
is encountered. Because the definition of macro 1 is not yet
complete, macro 1 is treated as an undefined macro.
DEFT MACRO - 82
This command defines a transmit macro. This is a string
of bytes which is intended to be transmitted back to the
host computer. The data bytes in a DEFT MACRO are not
executed and are not necessarily NAPLPS data. They are only
useful if the terminal program provides some means of
causing the macro to be transmitted back to the host when a
function key or mouse click event occurs. This is similar to
defining a programmable function key except that the NAPLPS
spec doesn't deal directly with the keys. It would be up to
the terminal program to allow the user to associate a given
macro with a given key combination. The transmit macros must
always be available to the user for transmission, even when
the cursor is off.
The transmit macros use the same pool of 96 macro
numbers as do other macros. There is only 1 macro set.
Macros linked to keystrokes should be defined starting
with code 20 and macros that are not linked should be
defined in reverse order starting with code 7F. The terminal
program should provide at least 8 macros associated to
keystrokes. In my opinion, 12 is a better number for PC's as
there are 12 function keys available. In fact, the cluster
of INS,DEL,HOME,END,PGUP,PGDN and the 4 arrow keys should
also be associated with transmit macros.
DEF DRCS - 83
This command is used to define a DRCS character shape
in a manner similar to macro definition. If the byte
following DEF DRCS is between 20 and 7F it is used as the
code for the DRCS character to define or redefine. If the
code is not within the range then the DEF DRCS code and the
incorrect code are discarded.
Next comes a stream of NAPLPS data which is used to
define the shape of the DRCS character. This stream is
terminated by one of END, DEF MACRO, DEFP MACRO, DEFT MACRO,
DEF TEXTURE, or another DEF DRCS. The standard states that
the NAPLPS stream defining the character should be executed
as it is received, but is NOT displayed on the screen. It is
instead used to modify an in-memory bitmap which is used
later to display the DRCS character. It should also be
possible to store the NAPLPS stream as is done with macros,
and execute the stream at the time the DRCS character is to
be displayed. This would provide far better scalability of
the characters. You could also convert the NAPLPS stream
into a scalable format that is native to the graphical
environment you are using. This would allow somewhat faster
display when the DRCS is used. Note that you can use macros
and other DRCS characters as part of the definition
sequence.
All NAPLPS code received during DRCS definition will
have its usual effect on the state of the terminal program,
except that any drawing operations do NOT affect the display
area. However, things like palette changes WILL still be
visible as they are part of the global state. All these
state changes will remain in effect after DRCS definition is
finished.
When rendering the NAPLPS code into the in-memory
bitmap, the aspect ratio of the bitmap will be the same as
the character field dimensions in effect at the time the DEF
DRCS was received. The lower left corner of the bitmap will
correspond to the lower left corner of the unit screen. The
larger of the X and Y dimensions of the bitmap will be
considered to be equal to 1 unit (the full extent of the
unit screen in that dimension). Any changes to the character
field dimensions within a DRCS definition will not affect
this sizing but will effect the next DEF DRCS command. The
in-memory bitmap is a monochrome bitmap that is initially
all black. All drawing commands will be drawn in white on
the bitmap unless they are drawn with a nominal black color.
The actual resolution of this bitmap is implementation
independent. Although the standard does not suggest this, I
would think that on today's computer equipment, this
rendering should be delayed until the DRCS characters are
actually used, at which point the bitmap size should be
equal to the current character field size, and bitmap
characters should be cached for reuse.
Once the DRCS definition is completed, the unit screen
once again corresponds to the physical screen and the
current drawing point is set to (0,0).
If the DRCS definition is terminated by another DEF
DRCS command, then the character code to be defined is NOT
transmitted. It is calculated by incrementing the previous
character code and wrapping around so that 7F increments to
20. If a DEF DRCS command is terminated with no character
definition, then the character definition for that code is
reset to the default <space> character. The entire DRCS can
be cleared with the RESET PDI.
When a DRCS character is displayed, the rendered bitmap
is scaled to the current character filed dimensions and the
white portions of the bitmap are to be displayed in the
current drawing color. In color mode 2, the black portions
of the bitmap will also be displayed but in the current
background color. DRCS characters are subject to all the
attributes of text just as the ASCII set and supplementary
set.
I have gone a little further than the standard in
suggesting that the scaled bitmap method of displaying DRCS
characters is really not appropriate on today's computer
equipment. Since the ordinary text character shapes for the
ASCII and supplementary sets are not specified, most systems
will provide fully scalable fonts for those characters. If
the DRCS characters are not also handled in an equivalent
scalable manner, then they will not look very good.
DEF TEXTURE - 84
This defines or redefines one of the four programmable
pattern fills. The pattern mask A, B, C, or D is selected by
the byte following the DEF TEXTURE which must be one of 41,
42, 43 or 44. If the code is not one of these four, then the
2 bytes are discarded.
Next comes a stream of NAPLPS data which defines the
pattern mask in the same way as the DEF DRCS except that the
mask size defined in the TEXTURE PDI is used instead of the
character field size. The command is terminated by END, DEF
MACRO, DEFP MACRO, DEFT MACRO, DEF DRCS, or another DEF
TEXTURE.
If the INCREMENTAL POINT command is used in defining
the pattern, then be aware that the active field may be
rescaled as specified under the INCREMENTAL POINT PDI. This
rescaling will cause the actual area drawn by INCREMENTAL
POINT to be smaller than that specified.
If there is no data after the mask number, then the
specified mask is reset to its default state. At the end of
the DEF TEXTURE command, the unit screen is set back to the
physical display and the current drawing point is set back
to (0,0).
While the standard assumes that these pattern masks
will be stored as bitmaps and scaled as needed, I think it
would be useful to record them in the same scalealble manner
as I have suggested for the DRCS characters.
END - 85
This command terminates a DEF MACRO, DEFP MACRO, DEFT
MACRO, DEF DRCS or DEF TEXTURE. It is also used in
transmitting protected field data back to the host system.
UNPROTECT - 9F
This command turns the current active field into an
unprotected field. This makes the field area available for
the user to enter and edit data for transmission back to the
host system. The actual methods/keystrokes for entering and
editing data is implementation dependent. The default state
of the unit screen is protected, so no entry of data may
occur until an UNPROTECT is issued. If the UNPROTECT command
is received when the active field overlaps an already
unprotected field, then the unprotected field is changed to
protected before the active field is unprotected. This
ensures that unprotected fields never overlap. Changes in
the protection status do not affect the visible display.
The number of unprotected fields that may be defined is
implementation dependent but should be at least 40.
If the host transmits data into an unprotected field
that data will be recorded by the terminal program and will
be made available for the user to edit. Editing can only
take place if the unprotected field is also the active
field. The user can transmit the edited data back to the
host system by an implementation dependent keystroke or
mouse click. Details of the transmission format are defined
under "Service Delimiter" in the C0 set. When more than one
unprotected field is transmitted, they are transmitted from
left to right, top to bottom, using the field origin
coordinates to determine which is leftmost or topmost. The
transmission of data is to be handled independently of the
receiving of data, including any state changes made by the
user to text colors, character set, etc.
It is allowed to have other methods of user input that
are independent of the unprotected fields and that do not
affect the state of unprotected fields.
PROTECT - 90
This command causes any unprotected fields that overlap
the active field to be changed to a protected state. The
RESET PDI can be used to protect all unprotected fields.
REPEAT - 86
This command gets a repeat count from bits 6 through 1
of the byte following the REPEAT code and repeats the byte
preceding the REPEAT code, by that number of times. This
code can only be used to repeat <space> characters and any
spacing characters from the ASCII, supplementary, DRCS or
mosaic sets. This means that the non-spacing accents in the
supplementary set cannot be repeated. If the preceding
character is not one of those allowed, then the REPEAT code
and the count byte are discarded. If bits 7 through 1 of the
repeat count fall outside the range from 40 through 7F, then
the REPEAT code is discarded and the count byte is
interpreted as a normal NAPLPS code.
REPEAT TO EOL - 87
This command repeats the preceding byte as many times
as is required to reach the end of the current character
path if it is one of the allowed characters as for REPEAT.
Otherwise, the REPEAT TO EOL is discarded. If the character
field position lies wholly within the active field when this
command is received, then the character path will be
considered to end when it reaches (but does not pass) the
active field boundary.
REVERSE VIDEO - 88
This causes any following text from the ASCII,
supplementary, DRCS and mosaic sets to be drawn reversed. In
color modes 0 and 1, the pixels of the character shape are
not draw, only the background pixels are drawn using the
current drawing color. In color mode 2, the foreground and
background colors used are swapped. This will require
special handling to ensure that composite characters are
displayed correctly. Composite characters are composed of a
non-spacing accent followed by another character from the
ASCII set. The composite character codes must always be
transmitted in that order, accent first, then ASCII
character.
NORMAL VIDEO - 89
This terminates reverse video mode and returns to the
default.
Text Sizes
Text sizes can be set by the following commands or by
the TEXT PDI. The following commands effect only the
character field dimensions. All other text attributes remain
constant. The screen sizes quoted assume the default
rotation and character path is in effect.
SMALL TEXT - 8A
This sets the dimensions of the character field to 1/80
in the X dimension and 5/128 in the Y dimension. This
corresponds to an 80 by 19 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
MEDIUM TEXT - 8B
This sets the dimensions of the character field to 1/32
in the X dimension and 3/64 in the Y dimension. This
corresponds to a 32 by 15 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
NORMAL TEXT - 8C
This sets the dimensions of the character field to 1/40
in the X dimension and 5/128 in the Y dimension. This
corresponds to a 40 by 19 screen when accounting for the
fact that only 3/4 of the Y dimension is visible.
DOUBLE HEIGHT - 8D
This sets the dimensions of the character field to 1/40
in the X dimension and 5/64 in the Y dimension. This
corresponds to a 40 by 9 screen when accounting for the fact
that only 3/4 of the Y dimension is visible.
DOUBLE SIZE - 8F
This sets the dimensions of the character field to 1/20
in the X dimension and 5/64 in the Y dimension. This
corresponds to a 20 by 9 screen when accounting for the fact
that only 3/4 of the Y dimension is visible.
WORD WRAP ON - 95
Any text received after this code is word wrapped when
the line reaches the end of the character path. If the text
is being displayed in the active field, then word wrapping
takes place when the character path meets the active field
boundary. If a <space> character is the last character on
the line and the <space> character does not fit, then it is
simply discarded. A word is defined as a string of
characters between <space> characters. If one of the
following list of special characters is embedded within the
word (i.e. not at the beginning or end) then the word may be
broken AFTER the special character in order to fill the line
as much as possible.
! " $ % ( ) [ ] < > { } ^ * + - / , . : ; = ? _ ~
A word is also terminated when a mosaic character is
encountered or when any C set character (except SI, SO, SS2
, SS3) is encountered. If the word fills the line with no
spaces or special characters, then it is broken at the end
of the line anyway.
WORD WRAP OFF - 96
This turns off word wrap and text now breaks between
characters. This is the default.
SCROLL ON - 97
This turns on scroll mode. In this mode any <linefeed>
or <vertical tab> that would otherwise cause the character
field to move partially or wholly outside the display area,
triggers scrolling. The display scrolls in a direction
opposite to the direction of the <linefeed> or <vertical
tab> and only scrolls far enough so that the current
position of the character field is now wholly within the
display area. If the cursor movement command takes place
within the active field, then only the area within the
active field is scrolled. The blank area that scrolls into
view is nominal black in color modes 0 and 1, or the
background color in color mode 2.
Any buffering of data that is scrolled off the display
is implementation dependent.
SCROLL OFF - 98
This command turns off scrolling mode. If the text
cursor is advanced beyond the bounds of the display area (or
active field) by a <linefeed> or <vertical tab> then it
simply wraps to the opposite boundary.
UNDERLINE START - 99
` This command turns on underline mode. In this mode all
ASCII, supplementary, and DRCS characters and any <space>
character are displayed with a line. This line is drawn from
the character field origin across the entire width of the
character field but it does not go across the gaps created
by 5/4 and 3/2 character spacing. Its thickness is the
height of the logical pel. Mosaic characters are not
underlined, but are instead displayed in separated mode as
defined under the section "The Mosaic Set".
The underscore is then rotated along with the rest of
the character field if a rotation is specified.
UNDERLINE STOP - 9A
This terminates underline mode. In this mode, mosaics
are displayed contiguously so as to form a monochrome
bitmap.
FLASH CURSOR - 9B
This cause the cursor to blink. It also may enable user
input if the active field is in an unprotected field.
STEADY CURSOR - 9C
This cause the cursor to be displayed with no blinking.
It also may enable user input if the active field is in an
unprotected field.
CURSOR OFF - 9D
This sets the cursor to its default invisible mode. The
cursor still exists and can be positioned. This may also
disable user input, but that is implementation dependent.
BLINK START - 8E
This creates a simple blink process using the current
drawing color as the blink-from color and nominal black (the
background color in mode 2) as the blink-to color. The on
and off intervals are implementation dependent and the start
delay is zero. This is intended to provide a facility
similar to the ANSI graphics blinking found on PC's.
BLINK STOP - 9E
This terminates any blink process using the current
drawing color as the blink-from color.
EDC1, EDC2, EDC3, EDC4 - 91, 92, 93, 94
These codes are reserved for future use. At the present
time they should be discarded.
Proportional Spacing of Text
Overview
In order to guarantee the placement of text and the
positioning of line breaks on varying implementations of
NAPLPS at varying display resolutions, it is necessary to
have some guidelines as to how to produce proportionally
spaced text. If a terminal program adheres to these
guidelines, then a host system can place proportionally
spaced text onto the screen in a predictable manner.
An algorithm is provided which defines how far to move
the cursor if the character field width is parallel to the
character path. If it is not parallel, then proportional
spacing is not possible and the spacing is always based on
the full height of the character field. The spacing for the
widest characters is always equal to the character field
width, while the spacing for other characters is arranged so
that the visible gaps between characters are identical. The
algorithm is arranged so that normal size text will be
spaced identically on both low and high resolution
terminals.
Algorithms
The following tables classify the ASCII and
supplementary sets into 10 different width classes.
Characters in a given class are spaced according to the same
algorithm over the range of font sizes.
ASCII Width Classes
2 3 4 5 6 7
------------------------
0 9 5 9 5 1 5
1 0 1 5 6 5 5
2 4 5 5 5 5 5
3 6 5 5 5 5 5
4 9 5 5 9 5 2
5 9 5 5 5 5 5
6 9 5 5 9 5 9
7 0 5 8 9 5 9
8 1 5 5 9 5 9
9 1 5 2 9 0 5
A 9 0 5 9 4 5
B 9 3 5 4 5 5
C 3 5 5 9 0 0
D 5 8 9 4 9 5
E 0 5 5 2 5 9
F 9 8 9 9 5
Supplementary Width Classes
2 3 4 5 6 7
--------------------------------
0 9 4 9 5 6 9
1 0 9 2 1 9 9
2 9 4 2 9 6 6
3 5 4 2 9 5 5
4 9 7 9 9 9 6
5 9 6 5 6 9 0
6 9 9 5 9 9 4
7 6 0 0 9 5 4
8 9 9 4 9 9 7
9 1 1 9 9 9 9
A 6 6 1 9 9 9
B 8 8 7 9 5 6
C 9 9 9 9 5 4
D 7 9 4 9 9 2
E 9 9 8 9 6 5
F 7 8 2 9 9
The width class of an accented character is the maximum
width of the two components. Note that the <space> character
is always in the maximum width class. In proportional mode
<tab> and <backspace> are always considered to be in the
maximum width class (same as <space>) when they are received
from the host system.
The algorithm that determines the actual width of a
character is based upon the width class and the width of the
current fixed character field. This algorithm is intended to
make the interfont gap between all characters identical, so
when designing your implementation dependent font, you
should take this algorithm into consideration. The algorithm
is structured to ensure that smaller sizes of text appear
spaced identically in both low and high resolution video
displays.
TEXT SIZES up to (but not including) 12/256 wide
------------------------------------------------
width 0 1 2 3 4 5 6 7 8 9
------------------------------------------------
6 2 3 4 3 4 5 6 4 5 6
7 3 4 5 4 5 6 7 5 6 7
8 2 3 4 4 5 6 7 6 7 8
9 3 4 5 5 6 7 8 7 8 9
10 4 5 6 6 7 8 9 8 9 10
11 3 4 6 6 7 8 10 8 10 11
------------------------------------------------
12 6 5 4 4 3 2 1 2 1 0
The above table contains the cursor displacement to be
applied to characters in each width class at various
different character field widths. To determine which row to
use, take the character field width (which is a binary
fraction), multiply by 256 to get a number n.m/256, then
truncate the fractional portion of the number to find n. If
this result is less than 12, then use the corresponding row
in the table and scale the character displacement. For
instance, if the character field width is 15/512, then
multiply by 256 to get 8.5/256. Truncate to 8, therefore use
row 8 in the table. If the width class is 0 then the
character displacement is 2/256 which is the same as 2/8 of
the full displacement.
If the scaling result is greater than or equal to 12
then the 12 row is first scaled to determine the amount to
adjust the character displacement.
1. The character field width is truncated to DOMAIN 3
leaving the 8 most significant bits. Call this n.
2. Multiply n by 11/13 being careful to avoid overflow.
3. Subtract 1/256 from the result, then bitwise OR the
result with 1/256 and again subtract 1/256 from the
result. Truncate this final result to DOMAIN 3, i.e.
to 8 bits. This is the scale factor f. This step
causes the font patterns for the widest character
class to be scaled to an odd width.
4. Get the unit spacing number from the 12 row for the
appropriate width class.
5. Multiply this unit spacing by f.
6. Divide the result by 6, then add 1/512 for rounding,
then truncate to DOMAIN 3 leaving the 8 most
significant bits. Subtract this result from n to get
the actual cursor displacement amount.
For example, a character in width class 0 using a character
field with of 12/256.
1. 12/256 is already an 8-bit value so it is n.
2. Multiply by 11 and divide by 13 to get a 16 bit
number = 2599.
3. Result 2087 scaled down to 8 bits = 8.
4. Use 6.
5. 6 * 8 = 48, divide by 6 to get 8, add .5 and round
down to 8. Subtract 8 from 12 to get a displacement
of 4/256.
Similarly, if the field width is 24/256, then the
displacement would be 6/256. This is a very tricky part of
the standard to follow and it leaves a lot to be assumed
such as 8 bit numbers being multiplied or divided into a 16
bit register. I hope that I got it right.
Ideas and Implementations
Terminal Programs
I have come across several terminal programs that
support NAPLPS on the PC and one that supports NAPLPS on
Amiga and Macintosh computers.
PP3 (Personality Plus III) SHAREWARE
This is the only terminal program I know that fully supports
all of NAPLPS including bitmaps and DRCS characters. It is
available in English and French versions which use a user
customizable language file so it is easy to provide support
for other languages. Supports CGA, Herc mono, EGA, MCGA,
VGA, ET4000-256, TARGA-16. Basic registration fee is $25
while $40 gets you a printed manual and info on other NAPLPS
products and services.
CTLINK
Hmmm. I seem to have deleted this one. I had some problems
with it (which may have been the modem) but I remember that
it was really oriented as a terminal for commercial videotex
services. I read some comments from Dave Hughes that
indicated it is not a complete implementation, but if you
see it around, why not try it for yourself.
Tam Tam COMMERCIAL
This program is available from MacGregor Inc. in Montreal
for the Amiga and the Macintosh in both English and French
versions. The price was $79-$99 depending on which version
but I have lost my info sheet. Just call directory
assistance to get a hold of them. They do speak English just
fine, so don't be shy.
Drawing Programs
To date, I know of only one shareware drawing program
that supports NAPLPS. There are other commercial programs
but I don't yet have any info on them. In addition, I have
written a program to convert Windows 3 icons to NAPLPS
format and have a beta version of a program to convert
metafiles created by CorelDraw into NAPLPS format. The Memra
logo in the sample file MEMRA2.NAP was converted from an
original CorelDraw image.
MGE (Microstar Graphics Editor) SHAREWARE
This is an object oriented drawing (not painting) program
from Microstar Inc. that uses NAPLPS as its file format. It
can draw all the basic objects as well as providing control
over text. It can define macros, fields and blinks. If using
the VGA 16 or 256 color drivers, you can customize the
palette. This is an important feature of NAPLPS. It is not
restricted to the default DOS/Windows 16 color palette. On a
standard VGA you can display any 16 out of the 262,000
shades it is capable of displaying. Notable omissions are
NAPLPS bitmaps and DRCS characters. Microsoft compatible
mouse required (or a graphics tablet that emulates a
Microsoft mouse). This is a good program that is often
criticized because its interface is not 100% the same as
Windows, however if you do PRINT OUT the README.MGE file and
keep it by your side while you draw, you will find that this
program is every bit as effective as CorelDraw and a much
better deal. Supports CGA, Herc mono, EGA, MCGA, VGA, ET4000-
256, TARGA-16. Basic registration fee is $50 while $75 will
get you a printed copy of the manual and info on other
NAPLPS products and services.
Teledraw COMMERCIAL
This program is being developed by Dave Hughes in
conjunction with a team of programmers in Russia. He has
working beta versions and is expected to release the program
by the end of April 1993. This program will provide full
NAPLPS support including the design and use of DRCS
characters such as the Russian characters used in
SAIL.NAP. This program is a combination drawing/terminal
program that will decode NAPLPS images in electronic mail on
the fly and will allow you to draw or edit images and
transmit them in electronic mail messages.
NAPICO SHAREWARE
This program from Memra Software Inc. is intended to enhance
NAPLPS images created with MGE by adding Windows icons to
the image. The icon positions are marked with a small
rectangle and NAPICO takes a list of Windows 3 .ICO files
and inserts the icon bitmap into those marked positions. The
use of SMALL bitmaps like these icons can really enhance a
NAPLPS image. A $10 registration fee is requested from those
who can afford it.
NAPWMF SHAREWARE
This program from Memra Software Inc. converts Windows
metafiles that are created using CorelDraw's File Export
function. It does not necessarily work with metafiles from
other programs, although full .WMF support will be included
in a future version. This makes it possible to add a wide
range of clipart images and True Type fonts to a NAPLPS
image. See the Memra logo in MEMRA2.NAP that was produced by
a beta version of this program. The images produced by
version 1.0 won't be quite as big.
TURSHOW SHAREWARE
This program doesn't fit under either category. It simply
displays the NAPLPS images on your CGA, EGA or VGA screen.
Clip Art libraries
I would like to see people put together libraries of
non-copyrighted clipart for use by others. Note that this
means the images must be original art, not converted from a
commercial clipart library. As soon as I get NAPWMF
released, I will be creating a library of electrical symbols
for use in drawing circuits.
ANSI compatibility
It should be possible for a terminal program to
simultaneously support both NAPLPS and the ANSI-BBS protocol
simultaneously. Because of a conflict with the FLASH CURSOR
command, it is not possible to arbitrarily interleave ANSI
and NAPLPS data streams but it should be possible to support
both code systems in a non-interleaved manner. The NAPLPS
spec uses the 3 character sequence ESC 25 41 to indicate
that NAPLPS decoding is to be turned ON and the sequence ESC
25 40 turns OFF the NAPLPS decoding. Outside of this
bracketing, it should be possible to support ANSI escape
sequences. It is fairly straightforward for sysops to ensure
that the ON/OFF sequences are transmitted, especially if
they are using Microstar's SHOWPLP utility.
User Interaction
Although NAPLPS provides facilities for user
interaction in the form of unprotected fields, the cursor
and transmit macros, it does not require that those
facilities be used when there is an application layer
protocol for handling such things. I would like to suggest
that the general BBS and NAPLPS community should agree on a
standard way for handling such user interactions that would
allow mouse and keyboard support in a non hardware dependent
manner.
As for mice and other pointing devices, I would like to
suggest that the terminal program transmit a POINT SET ABS
(code 24) PDI to the BBS using the currently set domain co-
ordinates to indicate a mouse click followed by some code to
indicate whether it was a button-down or button-up event and
which button it was. A POINT SET REL could be transmitted to
indicate a mouse move event.
For keyboard events (key-up and key-down) a form of the
PC scan-codes could be transmitted. These codes are also
used by certain UNIX terminals and similar events are
generated by Macintosh keyboards and X-Windows keyboards so
the only thing about these codes that is specific to the PC
is the actual code numbers.
There should probably be some indicator code
transmitted to distinguish between transmission of
unprotected fields and transmission of an event. Transmit
macros could, of course, be programmed to emulate either
events or unprotected field transmittal or anything else.
I would like comments on these ideas, please.
Level 6 vs. Level 7
It is important to remember that NAPLPS exists at the
presentation layer which is the 6th of the 7 OSI networking
levels. It is intended to be used as the foundation for
interactive on-line real-time graphical applications, which
are at the 7th OSI level. NAPLPS does not do everything and
it is not intended to do everything. I feel that it is
important for BBS operators and users to start discussions
on an overall standard for graphical BBS interchange, and I
would like to see NAPLPS as the foundation for the
presentation layer of that interchange. I would also like to
see any overall standards maintain the OSI division into 6
independent layers.
It may be appropriate to extend NAPLPS to include
additional G-sets and I know that there is already a JPEG
extension to NAPLPS being prepared for public release. Since
the BBS community is likely to be the major user of NAPLPS
over the next few years, we need to maintain a discussion of
this protocol and its implementations and suggestions for
extensions.
Resource List
I have put a lot of work into writing this document and
getting it widely distributed (worldwide). If you find it to
be of use and can afford to, I would appreciate receiving
$20 to help me continue to work on NAPLPS support.
Star Valley BBS 1-604-546-8022
- 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 (dave@oldcolo.com) operates an
Internet/BITNET/Fidonet NAPLPS mailing list
- about to release Teledraw a combination NAPLPS
drawing and terminal program
Le Muse 1-514-984-1297
- 2400 bps
- an experimental electronic gallery
- text in French
- includes a selection of children's art
The Gadget Zone 1-604-946-5815
- speeds up to v.32bis
- home of the ONLINE_GRAPHICS echo message area
- many NAPLPS related files
- Fidonet address 1:153/951
Harris Technology Associates BBS 1-508-877-7233
- NAPLPS software for TBBS systems
- many NAPLPS menus
- several NAPLPS games
- illustrated electronic books
Hi Res BBS 1-306-782-6820
- some sample bitmaps converted to NAPLPS with a
commercial .PCX conversion program
- full NAPLPS support (running Turboard)
- sysop Warren Zatwarniski
- Fidonet 1:140/111
Online Acess magazine
the Summer 1992 has an article about several on-line
NAPLPS art galleries. It includes several wonderful
photos of sample NAPLPS artwork captured from a low-
resolution 16-color video display
BoardWatch magazine
The December 1992 issue has an article on NAPLPS
support by several BBS systems. It includes 6 color
photos of NAPLPS screens.
Byte magazine
There was a series of 4 articles (55 pages in total)
explaining much of the NAPLPS coding system and
discussing the potential for NAPLPS. These articles
were in the February, March, April and May 1983 issues.
In the 2nd article, a small NAPLPS image is decoded and
explained in detail. To recreate that image, cut out
the following lines between the dashed ones and place
in a file named BYTE.SCR. Then type DEBUG <BYTE.SCR
This will create the image in a file called BYTE.NAP.
If you are not using a PC, then you will have to find
some other means of entering the hex codes into a
document file. Note the picture will display in PP3 but
is not editable in MGE. If you create BPREF.NAP and
prepend it to the image by typing:
COPY BPREF.NAP+BYTE.NAP BEDIT.NAP
then you will create an editable version of the same
image which will actually look more like the original
as far as line thickness and line texture.
---------8X----cut here-------------BYTE.SCR follows---
E 100 E 3C 49 20 50 3C 64 23
E 108 40 37 49 60 40 48 60 40
E 110 48 42 40 46 46 40 60 40
E 118 40 40 46 47 40 6A 60 3C
E 120 52 23 44 24 48 57 44 31
E 128 40 7C 40 25 78 44 60 3C
E 130 40 35 40 61 47 47 66 41
E 138 25 47 55 64 F 48 6F 75
E 140 73 65 E 3C 6D 24 42 68
E 148 47 F 42 49 52 44 53 E
E 150 2F 41 77 50 47 47 64 47
E 158 47 54 2D 40 40 54 40 40
E 160 76 23 40 25 40 49 4A 2D
E 168 47 47 64 47 47 54 2D 40
E 170 40 54 40 40 76 24 52 70
E 178 3C 7F 2D 78 78 66 40 48
E 180 5B 2D 40 48 47 47 47 75
E 188 2D 40 51 49 47 45 44 2D
E 190 7F 6F 5B 78 68 7B 35 40
E 198 41 79 40 48 74 47 56 4D
E 1A0 25 78 62 54 F 43 4C 4F
E 1A8 55 44 E 3C 6D 25 47 44
E 1B0 6A 23 42 29 7F 75 74 25
E 1B8 40 52 62 23 41 29 7F 75
E 1C0 74 23 40 25 40 52 67 29
E 1C8 7F 75 74 25 40 52 60 22
E 1D0 4C F 52 41 49 4E E 22
E 1D8 40 3C 40 24 40 40 40 35
E 1E0 50 46 42 40 51 66 40 50
E 1E8 60 7F 6D 76 77 62 72 24
E 1F0 50 42 44 F 52 4F 41 44
E 1F8 E 22 40 40 40 4A 64 24
E 200 4A 45 47 F 46 69 67 75
E 208 72 65 20 31 E 3C 76 24
E 210 42 7E 78 F 46 69 67 75
E 218 72 65 20 31 0
N byte.nap
RCX
11E
W
Q
---------8X----cut here-------BPREF.SCR follows----
E 100 E 20 7F 4F 21 48 40 40
E 108 49 3E
N bpref.nap
RCX
A
W
Q
---------8X----cut here---------------------------
Reference in New Issue View Git Blame Copy Permalink