GNOME Bugzilla – Bug 573282
consistent (per module) character naming with speech-dispatcher backend
Last modified: 2009-03-17 19:36:30 UTC
From mailing list, '"' when typed is said double-quote but when deleted or arrowed over quotes is heard. '#' is said as pound when typed, but said as number when arrowed/deleted. The to be attached patch should resolve this.
Created attachment 129575 [details] [review] rev 1 Hi Tomas, I was looking into why we are hearing diffrent character names when a key is pressed (inserted) or deleted in orca, verses when we arrow over them. I think I have found a little bug with the ibmtts backend, and maybe you can varify it? on the command line, doing spd-say -o ibmtts ">" i hear "greater than" spd-say -o ibmtts "<" i hear "less than" which is correct. when orca does: self._send_command(self._client.char, ">") or self._send_command(self._client.char, "<") I hear nothing. all other characters work as expected. maybe a bug on the espeak backend: spd-say -o espeak "<" i hear "r angle r angle stroke speak l angle" self._send_command(self._client.char, "<") correctly speaks "l angle" Could you share some light on this? Thank you for your help. -Jon
(In reply to comment #0) > From mailing list, '"' when typed is said double-quote but when deleted or > arrowed over quotes is heard. > '#' is said as pound when typed, but said as number when arrowed/deleted. > The to be attached patch should resolve this. > Hello Jon, thank you for your effort. The problem is, unfortunately, not in the SD backend. The problem is in the speech synthesizer engine and should be fixed there. KEY_NAMES should not be changed, since it is designed to translate key names according to the SSIP specification. Using it for other purposes would break things. The backend now leaves all verbalization up to the synthesizer. It makes no sense to violate this rule to fix separete problems of synthesizers. The only other option is to do the verbalization *completely* before the text is sent to the synthesizer as suggested in bug #440114. Best regards, Tomas
(In reply to comment #1) > I think I have found a little bug with the ibmtts backend, and maybe you can > varify it? Unfortunately I don't own ibmtts license, so can't verify with this one. > on the command line, doing > spd-say -o ibmtts ">" i hear "greater than" > spd-say -o ibmtts "<" i hear "less than" > > which is correct. > > when orca does: > self._send_command(self._client.char, ">") or > self._send_command(self._client.char, "<") > I hear nothing. Normally I would recommend checking the punctuation mode, but in case of ibmtts, I not sure whether the punctuation settings are respected correctly. > maybe a bug on the espeak backend: > spd-say -o espeak "<" i hear "r angle r angle stroke speak l angle" > self._send_command(self._client.char, "<") correctly speaks "l angle" This seems like some incorrect interaction with SSML in spd-say. It might be better to report these problems on the Speech Dispatcher mailing list (http://lists.freebsoft.org/mailman/listinfo/speechd). Regards, Tomas
(In reply to comment #2) > Hello Jon, thank you for your effort. The problem is, unfortunately, not in > the SD backend. The problem is in the speech synthesizer engine and should be > fixed there. KEY_NAMES should not be changed, since it is designed to > translate key names according to the SSIP specification. Using it for other > purposes would break things. > The backend now leaves all verbalization up to the synthesizer. It makes no > sense to violate this rule to fix separete problems of synthesizers. The only > other option is to do the verbalization *completely* before the text is sent to > the synthesizer as suggested in bug #440114. > Best regards, Tomas Hi Tomas, Ok, I agree that KEY_NAMES should not change. but why does speakKeyEvent use KEY_NAMES, and speakCharacter does not? Do you agree that either both of them should use KEY_NAMES or neither should use it? Thanks for your quick reply.
(In reply to comment #1) > self._send_command(self._client.char, ">") or > self._send_command(self._client.char, "<") > I hear nothing. Could you please try to turn on the "protocol" log in speech dispatcher. You will find the option in your speechd.conf. This would reveal what is actually sent to SD in this case. The same would help to track down the problem with espeak and spd-say. A more convenient way to test this would be from python directly: >>> import speechd >>> c = speechd.SSIPClient('test') >>> c.char('<') If the communication seems ok in protocol log, you can try to increase SD logging level or output module debugging and check the log files. See speechd.conf and output module configuration files for these options. Thank you for your cooperation. Tomas
(In reply to comment #4) > Ok, I agree that KEY_NAMES should not change. > but why does > speakKeyEvent use KEY_NAMES, and > speakCharacter does not? Because the CHAR command in SSIP accepts a unicode string, but KEY accepts symbolic key names. In Orca backend, we are using the KEY command only for printable characters. KEY_NAMES provides translation of printable characters to symbolic key names. See http://www.freebsoft.org/doc/speechd/ssip_8.html for more information. Thus KEY_NAMES may only be used in speakKeyEvent. No conversion is needed for the CHAR command. It is up to the synthesizer and also its SD module to speak the same things consistently. The problem must be solved there. As I said, the other option is to bypass this complexity completely by handling everything in Orca before sending it to the synth. Mixing these two approaches would lead to a never ending chain of problems. Best regards, Tomas
Created attachment 129795 [details] [review] rev 2 Ok, this patch does not touch key_names, so the user experience is still inconsistent in terms of quotes and double quotes, underScore vs underscore. We are now consistent for: £ (pound), # (number or hash), ¬ (optional hyphen, or logical not) consistent, refers to what is heard when the given symbol is pressed on the keyboard vs when the symbol is deleted.
Well, probably all printable keys are single characters, so what the current patch effectively does is replacing the KEY command by the CHAR command. Since the symbolic key names should only be used with the KEY command, using them for the CHAR command is not correct. So if we decide to use CHAR instead of KEY, we should not use KEY_NAMES at all. This translation should only be performed if KEY command is used. Another question is, whether it is correct to replace the KEY command by the CHAR command. While I understand that it may work around the problem of espeak's inconsistency in pronouncing keys vs. chars, it may, and it will, break things for other synthesizers. For example the SD's Festival output module uses audio sample caching for key names. This increases Festival's responsibility in keyboard echo dramatically. Festival is hardly usable without this feature and users who prefer Festival (for example because there is no other free TTS for their language), would be seriously affected by this change. I'm sorry if I sound like repeating myself, but this problem really must be fixed in espeak or its SD output module, not in Orca. Orca does its job correctly, so there is no need to change anything in Orca. Would you, please, send a complete list of characters, which are pronounced inconsistently to the Speech Dispatcher mailing list? People there should be able to decide whether the problem is in espeak itself or its SD output module. Thank you for your help and for reporting the problem.
Hi Tomas, Still need to use the length check, since we get symbol 0 for both the _ key and the quotes key. It is printable, but is longer than one char. what about checking this in temporarily, because it gives us consistancy now. And when you have time to resolve bug #440114, then maybe this should be roled back. I have signed up and have mailed the speechd mailing list. -Jon
(In reply to comment #9) > Still need to use the length check, since we get symbol 0 for both the _ key > and the quotes key. > It is printable, but is longer than one char. Yes, but what I was trying to explain was that if you use the CHAR command, it is incorrect to use KEY_NAMES at all. You should pass `event_string' without any transformation to `self._send_command(self._client.char, ...)'. Without this transformation, underscore and double quote stay single characters. But this is only to explain the meaning of KEY_NAMES. Even if KEY_NAMES is used correctly, I don't think we want to change the code within Orca, since the code is correct. Problem is somewhere else and should be fixed there. > what about checking this in temporarily, because it gives us consistancy now. > And when you have time to resolve bug #440114, then maybe this should be roled > back. This will give consistency to espeak users, but it will break usability for festival users. Fixing espeak (or its SD driver) now will give us consistency now and for ever without unpleasant side effects.
closing as wontfix, due to the festival issues.