> Does anyone from the Orca team have an opinion on this?  Do you think that
> making such a configuration option is worth the trouble?  What about having it
> only in the config file and not in the GUI?  Or any other idea?

Tomas - I'm not sure I understand the proposal.  Can you describe more about what would be changed in Orca itself and what changes the user would see?

> Can you describe more about what would be changed in Orca itself and what
> changes the user would see?

Ok, I'll try...

Orca defines punctuation levels for all sorts of characters in the module `punctuation_settings.py'.  Then the method `__addVerbalizedPunctuation()' in `gnomespeechfactory.py' uses this information to verbalize punctuation according to current punctuation settings.  This is what I call "Orca controlled punctuation verbalization".

On the other hand, Speech Dispatcher leaves punctuation verbalization to the synthesizer.  This is intended, because punctuation verbalization belongs to the TTS layer (it is language specific etc.).

From the user's point of view it may be hard to decide what is better.

The first solution (Orca controlled) has the advantage of consistent behavior across all TTS engines and may provide better results with simple TTS engines which don't implement punctuation verbalization in such an extent as it is done by Orca.

The second solution may provide better results with more advanced TTS engines and will often be preferred with languages other than English.

So my suggestion is to make this configurable.  A new boolean option would decide whether we want to verbalize the punctuation before sending it to TTS or whether we want to leave the text as is and rely on the TTS to verbalize it.

I believe such an option is necessary.  I only don't know whether it is so important that we want to have it in the speech preferences dialog.  For the beginning, it might be enough to have it in the config file.

I can imagine several ways how to implement this.  The simplest solution would be to move the `__addVerbalizedPunctuation()' method to the generic speech server class.  The speech server would be responsible for using it when Orca controlled verbalization is enabled or setting the correct verbalization mode in the TTS when it is disabled.  More about implementation if we agree about the overall goal of this feature...

Does it make sense now?

> On the other hand, Speech Dispatcher leaves punctuation verbalization to the
> synthesizer.  This is intended, because punctuation verbalization belongs to
> the TTS layer (it is language specific etc.).

I think one can make an argument either way, but I definitely would prefer that the TTS layer handle this for us.  Unfortunately, not all TTS engines handle this, so we needed to do it ourselves.

> So my suggestion is to make this configurable.  A new boolean option would
> decide whether we want to verbalize the punctuation before sending it to TTS or
> whether we want to leave the text as is and rely on the TTS to verbalize it.

Sounds reasonable.

> I believe such an option is necessary.  I only don't know whether it is so
> important that we want to have it in the speech preferences dialog.  For the
> beginning, it might be enough to have it in the config file.

Sounds reasonable.

> I can imagine several ways how to implement this.  The simplest solution would
> be to move the `__addVerbalizedPunctuation()' method to the generic speech
> server class.  The speech server would be responsible for using it when Orca
> controlled verbalization is enabled or setting the correct verbalization mode
> in the TTS when it is disabled.  More about implementation if we agree about
> the overall goal of this feature...

I think this sounds reasonable, too.  The speech stuff is in dire need of refactoring as well.  We've been bantying this about for a while, and I think we've decided that the major refactor should happen around the beginning of the GNOME 2.22 cycle.  

But, the minor refactor proposed here sounds useful, especially if you provide a patch.  ;-)

BTW, one problem we've run into with Orca doing its own verbalized punctuation is being able to map speech synthesis events back into the original non-verbalized punctuation string.  Right now, we get synthesis events for the verbalized punctutation string, which throws off our ability to accurately position the caret when speech stops or is interrupted.

> BTW, one problem we've run into with Orca doing its own verbalized punctuation
> is being able to map speech synthesis events back into the original
> non-verbalized punctuation string.  Right now, we get synthesis events for the
> verbalized punctutation string, which throws off our ability to accurately
> position the caret when speech stops or is interrupted.

See also bug 439191 for more discussion on this.

Tomas - where are we with this bug?

