From: Michael De La Rue <mikedlr@it.com.pl>
To: blinux-list@goldfish.cube.net
Cc: Oedipus Wrecked <oedipus@ns.hicom.net>,
Jim Van Zandt <jrv@vanzandt.mv.com>
Subject: Answers to various people / Updated proposal / I'm gone
Date: Thu, 01 Aug 1996 09:21:32 +0200 [thread overview]
Message-ID: <199608010721.JAA01140@wolfgang.it.com.pl> (raw)
> first, a question: is access-howto@ed.ac.uk an alias or an emailing list?
Errr. a mailing list containing just me. Basically it's just used for
filtering my mail into different boxes right now, but I assume that if somone
sends to that address they aren't sending me a personal mail, so I could pass
it on without permission, and potentially in the long run the address could
become a mailing list if that turns out to be the best way to maintain the
Access HOWTO. I'll mention explicitly if it ever does become a mailing list.
Okay, here's a revised version of the document. I've just accepted all of the
changes that people suggested. I have no problems with them. I'm also keen
to see this proposal distributed, though if we do that we are committing, in a
way, to fullfilling something. I think though (given the number of people
who seem to help and the amount that has been done so far by people like T.V.
Raman and the BRLTTY team) that that should be possible.
J.V.Z Thanks for the patch.. It fitted straight in with one command
(show -nosh | patch vis.*.html).. this is what we like to
see.
Here we go again. This will clash slightly with the version on the Web, but
at least shows what I have so far. I'll fix that when I come back if needed.
Odeipus, if you want to take over maintainance of this, certainly for right
now, feel free. I've added a copyright message at the bottom to make it clear
it can be distributed and modified.
Next:- I'm just sending off an update to the Access HOWTO. I'm mentioning
Jim's installation guide so that people can know about it. If possible could
it be put up for people to read on the WWW, at least until we get it into some
printed form as well.
Next:- I'm away climbing for the next cople of days. This is the last message
I'll send before that.
Michael
<HTML>
<HEAD>
<TITLE>Documenting Linux For the Visually Impaired ( 1-Aug-1996)</TITLE>
<!-- Created by: Michael De La Rue, 11-Mar-1996 -->
<!-- Changed by: Michael De La Rue, 1-Aug-1996 -->
</HEAD>
<BODY>
<H1>Documenting Linux For the Visually Impaired</H1>
<P>Once a visually impaired person has Linux working, all of the
documentation needed is available online and he or she can read it
using a normal screen reading system. The problem is that in order to
set Linux up, you need access to the documentation. This is an attempt
enough documentation available to the visually impaired to get them to
them to that stage. The aim is to eliminate the need for another
computer to be set up so that the blind user can read the
documentation, so that, at the very least, the documentation will be
available to a blind or visually impaired person with only one
computer while he or she is installing linux.
<H2>Target Documents</H2>
<P>Only certain documents are needed as targets for this project.
These are introductory material, installation material and material
which should allow someone to restart a non functional computer. At
present the documents suggested are
<DL>
<DT>The Linux Info Sheet
<DD>This is the document which introduces Linux for someone who has
never heard of it before and is needed to allow people to find out
whether they want it or not.
<DT>The Meta FAQ
<DD>This document covers other sources of information about Linux. In
other words, if you want to find something out, you start here and
from here find the document with the information you need.
<DT>The Linux Installation HOWTO
<DD>This document is the one which will cover not just installation,
but most of what is needed for reinstallation in the case of a serious
crash of some kind. Unfortunately it's somewhat outdated and we may
need more specific `per distribution' installation information instead.
<DT>The Linux Access HOWTO
<DD>This covers adaptive technology under Linux, and may well be
needed to allow the visually impaired to choose the hardware they
want to buy as well as setting it up correctly to allow the use of
Linux.
<DT>The Linux FAQ
<DD>This is a complete list of `Frequently Asked Questions' about
linux. It is a very long document and covers much detail. It would
hopefully not be needed in this form for most users, but the
probability is that someone will find the need and when they do it
will be important.
</DL>
<P>Documents that need to be specially created
<DL>
<DT>Designing a Linux Setup
<DD>This should cover the basics of choosing Linux hardware from the
perspective of a blind or visually impaired user.
<DT>Beginning to use Linux
<DD>This is probably the most difficult and important document, one
covering the way in which people should begin to use Linux. The
needs of users vary considerably here, depending on their previous
experience, but in the worst case, a near vertical `learning curve'
must be got around before the user can begin to get into linux.
This should be a step by step guide to the process, possibly based
on the DOS2Linux Mini HOWTO as well as the Access HOWTO.
</DL>
<P>Other possibilities for inclusion are suggested below.
<DL>
<DT>Linux HOWTO Index
<DD>This indexes all of the other HOWTOs in more detail than the META
FAQ. Since the collection suggested above is reasonably small, I
think this probably won't be needed except online.
<DT>Linux Kernel HOWTO
<DD>This covers altering the Linux Kernel. Unfortunately this may be
needed by some people to be able to use Linux effectively. How they
are going to get to the stage of being able to use this HOWTO without
a working Linux setup I don't know..
</DL>
<H2>Formats</H2>
<P>The aim is to have these documents available in Braille and audio
formats. Neither one of these formats covers everyone, because there
are visually impaired people who cannot read Braille and there are
deaf-blind people who cannot use audio formats. <EM>Both are needed</EM>.
<P>If the audio format is being produced for a media like CD which
supports semi-random access, then considerable effort should be put in
to make use convenient. In the case of CD, I would guess that the
best way is to make each HOWTO and each section of the FAQ a different
track and use divisions within tracks for each question (yes these do
exist; not all CD players support them, but many CD players don't
support having more than 10 tracks well).
<H2>Specially Labeled Boot Disks</H2>
<P>Most versions of the Linux operating system are designed to be
booted from a floppy disk. In order to allow this to be done by a
visually impaired person, we suggest specially labeled boot disks.
These should be in dual format. A large type label should be
overprinted with Braille. This has the advantage of covering visually
impaired (not blind n.b.) people who cannot read Braille and making
handling easy for producers who are not visually impaired.
<STRONG>Don't get the labels confused</STRONG>. Hopefully a system
can be devised to make it easy for sighted volunteers to check that
Braille matches text?
<H2>What needs done</H2>
<H3>Speaking the Texts</H3>
<P>There is a large amount of text which needs to be recorded by
someone with a reasonably clear voice. It's possible that some of
this is better done with a high quality speech synthesiser?
<P>The texts should each be broken up as structured so that the audio
translation can be edited later to match any changes that occur.
Particularly in the FAQ, section numbers change regularly and should
be kept separate from anything else.
<P>Presumably digital recording should be used, both because of the
community, computer users, that this is aimed at and because of the
large amount of editing that will need to be done.
<H3>Audio Duplication</H3>
<P>Probably CD should be the main format for distribution. There are
a large number of people in the Linux community who use and have
experience with the technology. (Others are pushing for the standard
eight track - extremely long playing tapes as the best format. I
still say that recording to digital may well be worthwhile)
<P>The license on the recordings should be such that local
re-recording onto tape is a guaranteed right. Probably some variant
of the GNU Public License.
<H3>Braille Conversion</H3>
<P>The most important task would be to add a Braille output mode to
the package which is used to format the HOWTOs. Since this is an SGML
variant (linuxdoc-sgml) this should be relatively easy. In Braille
translation ease is <STRONG>always</STRONG> relative. I have a lot to
find out about the specification of grade 2 Braille before this can be
done. I think that looking into getting recode (from GNU) to do some
of this would be very useful.
<H3>Braille Printing</H3>
<P>Braille printing is somewhat expensive and requires specialised
hardware. Once source is available, hopefully some commercial entity
or charity covering the visually impaired should be able to do this.
<H2>Repeating this project in other Languages</H2>
<P>If this project is repeated in another language then mostly
the procedure should be the same as the one described here. The main
difference is that for languages with a specific HOWTO related to that
language, it should probably be translated too. Examples are the
Linux Italian HOWTO and the possibly the Linux JE HOWTO for Japanese.
<P>Obviously, handling Linux documentation in other languages is done
best if the complete set of normal documentation has already been
translated to those languages. I believe that Japanese, German,
Italian and French are the closest to this.
<H2>Copyright</H2>
<P>This document is copyright Michael De La Rue. It may be distributed in any
format and modified in any way as long as a) this copyright is maintained in
tact on any copies distributed b) any modifications are clearly ttributed to the
person who makes those modifications.
</BODY>
</HTML>
reply other threads:[~ UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199608010721.JAA01140@wolfgang.it.com.pl \
--to=mikedlr@it.com.pl \
--cc=blinux-list@goldfish.cube.net \
--cc=jrv@vanzandt.mv.com \
--cc=oedipus@ns.hicom.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).