[Prev][Next][Index][Thread][Search]

Accent driver

Hi Alan,

I'll answer your questions in order, and I'm glad you and your wife are
enthusiastic about emacspeak.

1) You're right in that the structure of the driver wont have to change much,
you'll basically need to replace dectalk control sequences with accent
sequences.

2) Voice locking means that emacspeak uses different voices (either entirely
different voices, or the same voice with some parameter changed) the same way
X uses different fonts.
So you can listen to program source code with the type specifiers in a
different voice, strings in another voice etc. and it is quite useful (in
addition to being cute).
If you use the Emacs W3 www browser inside emacs, all the hotlinks are spoken
in a different voice etc etc.

The reason I say this is dectalk specific is that though you can change the
pitch on the accent, the way voice-locking is currently implemented would
require the changing of one emacs-lisp module to support hte accent's pitch
changes.
ut could be done if found necessary.

3) Voice-locking as implemented in emacspeak is "orthogonal" to font-locking,
ie you dont have to have font-locking turned on in order for having
voice-locking turned on.

4) This said, emacspeak will work under X; I've often run it under an X-term
and everything works fine.

So for instance, if your wife is in school and walks into one of the labs
where all the workstations are running X, she should be able to use Emacspeak
at an X-term.
She would connect her speech box to the workstation, and be off and running

You could set things up for her such that her login sequence launches an
X-term and fires up emacspeak inside it; she would not have to be even aware
that X is running.
This said, the only problem I've encountered in doing this is that sometimes
the mouse gets accidentally pushed and this ends up losing focus in the
X-term; and of course, then you're sunk.

So emacspeak will work just as well inside X as it does outside, but note: the
only things that talk are things run from inside emacs, so generic X
applications that put up their own windows will not talk.

(Not much you cannot do inside emacs, so not a problem <smile>)

There is an ongoing effort to write a speech-access program for X using the
traditional screen-reading approach.
They expect to have something out in a year or two (this is research done at
GATECH as part of the Mercator project that is being commercialized)
But the spoken output you get from emacspeak is far richer than what you get
from any screenreader that speaks the screen, so in a sense Emacspeak will
always remain a qualitatively different solution, albeit not as
general-purpose as a general screenreader.

--Raman 

-- 
Best Regards,
--raman

      Adobe Systems                 Tel: 1 (408) 536 3945   (W14-129)
      Advanced Technology Group     Fax: 1 (408) 537 4042 
      (W14 129) 345 Park Avenue     Email: raman@xxxxxxxxxxx 
      San Jose , CA 95110 -2704     Email:  raman@xxxxxxxxxxx
      http://labrador.corp.adobe.com/~raman/raman.html (Adobe  Internal)
      http://www.cs.cornell.edu/Info/People/raman/raman.html  (Cornell)
-----------------------------------------------------------------------
    Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________