LDP/LDP/howto/linuxdoc/Access-HOWTO.sgml

<!-- Linux Access HOWTO Source File  **** SEE BUGS BELOW *****

Please send a copy of this ID string with any changes to the HOWTO you send
to me.  This will let me check more easily where the changes belong.  I will
be keeping all versions of the HOWTO released within the last year, subject
only to data loss (which shouldn't happen ;-)

$Id$

this SGML version has some extra comments that may be of use to people
thinking of sending in changes.  Certainly, if you send in your
changes as patches to this version, I will be very grateful.  Use 

	diff -u

to generate the differences please.

If you don't understand diff PLEASE CONTRIBUTE anyway.  Contributing
useful information always saves me time that I might spend looking for
it.  Just send me a normal email / floppy disk / letter (if they are
short) with the changes.

Things to look for

-->

<!-- Known bugs

Characters misformatted (BAD BAD BAD) ****** READ THIS *******

	Text formatting problems.  It seems that the text formatting I
	want to do is impossible to keep consistent across all of the
	formats.  if you put { inside a VERB(atim) environment, then
	info complains, but if you put &lcub;, latex outputs \{.  Most
	probably I'll just go for messing up LaTeX, because it's
	least likely people will cut and paste directly from Latex to
	patch, and I can hope that most book publishers will read
	this.  

	You can find all of the problems I know about by looking for
	the string "FIX_FORMAT"

URLs missing in info

	I don't get URLs to turn up in the info version when I use 
	the htmlurl tag, but they turn up in the text

	There are two lines which are too long for the text
	processing.  I think these are long URLs embedded within the
	LSM entries.  I'm not sure what to do with them.  I think we
	should consider making the LSM more useful as paper
	documentation and printing that with the HOWTOs?

-->

<!doctype linuxdoc system>

<!-- keywords:-  can't put these in otherwise?  Linuxdoc-SGML really 
needs more of the man functionality
	adaptive technology
	access
	blind
	handicap
	disabled
	deaf
	hard of hearing
	visually impaired
	Braille
put these all in for any postings of announcements about this document
-->

<article>

<title>Linux Access HOWTO
<author>Michael De La Rue,  <htmlurl url="mailto:access-howto@ed.ac.uk"
name="&lt;access-howto@ed.ac.uk&gt;">
<date>v2.11, 28 March 1997
<abstract>
The Linux Access HOWTO covers the use of adaptive technology with
Linux, In particular, using adaptive technology to make Linux
accessible to those who could not use it otherwise.  It also covers
areas where Linux can be used within more general adaptive technology
solutions.  
</abstract>

<toc> <!-- the way I write has lead to many sections, I wonder if
suppressing sect3 contents entries would be a good idea -->

<sect>Introduction

<!-- why -->

<P>The aim of this document is to serve as an introduction to the
technologies which are available to make Linux usable by people who,
through some disability would otherwise have problems with it.  In
other words the target groups of the technologies are, the blind, the
partially sighted, deaf and the physically disabled.  As any other
technologies or pieces of information are discovered they will be
added.

<P>The information here not just for these people (although that is
probably the main aim) but also to allow developers of Linux to become
aware of the difficulties involved here.  Possibly the biggest
problem is that, right now, very few of the developers of Linux are
aware of the issues and various simple ways to make life simpler for
implementors of these systems.  This has, however, changed noticeably
since the introduction of this document, and at least to a small
extent because of this document, but also to a large extent due to the
work of some dedicated developers, many of whom are mentioned in the
document's Acknowledgements.

<P>Please send any comments or extra information or offers of
assistance to <htmlurl url="mailto:access-howto@ed.ac.uk"
name="&lt;access-howto@ed.ac.uk&gt;"> This address might become a
mailing list in future, or be automatically handed over to a future
maintainer of the HOWTO, so please don't use it for personal email.

I don't have time to follow developments in all areas.  I probably
won't even read a mail until I have time to update this document.
It's still gratefully received.  If a mail is sent to the blind-list
or the access-list, I <it/will/ eventually read it and put any useful
information into the document.  Otherwise, please send a copy of
anything interesting to the above email address.

<P>Normal mail can be sent to 

<tscreen><verb>
Linux Access HOWTO
23 Kingsborough Gardens
Glasgow G12 9NH
Scotland
U.K.
</verb></tscreen>

And will gradually make its way round the world to me.  Email will be
faster by weeks.

<!-- IMHO, all such documents should have normal mail addresses for
contributions from those without Internet access. -->

<P>I can be personally contacted using <htmlurl url="mailto:miked@ed.ac.uk" 
name="&lt;miked@ed.ac.uk&gt;">.  Since I use mail filtering on all mail I
receive, please use the other address except for personal email.  This
is most likely to lead to an appropriate response.

<sect1>Distribution Policy

<!-- I've put each paragraph individually in a tscreen 'cos it doesn't 
work otherwise.  Have to see how this comes out in the final version.-->

<P>
<tscreen>
The ACCESS-HOWTO is copyrighted (c) 1996 Michael De La Rue
</tscreen>

<tscreen>
The ACCESS-HOWTO may be distributed, at your choice, under either the
terms of the GNU Public License version 2 or later or the standard
Linux Documentation project terms.  These licenses should be available
from where you got this document.  Please note that since the LDP
terms don't allow modification (other than translation), modified
versions can be assumed to be distributed under the GPL.
</tscreen>

<sect>Comparing Linux with other Operating Systems

<sect1>General Comparison

<P>The best place to find out about this is in such documents as the
`Linux Info Sheet', `Linux Meta FAQ' and `Linux FAQ' (see <ref
id="linux-docs" name="Linux Documentation">).  Major reasons for a
visually impaired person to use Linux would include it's inbuilt
networking which gives full access to the Internet.  More generally,
users are attracted by the full development environment included.
Also, unlike most other modern GUI environments, the graphical front
end to Linux (X Windows) is clearly separated from the underlying
environment and there is a complete set of modern programs such as
World Wide Web browsers and fax software which work directly in the
non graphical environment.  This opens up the way to provide
alternative access paths to the systems functionality; Emacspeak is a
good example.

For other users, the comparison is probably less favourable and less
clear.  People with very specific and complex needs will find that the
full development system included allows properly customised solutions.
However, much of the software which exists on other systems is only
just beginning to become available.  More development is being done
however in almost all directions.

<sect1>Availability of Adaptive Technology

<P>There is almost nothing commercial available <em/specifically/ for
Linux.  There is a noticeable amount of free software which would be
helpful in adaptation, for example, a free speech synthesiser and some
free voice control software.  There are also a number of free packages
which provide good support for certain Braille terminals, for example.

<sect1>Inherent Usability

<P>Linux has the vast advantage over Windows that most of it's
software is command line oriented.  This is now changing and almost
everything is now available with a graphical front end.  However,
because it is in origin a programmers operating system, line oriented
programs are still being written covering almost all new areas of
interest.  For the physically disabled, this means that it is easy
to build custom programs to suit their needs.  For the visually
impaired, this should make use with a speech synthesiser or Braille
terminal easy and useful for the foreseeable future.

<P>Linux's multiple virtual consoles system make it practical to use
as a multi-tasking operating system by a visually impaired person
working directly through Braille.

<P>The windowing system used by Linux (X11) comes with many
programming tools, and should be adaptable.  However, in practice, the
adaptive programs available up till now have been more primitive than
those on the Macintosh or Windows.  They are, however, completely free
(as opposed to hundreds of pounds) and the quality is definitely
improving.

<P>In principle it should be possible to put together a complete,
usable Linux system for a visually impaired person for about
&dollar;500 (cheap &amp; nasty PC + sound card).  This compares with
many thousands of dollars for other operating systems (screen reader
software/ speech synthesiser hardware).  I have yet to see this.  I
doubt it would work in practice because the software speech
synthesisers available for Linux aren't yet sufficiently good.  For a
physically disabled person, the limitation will still be the
expense of input hardware.

<sect>Visually Impaired

<P>I'll use two general categories here.  People who are partially
sighted and need help seeing / deciphering / following the text and
those who are unable to use any visual interface whatsoever.  

<sect1>Seeing the Screen with Low Vision

<P>There are many different problems here.  Often magnification can be
helpful, but that's not the full story.  Sometimes people can't track
motion, sometimes people can't find the cursor unless it moves.  This
calls for a range of techniques, the majority of which are only just
being added to X.

<sect2>SVGATextMode

<P>This program is useful for improving the visibility of the normal
text screen that Linux provides.  The normal screen that Linux
provides shows 80 characters across by 25 vertically.  This can be
changed (and the quality of those characters improved) using
SVGATextMode.  The program allows full access to the possible modes of
an SVGA graphics card.  For example, the text can be made larger so
that only 50 by 15 characters appear on the screen.  There isn't any
easy way to zoom in on sections of a screen, but you can resize when
needed.

<sect2>X Window System 

<P>For people who can see the screen there are a large number of ways
of improving X.  They don't add up to a coherent set of features yet,
but if set up correctly could solve many problems.

<sect3>Different Screen Resolutions

<P>The X server can be set up with many different resolutions.  A
single key press can then change between them allowing difficult
to read text to be seen.

In the file <tt>/etc/XF86Config</tt>, you have an entry in the Screen section
with a line beginning with modes.  If, for example, you set this to
<tscreen><verb>
Modes       "1280x1024" "1024x768" "800x600" "640x480" "320x240"
</verb></tscreen>
with each mode set up correctly (which requires a reasonably good
monitor for the highest resolution mode), you will be able to have
four times screen magnification, switching between the different
levels using

<tt/Ctrl+Alt+Keypad-Plus/ and <tt/Ctrl+Alt+Keypad-Minus/

<!-- how should I render key presses?-->

Moving the mouse around the screen will scroll you to different parts
of the screen.  For more details on how to set this up you should see
the documentation which comes with the <bf/XFree86/ X server.

<!-- does anyone know how usable this turns out to be in practice -->

<sect3>Screen Magnification<label id="screen-mag">

<P>There are several known screen magnification programs, <tt/xmag/ which
will magnify a portion of the screen as much as needed but is very
primitive.  Another one is <tt/xzoom/.  Previously I said that there
had to be something better than <tt/xmag/, well this is it.  See
section <ref id="xzoom" name="xzoom">.

Another program which is available is <tt/puff/.  This is
specifically oriented towards visually impaired users.  It provides
such features as a box around the pointer which makes it easier to
locate.  Other interesting features of <tt/puff/ are that, if
correctly set up, it is able to select and magnify portions of the
screen as they are updated.  However, there seem to be interacations
between <tt/xpuff/ and the window manager which could make it
difficult to use.  When used with my <tt/fvwm/ setup, it didn't
respond at all to key presses.  However using <tt/twm/ improved the
situation.  

The final program which I have seen working is <tt/dynamag/.  This
again has some specific advantages such as the ability to select a
specific area of the screen and monitor it, refreshing the magnified
display at regular intervals between a few tenths of a second at
twenty seconds.  <tt/dynamag/ is part of the UnWindows distribution.  See
<ref id="unwindows" name="UnWindows"> for more details.

<!-- There seems to be a bunch of new things coming out of the X
consortium.  Should soon be available to Linux to some extent.  -->

<sect3>Change Screen Font

<P>The screen fonts all properly written X software should be
changeable.  You can simply make it big enough for you to read.  This
is generally accomplished by putting a line the file <tt/.Xdefaults/
which should be in your home directory.  By putting the correct lines
in this you can change the fonts of your programs, for example

<verb>
Emacs.font: -sony-fixed-medium-r-normal--16-150-75-75-c-80-iso8859-*
</verb>

To see what fonts are available, use the program <tt/xfontsel/ under
X.

There should be some way of changing things at a more fundamental
level so that everything comes out with a magnified font.  This could
be done by renaming fonts, and by telling telling font generating
programs to use a different level of scaling.  If someone gets this
to work properly, please send me the details of how you did it.

<sect3>Cross Hair Cursors etc..

<P>For people that have problems following cursors there are many things
which can help;
	
<itemize>
<item>cross-hair cursors (horizontal and vertical lines from the
	edge of the screen)

<item>flashing cursors (flashes when you press a key)
</itemize>

<P>No software I know of specifically provides a cross hair cursor.
<tt/puff/, mentioned in the previous section does however provide a
flashing box around the cursor which can make it considerably easier
to locate.  

<P>For now the best that can be done is to change the cursor bitmap.
Make a bitmap file as you want it, and another one which is the same
size, but completely black.  Convert them to the XBM format and run

<verb>
	xsetroot -cursor cursorfile.xbm black-file.xbm
</verb>

actually, if you understand masks, then the black-file doesn't have to
be completely black, but start with it like that.  The <tt/.Xdefaults/
file controls cursors used by actual applications.  For much more
information, please see the X Big Cursor mini-HOWTO, by Joerg
Schneider <htmlurl url="mailto:schneid@ira.uka.de" name="&lt;schneid@ira.uka.de&gt;">.

<sect2>Audio 

<P>Provided that the user can hear, audio input can be very useful for
making a more friendly and communicative computing environment.  For a
person with low vision, audio clues can be used to help locate the
pointer (see <ref id="unwindows" name="UnWindows">).  For a console
mode user using Emacspeak (see <ref id="emacspeak" name="Emacspeak">),
the audio icons available will provide very many useful facilities.

Setting up Linux audio is covered in the Linux Sound HOWTO (see <ref
id="linux-docs" name="Linux Documentation">).  Once sound is set up,
sounds can be played with the <tt/play/ command which is included with
most versions of Linux.  This is the way to use my version of
UnWindows.

<sect2>Producing Large Print

<P>Using large print with Linux is quite easy.  There are several
techniques.  

<sect3>LaTeX / TeX

<P>LaTeX is an extremely powerful document preparation system.  It may
be used to produce large print documents of almost any nature.  Though
somewhat complicated to learn, many documents are produced using LaTeX
or the underlying typesetting program, TeX.


<P>this will produce some reasonably large text

<tscreen><verb>
\font\magnifiedtenrm=cmr10 at 20pt  &percnt; setup a big font
\magnifiedtenrm
this is some large text
\bye
</verb></tscreen>

<P>For more details, see the LaTeX book which is available in any
computer book shop.  There are also a large number of introductions
available on the internet. <!-- reference one?? *********** -->

<sect2>Outputting Large Text

<P>Almost all Linux printing uses postscript, and Linux can drive almost
any printer using it.  I output large text teaching materials using a
standard Epson dot matrix printer.

For users of X, there are various tools available which can produce
large Text.  These include <tt/LyX/, and many commercial word
processors.

<sect1>Aids for Those Who Can't Use Visual Output

<P>For someone who is completely unable to use a normal screen there
are two alternatives Braille and Speech.  Obviously for people who
also have hearing loss, speech isn't always useful, so Braille will
always be important.

If you can choose, which should you choose?  This is a matter of
`vigorous' debate.  Speech is rapid to use, reasonably cheap and
especially good for textual applications (e.g. reading a long document
like this one).  Problems include needing a quiet environment,
possibly needing headphones to work without disturbing others and
avoid being listened in on by them (not available for all speech
synthesisers).

Braille is better for applications where precise layout is important
(e.g. spreadsheets).  Also can be somewhat more convenient if you want
to check the beginning of a sentence when you get to the end.  Braille
is, however, much more expensive and slower for reading text.
Obviously, the more you use Braille, the faster you get.  Grade II
Braille is difficult to learn, but is almost certainly worth it since
it is much faster.  This means that if you don't use Braille for a
fair while you can never discover its full potential and decide for
yourself. Anyway, enough said on this somewhat controversial topic.

based on original by James Bowden 
<htmlurl url="mailto:jrbowden@bcs.org.uk" name="&lt;jrbowden@bcs.org.uk&gt;">

<sect2>Braille Terminals

<P>Braille terminals are normally a line or two of Braille.  Since these
are at most 80 characters wide and normally 40 wide, they are somewhat
limited.  I know of two kinds

<itemize>
<item>Hardware driven Braille terminals.
<item>Software driven Braille terminals.
</itemize>

<P>The first kind works only when the computer is in text mode and
reads the screen memory directly. See section <ref id="memmap-braille"
name="hardware driven Braille terminals">.

<P>The second kind of Braille terminal is similar, in many ways,
to a normal terminal screen of the kind Linux supports automatically.
Unfortunately, they need special software to make them usable.

<P>There are two packages which help with these.  The first,
<tt/BRLTTY/, works with several Braille display types and the authors
are keen to support more as information becomes available.  Currently
<tt/BRLTTY/ supports Tieman B.V.'s CombiBraille series, Alva B.V.'s
ABT3 series and Telesensory Systems Inc.'s PowerBraille and Navigator
series displays.  The use of Blazie Engineering's Braille Lite as a
Braille display is discouraged, but support may be renewed on demand.
See section <ref id="serial-braille" name="Software Braille
Terminals">.

<P>The other package I am aware of is Braille Enhanced Screen.  This
is designed to work on other UNIX systems as well as Linux.  This
should allow user access to a Braille terminal with many useful
features such as the ability to run different programs in different
`virtual terminals' at the same time.

<sect2>Speech Synthesis

<P>Speech Synthesisers take (normally) ASCII text and convert it into
actual spoken output.  It is possible to have these implemented as
either hardware or software.  Unfortunately, the free Linux speech
synthesisers are, reportedly, not good enough to use as a sole means
of output.  

<P>Hardware speech synthesisers are the alternative.  The main one
that I know of that works is DECtalk from Digital, driven by
<TT/emacspeak/.  However, at this time (March 1997) a driver for the
Doubletalk synthesiser has been announced.  Using <TT/emacspeak/ full
access to all of the facilities of Linux is fairly easy.  This
includes the normal use of the shell, a world wide web browser and
many other similar features, such as email.  Although, it only acts as
a plain text reader (similar to IBM's one for the PC) when controling
programs it doesn't understand, with those that it does, it can
provide much more sophisticated control.  See section <ref
id="emacspeak" name="Emacspeak"> for more information about
<tt/emacspeak/.

<sect2>Handling Console Output

<P>When it starts up, Linux at present puts all of its messages straight
to the normal (visual) screen.  This could be changed if anyone with a
basic level of kernel programming ability wants to do it.  This means
that it is impossible for most Braille devices to get information
about what Linux is doing before the operating system is completely
working.  

<P>It is only at that stage that you can start the program that you need
for access.  If the <tt/BRLTTY/ program is used and run very early in the
boot process, then from this stage on the messages on the screen can
be read.  Most hardware and software will still have to wait until the
system is completely ready.  This makes administering a Linux system
difficult, but not impossible for a visually impaired person.  Once
the system is ready however, you can scroll back by pressing (on the
default keyboard layout) Shift-PageUP.

<P>There is one Braille system that can use the console directly,
called the Braillex.  This is designed to read directly from the
screen memory.  Unfortunately the normal scrolling of the terminal
gets in the way of this.  If you are using a Kernel newer than 1.3.75,
just type <tt/linux no-scroll/ at the LILO prompt or configure LILO to
do this automatically. If you have an earlier version of Linux, see
section <ref id="memmap-braille" name="Screen Memory Braille Terminals"> 
<!-- someone come up with a catchier label -->

<P>The other known useful thing to do is to use sounds to say when each
stage of the boot process has been reached. (T.V. Raman suggestion)

<sect2>Optical Character Recognition

<P>There is a free Optical Character Recognition (OCR) program for
Linux called <tt/xocr/.  In principle, if it is good enough, this
program would allow visually impaired people to read normal books to
some extent (accuracy of OCR is never high enough..).  However,
according to the documentation, this program needs training to
recognise the particular font that it is going to use and I have no
idea how good it is since I don't have the hardware to test it.

<sect1>Beginning to Learn Linux

<P>Beginning to learn Linux can seem difficult and daunting for someone
who is either coming from no computing background or from a pure DOS
background.  Doing the following things may help:

<itemize>
<item>Learn to use Linux (or UNIX) on someone else's system before
setting up your own.
<item>Initially control Linux from your own known speaking/Braille
terminal.  If you plan to use speech, you may want to learn <tt/emacs/
now.  You can learn it as you go along though.  See below
<item>If you come from an MS-DOS background, read the DOS2Linux Mini
HOWTO for help with converting (see <ref id="HOWTOs" name="The Linux
HOWTO Documents">).
</itemize>

The Emacspeak HOWTO written by Jim Van Zandt (<htmlurl
URL="mailto:jrv@vanzandt.mv.com" NAME="&lt;jrv@vanzandt.mv.com&gt;">)
covers this in much more detail (see <ref id="HOWTOs" name="The Linux
HOWTO Documents">).

<!-- the advice to learn emacs before wiring up to linux is from the
original version.  Never having done this, I can't comment on whether
it would be easier to learn emacs with the help of <tt/emacspeak/ than
the other way round.. thoughts anyone?  What are the teaching
facilties of emacspeak like? -->

If you are planning to use Emacspeak, you should know that Emacspeak
does not attempt to teach Emacs, so in this sense, prior knowledge of
Emacs would always be useful.  This said, you certainly do not need to know
much about Emacs to start using Emacspeak.  In fact, once Emacspeak is
installed and running, it provides a fluent interface to the rich set
of online documentation including the info pages, and makes learning
what you need a lot easier.

"In summary: starting to use Emacspeak takes little learning.  Getting
the full mileage out of Emacs and Emacspeak, especially if you intend
using it as a replacement for X Windows as I do does involve
eventually becoming familiar with a lot of the Emacs extensions; but
this is an incremental process and does not need to be done in a day."
- <it/T.V.Raman/

One other option which may be interesting are the RNIB training tapes
which include one covering UNIX.  These can be got from

<tscreen><verb>
RNIB
Customer Services
PO Box 173
Peterborough
Cambridgeshire PE2 6WS
Tel: 01345 023153 (probably only works in UK)
</verb></tscreen>

<!-- on into complete installation??? -->

<sect1>Braille Embossing

<P>Linux should be the perfect platform to drive a Braille embosser
from.  There are many formatting tools which are aimed specifically at
the fixed width device.  A Braille embosser can just be connected to
the serial port using the standard Linux printing mechanisms.  For
more info see the Linux Printing HOWTO.

<P>There is a free software package which acts as a multi-lingual
grade two translator available for Linux from the American ``National
Federation for the Blind''.  This is called NFBtrans.  See section
<ref id="nfbtrans" name="NFB translator"> for more details.

<sect>Hearing Problems

<P>For the most part there is little problem using a computer for
people with hearing problems.  Almost all of the output is visual.
There are some situations where sound output is used though.  For
these, the problem can sometimes be worked round by using visual
output instead.

<sect1>Visual Bells

<P>By tradition, computers go `beep' when some program sends them a
special code.  This is generally used to get attention to the program
and for little else.  Most of the time, it's possible to replace this
by making the entire screen (or terminal emulator) flash.  How to do
this is very variable though.

<descrip>

<tag/xterm (under X)/ for xterm, you can either change the setting by
pressing the middle mouse button while holding down the control key,
or by putting a line with just `<tt/XTerm*visualBell: true/' (not the
quotes of course) in the file <tt/.Xdefaults/ in your home directory.

<tag/the console (otherwise)/ The console is slightly more complex.
Please see Alessandro Rubini's Visual Bell mini HOWTO for details on
this.  Available along with all the other Linux documentation (see
section <ref id="linux-docs" name="other Linux documents">).  Mostly
the configuration has to be done on a per application basis, or by
changing the Linux Kernel its self.

</descrip>

<sect>Physical Problems

<P>Many of these problems have to be handled individually.  The needs
of the individual, the ways that they can generate input and other
factors vary so much that all that this HOWTO can provide is a general
set of pointers to useful software and expertise.

<sect1>Unable to Use a Mouse/Pointer

<P>Limited mobility can make it difficult to use a mouse.  For some
people a tracker ball can be a very good solution, but for others the
only possible input device is a keyboard (or even something which
simulates a keyboard).  For normal use of Linux this shouldn't be a
problem (but see the section <ref id="keyb-behave" name="Making the
keyboard behave">), but for users of X, this may cause major problems
under some circumstances.

Fortunately, the <tt/fvwm/ window manager has been designed for use
without a pointer and most things can be done using this.  I actually
do this myself when I lose my mouse (don't ask) or want to just keep
typing.  <tt/fvwm/ is included with all distributions of Linux that I
know of.  Actually using other programs will depend on their ability
to accept key presses.  Many X programs do this for all functions.
Many don't.  I sticky mouse keys, which are supposedly present in the
current release of X should make this easier.

<sect2>Unable to Use a Keyboard

<P>People who are unable to use a keyboard normally can sometimes use
one through a headstick or a mouthstick.  This calls for special setup
of the keyboard.  Please see also the section <ref id="keyb-behave"
name="Making the keyboard behave">.

<sect3>Other Input Hardware (X Windows System only)

<P>For others, the keyboard cannot be used at all and only pointing
devices are available.  In this case, no solution is available under
the standard Linux Console and X will have to be used.  If the X-Input
extension can be taught to use the device and the correct software for
converting pointer input to characters can be found (I haven't seen it
yet) then any pointing should be usable without a keyboard.

There are a number of devices worth considering for such input such as
touch screens and eye pointers.  Many of these will need a `device
driver' written for them.  This is not terribly difficult if the
documentation is available, but requires someone with good C
programming skills.  Please see the <sl/Linux Kernel Hackers guide/
and other kernel reference materials for more information.  Once this
is set up, it should be possible to use these devices like a normal
mouse.

<sect2>Controlling Physical Hardware From Linux

<P>The main group of interest here are the Linux Lab Project.
Generally, much GPIB (a standard interface to scientific equipment,
also known as the IEEE bus) hardware can be controlled.  This
potentially gives much potential for very ambitious accessibility
projects.  As far as I know none have yet been attempted.

<!-- one guy did contact me with plans.. I don't think that they got
much further though **** -->

<sect1>Speech Recognition

<P>Speech recognition is a very powerful tool for enabling computer
use.  There are two recognition systems that I know of for Linux, the
first is <tt/ears/ which is described as ``recognition is not optimal.
But it is fine for playing and will be improved'', the second is
<tt/AbbotDemo/ ``A speaker independent continuous speech recognition
system'' which may well be more interesting, though isn't available
for commercial use without prior arrangement.  See the Linux software
map for details (see section <ref id="linux-docs" name="other Linux
documents">).

<sect1>Making the Keyboard Behave<label id="keyb-behave">

<sect2>X Window System.

<P>The latest X server which comes with Linux can include many
features which assist in input.  This includes such features as
StickKeys, MouseKeys, RepeatKeys, BounceKeys, SlowKeys, and TimeOut.
These allow customisation of the keyboard to the needs of the user.
These are provided as part of the <tt/XKB/> extension in versions of X
after version 6.1.  To find out your version and see whether you have
the extension installed, you can try.

<verb>
xdpyinfo -queryExtensions
</verb>

<sect2>Getting Rid of Auto Repeat

<P>To turn off key repeat on the Linux console run this command (I think
it has to be run once per console; a good place to run it would be in
your login files, <tt/.profile/ or <tt/.login/ in your home directory).

<verb>
setterm -repeat off
</verb>

<P>To get rid of auto repeat on any X server, you can use the command 

<verb>
xset -r 
</verb>

<P>which you could put into the file which get runs when you start using
X (often <tt/.xsession/ or <tt/.xinit/ under some setups)

<P>Both of these commands are worth looking at for more ways of changing
behaviour of the console.

<sect2>Macros / Much input, few key presses

<P>Often in situations such as this, the biggest problem is speed of
input.  Here the most important thing to aim for is the most number of
commands with the fewest key presses.  For users of the shell
(<tt/bash/ / <tt/tcsh/) you should look at the manual page, in
particular command and filename completion (press the tab key and bash
tries to guess what should come next).  For information on macros
which provide sequences of commands for just one key press, have a
look at the Keystroke HOWTO.

<sect2>Sticky Keys<label id="sticky-key">

<P>Sticky keys are a feature that allow someone who can only reliably
press one button at a time to use a keyboard with all of the various
modifier keys such as shift and control.  These keys, instead of
having to be held on at the same time as the other key instead become
like the caps lock key and stay on while the other key is pressed.
They may then either switch off or stay on for the next key depending
on what is needed.  For information about how to set this up please
see the Linux Keyboard HOWTO, especially section `I can use only one
finger to type with' (section 15 in the version I have) for more
information on this.  - Information from Toby Reed.

<sect>General Programming Issues

<P>Many of the issues worth taking into account are the same when writing
software which is designed to be helpful for access as when trying to
follow good design.

<sect1>Try to Make it Easy to Provide Multiple Interfaces

<P>If your software is only usable through a graphical interface then
it can be very hard to make it usable for someone who can't see.  If
it's only usable through a line oriented interface, then someone who
can't type will have difficulties.

Provide keyboard shortcuts as well as the use of the normal X pointer
(generally the mouse).  You can almost certainly rely on the user
being able to generate key presses to your application.

<sect1>Make software configurable.

<P>If it's easy to change fonts then people will be able to change to
one they can read.  If the colour scheme can be changed then people
who are colour blind will be more likely to be able to use it.  If
fonts can be changed easily then the visually impaired will find your
software more useful.

<sect1>Test the Software on Users.

<P>If you have a number of people use your software, each with
different access problems then they will be more likely to point up
specific problems.  Obviously, this won't be practical for everybody,
but you can always ask for feedback.

<sect1>Make Output Distinct

<P>Where possible, make it clear what different parts of your program
are what.  Format error messages in a specific way to identify them.
Under X, make sure each pane of your window has a name so that any
screen reader software can identify it.

<sect1>Licenses

<P>Some software for Linux (though none of the key programs) has
license like `not for commercial use'.  This could be quite bad for a
person who starts using the software for their personal work and then
possibly begins to be able to do work they otherwise couldn't with
it.  This could be something which frees them from financial and other
dependence on others people.  Even if the author of the software is
willing to make exceptions, it makes the user vulnerable both to
changes of commercial conditions (some company buys up the rights) and
to refusal from people they could work for (many companies are overly
paranoid about licenses).  It is much better to avoid this kind of
licensing where possible.  Protection from commercial abuse of
software can be obtained through more specific licenses like the GNU
Public License or Artistic License where needed.

<sect>Other Information

<sect1>Linux Documentation<label id="linux-docs">

<P>The Linux documentation is critical to the use of Linux and most of
the documents mentioned here should be included in recent versions of
Linux, from any source I know of.

If you want to get the documentation on the Internet, here are some
example sites.  These should be mirrored at most of the major FTP
sites in the world.

<itemize>
<item>ftp.funet.fi (128.214.6.100) : 
<htmlurl url="ftp://ftp.funet.fi/pub/OS/Linux/doc/" name="/pub/OS/Linux/doc/">
<item>tsx-11.mit.edu (18.172.1.2) : 
<htmlurl url="ftp://tsx-11.mit.edu/pub/linux/docs/" name="/pub/linux/docs/">
<item>sunsite.unc.edu (152.2.22.81) :
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/" name="/pub/Linux/docs/">
</itemize>

<sect2>The Linux Info Sheet

<P>A simple and effective explanation of what Linux is.  This is one
of the things that you should hand over when you want to explain why
you want Linux and what it is good for.

<!-- FIX_FORMAT: Latex fails to break this right for me.  -->
The Linux Info Sheet is available on the World Wide Web from 
<url url="http://sunsite.unc.edu/mdw/HOWTO/INFO-SHEET.html"> and other
mirrors.

<!-- *** these sections are a bit short; possibly put as a definition -->
<!-- list? -->

<sect2>The Linux Meta FAQ

<P>A list of other information resources, much more complete than this
one.  The meta FAQ is available on the World Wide Web from
<url url="http://sunsite.unc.edu/mdw/HOWTO/META-FAQ.html"> and other
mirrors

<sect2>The Linux Software Map

<P>The list of software available for Linux on the Internet.  Many of
the packages listed here were found through this.  The LSM is
available in a searchable form from 
<url url="http://www.boutell.com/lsm/">.  It is also available in a
single text file in all of the FTP sites mentioned in section 
<ref id="linux-docs" name="Linux Documentation">.

<sect2>The Linux HOWTO documents<label id="HOWTOs">

<P>The HOWTO documents are the main documentation of Linux.  This
Access HOWTO is an example of one.

The home site for the Linux Documentation Project which produces this
information is <url url="http://sunsite.unc.edu/mdw/linux.html">.
There are also many companies producing these in book form.  Contact a
local Linux supplier for more details.

The Linux HOWTO documents will be in the directory <tt/HOWTO/ in all
of the FTP sites mentioned in section 
<ref id="linux-docs" name="Linux Documentation">.

<sect2>The Linux FAQ

<P>A list of `Frequently Asked Questions' with answers which should
solve many common questions.  The FAQ list is available from 
<url url="http://www.cl.cam.ac.uk/users/iwj10/linux-faq/"> as well as
all of the FTP sites mentioned in section 
<ref id="linux-docs" name="Linux Documentation">.

<sect1>Mailing Lists

<P>There are two lists that I know of covering these issues
specifically for Linux.  There are also others which it is worth
researching which cover computer use more generally.  Incidentally, if
a mail is sent to these lists I <it/will/ read it eventually and
include any important information in the Access-HOWTO, so you don't
need to send me a separate copy unless it's urgent in some way.

<sect2>The Linux Access List

<P>This is a general list covering Linux access issues.  It is
designed `to service the needs of users and developers of the Linux OS
and software who are either disabled or want to help make Linux more
accessible'.  To subscribe send email to <htmlurl
NAME="&lt;majordomo@ssv1.union.utah.edu&gt;"
url="mailto:majordomo@ssv1.union.utah.edu"> and in the BODY (not the
subject) of the email message put:

<tscreen><verb>
subscribe linux-access <your-email-address>
</verb></tscreen>

<sect2>The Linux Blind List

<P>This is a mailing list covering Linux use for blind users.  There
is also a list of important and useful software being gathered in the
list's archive.  To subscribe send mail to <htmlurl
url="mailto:blinux-list-request@redhat.com"
name="&lt;blinux-list-request@redhat.com&gt;"> with the <tt/subject:
help/.  This list is now moderated.

<sect1>WWW References<label id="www">

<!-- is this navigable.. it renders as urls with urllinks.. perhaps I
should use the htmlurl feature instead of url?  Remember that the
primary method of dissemination is assumed _not_ to be HTML files.
Probably plain text. -->

<P>The World Wide Web is, by it's nature, very rapidly changing.  If
you are reading this document in an old version then some of these are
likely to be out of date.  The original version that I maintain on the
WWW shouldn't go more than a month or two out of date, so refer to
that please. 

Linux Documentation is available from 
<url url="http://sunsite.unc.edu/mdw/linux.html">

Linux Access On the Web 
<url url="http://www.tardis.ed.ac.uk/&tilde;mikedlr/access/"> with all of
the versions of the HOWTO in 
<url url="http://www.tardis.ed.ac.uk/&tilde;mikedlr/access/HOWTO/">.
Preferably, however, download from one of the main Linux FTP sites.
If I get a vast amount of traffic I'll have to close down these pages
and move them elsewhere.

The BLINUX Documentation and Development Project 
<url url="http://leb.net/blinux/">.  "The purpose of The BLINUX
Documentation and Development Project is to serve as a catalyst which
will both spur and speed the development of software and documentation
which will enable the blind user to run his or her own Linux
workstation."

Emacspeak WWW page 
<url url="http://cs.cornell.edu/home/raman/emacspeak/emacspeak.html">

BRLTTY unofficial WWW page
<url url="http://www.sf.co.kr/t.linux/new/brltty.html">

Yahoo (one of the most major Internet catalogues)
<url url="http://www.yahoo.com/Society&lowbar;and&lowbar;Culture/Disabilities/Adaptive&lowbar;Technology/">

The Linux Lab Project <url url="http://www.fu-berlin.de/&tilde;clausi/">.

The BLYNX pages: Lynx Support Files Tailored For Blind and Visually
Handicapped Users <url url="http://leb.net/blinux/blynx/">.

<sect1>Suppliers

<P>This is a UK supplier for the Braillex.

<verb>
Alphavision Limited
</verb>

<sect1>Manufacturers

<!-- FIX_FORMAT: as the only simple way, I've used description lists
here for the various contact methods.  This leads to far too much
space being used, but is better than being unable to use URL tags-->

<sect2>Alphavision

<P>I think that they are a manufacturer?  RNIB only lists them as a
supplier, but others say they make the Braillex.

<verb>
Alphavision Ltd
Seymour House
Copyground Lane
High Wycombe
Bucks HP12 3HE
England
U.K.
</verb>
<descrip>
<tag/Phone/ +44 1494-530 555
</descrip>

<sect3>Linux Supported Alphavision AT Products

<P><itemize>
<item>Braillex
</itemize>

<sect2>Blazie Engineering

<P>The Braille Lite was supported in the original version of
<tt/BRLTTY/.  That support has now been discontinued.  If you have one
and want to use it with Linux then that may be possible by using this
version of the software.

<verb>
Blazie Engineering
105 East Jarrettsville Rd. 
Forest Hill, MD 21050 
U.S.A.
</verb>

<descrip>
<tag/Phone/ +1 (410) 893-9333 
<tag/FAX/   +1 (410) 836-5040 
<tag/BBS/   +1 (410) 893-8944 
<tag/E-Mail/ <htmlurl url="mailto:info@blazie.com" name="&lt;info@blazie.com&gt;">
<tag/WWW/ <url url="http://www.blazie.com/">
</descrip>


<sect3>Blazie AT Products

<P><itemize>
<item>Braille Lite (support discontinued)
</itemize>


<sect2>Digital Equipment Corporation

<P><verb>
Digital Equipment Corporation
P.O. Box CS2008
Nashua
NH 03061-2008
U.S.A
</verb>

<descrip>
<tag/Order/ +1 800-722-9332
<tag/Tech info/ +1 800-722-9332
<tag/FAX/  +1 603-884-5597
<tag/WWW/ <url url="http://www.digital.com/">
</descrip>

<sect3>Linux Supported DEC AT Products

<P><itemize>
<item>DECTalk Express
</itemize>

<sect2>Kommunikations-Technik Stolper GmbH

<P><verb>
KTS Stolper GmbH
Herzenhaldenweg 10
73095 Albershausen
Germany
</verb>

<descrip>
<tag/Phone/ +49 7161 37023
<tag/Fax/   +49 7161 32632
</descrip>

<sect3>Linux Supported KTG AT Products

<P><itemize>
<item>Brailloterm
</itemize>

<sect>Software Packages

<P>References in this section are taken directly from the Linux
Software map which can be found in all standard places for Linux
documentation and which lists almost all of the software available for
Linux.

<sect1>Emacspeak<label id="emacspeak">

<P>Emacspeak is the software side of a speech interface to Linux.  Any
other character based program, such as a WWW browser, or <tt/telnet/
or another editor can potentially be used within <tt/emacspeak/.  The
main difference between it and normal screen reader software for such
operating systems as DOS is that it also has a load more extra
features.  It is based in the emacs text editor.

A text editor is generally just a program which allows you to change
the contents of a file, for example, adding new information to a
letter.  Emacs is in fact far beyond a normal text editor, and so this
package is much more useful than you might imagine.  You can run any
other program from within emacs, getting any output it generates to
appear in the emacs terminal emulator.

The reason that emacs is a better environment for Emacspeak is that it
can can understand the layout of the screen and can intelligently
interpret the meaning of, for example, a calendar, which would just be
a messy array of numbers otherwise.  The originator of the package
manages to look after his own Linux machine entirely, doing all of the
administration from within emacs.  He also uses it to control a wide
variety of other machines and software directly from that machine.

Emacspeak is included within the Debian Linux distribution and is
included as contributed software within the Slakware distribution.
This means that it is available on many of the CDROM distributions of
Linux.  By the time this is published, the version included should be
5 or better, but at present I only have version 4 available for
examination.  

<!-- ********* there's a version 5 of this out.. whe I can get to it I
should replace the lsm URL: from
http://cs.cornell.edu/home/raman/emacspeak/emacspeak.html -->

<tscreen><verb>
Begin3
Title:          emacspeak - a speech output interface to Emacs
Version:        4.0
Entered-date:   30MAY96
Description:    Emacspeak is the first full-fledged speech output
		system that will allow someone who cannot see to work
		directly on a UNIX system. (Until now, the only option
		available to visually impaired users has been to use a
		talking PC as a terminal.) Emacspeak is built on top
		of Emacs. Once you start emacs with emacspeak loaded,
		you get spoken feedback for everything you do. Your
		mileage will vary depending on how well you can use
		Emacs.  There is nothing that you cannot do inside
		Emacs:-)
Keywords:       handicap access visually impaired blind speech emacs
Author:         raman@adobe.com (T. V. Raman)
Maintained-by:  jrv@vanzandt.mv.com (Jim Van Zandt)
Primary-site:   sunsite.unc.edu apps/sound/speech
                124kB	emacspeak-4.0.tgz
Alternate-site: 
Original-site:  http://www.cs.cornell.edu /pub/raman/emacspeak
                123kB   emacspeak.tar.gz/Info/People/raman/emacspeak/emacspeak.tar.gz
Platforms:      DECtalk Express or DEC Multivoice speech synthesizer,
                GNU FSF Emacs 19 (version 19.23 or later) and TCLX
                7.3B (Extended TCL).
Copying-policy: GPL
End
</verb></tscreen>

<sect1>BRLTTY<label id="brltty">

<P>This is a program for running a serial port Braille terminal.  It
has been widely tested and used, and supports a number of different
kinds of hardware (see the Linux Software Map entry below).  

The maintainer is, Nikhil Nair <htmlurl
url="mailto:nn201@cus.cam.ac.uk" name="&lt;nn201@cus.cam.ac.uk&gt;">.
The other people working on it are Nicolas Pitre <htmlurl
url="mailto:nico@cam.org" name="&lt;nico@cam.org&gt;"> and Stephane
Doyon <htmlurl url="mailto:doyons@jsp.umontreal.ca"
name="&lt;doyons@jsp.umontreal.ca&gt;">.  Send any comments to all of
them.

The authors seem keen to get support in for more different devices, so
if you have one you should consider contacting them.  They will almost
certainly need programming information for the device, so if you can
contact your manufacturer and get that they are much more likely to be
able to help you.  

A brief feature list (from their README file) to get you interested

<itemize>
   <item> Full implementation of the standard screen review facilities.
   <item> A wide range of additional optional features, including blinking
     cursor and capital letters, screen freezing for leisurely review,
     attribute display to locate highlighted text, hypertext links, etc.
   <item> `Intelligent' cursor routing.  This allows easy movement of
     the cursor in text editors etc. without moving the hands from the
     Braille display.
   <item> A cut &amp; paste function.  This is particularly useful for copying long
     filenames, complicated commands etc.
   <item> An on-line help facility.
   <item> Support for multiple Braille codes.
   <item> Modular design allows relatively easy addition of drivers for other
     Braille displays, or even (hopefully) porting to other Unix-like
     platforms.
</itemize>

<tscreen><verb>
Begin3
Title:          BRLTTY - Access software for Unix for a blind person
		         using a soft Braille terminal
Version:        1.0.2, 17SEP96
Entered-date:   17SEP96
Description:    BRLTTY is a daemon which provides access to a Unix console
		for a blind person using a soft Braille display (see the
		README file for a full explanation).

		BRLTTY only works with text-mode applications. 

		We hope that this system will be expanded to support
		other soft Braille displays, and possibly even other
		Unix-like platforms.
Keywords:       Braille console access visually impaired blind
Author:         nn201@cus.cam.ac.uk (Nikhil Nair)
		nico@cam.org (Nicolas Pitre)
		doyons@jsp.umontreal.ca (Stephane Doyon)
		jrbowden@bcs.org.uk (James Bowden)
Maintained-by:  nn201@cus.cam.ac.uk (Nikhil Nair)
Primary-site:   sunsite.unc.edu /pub/Linux/system/Access
		110kb brltty-1.0.2.tar.gz (includes the README file)
		  6kb brltty-1.0.2.README
		  1kb brltty-1.0.2.lsm
Platforms:      Linux (kernel 1.1.92 or later) running on a PC or DEC Alpha.
		Not X/graphics.
		Supported Braille displays (serial communication only):
		  - Tieman B.V.: CombiBraille 25/45/85;
		  - Alva B.V.: ABT3xx series;
		  - Telesensory Systems Inc.: PowerBraille 40 (not 65/80),
		    Navigator 20/40/80 (latest firmware version only?).
Copying-policy: GPL
End
</verb></tscreen>

<sect1>Screen

<P>Screen is a standard piece of software to allow many different
programs to run at the same time on one terminal.  It has been
enhanced to support some Braille terminals (those from Telesensory)
directly.

<!-- used to be tt.. doesn't seem to work for txt version, sigh
	LDSBUG (or not?) -->
<sect1>Rsynth

<P>This is a speech synthesiser listed in the Linux Software Map.  It
doesn't apparently work well enough for use by a visually impaired
person.  Use hardware instead, or improve it.. a free speech synthesiser
would be really really useful.

<!-- used to be tt.. doesn't seem to work for txt version, sigh
	LDSBUG (or not?) -->
<sect1>xocr

<P><tt/xocr/ is a package which implements optical character recognition for
Linux.  As with <tt/Rsynth/, I don't think that this will be acceptable as
a package for use as a sole means of input by a visually impaired
person.  I suspect that the algorithm used means that it will need to
be watched over by someone who can check that it is reading correctly.
I would love to be proved wrong.

<sect1>xzoom<label id="xzoom">

<P><tt/xzoom/ is a screen magnifier, in the same vein as <tt/xmag/,
but sufficiently better to be very useful to a visually impaired
person.  The main disadvantages of <tt/xzoom/ are that it can't magnify
under itself, that some of the key controls aren't compatible with
<tt/fvwm/, the normal Linux window manager and that it's default
configuration doesn't run over a network (this can be fixed at some
expense to speed).  Apart from that though, it's excellent.  It does
continuous magnification which allows you to, for example, scroll a
document up and down, whilst keeping the section you are reading
magnified.  Alternatively, you can move a little box around the
screen, magnifying the contents and letting you search for the area
you want to see.  <tt/xzoom/ is also available as an rpm from the
normal RedHat sites, making it very easy to install for people using
the rpm system (such as Redhat users).

<tscreen><verb>
Begin3
Title:          xzoom
Version:        0.1
Entered-date:   Mar 30 1996
Description:    xzoom can magnify (by integer value) rotate
                (by a multiple if 90 degrees) and mirror about
                the X or Y axes areas on X11 screen 
                and display them in it's window.
Keywords:       X11 zoom magnify xmag
Author:         Itai Nahshon <nahshon@best.com>
Maintained-by:  Itai Nahshon <nahshon@best.com>
Primary-site:   sunsite.unc.edu
                probably in /pub/Linux/X11/xutils/xzoom-0.1.tgz
Platforms:      Linux+11. Support only for 8-bit depth.
                Tested only in Linux 1.3.* with the XSVGA 3.1.2
driver.
                                Needs the XSHM extension.
Copying-policy: Free
End
</verb></tscreen>

<sect1>NFBtrans<label id="nfbtrans">

<P><tt/nfbtrans/ is a multi-grade Braille translation program
distributed by the National Federation for the Blind in the U.S.A.  It
is released for free in the hope that someone will improve it.
Languages covered are USA English, UK English, Spanish, Russian,
Esperanto, German, Biblical Hebrew and Biblical Greek, though others
could be added just by writing a translation table.  Also covered are
some computer and math forms.  I have managed to get it to compile
under Linux, though, not having a Braille embosser available at the
present moment I have not been able to test it.

NFBtrans is available from 
<url url="ftp://nfb.org/ftp/nfb/braille/nfbtrans/">.  After
downloading it, you will have to compile it.

<sect2>Compiling NFBtrans on Linux

<P>I have returned this patch to the maintainer of NFBtrans and he
says that he has included it, so if you get a version later than 740,
you probably won't have to do anything special.  Just follow the
instructions included in the package.

<P><verb>
	unzip -L NFBTR740.ZIP   &num;or whatever filename you have
	mv makefile Makefile
</verb>

<!-- patch considered obsolete.  Will be deleted in the next version, 
but left in for completeness now. -->


Next save the following to a file (e.g. <tt/patch-file/)

<tscreen><verb>
*** nfbpatch.c.orig     Tue Mar 12 11:37:28 1996
--- nfbpatch.c  Tue Mar 12 11:37:06 1996
***************
*** 185,190 ****
--- 185,193 ----
    return (finfo.st&lowbar;size);
  &rcub;                /* filelength */
  
+ &num;ifndef linux 
+ /* pretty safe to assume all linux has usleep I think ?? this should be
+ done properly anyway */
  &num;ifdef SYSVR4
  void usleep(usec)
    int usec;
***************
*** 195,200 ****
--- 198,204 ----
UKP  &rcub;                /* usleep */
  
  &num;endif
+ &num;endif 
  
  void beep(count)
    int count;
</verb></tscreen>

and run 

<tscreen><verb>
patch &lt; patch-file
</verb></tscreen>

then type 

<tscreen><verb>
make
</verb></tscreen>

and the program should compile.

<sect1>UnWindows<label id="unwindows">

<P>UnWindows is a package of access utilities for X which provides
many useful facilities for the visually impaired (not blind).  It
includes a screen magnifier and other customised utilities to help
locate the pointer.  UnWindows can be downloaded from <url
url="ftp://ftp.cs.rpi.edu/pub/unwindows">.

As it comes by default, the package will not work on Linux because it
relies on special features of Suns.  However, some of the utilities do
work and I have managed to port most of the rest so this package may
be interesting to some people.  My port will either be incorporated
back into the original or will be available in the BLINUX archives
(see <ref id="www" name="WWW references">).  The remaining utility
which doesn't yet work is the configuration utility.

In my version the programs, instead of generating sounds themselves,
just call another program.  The other program could for example be

<tscreen><verb>
play /usr/lib/games/xboing/sounds/ouch.au
</verb></tscreen>

Which would make the <tt/xboing/ ouch noise, for example it could do
this as the pointer hit the left edge of the screen.

<sect2>dynamag

<P><tt/dynamag/ is a screen magnification program.  please see the
section on Screen magnification (<ref id="screen-mag"
name="magnification">).  This program worked in the default
distribution.

<sect2>coloreyes

<P><tt/coloreyes/ makes it easy to find the pointer (mouse) location.
It consists of a pair of eyes which always look in the direction of
the pointer (like xeyes) and change color depending on how far away
the mouse is (unlike xeyes).  This doesn't work in the default
distribution, but the test version, at the same location, seems to
work.  

<sect2>border

<P><tt/border/ is a program which detects when the pointer (mouse) has
moved to the edge of the screen and makes a sound according to which
edge of the screen has been approached.  The version which is
available uses a SUN specific sound system.  I have now changed this
so that instead of that, it just runs a command, which could be any
Linux sound program.  

<sect2>un-twm

<P>The window manager is a special program which controls the location
of all of the other windows (programs) displayed on the X screen.
<tt/un-twm/ is a special version which will make a sound as the pointer
enters different windows.  The sound will depend on what window has
been entered.  The distributed version doesn't work on linux because,
like <tt/border/ it relies on SUN audio facilities.  Again I already
have a special version which will be avaliable by the time you read
this.

<sect>Hardware

<sect1>Braille terminals driven from Screen Memory<label id="memmap-braille">

<P>These are Braille terminals that can read the screen memory
directly in a normal text mode.  It is possible to use it to work with
Linux for almost all of the things that a seeing user can do on the
console, including installation.  However, it has a problem with the
scrolling of the normal Linux kernel, so a kernel patch needs to be
applied.  See <ref id="memmap-patch" name="Patching the Kernel for
Braillex and Brailloterm">.

<sect2>Braillex 

<P>The Braillex is a terminal which is designed to read directly from
the Screen memory, thus getting round any problems with MS-DOS
programs which don't behave strangely.  If you could see it on screen,
then this terminal should be able to display it in Braille.  In Linux,
unfortunately, screen handling is done differently from MS-DOS, so
this has to be changed somewhat.  

To get this terminal to work, you have to apply the patch given below
in section <ref id="memmap-patch" name="Patching the Kernel">.  Once
this is done, the Braillex becomes one of the most convenient ways to
use Linux as it allows all of the information normally available to a
seeing person to be read.  Other terminals don't start working until
the operating system has completely booted.

The Braillex is available with two arrangements of Braille cells (80x1
or 40x2) and there is a model, called the IB 2-D which also has a
vertical bar to show information about all of the lines of the screen
(using 4 programmable dots per screen line)

<verb>
Price: 8,995  (pounds sterling) or 11495 UKP for 2-D
Manufacturer: Alphavision Limited (UK)
Suppliers: ????
</verb>

<sect2>Brailloterm

<P>``What is Brailloterm?

<P>It's a refreshable display Braille, made by KTS
Kommunikations-Technik Stolper GmbH.  It has 80 Braille cells in an
unique line. Each cell has 8 dots that are combined (up/down) to
represent a character. By default, Brailloterm shows me the line in
which the screen cursor is. I can use some functions in Brailloterm to
see any line in the screen.'' - <it/Jose Vilmar Estacio de Souza/
<htmlurl url="mailto:jvilmar@embratel.net.br"
	name="&lt;jvilmar@embratel.net.br&gt;">

<P>Jose then goes on to say that the terminal can also use the serial
port under DOS but that it needs a special program.  I don't know if
any of the ones for Linux would work.

<P>As with Braillex, this needs a special patch to the kernel work
properly.  See section <ref id="memmap-patch" name="Patching the
Kernel">.  

<verb>
Price: about 23.000,- DM /  &dollar; 15.000,
Manufacturer: Kommunikations-Technik Stolper GmbH
Suppliers: ????
</verb>


<sect2>Patching the Kernel for Braillex and Brailloterm
<label id="memmap-patch">

<P>This probably also applies to any other terminals which read
directly from screen memory to work under MS-DOS.  Mail me to confirm
any terminals that you find work.  This does not apply and will
actually lose some features for terminals driven using the BRLTTY
software.

<P>I am told this patch applies to all Kernels version 1.2.X.  It
should also work on all Kernel versions from 1.1.X to 1.3.72, with
just a warning from patch (I've tested that the patch applies to
1.3.68 at least).  <bf/From 1.3.75 the patch is no longer needed/
because the Kernel can be configured not to scroll using `<tt/linux
no-scroll/' at the LILO prompt.  See the Boot Prompt HOWTO for more
details.

<!-- FIX_FORMAT: in at least some versions of sgml tools this patch 
renders incorrectly into latex format, but this cannot be avoided
because alternatives render incorrectly into text. -->

<tscreen><verb>
*** drivers/char/console.c&tilde;	Fri Mar 17 07:31:40 1995
--- drivers/char/console.c	Tue Mar  5 04:34:47 1996
***************
*** 601,605 ****
  static void scrup(int currcons, unsigned int t, unsigned int b)
  &lcub;
! 	int hardscroll = 1;
  
  	if (b > video&lowbar;num&lowbar;lines || t >= b)
--- 601,605 ----
  static void scrup(int currcons, unsigned int t, unsigned int b)
  &lcub;
! 	int hardscroll = 0;
  
  	if (b > video&lowbar;num&lowbar;lines || t >= b)
</verb></tscreen>

To apply it:

<enum>
<item>Save the above text to a file (say patch-file)
<item>change to the drivers/char directory of your kernel sources
<item>run 
	<tscreen><verb>
		patch &lt; patch-file
	</verb></tscreen>
<!-- FIX_FORMAT: in at least some versions of sgml tools this patch 
renders incorrectly into latex format, but this cannot be avoided
because alternatives render incorrectly into text. -->
<item>Compile your kernel as normal
</enum>

<P>Apply those patches and you should be able to use the Braille terminal
as normal to read the Linux Console. 

<P>Put in words, the patch just means `change the 1 to a 0 in the
first line of the function <tt/scrup/ which should be near line 603 in the
file drivers/char/console.c'.  The main thing about <tt/patch/ is that
program understands this, and that it knows how to guess what to do
when the Linux developers change things in that file.

<P>If you want to use a more modern kernel with completely disabled
scrolling, (instead of the boot prompt solution I already mentioned),
please use the following patch.  <bf/This does not apply to kernels
earlier than 1.3.75/.


<!-- FIX_FORMAT: in at least some versions of sgml tools this patch 
renders incorrectly into lates format, but this cannot be avoided
because alternatives render incorrectly into text. -->

<tscreen><verb>
*** console.c&tilde;	Fri Mar 15 04:01:45 1996
--- console.c	Thu Apr  4 13:29:48 1996
***************
*** 516,520 ****
  unsigned char has&lowbar;wrapped;          /* all of videomem is data of fg&lowbar;console */
  static unsigned char hardscroll&lowbar;enabled;
! static unsigned char hardscroll&lowbar;disabled&lowbar;by&lowbar;init = 0;

  void no&lowbar;scroll(char *str, int *ints)
--- 516,520 ----
  unsigned char has&lowbar;wrapped;          /* all of videomem is data of fg&lowbar;console */
  static unsigned char hardscroll&lowbar;enabled;
! static unsigned char hardscroll&lowbar;disabled&lowbar;by&lowbar;init = 1;

  void no&lowbar;scroll(char *str, int *ints)
</verb></tscreen>


<sect1>Software Driven Braille Terminals<label id="serial-braille">

<P>The principle of operation of these terminal is very close to that
of a CRT terminal such as the vt100.  They connect to the serial port
and the computer has to run a program which sends them output.  At
present there are two known programs for Linux.  <tt/BRLTTY/, see section
<ref id="brltty" name="BRLTTY">) and Braille enhanced screen.

<sect2>Tieman B.V. 

<sect3>CombiBraille

<P>This Braille terminal is supported by the <tt/BRLTTY/
software.  It comes in three versions with 25, 45 or 85 Braille cells.
The extra five cells over a standard display are used for status
information.

<verb>
Price: around 4600 UKP for the 45 cell model ...
Manufacturer: Tieman B.V.
Suppliers: Concept Systems, Nottingham, England (voice +44 115 925 5988)
</verb>

<sect2>Alva B.V. 

<P>The ABT3xx series is supported in <tt/BRLTTY/.  Only the ABT340 has
been confirmed to work at this time.  Please pass back information to
the <tt/BRLTTY/ authors on other models.

<verb>
Price: 20 cell - 2200 UKP; 40 cell 4500 UKP; 80 cell 8000 UKP
Manufacturer: Alva
Suppliers: Professional Vision Services LTD, Hertshire, England 
           (+44 1462 677331)
</verb>

<sect2>Telesensory Systems Inc. displays

<P>Because they have provided programming information to the
developers, the Telesensory displays are supported both by <tt/BRLTTY/
and <tt/screen/.

<sect3>Powerbraille

<P>There are three models the 40, the 65 and the 80.  Only the 40 is
known to be supported by <tt/BRLTTY/.

<verb>
Price: 20 cell - 2200 UKP; 40 cell 4500 UKP; 80 cell 8000 UKP
Manufacturer: Alva
Suppliers: Professional Vision Services LTD, Hertshire, England 
           (+44 1462 677331)
</verb>

<sect3>Navigator

<P>Again there are three models the 20, the 60 and the 80.  Recent
versions are all known to work with <tt/BRLTTY/ but whether earlier
ones (with earlier firmware) also work has not been confirmed.  

<verb>
Price: 80 cell 7800 UKP
Manufacturer: Alva
Suppliers: Professional Vision Services LTD, Hertshire, England 
           (+44 1462 677331)
</verb>

<sect2>Braille Lite

<P>This is more a portable computer than a terminal.  It could,
however, be used with BRLTTY version 0.22 (but not newer versions) as
if it was a normal Braille terminal.  Unfortunately, many of the
features available with the CombiBraille cannot be used with the
Braille Lite.  This means that it should be avoided for Linux use
where possible.

<verb>
Price: &dollar;3,395.00
Manufacturer: Blazie Engineering
</verb>

<sect1>Speech Synthesisers

<P>Speech synthesisers normally connect to the serial port of a PC.
Useful features include

<itemize>
<item>Braille labels on parts
<item>Many voices to allow different parts of document to be spoken
         differently 
<item>Use with headphones (not available on all models)
</itemize>

The critical problem is that the quality of the speech.  This is much
more important to someone who is using the speech synthesiser as their
main source of information than to someone who is just getting neat
sounds out of a game.  For this reason T.V. Raman seems to only
recommend the DECTalk.  Acceptable alternatives would be good.

<sect2>DECTalk Express

<P>This is a hardware speech synthesiser.  It is recommended for use
with Emacspeak and in fact the DECTalk range are the only speech
synthesisers which work with that package at present.  This
synthesiser has every useful feature that I know about.  The only
disadvantage that I know of at present is price.

<verb>
Price: &dollar;1195.00
Manufacturer: Digital Equipment Corporation

Suppliers: Many.  I'd like details of those with Specific Linux
	support / delivering international or otherwise of note only
	please.  Otherwise refer to local organisations.
	Digital themselves or the Emacspeak WWW pages.
</verb>


<sect2>Accent SA

<P>This is a synthesiser made by Aicom Corporation.  An effort has
begun to write a driver for it however help is needed.  Please see
<url url="http://www.cyberspc.mb.ca/~astrope/speak.html"> if you think
you can help.

<!-- FIX_FORMAT: the tilde comes out as a space on latex -->

<sect2>SPO256-AL2 Speak and Spell chip.

<P>Some interest has been expressed in using this chip in self built
talking circuits.  I'd be interested to know if anyone has found this
useful.  A software package <tt/speak-0.2pl1.tar.gz/ was produced by
David Sugar <htmlurl url="mailto:dyfet@tycho.com" 
name="&lt;dyfet@tycho.com&gt;">.  My suspicion, though, is
that the quality of the output wouldn't be good enough for regular use.

<sect>Acknowledgements

<P>Much of this document was created from various information sources
on the Internet, many found from Yahoo and DEC's Alta Vista Search
engine.  Included in this was the documentation of most of the
software packages mentioned in the text.  Some information was also
gleaned from the Royal National Institute for the Blind's helpsheets.

T.V. Raman, the author of Emacspeak has reliably contributed comments,
information and text as well as putting me in touch with other people
who he knew on the Internet.

Kenneth Albanowski <htmlurl url="mailto:kjahds@kjahds.com" 
name="&lt;kjahds@kjahds.com&gt;"> provided the
patch needed for the Brailloterm and information about it.

Roland Dyroff of <htmlurl url="http://www.suse.de/" name="S.u.S.E. GmbH"> 
(Linux distributors and makers of S.u.S.E. Linux (English/German)) looked up
KTS Stolper GmbH at my request and got some hardware details and
information on the Brailloterm.

The most major and careful checks over of this document were done by
James Bowden, <htmlurl url="mailto:jrbowden@bcs.org.uk" 
name="&lt;jrbowden@bcs.org.uk&gt;"> and Nikhil Nair <htmlurl
url="mailto:nn201@cus.cam.ac.uk" name="&lt;nn201@cus.cam.ac.uk&gt;">, the
<tt/BRLTTY/ authors who suggested a large number of corrections
as well as extra information for some topics.

The contributors to the blinux and linux-access mailing lists have
contributed to this document by providng information for me to read.  

Mark E. Novak of the Trace R&amp;D centre 
<url url="http://trace.wisc.edu/"> pointed me in the direction of several
packages of software and information which I had not seen before.  He
also made some comments on the structure of the document which I have
partially taken into account and should probably do more about.

Other contributors include Nicolas Pitrie and Stephane Doyon.

A number of other people have contributed comments and information.
Specific contributions are acknowledged within the document.

This version was specifically produced for <htmlurl
url="http://www.redhat.com/" name="RedHat">'s Dr. Linux book.  This is
because they provided warning of it's impending release to myself and
other LDP authors.  Their doing this is strongly appreciated since
wrong or old information sits around much longer in a book than on the
Internet.

No doubt you made a contribution and I haven't mentioned it.  Don't
worry, it was an accident.  I'm sorry.  Just tell me and I will add
you to the next version.  

</article>