Speakup works with Czech language

[Hynek Hanke]

Hello Kirk,

I've some news for you regarding Speakup internationalization
and it's connection to Speech Dispatcher.

I'll describe now what's necessary to make it work
with Czech language in more detail:

1) speakup.c must be patched on one place. The spk_chartab
table is specific to iso-8859-1 and it doesn't work with
other codings (~l. 206, speakup.c), because in the extended character
sets, some symbols over 128 are also ALPHA or A_CAP, not just
B_SYM. If this is not changed, Speakup writes strange codes
of these keys into /dev/softsynth (not the codes defined
in iso-8859-2 for Czech, for example).

Since it's not desirable to change Speakup's code for every
internationalization and change it every time we want to use
a different language, I'd like to ask if it wouldn't be possible
to make this table accessible from /proc/speakup? So that users
are able to change it like they are able to change
/proc/speakup/characters.

Then for example speechd-up would be able to set this table
automatically, since there are routines in libc for telling
if a given character, according to the given locales, is
alpha, number or a capital alpha.

2) As for character reading and punctuation, /dec/proc/characters
needs to be changed, of course. But we think it would be desirable
if we could turn out these things in Speakup totally, so that
we could let the software TTSs handle this task. There are good
capabilities for processing punctuation and single characters in
Festival, it's configurable for every language etc. So it would be best
if Speakup just passes the "punctuation mode" DoubleTalk commands
like it does now and don't process the text itself alone. If only
one letter is passed, it's quite straightforward that it should be
read as a single character. Again, we would welcome no processing
on the Speakup's side.

3) Only some kinds of console screen fonts can be used for the
Czech language. I don't really understand why, but it doesn't
work with some console fonts, although all of them use iso-8859-2.
If I use a different font than iso02.fxx.psf, the codes of the
alphanumeric characters above 128 returned by Speakup don't correspond
with iso-8859-2. It doesn't work with e.g. lat2u-xx.psf or
lat2-sunxx.psf although these fonts are also iso-8859-2. I don't
know what's the difference in them from the Speakup's perspective.

But Mr. Buchal says it's the same with Brltty. The keycodes that
brltty reads are also different according to the currently used
console fonts.

So I have a question: Where does Speakup actually read the input
text from? Don't you know, how different fonts (although all working
in the same character set) could influence this?


If the above points are fulfilled, it works with Czech language.
Something more might be needed for some other language, but I think
this is sufficient for a large group of languages. We tested it
with Speakup (cvs) loaded as a module, Speechd-up (cvs) interface daemon,
Speech Dispatcher (cvs) and Festival 1.4.3.


I've setup CVS for this interface daemon between Speakup and Speech
Dispatcher which we called Speechd-Up to combine both names. Please
look at
        http://www.freebsoft.org/speechd-up
where there are information about the anonymous CVS acces and other
things. After having downloaded the module, please see the file named
INSTALL for more details about how to compile it.


I'd like to ask some more questions:

1) How does CAPS_START and CAPS_STOP work and where and why is it used?
It's not present in the documentation of the DoubleTalk protocol and I
somehow don't understand it.

2) Wouldn't it be possible to pass also some command for setting
language through /dev/softsynth? My idea is that the user could
switch between two or three languages just by pressing a Speakup
key shortcut. Then Speakup would send a command like ^XL2 or something
like that to /dev/softsynth, Speechd-Up would look for what it's
configured to do with language number 2, it would set the /proc/speakup/
tables accordingly, it would switch it's character set and synthesis
language and the user could continue using this language. This way,
software synthesis users would be able to easily switch languages.

I think this partially applies also to hardware synthesis where this
would be useful, but I'm not sure to what degree.

3) Speakup works fine!

Thanks for your comments,
Hynek