GNOME Bugzilla – Bug 552343
Quoting special characters in espeechfactory.py and other changes
Last modified: 2008-10-08 22:06:29 UTC
Please describe the problem: I have a patch for espeechfactory.py at the address (I haven't figured yet how to attach it in this bug report): http://paduch.telenet.ru/tmp/espeechfactory.patch The patch makes the following changes: 1. Emacspeak uses Tcl syntax to communicate with its speech servers. It embraces text in curly braces, so that at least {, }, and \ must be quoted when sending text to speech server. But individual speech engines have their own special characters in addition to those of Tcl. Dectalk perceives speech parameters enclosed in square brackets, and Emacspeak exploits this to transmit speech settings to Dectalk. Thus we must quote [ and ] in a text of the command 'q {...}' too. For Outloud '`' (grave accent) is special. The patch makes espeechfactory to replace those characters by their names as specified by the module chnames. 2. The bug #403760 which was fixed earlier is addressed in another way. The variable __getSpeechServersCalled is removed entirely; instead the method getSpeechServers() re-reads file .servers on each call and tries to start all servers listed there except those servers which are already running. Then the method waits for a seconds and shutdowns dead servers. The list of remaining servers is returned. 3. The method queueText splits text to be spoken into smaller chunks. Emacspeak itself does this (or at least used to do this in the past): it splitted text after each punctuation mark followed by a whitespace. It helps some speech servers to behave better. Admittedly, those speech servers themselves should be fixed. 4. changes of lesser relevance. For example, doc strings of methods have been updated to match those of speechserver.SpeechServer class. Some of these doc strings were dated or incomplete. The doc string of getSpeechServers() was incorrect about returning a list of [name, id] values identifying the available speech servers. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 118749 [details] [review] Proposed patch (In reply to comment #0) > I have a patch for espeechfactory.py at the address (I haven't figured > yet how to attach it in this bug report): Thanks! To add an attachment, you follow the "Create a New Attachment" link on the bug page. It appears after you file the bug, so the usual process is to file the bug and then add an attachment as a follow up. > 1. Emacspeak uses Tcl syntax to communicate with its speech servers. > It embraces text in curly braces, so that at least {, }, and \ must be > quoted when sending text to speech server. But individual speech > engines have their own special characters in addition to those of Tcl. > Dectalk perceives speech parameters enclosed in square brackets, and > Emacspeak exploits this to transmit speech settings to Dectalk. Thus > we must quote [ and ] in a text of the command 'q {...}' too. For > Outloud '`' (grave accent) is special. The patch makes espeechfactory > to replace those characters by their names as specified by the module > chnames. > > 2. The bug #403760 which was fixed earlier is addressed in another > way. The variable __getSpeechServersCalled is removed entirely; > instead the method getSpeechServers() re-reads file .servers on each > call and tries to start all servers listed there except those servers > which are already running. Then the method waits for a seconds and > shutdowns dead servers. The list of remaining servers is returned. > > 3. The method queueText splits text to be spoken into smaller chunks. > Emacspeak itself does this (or at least used to do this in the past): > it splitted text after each punctuation mark followed by a whitespace. > It helps some speech servers to behave better. Admittedly, those > speech servers themselves should be fixed. > > 4. changes of lesser relevance. For example, doc strings of methods > have been updated to match those of speechserver.SpeechServer class. > Some of these doc strings were dated or incomplete. The doc string of > getSpeechServers() was incorrect about returning a list of [name, id] > values identifying the available speech servers. Today is code freeze for GNOME 2.24.0, and I need to evaluate patches for risk and impact. Because of the code freeze, I want low risk, high impact fixes. This is a pretty substantial patch (i.e., it's high risk). I'm also not sure how many simultaneous emacspeak/orca users there are (i.e., it's low impact). So, I'm tempted to push this out to the next cycle. If you can tell me you've tested this patch for a very hard and very long time, though, I can be persuaded to get it in for today.
> This is a pretty substantial patch (i.e., it's high risk). I'm also not > sure how many simultaneous emacspeak/orca users there are (i.e., it's low > impact). So, I'm tempted to push this out to the next cycle. If you can > tell me you've tested this patch for a very hard and very long time, > though, I can be persuaded to get it in for today. It works for me, but I cannot guarantee that it won't break something. I think that delaying it to the next cycle is quite reasonable. At least for me it is OK.
(In reply to comment #2) > > This is a pretty substantial patch (i.e., it's high risk). I'm also not > > sure how many simultaneous emacspeak/orca users there are (i.e., it's low > > impact). So, I'm tempted to push this out to the next cycle. If you can > > tell me you've tested this patch for a very hard and very long time, > > though, I can be persuaded to get it in for today. > > It works for me, but I cannot guarantee that it won't break something. I > think that delaying it to the next cycle is quite reasonable. At least for > me it is OK. Thanks!
Let me disagree about low impact of this patch. Especially it has big sense for russian community, becouse most of all are using emacspeak server named multispeech. And ofcourse we can apply it manually, however this may confuse new users. for example i want recommend upcoming ubuntu 8.10 (with gnome 2.24) for my friends who are using windows, and i want orca works with multispeech without special tweaking. so if you have time, please test it and commit, this will be usefull work.
Code freeze for 2.24.0 was last week. I'll shoot for getting this into 2.24.1, though. Thanks!
Thanks! Committed for GNOME 2.24.1.