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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
