GNOME Bugzilla – Bug 620109
Speech Dispatcher (and OpenTTS?) do not present bullets from OOo Writer
Last modified: 2010-09-20 10:56:22 UTC
Steps to reproduce: 1. Create a bulleted list in OOo Writer 2. Use Up and Down Arrow to read the text Expected results: Each time you arrow to a line with a bullet character, you would hear the bullet as part of the line contents. Actual results: Each time you arrow to a line with a bullet character, you do not hear the bullet as part of the line contents. However, if you are using espeak with gnome-speech instead of speech dispatcher, this problem does not occur; bullets get spoken as you'd expect.
I'll take this one. I first need to verify patch for bullets and numbering works on my box OK and then I will proceed. I will get this working in both Speech Dispatcher as well as OpenTTS. I will probably test OpenTTS first as that is my current default situation.
So far, all current test has been done with OpenTTS and Gnome-Speech Services. While testing, I tried two different bulletting styles and made the following observations. First, I used the solid round bullets. With OpenTTS, I actually got the bullets to speak when I changed punctuation level to All. With gnome-speech, punctuation level did not seem to be a factor. I should also note here that the unicode value for this style is 2022. I then tried the other bullet style available to me, described by Orca as "Solid right pointing arrow" or something close to that. This bullet did not speak in either gnome-speech nor OpenTTS but flat review showed me that the unicode value is 2794. What I'm not sure at this time is where these pronunciations come from; wheather these come from a dictionary some place in Orca or if in the factory modules. I'll look there next unless someone knows this already.
Thanks for tackling this Steve. I totally owe you! chnames.py has the defined pronunciations. What I suspect is happening when you set your punctuation level to all is that we're adjusting what we send to the synth from the symbol to the spoken equivalent. The question is, what's happening when you navigate by line. And without digging into the code myself, I couldn't tell you. Having said that, as questions come up and you need me to dig into the code, I will. In the meantime, I want to tackle some more of these OOo issues.
Yes, while in chnames.py, I found an error where '2794' had been transposed to '2974'; the correct value is indeed '2794'. I tested again and the "right pointing arrow" description is now spoken when gnome-speech is used. When speech dispatcher or opentts is used, punctuation level needs to be set to All and then ths original round bullets speak but the right pointing arrow is not but an audio sound is uttered. I'm guessing this has to do with speech dispatcher itself. I think for sake of consistency, this should be made to be the same behavior. But this also runs into the differences with punctuation characters and how gnome-speech is different from speech dispatcher. One other observation I should point out is when the bulletted items are looked at and if I use the left and right arrow keys, The spoken symbol is "bullet" for the round circle but for the right arrow, Espeak says "symbol 2794" which runs the same route as other non speaking characters under speech dispatcher / opentts. The fact that speech dispatcher and friends get u'2022' as bullet, we should be able to get u'2794' to speak "right pointing arrow."
Created attachment 162505 [details] [review] Updates speechdispatcherfactory.py and opentts.py to pronounce bullets regardless of punctuation settings. I still see one minor problem with this patch. When you are in ALL punctuation mode, periods are being spoken twice as in "dot dot". If you set punctuation to any other value, then periods are not spoken and everything else appears to work properly. With my tests, I can get Orca to speak two bullet styles by reading through line by line with any punctuation level. Another side effect of this patch is, capital letters are now pronounced with the pitch change instead of "Capital" every time. This is because I incorporated the character substitution logic that was in gnome-speech. I made this change to both Speech Dispatcher and OpenTTS factory modules.
Review of attachment 162505 [details] [review]: Thanks for doing this Steve. With respect to this: + # Used to keep a list of character offsets into the new text string, + # once it has been converted to use verbalized punctuation, one for + # each character in the original string. + # + self.textCharIndices = [] That should be defined in __init__(). With respect to this: > I still see one minor problem with this patch. Do you have a fix for it?
Concerning your first point, which file are you referring to? I guess I'm too lazy to figure out which file to look at and fix per your suggestion. To answer your second question, the answer is "No." I haven't been able to figure that out; I could use some help in this area. I'm not even sure how many people have observed this. That's why I mentioned something to the list, hoping for some other feedback or possible ideas causing this behavior. I did see one post suggesting something to do with periods possibly used to terminate a block of text to be spoken though I'm not very sure about that.
Hi Steve, (In reply to comment #7) > Concerning your first point, which file are you referring to? I guess I'm too > lazy to figure out which file to look at and fix per your suggestion.. please install pylint and run the included pylint script on your code and you will find out where the issues are. at the root of the orca code, do make;sudo make install then ./run_pylint.sh > To answer your second question, the answer is "No." I haven't been able to figure > that out; I could use some help in this area. I'm not even sure how many > people have observed this. That's why I mentioned something to the list, > hoping for some other feedback or possible ideas causing this behavior. I did > see one post suggesting something to do with periods possibly used to terminate > a block of text to be spoken though I'm not very sure about that. Yes, sorry I should have picked you up on this one earlier. If in the orca gui you disable "break speach into chunks" check box you should not hear the double speaking of dots. If this is the case, then it is a known issue, bgo#591709 And it isnt a side effect of your patch. If the issue goes away, when the checkbox is unchecked, then please leave a comment to that effect on that bug, so that we can track what is effected by it.
(In reply to comment #8) > Hi Steve, > > Yes, sorry I should have picked you up on this one earlier. > If in the orca gui you disable "break speach into chunks" check box you should > not hear the double speaking of dots. > If this is the case, then it is a known issue, bgo#591709 > And it isnt a side effect of your patch. > If the issue goes away, when the checkbox is unchecked, then please leave a > comment to that effect on that bug, so that we can track what is effected by > it. Alas, that suggestion did not work for me. I get the exact same behavior when I unchecked the "breaking into chunks" option. Iguess I'll have to pour over this code some more. I think it has to do with my inclusion of logic from gnome-speech although gnome-speech doesn't exhibit this behavior. What I think might be happening is when we change to "All" punctuation mode is perhaps speech dispatcher is telling espeak to speak anything that comes to it and then we are also substituting or inserting punct marks under special cases. For example, there is special logic to force include periods and colons for speaking of file/path names and URL information. That special logic enables the speaking of these additional punctuation marks with lower punct levels. At least this is what I think; now to some-how stop that but use the feature to speak these other symbols like bullets and the like. Without the special logic, you would have to turn on punctuation level to "All" in order for this to work right. See the conflict?
(3.0 Planning Spam-o-rama. Sorry!)
Created attachment 166476 [details] [review] Corrects speaking of large right pointing arrow and enables consistent speaking of bullets regardless of punct levels In this patch, the definition of textCharIndices was moved to __init__(); this was done in speech-dispatcher and opentts.
I used pylint on the opentts and speechdispatcher factory modules specifically and noticed the suggestion concerning the placement of textCharIndices. There numerous other suggestions which should probably be addressed but I'm not sure of their severity. Also, to repeat my last comment, the altering of the speaking in chunks checkbox did not have any effect on the extra periods being spoken. This thing works great as long as punct level is not set to 'All'.
And if puct level is set to 'All' it double speaks not just periods.... We need to resolve this. I'll take a look....
Created attachment 166896 [details] [review] Proposed patch * Eliminates the aforementioned double-speaking issues * Is more consistent with the current implementation, which largely defers to SpeechDispatcher/OpenTTS for the presentation of punctuation * Solves the reported problem * (Is a fix needed for a related GCalctool bug I need to file) Please test. Thanks!
Review of attachment 166896 [details] [review]: I just arrowed around briefly on a website and then went to my OOo document where I had my bullet samples and numbered lists. I did this testing with both punct level of Most and All. All bullet items spoke properly with both punct levels and I only heard one period whenever I had punct level set to All. The only minor issue I notice now is I hear periods spoken after items in the Nautilus list table like file names and file sizes; this only happens when punct level is set to All. I think this goes back to a really old problem that might be with gnome-speech too; can't remember for sure. Other than that, I would say the patch looks good to me. Sorry for not getting this all figured out myself. Also should note that any bit of going back to being more similar to gnome-speech did not undo the implicit improvements in handling of capital letters with Speech Dispatcher and Open TTS.
Hey Steve. Thanks so much for giving this a spin! I'll have something else for you to try shortly, whereby we properly speak superscripts and subscripts even with multiple digits. It's actually kinda cool. <grins foolishly> In the meantime, about this: > only minor issue I notice now is I hear periods spoken after items in the > Nautilus list table like file names and file sizes; this only happens when > punct level is set to All. And for me that happens without my patch. > I think this goes back to a really old problem that > might be with gnome-speech too; can't remember for sure. I believe it's that in some cases we're added a final period for prosody when presenting objects. The act of adding a punctuation mark is probably not the smartest thing we could be doing. But I'll call that an issue for another day. <smile> > Other than that, I would say the patch looks good to me. Thanks! > Sorry for not getting this all figured out myself. Hey, it's a tough problem. It boils down to how much do we pre-process and how much do we just pass along? And the answer to that question seems to be based on two things: Who did the work and what synthesizers are being supported. Orca's gnome-speech module loves to pre-process; its speech-dispatcher module prefers to turn things over. This is an issue I'd like to (re)discuss on the devel list. > Also should note that any bit of going back to being more similar > to gnome-speech did not undo the implicit improvements in handling of capital > letters with Speech Dispatcher and Open TTS. Yeah, I ain't worried about capitals; I was more worried about unintended consequences this late in the came around punctuation.
Comment on attachment 166896 [details] [review] Proposed patch http://git.gnome.org/browse/orca/commit/?id=aff71a6dcc2eeadeb7144780d0f2b1b6d46ce09c
(In reply to comment #16) > > only minor issue I notice now is I hear periods spoken after items in the > > Nautilus list table like file names and file sizes; this only happens when > > punct level is set to All. > > And for me that happens without my patch. > > > I think this goes back to a really old problem that > > might be with gnome-speech too; can't remember for sure. > > I believe it's that in some cases we're added a final period for prosody when > presenting objects. The act of adding a punctuation mark is probably not the > smartest thing we could be doing. But I'll call that an issue for another day. > <smile> The issue being commented on is due to bug 591709 Which I will attend to shortly. Thanks