(In reply to comment #5)
> Tomas - where are we with this bug?
> 

I plan to implement that as suggested, but I am currently focusing more on higher priority features, such as synthesizer/voice selection etc.

First coarse pass at GNOME 2.24 planning.

Moving to FUTURE since this depends upon an external party (Tomas).

Tomas, I see an interesting problem when I using Speech-dispatcher with Orca.
If I use gnome-speech driver and Espeak, all translated punctuation characters spokening correct (", / etc) if the orca punctuation setting is most.
When I using Speech-dispatcher, the following punctuation characters is spokening different (I write few examples, not all problematic characters):
The " character: If I using gnome-speech driver, the correct hungarian translated character text spokening (idézőjel word). If I using speech-dispatcher, Espeak says double quote word when I type the " character.
! character: speech-dispatcher says felkiáltó word, gnome-speech driver says felkiáltójel word.
Lot of punctuation characters spokening different with speech-dispatcher and gnome-speech driver.
I think the problem is following, but I am not sure and need your hint:
Lot of characters not add, or not correct add with Espeak hungarian language file, because before not happen gnome-speech driver replacement with Speech-dispatcher, not need to do this task, because all needed characters translation handled with src/orca/chnames.py and src/orca/punctuation_settings.py file.
My question: Enough Only I edit the Espeak hungarian language table and send Espeak developer, or need modification with Orca source code or Speech-dispatcher source code? The purpose the bugfix: equals translated punctuation character translations with gnome-speech driver and Speech-dispatcher spokening output.

I try configure Speech-dispatcher punctuation settings to most with .speech-dispatcher/conf/speechd.conf, but not solve my problem. I add following line with need place:
DefaultPunctuationMode "some"
I use espeak sinth module, and I do orca client conf file with .speech-dispatcher/conf/clients/orca.conf with following lines, but not help:
# Local configuration for Orca
BeginClient "*:orca:*"
    DefaultLanguage "hu"
DefaultPunctuationMode "some"    
DefaultCapLetRecognition "none"
EndClient
I included correct with orca client configuration file with end of .speech-dispatcher/conf/speechd.conf:
Include "clients/orca.conf"

This punctuation problem only present if I choose Speech-dispatcher with Orca preferences gui/speech tab in speech system combo box, and I choose espeak with speech sinthesizer combo box.
If I choose gnome-speech driver in Orca preferences gui/speech page in speech system combo box and choose Speech-dispatcher Gnomespeech Driver in speech sinthesizer combo box, this problem not present.

Attila

Hi Attila, Yes, what you see is exactly the known behavior which this proposal tries to resolve.  Currently all punctuation processing is left up to the synthesizer, when you use SD backend, as oposed to gnome speech which processes punctiation before sending to synthesizer.  So if translations are missing/bad in the synth (such as Hungarian in Espeak), you will get bad results with SD, while if the translations are missing/bad in orca, you wil get bad results with Gnome Speech.

This bug report proposes to make the processing optional with SD, so that the user can choose whether he/she prefers the punctuation processing provided by Orca or by the synth according to his preference (which mostly depends on the quality of the translations provided for given language).

Until this is implemented, the only solution is to improve the Hungarian translations in Espeak (which is a good idea anyway).  The Espeak author is definitely very cooperative and will help you with that, I believe.  No changes in SD or Orca are needed for that to happen.

Thank you Tomas,
I go edit Espeak hungarian language file.
I have one question, and after this I try not disturb you. :-):-)
Now I defined the "double quote" word with hungarian mean idézőjel word (this word says Espeak when I type or navigate this character with left or right arrow correct) in Espeak hu_list file.
But if I press up or down arrow key, I not hear this character word, for example the following text:
"Hello Tomas!"
Espeak only says when I using Speech-dispatcher:
Hello Tomas!
The correct wishing text is if the punctuation setting is most in Speech-dispatcher configuration:
Idézőjel Hello Tomas!idézőjel

This is a known issue with this situation?

Attila

Interesting. If I do following command (not using Speech-dispatcher) in gnome-terminal, Espeak says correct the idézőjel word:
espeak -v hu --punct "\""

Attila

The punctuation setting in SD configuration file determines the default value, but Orca initializes punctuation settings according to Orca configuration, so these settings should override the default values set in SD configuration file.

Are you sure you have set the maximum punctuation level in Orca preferences?  This should do what you want.  HTH, Tomas.

Yes Tomas, I try all punctuation setting with Orca, but unfortunately not help, nothing changed.
I configured Speech-dispatcher with all punctuation setting. I test spd-say, the setting is applyed correct when I using spd-say command.
After this I try configured Orca with all punctuation setting, for example the ( or ) or # character does'nt spoken Orca with text editors, gnome-speech driver spoken right this characters with most Orca setting.

