Re: State of braille and speech access under Linux (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


---------- 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.

"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
Blinux web page at
To unsubscribe send mail to blinux-list-request@xxxxxxxxxx
with subject line: unsubscribe

[Index of Archives]     [Linux for the Blind]     [Fedora]     [Kernel List]     [Red Hat Install]     [Red Hat Watch List]     [Red Hat Development]     [Gimp]     [Yosemite News]     [Big List of Linux Books]