GNOME Bugzilla – Bug 512608
Punctuation in keyboard review mode
Last modified: 2008-07-22 19:33:40 UTC
Please describe the problem: Punctuation characters are not read when reviewing text character by character. This problem only appears with the Speech Dispatcher backend. Steps to reproduce: 1. Select Speech Dispatcher Speech System with espeak synthesizer in Orca speech preferences 2. Go to a terminal or gedit window 3. Use keys 1-3 on numeric keypad to review the text character by character Actual results: Only characters which belong to the current punctuation level are read. Expected results: All characters including all punctuation should be read in this mode. Does this happen every time? Always with Espeak through Speech Dispatcher Other information: I've got a patch prepared so I will submit it soon.
Is this related to bug 440114?
(In reply to comment #1) > Is this related to bug 440114? No, this is actually a bug while 440114 is more an improvement.
Created attachment 103918 [details] [review] Use the speakCharacter() method of the speech server to force punctuation reading in character review mode The `speakCharacter()' method existed in the `SpeechServer' API, but was not used anywhere, since it was not present in the `speech' module. I added the corresponding function to the `speech' module and made use of this function within the default script. I also fixed its implementation in the Speech Dispatcher backend to accept also the newline character and apply voice styles for this command.
The patch also fixes upper case character recognition for keyboard review by character within the default script. The recognition was done by calling the `.isupper()' method on a UTF-8 encoded string. This works for ascii characters, but does not for most others, so it breaks internationalization . The same problem appears on many other places in Orca, but decoding UTF-8 encoded strings at every place where you need to work with unicode is not a solution. The true solution would be to work with Python unicode strings instead of UTF-8 encoded 8-bit strings - this is how the Python unicode support was meant to be used. You just decode all strings on input, work with unicode with all the advantages it has and encode it on output. This is, however, another story. Shall I submit this as a new bug so that we can discuss it there or is there a better place for such discussion?
Forgot to mention that the patch is against the gnome-2-20 branch. I can send one for trunk if this is a problem.
Created attachment 103950 [details] [review] The same patch against trunk This patch does the same as the previous one for Orca trunk plus it adds a fix to Speech Dispatcher version check which was broken in trunk after some pychecker related tuning.
I think these look fine. They pylint well, the changes seem sane, and it tests OK for me. Mike, can you give this one a shot? In addition, Tomas, can you give some more specific examples of the strings you typed in gedit and the various punctuation levels you tested this with? Finally -- if this tests well, we can check it in to both trunk and the GNOME 2.20 branch, but I don't think there is another GNOME 2.20.x release planned: http://live.gnome.org/TwoPointTwentyone. Thanks Tomas!
(In reply to comment #7) > can you give some more specific examples of the strings you > typed in gedit and the various punctuation levels you tested this with? Sample string: "abc*=+.,?". I tested with the level "Some" and "All". With "Some" only "abc" is read, with "All" everything is read. This is not correct, since we want to read all characters when reviewing the text chrarcter by character. The punctuation level should be ignored.
I've been testing this for a couple hours using gnome-speech and espeak. So far I haven't noticed any problem. seems safe to me
Committed the trunk branch.
Patch also committed to gnome-2-20 branch, though I'm not sure when the next release will be. Thanks for your work on this, Tomas!
Minor nit: I just ran the Firefox regression tests and my flat review by char test is failing because of what's getting logged. Example: Test 15 of 34 FAILED: /home/jd/orca/test/keystrokes/firefox/flat_review_text_by_word_and_char.py:flat review next char EXPECTED: [...] "SPEECH OUTPUT: 's'", ACTUAL: [...] "speak character='s'", Looking at the patch, I see: + debug.println(debug.LEVEL_INFO, "SPEECH OUTPUT: '" + character + "'") + log.info("speak character='%s'" % character) Is there any reason why the log.info needs to be "speak character=" rather than "SPEECH OUTPUT:"?
Created attachment 104093 [details] [review] Patch to hopefully fix the "speak character" vs. "SPEECH OUTPUT" problem I'm sitting in a hotel room very tired and something else is tying up my machine so I cannot run the regression test suite, but I think this patch should fix the problem. I checked it in with the confidence that I'm not that tired. But, that will guarantee I screwed it up. I'll run the regression tests when I get a chance, but that might not be until this weekend.
Thanks Will. Re-running the FF tests now to see <strike>what breakage the latest FF build will bring</strike> if your patch addresses the issue. ;-) Earlier today during some manual testing I noticed a diff w.r.t. the speaking of a single punctuation character, but that might be my imagination or a coincidence. I'll investigate more tomorrow when I'm less tired. Time to read a book. You, get some sleep. :-)
(In reply to comment #12) > Is there any reason why the log.info needs to be "speak character=" rather than > "SPEECH OUTPUT:"? Hi Joanie, sorry for that annoyance. I'll be more conservative about logging next time. Thanks for the fix, Will.
(In reply to comment #14) > Thanks Will. Re-running the FF tests now to see <strike>what breakage the > latest FF build will bring</strike> if your patch addresses the issue. ;-) > > Earlier today during some manual testing I noticed a diff w.r.t. the speaking > of a single punctuation character, but that might be my imagination or a > coincidence. I'll investigate more tomorrow when I'm less tired. Time to read > a book. You, get some sleep. :-) Did your testing showing anything bad?
Heh. Not sure. But right now I'm chalking it up to FF changes and weirdness and bugs (oh my!). Since I am currently focusing on the accuracy and performance of the line nav, the absence/non-speaking of the occasional punctuation mark is on the back burner. I suggest this bug gets closed out and anything that needs doing w.r.t. FF, I'll open a new bug for. Make sense?
Makes sense to me. Thanks!