---------- Forwarded message ---------- Date: Mon, 15 Mar 1999 12:51:53 -0500 From: Lar Kaufman <lark@xxxxxxxxxxxxx> Reply-To: blinux-list@xxxxxxxxxx To: blinux-list@xxxxxxxxxx, blinux-list@xxxxxxxxxx Subject: Re: State of braille and speech access under Linux Resent-Date: 15 Mar 1999 18:01:17 -0000 Resent-From: blinux-list@xxxxxxxxxx Resent-cc: recipient list not shown: ; Clearly, BRLTTY needs to be mapped for curses, termcap, termio and whatever other traditional UNIX I/O device-handling to use, as this is consistent with ancient and honored methods of developing UNIX utilities and applications. Speech access under an X application or other application-level approach is, IMHO, any individual's perogative. It's hard to conceive that such an approach will impact or preempt a universal utility. More useful approaches would determine what needs to be done to the operating system to allow low-level support for open information mapping systems. And I'll admit a strong bias toward structurally oriented information mapping (specifically SGML) as opposed to page description mapping (e.g. PostScript, PDF, RTF) which focuses on presentation and placement of information on a page rather than the type of data being presented. In the context of OS installation, certain decision points occur that require choices to be made. Those decision points relating to the administrator's interface to the computer can be identified and handled (in the kernel, I suggest) to provide hooks to various renderings of system prompts based on the choices made by the installer. To me, this doesn't imply any major changes to the Linux kernel, but it does suggest SOME changes. Whether the system subsequently needs to send audio data to a sound card, "ring" a bell, or send ASCII characters to a terminal (that may independently reprocess and render them to a user) has to be handled by the OS; the actual data presented to the user can be handled by a shell, desktop, or application. If my understanding is valid, and I'm not entirely confident it is, then we need to analyse what information an OS needs to have to support any available interface that the installer requires (or wants) to receive prompts from the system and to input responses to it. Hopefully this will only be a short list of choices that will "tune" the system to use appropriate input and output devices to interact with the installer. Defining these choices defines the accommodations to be handled in the Linux kernel, it seems to me, as long as the choices are ONLY those required to enable the correct devices and to transmit intelligable prompts to the installer. An aside: this notion may be familiar to old LISP programmers. The "OS" of LISP machines is the Universal Command Loop, or UCL. It mapped essential actions such as "ring the terminal bell" to functions such as "beep". The beep function might send the BEL character to an ASCII terminal, but it just as easily could "flash" a display by inverting video (as a blinking cursor does) or send a sound file to an audio output device. On one LISP system I used, the "beep" function rendered a good imitation of Marilyn Monroe saying "beep, beep, Mr. President". But for the OS to decide to deviate from using the traditional "glass tty" and keyboard (before loading a shell/GUI and installation program) some decision points have to be supported by the OS as it is loading. Or else, it has to load with no help whatsoever and THEN adapt to the user; the variety of systems hardware etc. suggests this isn't the most practical approach, as often the result would be a non-functional installation or complete failure to install. -lar "The sum of all we drive at is that every man may enjoy the same rights that are granted to others." -- John Locke, 1689, A Letter Concerning Toleration --- Send your message for blinux-list to blinux-list@xxxxxxxxxx Blinux software archive at ftp://leb.net/pub/blinux Blinux web page at http://leb.net/blinux To unsubscribe send mail to blinux-list-request@xxxxxxxxxx with subject line: unsubscribe