GNOME Bugzilla – Bug 167810
dectalk driver may report wrong markers
Last modified: 2005-03-22 09:49:26 UTC
When large pieces of text are sent to dectalk tts, the tts callback is not called for all markers. Because of that not all markers in the index_marker_queue are presented by the driver. All markers before the current one in that queue shoud be presented in the callback.
Created attachment 37644 [details] [review] proposed patch
Created attachment 38204 [details] [review] reworked patch
Created attachment 38885 [details] [review] proposed patch Strings with length 0 can be sent to DECtalk and this is not good. The patch solves this problem.
Created attachment 38892 [details] [review] reworked patch
Comment on attachment 38892 [details] [review] reworked patch I'm a little concerned about the use of g_ascii_isspace(); can we use something UTF-8-safe here? Otherwise patch looks good. Please remember when replacing patches, to mark the old ones obsolete. Thanks
Comment on attachment 38892 [details] [review] reworked patch please replace usage of g_ascii_isspace with g_unichar_isspace (you'll have to use g_utf8_get_char() to obtain the unichar to check).
Created attachment 38902 [details] [review] reworked patch g_ascii_isspace() was used before I made the changes.
Comment on attachment 38902 [details] [review] reworked patch the problem with the text handling where you look for spaces is that you are using "++c" instead of properly incrementing the UTF-8 character position. This will fail for non-ASCII text strings! Of course, this problem has been there before you started submitting this patch, but it does need to be fixed.... thanks!
Created attachment 39006 [details] [review] reworked patch
Comment on attachment 39006 [details] [review] reworked patch ... > /* Add index between words */ > > while (*beginning) { > end = beginning; >- while (*end && !g_ascii_isspace(*end)) >- end++; Oana: I don't understand why the first 'while' below is needed now, and wasn't needed before. It seems to subtly alter the logic. Otherwise this looks good, thanks! >+ while (*end && g_unichar_isspace(g_utf8_get_char (end))) >+ end = beginning = g_utf8_next_char (end); >+ while (*end && !g_unichar_isspace(g_utf8_get_char (end))) >+ end = g_utf8_next_char (end); > word = g_strndup (beginning, end-beginning); > dectalk_add_string (d, word); > g_free (word); > dectalk_synthesis_driver_add_index(d, > speaker->cb, > GNOME_Speech_speech_callback_speech_progress, >- text_id, end-text); >+ text_id, end-text, marker_id++); > if (!*end) > break; >- beginning = end+1; >+ beginning = g_utf8_next_char (end); > }
If the string text sent to be spoken by DEctalk contains many spaces one followed by another then strings with length 0 are sent to DECtalk. For example, if the string "1 2" is send to be spoken, then the following strings are sent to DECtalk: "1" "" "" "" "" "" "2" (I used quotation marks just to see better the strings sent to DECtalk) If many strings with length 0 are sent (one after another), DECtalk crashes. I seen this behavior in 'flat review mode'. We found that this problem should be fixed, too.
Comment on attachment 39006 [details] [review] reworked patch Please apply, after thorough testing.
Comment on attachment 39006 [details] [review] reworked patch Patch committed to head.