Further problems with speech implementation.

[Henrik Nilsen Omma]

Hi all,

To broaden the discussion I've also added in the -devel list.

Luke Yelavich wrote:
> Hi all
> For those who weren't at the meeting, we discussed various aspects of 
> implementation for the live CD, and the GUI install. A couple of issues 
> were raised conserning the implementation of speech for gnopernicus. 
> From further discussion with Daniel Holbach, it seems that there is more 
> to do than first thought. The following is a summary of what has been 
> discussed so far, including the first implementations, up to my 
> conversation this evening.
>
> * An option on the gfxboot screen was created for people to select 
> various accessibility profiles to be loaded when the live CD boots.
> * One of these involves loading a screen reader with synthesized speech 
> for access to GNOME and the installer.
> * The necessary settings for these profiles to be activated are not yet 
> implemented, but it was decided to put flite on the CD rather than 
> festival, due to disk space constraints, as flite is much smaller.
> * It was determined that gnome-speech does not have a driver for flite, 
> so an alternate way of interfacing flite with gnopernicus was suggested, 
> this being to use a newly developed driver for gnome-speech to interface 
> with speech-dispatcher. Speech-dispatcher can interface with flite. This 
> would require either waiting for a new gnome-speech release, or patching 
> the current package with CVS code containing the speech-dispatcher 
> driver.
> * Speech-dispatcher 0.6 has not yet entered Debian sid, and 0.6 is the 
> only version that the gnome-speech driver will work with. In order for 
> us to use it, we need to upgrade the package in universe to 0.6, and get 
> it promoted to main.
> * In order to prevent festival from being pulled in when gnome-speech is 
> included, we need to split one or both gnome-speech drivers from the 
> core gnome-speech packages to prevent this from happening. 
> Speech-dispatcher itself doesn't have many dependancies, the biggest one 
> being flite.
> * Daniel mentioned that feature freeze is fast approaching, and all this 
> needs to be packaged up, and tested on all three architectures.
>
> So as you can see, this might be more difficult than we first thought. 
> Daniel, if I have missed anything, please bring it up or correct me.
>
> Henrik, I am very interested in your opinion about all of this. If 
> anybody else has anything to say, please speak up, as we need to get 
> something sorted for the release ASAP.
>   

I'd like to bring the core developers into the discussion at this point 
to since we are approaching a crunch point.

As I see it, we have 3 options:

1. Pursue the path you describe above of packaging and promoting speech 
dispatcher along with the gnome drivers. This would land us on 
approximately the solution we had planned, though it will be tight to 
get it working in time. Perhaps we can pursue this if we also agree on a 
reasonable fall-back plan.

2. Upgrade from Festival-lite to the full Festival - This would give us 
better speech quality and add 6-7 languages, but would require 40MB 
instead of the 8MB used by f-lite. While this is theoretically possible 
by removing language packs and/or Windows-FOSS, I doubt it will be given 
serious consideration because it will have a significant impact for a 
large number of users (and space is just always tight). Since the space 
calculations get more detailed as we approach the release date and other 
things settle in, I also don't think this would be a possible fall-back 
option. I would of course love to be wrong :)

3. Remove support for screen readers on the Dapper Live CD. This would 
also mean removing the 'blindness' option from the menu. This is an 
unfortunate thing to do since the visually impaired community is by far 
the most active AT user group on Linux and are as such our main target 
group at this stage (there are other, larger groups, such as the elderly 
with mild motoric difficulties, but these may not be early adopters in 
the same way.) It would also not allow us to claim to have the best 
default AT support among distros (perhaps we still would in some ways, 
but it wouldn't be such a clear case to make).

Orthogonally to these option, we also have the opportunity of creating 
an AT derivative. This could easily have the full Festival package and 
perhaps a few additional AT packages like dasher. This could be released 
shortly after dapper and be made available for download (space can be 
made by removing the Win-FOSS). There are benefits to this approach, but 
getting the AT infrastructure support onto the main CDs is still the big 
prize.

Personally, I would like to see us push for option #1 (assuming #2 to be 
unrealistic) and have #3 as a fall-back. I'm not the best suited to 
judge what is required to make #1 a reality though. I'd like to hear 
from Matt and Colin if possible what you thing WRT timeframes and the 
suitability of the less-than-completely-mature speech dispatcher et al.

- Henrik