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 and . The code is therefore available in both the ASCII and supplementary character sets. The 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 ) - 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 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 , or 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 or 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 is executed. If, by chance, a 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 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 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 is executed. Tab - 09 This moves the cursor in an opposite direction but in a similar manner to . 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 . 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 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 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 character is the last character on the line and the character does not fit, then it is simply discarded. A word is defined as a string of characters between 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 or 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 or 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 or 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 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 character is always in the maximum width class. In proportional mode and are always considered to be in the maximum width class (same as ) when they are received from the host system. The algorithm that determines the actual width of a character is based upon the width class and the width of the current fixed character field. This algorithm is intended to make the interfont gap between all characters identical, so when designing your implementation dependent font, you should take this algorithm into consideration. The algorithm is structured to ensure that smaller sizes of text appear spaced identically in both low and high resolution video displays. TEXT SIZES up to (but not including) 12/256 wide ------------------------------------------------ width 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------ 6 2 3 4 3 4 5 6 4 5 6 7 3 4 5 4 5 6 7 5 6 7 8 2 3 4 4 5 6 7 6 7 8 9 3 4 5 5 6 7 8 7 8 9 10 4 5 6 6 7 8 9 8 9 10 11 3 4 6 6 7 8 10 8 10 11 ------------------------------------------------ 12 6 5 4 4 3 2 1 2 1 0 The above table contains the cursor displacement to be applied to characters in each width class at various different character field widths. To determine which row to use, take the character field width (which is a binary fraction), multiply by 256 to get a number n.m/256, then truncate the fractional portion of the number to find n. If this result is less than 12, then use the corresponding row in the table and scale the character displacement. For instance, if the character field width is 15/512, then multiply by 256 to get 8.5/256. Truncate to 8, therefore use row 8 in the table. If the width class is 0 then the character displacement is 2/256 which is the same as 2/8 of the full displacement. If the scaling result is greater than or equal to 12 then the 12 row is first scaled to determine the amount to adjust the character displacement. 1. The character field width is truncated to DOMAIN 3 leaving the 8 most significant bits. Call this n. 2. Multiply n by 11/13 being careful to avoid overflow. 3. Subtract 1/256 from the result, then bitwise OR the result with 1/256 and again subtract 1/256 from the result. Truncate this final result to DOMAIN 3, i.e. to 8 bits. This is the scale factor f. This step causes the font patterns for the widest character class to be scaled to an odd width. 4. Get the unit spacing number from the 12 row for the appropriate width class. 5. Multiply this unit spacing by f. 6. Divide the result by 6, then add 1/512 for rounding, then truncate to DOMAIN 3 leaving the 8 most significant bits. Subtract this result from n to get the actual cursor displacement amount. For example, a character in width class 0 using a character field with of 12/256. 1. 12/256 is already an 8-bit value so it is n. 2. Multiply by 11 and divide by 13 to get a 16 bit number = 2599. 3. Result 2087 scaled down to 8 bits = 8. 4. Use 6. 5. 6 * 8 = 48, divide by 6 to get 8, add .5 and round down to 8. Subtract 8 from 12 to get a displacement of 4/256. Similarly, if the field width is 24/256, then the displacement would be 6/256. This is a very tricky part of the standard to follow and it leaves a lot to be assumed such as 8 bit numbers being multiplied or divided into a 16 bit register. I hope that I got it right. Ideas and Implementations Terminal Programs I have come across several terminal programs that support NAPLPS on the PC and one that supports NAPLPS on Amiga and Macintosh computers. PP3 (Personality Plus III) SHAREWARE This is the only terminal program I know that fully supports all of NAPLPS including bitmaps and DRCS characters. It is available in English and French versions which use a user customizable language file so it is easy to provide support for other languages. Supports CGA, Herc mono, EGA, MCGA, VGA, ET4000-256, TARGA-16. Basic registration fee is $25 while $40 gets you a printed manual and info on other NAPLPS products and services. CTLINK Hmmm. I seem to have deleted this one. I had some problems with it (which may have been the modem) but I remember that it was really oriented as a terminal for commercial videotex services. I read some comments from Dave Hughes that indicated it is not a complete implementation, but if you see it around, why not try it for yourself. Tam Tam COMMERCIAL This program is available from MacGregor Inc. in Montreal for the Amiga and the Macintosh in both English and French versions. The price was $79-$99 depending on which version but I have lost my info sheet. Just call directory assistance to get a hold of them. They do speak English just fine, so don't be shy. Drawing Programs To date, I know of only one shareware drawing program that supports NAPLPS. There are other commercial programs but I don't yet have any info on them. In addition, I have written a program to convert Windows 3 icons to NAPLPS format and have a beta version of a program to convert metafiles created by CorelDraw into NAPLPS format. The Memra logo in the sample file MEMRA2.NAP was converted from an original CorelDraw image. MGE (Microstar Graphics Editor) SHAREWARE This is an object oriented drawing (not painting) program from Microstar Inc. that uses NAPLPS as its file format. It can draw all the basic objects as well as providing control over text. It can define macros, fields and blinks. If using the VGA 16 or 256 color drivers, you can customize the palette. This is an important feature of NAPLPS. It is not restricted to the default DOS/Windows 16 color palette. On a standard VGA you can display any 16 out of the 262,000 shades it is capable of displaying. Notable omissions are NAPLPS bitmaps and DRCS characters. Microsoft compatible mouse required (or a graphics tablet that emulates a Microsoft mouse). This is a good program that is often criticized because its interface is not 100% the same as Windows, however if you do PRINT OUT the README.MGE file and keep it by your side while you draw, you will find that this program is every bit as effective as CorelDraw and a much better deal. Supports CGA, Herc mono, EGA, MCGA, VGA, ET4000- 256, TARGA-16. Basic registration fee is $50 while $75 will get you a printed copy of the manual and info on other NAPLPS products and services. Teledraw COMMERCIAL This program is being developed by Dave Hughes in conjunction with a team of programmers in Russia. He has working beta versions and is expected to release the program by the end of April 1993. This program will provide full NAPLPS support including the design and use of DRCS characters such as the Russian characters used in SAIL.NAP. This program is a combination drawing/terminal program that will decode NAPLPS images in electronic mail on the fly and will allow you to draw or edit images and transmit them in electronic mail messages. NAPICO SHAREWARE This program from Memra Software Inc. is intended to enhance NAPLPS images created with MGE by adding Windows icons to the image. The icon positions are marked with a small rectangle and NAPICO takes a list of Windows 3 .ICO files and inserts the icon bitmap into those marked positions. The use of SMALL bitmaps like these icons can really enhance a NAPLPS image. A $10 registration fee is requested from those who can afford it. NAPWMF SHAREWARE This program from Memra Software Inc. converts Windows metafiles that are created using CorelDraw's File Export function. It does not necessarily work with metafiles from other programs, although full .WMF support will be included in a future version. This makes it possible to add a wide range of clipart images and True Type fonts to a NAPLPS image. See the Memra logo in MEMRA2.NAP that was produced by a beta version of this program. The images produced by version 1.0 won't be quite as big. TURSHOW SHAREWARE This program doesn't fit under either category. It simply displays the NAPLPS images on your CGA, EGA or VGA screen. Clip Art libraries I would like to see people put together libraries of non-copyrighted clipart for use by others. Note that this means the images must be original art, not converted from a commercial clipart library. As soon as I get NAPWMF released, I will be creating a library of electrical symbols for use in drawing circuits. ANSI compatibility It should be possible for a terminal program to simultaneously support both NAPLPS and the ANSI-BBS protocol simultaneously. Because of a conflict with the FLASH CURSOR command, it is not possible to arbitrarily interleave ANSI and NAPLPS data streams but it should be possible to support both code systems in a non-interleaved manner. The NAPLPS spec uses the 3 character sequence ESC 25 41 to indicate that NAPLPS decoding is to be turned ON and the sequence ESC 25 40 turns OFF the NAPLPS decoding. Outside of this bracketing, it should be possible to support ANSI escape sequences. It is fairly straightforward for sysops to ensure that the ON/OFF sequences are transmitted, especially if they are using Microstar's SHOWPLP utility. User Interaction Although NAPLPS provides facilities for user interaction in the form of unprotected fields, the cursor and transmit macros, it does not require that those facilities be used when there is an application layer protocol for handling such things. I would like to suggest that the general BBS and NAPLPS community should agree on a standard way for handling such user interactions that would allow mouse and keyboard support in a non hardware dependent manner. As for mice and other pointing devices, I would like to suggest that the terminal program transmit a POINT SET ABS (code 24) PDI to the BBS using the currently set domain co- ordinates to indicate a mouse click followed by some code to indicate whether it was a button-down or button-up event and which button it was. A POINT SET REL could be transmitted to indicate a mouse move event. For keyboard events (key-up and key-down) a form of the PC scan-codes could be transmitted. These codes are also used by certain UNIX terminals and similar events are generated by Macintosh keyboards and X-Windows keyboards so the only thing about these codes that is specific to the PC is the actual code numbers. There should probably be some indicator code transmitted to distinguish between transmission of unprotected fields and transmission of an event. Transmit macros could, of course, be programmed to emulate either events or unprotected field transmittal or anything else. I would like comments on these ideas, please. Level 6 vs. Level 7 It is important to remember that NAPLPS exists at the presentation layer which is the 6th of the 7 OSI networking levels. It is intended to be used as the foundation for interactive on-line real-time graphical applications, which are at the 7th OSI level. NAPLPS does not do everything and it is not intended to do everything. I feel that it is important for BBS operators and users to start discussions on an overall standard for graphical BBS interchange, and I would like to see NAPLPS as the foundation for the presentation layer of that interchange. I would also like to see any overall standards maintain the OSI division into 6 independent layers. It may be appropriate to extend NAPLPS to include additional G-sets and I know that there is already a JPEG extension to NAPLPS being prepared for public release. Since the BBS community is likely to be the major user of NAPLPS over the next few years, we need to maintain a discussion of this protocol and its implementations and suggestions for extensions. Resource List I have put a lot of work into writing this document and getting it widely distributed (worldwide). If you find it to be of use and can afford to, I would appreciate receiving $20 to help me continue to work on NAPLPS support. Star Valley BBS 1-604-546-2705 - speeds up to v.32bis - NAPLPS art galleries including some bitmaps - look in file areas DOS.BBS and ART.NAP - downloading available on the 1st call - author of NAPICO and NAPWMF utilities - Fidonet address 1:353/350 FREQ NAPLPS - This document NAPICO - convert Windows 3 icons to NAPLPS NAPWMF - convert CorelDraw images to NAPLPS MGESHARE - Microstar Graphics Editor PP3SHARE - Personality Plus 3 term program SHOWPLP - door to add NAPLPS to your BBS TURBOARD - BBS program with built-in NAPLPS PC Atlanta 1-404-395-6327 - speeds up to v.32bis/HST - home of Turboard BBS software - full NAPLPS, ANSI, ASCII support - sysop Shawn Rhoads - Fidonet address 1:133/904 FREQ TB114.EXE - latest Turboard ver 1.14 Russell Country BBS 1-406-423-5433 - v.32bis - home of Native American Share-Art - sysop Cynthia Denton - wonderful online art galleries - Fidonet 1:3400/7 Microstar Support BBS 1-614-727-5272 - speeds up to v.32bis (I can only connect at 9600 bps) - samples from many NAPLPS systems - interactive NAPLPS game like Tetris - the authors of MGE and PP3 and SHOWPLP - NAPLPS message area - Fidonet 1:163/537 Old Colorado City 1-719-632-2658 - David Hughes (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