After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 612405 - [blocked] Espeak punctuation level sometimes causes switching to phoneme mode.
[blocked] Espeak punctuation level sometimes causes switching to phoneme mode.
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: speech
2.29.x
Other Linux
: Normal normal
: ---
Assigned To: Trevor Saunders (IRC: tbsaunde)
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-10 10:31 UTC by Hammer Attila
Modified: 2010-08-17 11:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The debug.out possible show what the problem. (40.18 KB, application/octet-stream)
2010-03-10 10:31 UTC, Hammer Attila
Details

Description Hammer Attila 2010-03-10 10:31:33 UTC
Created attachment 155718 [details]
The debug.out possible show what the problem.

Dear Developers,

Hungarian Ubuntu translation coordination happening with a Vikipedia page. When I would like editing this Viky document because I doed new translation, if the cursor go to following type strings, Orca sent not understable string with Speech-dispatcher, and impossible understanding the spokened output. I am using Ubuntu 10.04, Speech-dispatcher with Espeak builtin module (Espeak 1.43.02 latest stable version) and latest Git master Orca version.
The problematic string type is following:
|| - ||[[https://translations.launchpad.net/ubuntu/lucid/+source/app-install-data-ubuntu/+pots/app-install-data/hu

When Orca punctuation setting is not none (some, most or all), the spokened speech output is not understamble, Speech-dispatcher spokened a full incorrect text.
I not see any useful information with debug.out file. When I turn Orca punctuation setting with none, this problem is not present.
The generated speech results is following:
generate speech results:
  szerkesztőmező
  || - ||[[https://translations.launchpad.net/ubuntu/lucid/+source/app-install-data-ubuntu/+pots/app-install-data/hu
  <orca.speech_generator.Pause instance at 0x8a3fc4c>
  Gépelje be a kért információt, vagy módosítsa a meglévőt.
SPEECH OUTPUT: 'szerkesztőmező || - ||[[https://translations.launchpad.net/ubuntu/lucid/+source/app-install-data-ubuntu/+pots/app-install-data/hu'
SPEECH OUTPUT: 'Gépelje be a kért információt, vagy módosítsa a meglévőt.'

I wroted this problem with Jonathan Duddington Espeak Developer, this problem is possible not Espeak related, because if I test this problematic string with Speech-dispatcher spd-say utility, the string is spokened correctly.

Attila
Comment 1 Trevor Saunders (IRC: tbsaunde) 2010-05-25 04:43:32 UTC
 Hey,

just saw this one, i can confirm that this is a bug in openttsd or the espeak module.  I'll open abug at opentts.org and report back.
Comment 2 Mesar Hameed 2010-06-07 23:27:43 UTC
Just heard back from Trev, (Thanks Trev for chasing this one!)

--cut--
Actually we've figured this one out.  Its not our bug though its an
espeak bug.  run the following espeak --punct '||[[da'.  Basically espeak
interprets stuff between  a a pair of '[' and a pair of ']' as phonemes.
However we tell espeak we don't want this behavior, but there's a bug
in espeak particularly it still treets double | followed by double '['
as if the following text is phonemes.  We've emailed Jhonathan pointing it out.
--cut--

Trev, when the issue is resolved, please give us the espeak version that it is fixed in, and feel free to close this one after checking that it is indeed fixed.

hmm, i dont think espeak has a bug tracker, does it, A suggestion for Jonathan?
Comment 3 Chris Brannon 2010-06-17 14:45:38 UTC
It is fixed as of eSpeak 1.43.42, which is a testing version.
Not sure when the next stable release will be.
Comment 4 Trevor Saunders (IRC: tbsaunde) 2010-08-17 11:33:05 UTC
ok, the current version of espeak on espeak.sourceforge.net is 1.44.03 so this is fixed in stable espeakThis problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.