Accessability Repository was Thoughts on speech



Luke

Following up on one of the points mentioned in this thread.

How easy / practical would it be to have a Launchpad tree / repository that
includes all the current stable up to date accessibility type apps and
services?  My thinking is that with the fast work being done in various
areas, the main distro repos are generally speaking fairly quickly left
behind when compared to what is currently available.

This would mean opening up the latest and greatest to a far wider group
within the community who find the current way of updating to these new
packages daunting - I include myself in this group.  I'd love to be able to
use the latest versions of Orca / SD or whatever, but the thought of
grabbing them from the various projects repos, making them and installing
and getting dependancies right scares the socks off of me!

I believe the advantage is twofold - firstly, you're, as a user, not getting
frustrated at seeing all the work done and maybe even resolving issues you
have and not being able to use them.  Secondly, it extends the base of
testers at an intermediate level for when the next distro release is made
public.

I realise that Luke is a one man band at the moment, and pressure of other
accessibility work may make this suggestion a non starter, but I think it
worthwhile for consideration as a future benefit.

I'm unsure of the mechanics of such things, but I presume that the
Accessibility Repo would be useable by the Ubuntu Gnome derivatives and may
even be used upstream too?

Ian

-----Original Message-----
From: gnome-accessibility-list-bounces gnome org
[mailto:gnome-accessibility-list-bounces gnome org]On Behalf Of Hynek
Hanke
Sent: 25 February 2008 09:47
To: Willie Walker
Cc: Gnome Accessibility List
Subject: Re: Thoughts on speech



Willie Walker wrote:
 >    o Is the configuration simple enough and/or can it be made simpler?

Currently the configuration is handled via DotConf configuration
files. Of course it would be fairly simple to create some gtk tool
to modify these files, it is however questionable if this
brings some benefits for basic speech configuration for the
blind. Text configuration proved to be very efficient. If
you have a better idea, we can talk about it.

I believe though, that more important work related to installation
is in the distributions. Currently, one needs to install different
packages like orca, at-spi, speech-dispatcher, espeak, festival,
often with non-standard versions. For this, the user needs quite
a lot of know-how and I believe this could be made much simpler.
This point if of course not exclusive to Speech Dispatcher,
but I believe a consistent effort to target this issue in Debian
and Ubuntu would be quite useful.

 >    o What engines are supported now?  What drivers are being written?

Festival, Espeak, Flite, IBM TTS, Cicero. Then there is the
Generic module with configuration files ready for: Epos,
DecTalk, LliaPhon.

If the synthesizer in question has a reasonable command line
client application, I believe using it with Speech Dispatcher
via the Generic module is a task that an average experienced
user can handle (perhaps with our help on the mailing list).
Of course the capabilities of this type of solution are limited.

I'm not sure however whether  support for a wider variety
of (proprietary) synthesizers could be an effective improvement
for the general accessibility effort.

 >    o Cross platform compatibility.  I tried compiling w/o success on
 > Solaris last night.  :-(

This is not a very acurate description :) If you like to work
on it, please send a technical description of your problems to the
appropriate mailing list. If there will be some resources,
we can test and tune Speech Dispatcher for Solaris.

 >    o What additional work needs to be done to integrate it more tightly
 > with Orca?

We think that Speech Dispatcher supports all the important
functionality and most work to be done is now in Orca. Especially
regarding the lack of consistency of handling speech output and what
is handled where (Orca vs. TTS). The benefit of using Speech
Dispatcher for the user is currently limited by the way how Orca
uses it because its speech output was primarily designed for
the unsufficient Gnome Speech. Improving Orca speech
interface  would for example make another nice project.

Also, for the future, we started to work on a implementeation
of Speech Dispatcher in Python over the TTS API Provider
(which is being implemented in Python as well) and it provides
the very flexible API we agreed on across the different AT
projects.  It is a compatible solution that will have yet far
more capabilities, but currently there are not enough
resources for really effective continuation of developement.
That is another idea for a nice and useful project.

There is definitely a lot of work that still has to be done on speech
and I believe it could bring important improvements. We believe this
matter is one of the key components of the whole accessibility
infrastructure.

Best Regards,
Hynek Hanke
Brailcom


_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list




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