I have no more ydea.
This problem is important, because Ubuntu developers possible replace default Gnome-speech driver with Speech-dispatcher in Ubuntu Karmic final release.

Attila

Created attachment 140110 [details]
My Speech-dispatcher configuration file.

This is my Speech-dispatcher main configuration file.

Created attachment 140111 [details]
Orca client configuration file.

This is my Orca client configuration file.

Created attachment 140112 [details]
Espeak module configuration file.

This is my Espeak module configuration file.

There are differences between what Gnome Speech and Speech Dispatcher consider "most" punctuation.  Try setting Orca to read "all" punctuation.  Also, Speech Dispatcher recognizes only three punctuation levels, so "most" and "some" in Orca are currently both mapped to "some" in SD.  You should be able to configure the characters read for "some" punctuation mode in SD.  See the docs or ask at SD mailing list (I don't know from the top of my head).

Thank you Tomas your help.
Sure by sure, I try my prewious test with us english Espeak woice.
All works fine, so my prewious described problem is only hungarian language specific.

I hope finalize hungarian Espeak language file editing with relative short time.

Attila

Bulk reassigning Will's bugs to the default assignee. (Sorry for the spam!)

Tomas, what are your plans with respect to this bug? And is there something you need from us?

Planning spam. Sorry!

I will need to look at it again and see what is still relevant since I made the original research.  But I believe the main idea of having an option to process punctuation in orca or speech engine is still valid.

Thanks Tomas.

Shall we plan on your doing this in time for the 3.0 release or should we expect it to occur after that?

(In reply to comment #23)
> I will need to look at it again and see what is still relevant since I made the
> original research.  But I believe the main idea of having an option to process
> punctuation in orca or speech engine is still valid.

Hi Thomas, I'm priorizing all this bugs which depends on bug 614831. Can you, please, check if is still relevant this RFE?

Thanks!

Tomas, ping! :)

Oh, sorry for not being able to look at it yet.  This is just to let you know I'm alive.  I'll try to look at it next week.

I've just checked the current state.  It seems that the method __addVerbalizedPunctuation() has been moved from Gnome Speech to the SD backend already.  This means that Orca now performs punctuation verbalization also when Speech Dispatcher is used.

I still think that:
  * The method __addVerbalizedPunctuation() would better fit into

Sorry for spam, I commited the post before I finished it...  Here's the rest of the story.

I still think that:
  * The method __addVerbalizedPunctuation() would better fit into SpeechServer
    class rather than to any particular speech backend
  * It would be nice to have a configuration option to decide whether
    __addVerbalizedPunctuation() is used or whether punctuation verbalization
    is left up to the speech backend.  For some synthesizers and some languages
    it can make a significant difference.

But as the current state doesn't actually cause troubles to the users and no one seems to be complaining, I currently don't plan to put any effort into this issue.

Finally, the punctuation should really be handled in the speech backend and it should not be optional anyway.  One of the reasons is the lack of ability to map speech synthesis events back to the original text as noted by Will in comment 3.  If that starts to be a problem, someone may get back to this issue.

(In reply to comment #29)

> But as the current state doesn't actually cause troubles to the users and no
> one seems to be complaining, I currently don't plan to put any effort into this
> issue.

Okay, then in that case I am going to close it out.

> Finally, the punctuation should really be handled in the speech backend and it
> should not be optional anyway.

I would really like to not have to deal with punctuation at all. Can I totally leave it up to speech-dispatcher?

Joanie, now Speech-dispatcher if I using Orca with Espeak module spokening following simbols if I adding the simbols with .speech-dispatcher/conf/modules/espeak.conf file:
EspeakPunctuationList "@+_•\"\„()[]:-{}|%<>"
I using of course with most Orca punctuation setting.
For example, if I not using this list, not hear a code with { and } characters, and other important characters.
Previous with oldest GNOME Speech possibility most punctuation level automaticaly spokening this simbols, but if I using for example the none possibility, I not hear right this simbols.

Attila

Joanie, the old GNOME Speech textual punctuation character sending have a big adwantage prewious:
The method is full speech synthesis independent, and the punctuation texts is translatable in src/orca/chnames.py file. If a punctuation character are added, Orca absolute sure spokening the punctuation character associated text with proper punctuation level with proper locale translation text.
If you want remove punctuation related preference in Orca GUI preferences dialog, punctuation character spokening is handle only with Speech-dispatcher, with depending the actual used speech synthesizer. For example, english language users many speech synths are possible using, for example Festival, Voxin, Pico, Espeak, etc. Sure to all speech synths equals level spokening the proper punctuation simbol? I am not sure this.
If a non english language Orca handles with punctuation simbols, similar with old GNOME speech method, the punctuation character associated text spokening not depending the actual speech synth with the user using with Speech-dispatcher. If I for example translating the " character with Orca with idézőjel text, and Orca spokening this text, if future awailable hungarian language more speech synths with Speech-dispatcher, the hungarian user will be hear the " character associated idézőjel text, independent the actual hungarian language awailable speech synth.
Python-speechd prowide this possibility to Orca sends punctuation characters with text, not normal punctuation characters?
Speech-dispatcher now support following punctuation levels, I known only the 0.7 release awailable possibilities:
None, some, all.
If we changing Orca GUI preference dialog with punctuation preference, Orca dinamicaly change with Speech-dispatcher actual punctuation mode? Now Orca supports None, Fev, some and all punctuation modes.
If you tell me what can need testing to this bug is fixed future, I welcome try help you if you not have enough time now fixing this bug. If this bug future possible fixing, please remove the wontfix markup.

Attila

> I would really like to not have to deal with punctuation at all. Can I totally
> leave it up to speech-dispatcher?

Well, you can, but if you don't want to disrupt the user experience, its not that easy.  Orca now relies upon its own verbalization - Orca defines how is which symbol pronounced and there are translations of those pronunciations  into many languages.  In the simplest case, we can drop all that and send the text as is to Speech Dispatcher and only indicate what is the current punctuation level.  This will be the technically correct approach.  Speech Dispatcher will care about preserving the desired punctuation level in the synthesizer and the symbols will be pronounced when they should.  Each synthesizer, which supports a particular language, typically also has definitions of punctuation verbalization in that language so it should work in theoty.  So far so nice.  Practically, however, the result for the user will not be the same.  The user will often hear different pronunciations than he is currently used to.  I am sure many users will complain.  Atilla's concerns are quite valid.  You may actually get better results in some languages and with some synths, but even if the result is better in an absolute measure, most users will be confused, because it is a serious change of their user interface.  And in fact, the result will probably be worse as the Orca's pronunciations and especially their translations are now quite complete and fine tuned.

BTW, there has been a lot of noise in the past regarding this issue.  I and several other people from the Speech Dispatcher project were trying to push for this change, but there has been some strange resistance, probably given Sun's by "political" interests, I don't know.

Now, its gonna be a little harder to do, but if you really care, I believe it still could be done.  I can imagine two solutions.  Both of them require changes in Speech Dispatcher, so further discussion might be better in the SD list, but in a nutshell, we can either:
  A) Implement the support for user defined verbalization tables in SD  -- Orca
     would send the preferred verbalizations to SD on initialization.
  B) Implement verbalizations within SD and use the current definitions from
     Orca in SD.

In both cases it might be nice to let the user choose if she prefers the Orca's pronunciations or the synth's pronunciations (in case B its actually not Orca vs. synth, but SD vs. synth).  So we are back to the original subject of this bug report.  Case A would actually make it even more flexible -- the user could choose this per symbol and could even supply her own pronunciation.

There are also some quite interesting challenges regarding the support for multiple languages.  Let's say we have a user interface in English and read a Spanish text.  So we switch the current voice to a Spanish voice.  But now in which language should we pronounce the punctuation symbols found in the spanish text?  My gues is that it would be natural to still pronounce them in English, but that would require switching to an English voice to read the verbalized text.  The chosen solution should be open to such scenarios.

I'm not sure I am able to think of all consequences right now so it is possible that one or both solutions have some technical problem.

Hope I didn't discourage you totally :-).

Attila, sorry for misspelling your name in my previous post.  Hope you see that we know of the issues you mentioned and that the new solution would definitely need to address them.

Tomas, not matter, because both two form accepted with hungarian language.
Many my Attila named friends using newest Atilla name. Hungarian language is a very interesting language. :-):-)

Attila