shuford@cs.utk.edu (Richard Shuford) (02/19/91)
The BYTE article series about the North American Presentation-Level-Protocol Syntax (NAPLPS--which may be pronounced like "nap-lips"): NAPLPS: A New Standard for Text and Graphics, Part 1: Introduction. Jim Fleming and William Frezza. BYTE, February 1983, Vol. 8, num. 2., p. 203. NAPLPS: A New Standard for Text and Graphics, Part 2: Basic Features. Jim Fleming and William Frezza. BYTE, March 1983, Vol. 8, num. 3., p. 152. NAPLPS: A New Standard for Text and Graphics, Part 3: Advanced Features. Jim Fleming and William Frezza. BYTE, April 1983, Vol. 8, num. 4, p. 190. NAPLPS: A New Standard for Text and Graphics, Part 4: More Advanced Features and Conclusion. Jim Fleming and William Frezza. BYTE, May 1983, Vol. 8, num 5., p. 272. (I was working for BYTE at the time, and I served as the theme editor for that February 1983 issue on standards.) It may be fair to say that the North American Presentation-Level-Protocol Syntax (not "standard") grew out of the efforts in the early 1980s to create a mass market for what was variously called "teletex" or "video- text" (although at the time nobody could agree on what these terms really meant). The basic idea was for delivery of information to a nontechnical user base who were nonetheless familiar with video games and wanted to see pretty graphics. As I recall with some memory haze, there were two general graphics schemes developed for teletex. One was used in the British Prestel system, and I think it was called "alpha-mosaic". The other, somewhat more sophist- icated technology was pioneered in Canada with Telidon, an "alpha- geometric" protocol. A key feature is the extension of the ASCII-type codes to include Picture-Description Instructions (PDIs). Some of the advanced features of Telidon were incremental lines, macros, dynamically redefinable characters, chain-encoding of shape edges, and various types of display fields. AT&T added some features to Telidon and handed NAPLPS to the ANSI- accredited standards committees and said, "Here. Bless our standard," so the X3L2 (technical) Committee on Character Sets and Coding worked on it for some time. The draft document was BSR X3.110-198x; I don't know the numbers of any successor documents. Fleming and Frezza, who worked with the protocol for AT&T, were on this committee. In my opinion, a major handicap for NAPLPS was that for a long time the only equipment available for encoding the images was a special computer sold in the United States only by AT&T, costing tens of thousands of dollars. This major capital start-up expense delayed or killed a lot of creative ideas for using the NAPLPS protocol and/or teletex. Eventually there were some cheaper encoding products, based on an Apple or IBM PC-type platform, but the initial enthusiasm had already declined. The significance of the "presentation-level" part of the protocol's name has also been changed by events. The real OSI protocol stack, which was amorphous indeed back in 1983, now has a pretty firmly defined Presentation Service. So the Abstract Syntax Notation 1 (ASN.1) and its Basic Encoding Rules (BER) now occupy that slot. I suppose that somebody could adapt NAPLPS as an alternate to ASN.1/BER for certain applications, but the effort to make it mesh with the other OSI layers would be nontrivial. The CoSy conferencing software used by BIX (the BYTE Information eXchange) contains support for transmitting NAPLPS images to its users, but this feature has been rather neglected in recent years. There used to be some NAPLPS-encoded images in one of the BIX graphics conferences, but I don't know if these are still online. I was not aware that Prodigy is using NAPLPS. The concept certainly makes sense. It could be the beginning of a revival of interest in this unique -- ....Richard S. Shuford | "Do not rebuke a mocker or he will hate you; rebuke ....shuford@cs.utk.edu | a wise man and he will love you. Instruct a wise ....BIX: richard | man and he will be wiser still." Proverbs 9:7 NIV
rpw3@rigden.wpd.sgi.com (Rob Warnock) (03/11/91)
In article <1991Feb19.043620.12415@cs.utk.edu> shuford@cs.utk.edu (Richard Shuford) writes: +--------------- | In my opinion, a major handicap for NAPLPS was that for a long time the | only equipment available for encoding the images was a special computer | sold in the United States only by AT&T, costing tens of thousands of | dollars. This major capital start-up expense delayed or killed a lot of | creative ideas for using the NAPLPS protocol and/or teletex. Eventually | there were some cheaper encoding products, based on an Apple or IBM | PC-type platform, but the initial enthusiasm had already declined. +--------------- Historical trivia: During the development of the Fortune Systems 32:16 desktop Unix computer (circa 1981), we had a big internal argument about whether the Fortune-supplied ASCII terminals were going to used ANSI X3.64 or NAPLPS for their character sets and control codes. X3.64 was (and is) largely identified in many people's minds as being "vt100", mainly because DEC was one of the first volume terminal manufacturers to embrace X3.64, although by 1981 dozens of manufacturers had publicly announced support for X3.64. But the marketing guys said, "AT&T is bigger than DEC", and NAPLPS won. Of course, look around today and compare the number of async 80x24 terminals that do X3.64 ("vt100 compatible") versus the number that do NAPLPS... ;-} -Rob p.s. The Fortune terminal used only the ASCII and character-block-graphics subset of NAPLPS, so it wasn't "really" a NAPLPS terminal, in the sense of any kind of videotext capability. ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311