Raman,
1 isn't a problem at all. It is not necessary to feed multibyte
output into TTS engines because it is merely matter of choosing a
coding system for speaker process. For instance
(set-process-coding-system dtk-speaker-process
'cyrillic-koi8
'cyrillic-koi8)
If someone is interesting in more detaills it is possible to look into
multilingual speech server written by Igor Poretsky. Sources can be
found at
ftp://ftp.rakurs.spb.ru/pub/Goga/projects/speech-interfacemultispeech.tar.bz2
Best regards,
Dmitry
>>>>> "TVR" == T V Raman writes:
TVR> this patch does not solve the underlying reason why
TVR> emacspeak goes through the trouble of making sure the user
TVR> doesn't run emacs in multibyte mode.
TVR> 1) TTS engines barf on multibyte input at present.
TVR> 2) There are portions of emacspeak s own
TVR> internals (modules emacspeak-speak.el, dtk-speak.el and
TVR> dtk-tcl.el)
TVR> that have unibyte dependencies
TVR> Without the above being fixed --(and I dont plan to spend
TVR> energy fixing 2 while there is no solution to 1)--
TVR> there is no point in allowing the average user to run emacspeak
TVR> under multibyte emacs.
TVR> For cases where the user actually knows what he is doing,
TVR> e.g., Japanese Emacspeak --which I assumes handles
TVR> multibyte,
TVR> I expect that those versions will invoke emacs in multibyte
TVR> mode.
TVR> So the patch below is mostly meaningless since all it does
TVR> is to carefully undo the protection that was put into
TVR> emacspeak to avoid problems mentioned with running speech
TVR> with multibyte.
-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
subject of "unsubscribe" or "help"