wm (10/26/82)
Isn't the ASCII character set long overdue for a major overhaul? I keep seeing people complaining about funny escape sequences required for terminal control and so on. We've got the 8th bit to play with, come on, let's use it. Furthermore, don't you think that instead of leaving a standards committee to come up with some outdated standard, the net would be an interesting vehicle to formulate a standard? I propose that the following additions be made to the ASCII character set. Reserve the use of the 8th bit. If clear, the remaining 7 bits should form an existing ASCII code. If set, then the remaining 7 bits form one of 128 characters, divided into 4 groups of 32 characters. These groups are: Extended control characters. These should include (at least), modem control (i.e., autodialing, handshaking), CRT terminal screen control (cursor addressing, etc.), terminal identification codes (so a system can tell what kind of terminal you are on), terminal memory management for terminals with multiple pages of screen memory, controls for super- and sub-scripting, alternate character sets, and so forth. Workstation control characters. Support for advanced (i.e. bit mapped) terminals. I'm not sure all that is needed, but it should at least include control for changing fonts and point sizes, support for proportional spacing, window management, characters to control input devices such as mice. Maybe support for color and enough graphics commands to change a pixel, write a window with a raster of pixels, draw a line, etc. (in other words, enough to do some simple graphics such as graphs and charts). The keyword here is extensibility. Assume we will not know all that will be required in the future. For example, some control characters for networking may be valuable. Function key characters. Function keys are underused. If they were standardized they could be used in such things as screen editors where they are invaluable. Extended characters. Things such as the copyright sign that is required to be displayed in copyrighted software, but is not available in the current character set. I can think of many other characters that would be nice to have: arrows, simple math symbols, editing symbols, etc. Note that these characters are not for an alternate character set (such as APL), those should be available using an extended control character to change character sets. This list in incomplete, and is mainly designed to invite discussion. What are the pitfalls here? I know there will be some compatibility problems, but these seem reasonably easy to overcome. Wm Leler, UNC - Chapel Hill