Hi Actually, I'm not sure the buffer is at fault. The way it was explained, on the speechd list at least, was that speechd has different priorities of text. How it determines these priorities I don't know, butif it encounters a higher priority item, it will stop reading what it was reading and immediately read the new item. A good example is within lynx the chain, if there's no URL at the bottom of the screen then the entire screen will read. If there is, immediately for some reason the last part of the URL is spoken and the rest of the screen is not read. This is also why command not found errors aren't read, the shell prompt has a higher priority so it gets read instead. I think what would have to be done would be to have speechd_up ignore priorities completely, as they really aren't needed when using a screen reader and can in fact be a nuisance. If I had to guess. this is also part of the shut up problem, as a shut up key with no text gets ignored as a very low priority item. Remember, its not that speech won't interrupt, just that it won't interrupt if you don't send any text with it. If you read a line then move up to the previous line, then it will interrupt quite quickly and begin reading that line. On Sun, 28 Mar 2004, Kirk Reiser wrote: > This was an excellent overview Jacob, I think you should forward it > on to the speech dispatcher list as well. A lot of the things you > mentioned can be fixed with further fixes to their speakup driver > converting the pitch and voices and the like into the appropriate > commands for the software dectalk and/or other synths they support. > > I found two problems but haven't had time to try to look into them > which were that if you have to large of buffer say with a say screen > you lost everything after 256 or 512 bytes. The other problem was > what seems to me to be the software synth nemisis it won't shut up > when you hit the key what says shut up!
