Emacspeak controls the synth a lot more aggressively, which in this case
is a very good thing. There was some talk a while back about having
speech dispatcher handle unicode stuff, but so far only Emacspeak has
pushed ahead in this regard, tapping into Emac's list of Unicode
characters and their meaning. Since that's open source, I see no reason
why all that info couldn't be pulled from Emacs and put into eSpeak or
Speech Dispatcher, depending on if people think the synth should do all
the work, leaving out all others in the process, or if the speech server
should do the work, which would include all synths it supports and would
reduce the work load to one system, instead of lots of smaller ones.
That's just my idea though. I support all operating systems, and the
people that make them better for all people.
On 11/3/2016 10:49 PM, Jackie McBride wrote:
Jeffery, you don't tell us what synthesizer you're using w/Orca, but
the truth is it's the tts engine that really handles the language
aspects, as opposed to the screenreader itself. ESpeak, Flite, etc,
all have I18N capabilities, I believe, & these are all being used
w/Orca. I'm not familiar w/sbl, but here again, if it will work w/a
different synthesizer than what you're currently using, give that a
try & see if things are better.
On 11/3/16, Devin Prater <r.d.t.prater@xxxxxxxxx> wrote:
Emacs, with Emacspeak, can handle most, if not all, Unicode characters,
even emoji!
On 11/3/2016 9:24 PM, Jeffery Mewtamer wrote:
English is the only language I'm fluent in, and among the languages I
know more than a few words of, many of those words have been imported
into English anyways, but I still come across enough non-Latin text
for short comings in internationalization to be annoying.
In graphical mode on my desktop, I use Orca(do there even exist
graphical screen readers for Linux other than Orca), and it handles
non-English Latin text well enough, but for some non-Latin character
sets(such as Greek, Hebrew, and Arabic), it can only read
character-by-character instead of string characters into words, and
for others(such as Chinese and Japanese), it can only identify the
character set and then repeat the word "letter" for each character in
the string, and then there are some characters Orca can't identify at
all and just reads the Unicode code point in Hexadecimal.
This can be particularly annoying when reading wiki pages that are
heavy on foreign terms that are displayed both in their source
language and Romanized.
My text-mode screen reader, SBL, has even bigger issues, reading
pretty much all non-ASCII characters as "thorn", and can't even handle
things such as accented Latin characters or the curly versions of the
single and double quotes.
If anyone knows anything I could try to improve these, it would be
greatly appreciated.
If it matters, I'm running a system customized from Knoppix 7.7.1,
which is based on Debian.
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list