[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bep] Patch: Allow Emacspeak to work with 8-bit characters
- To: bep@argv.org
- Subject: Re: [bep] Patch: Allow Emacspeak to work with 8-bit characters
- From: Koichi INOUE <inoue@argv.org>
- Date: 26 Jun 2001 11:31:07 +0900
- Delivered-To: mailing list bep@argv.org
- Mailing-List: contact bep-help@argv.org; run by ezmlm
- Organization: Accessibility Research Group for the Visually Impaired(ARGV)
- User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 01)SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae)APEL/10.3 Emacs/21.0.103 (i386-windy-freebsd4.3) MULE/5.0 (SAKAKI)
井上です。
WATANABE Takayuki <takayuki@...> writes:
> BEPでは他にも修正しているところがありますから、私も
> このパッチだけではマルチバイト文字問題は解決しないと思います。
行読みで読み上げない行がでるとかいろいろですね。
quailに関してはこちらでは入れていない変更だと思うので、もらってくるとよ
いかも知れません。
> Ramanの返事を見ると、BEPみたいに、ユーザが自己責任で勝手にいじるのは
> 構わないけれど、一般ユーザを混乱させる修正はしたくないみたいですね。
Japanese Emacspeakとか書いてますね。しっかり認知されていてよかった。
> マルチバイトを喋らすときは、それに対応したスピーチサーバがいるかどうか
> 確認すればよいだけの話だと思うから、1が理由になるのは変だと思います。
> そういう意味では、BEPでもスピーチサーバの能力を確認するステップを
> 入れるべきかも。
multibyte文字をしゃべれるかどうかはEmacspeak本体ではなくてスピーチサーバ
を制御する部分でだけ問題になるようにすべきなのでしょうね。今はDTK_TCL環
境変数でssをtclだと思って起動させているという状態なので、きれいにしない
といけないでしょう。
> 理由2に関しても、修正できると思うのだけど、これはもう一度ソースを見て
> みます。
先日ごにょごにょ言っていてまだ説明できる状態にいたっていないregexp問題と
か、Emacsがunibyteで動いているかどうかで変わってくる挙動に依存する部分を
探し出す必要があると思います。
ちなみに先日言っていたのは、dtk-tcl.elの
dtk-fix-control-chars関数内にあるspecialsというregexpです。
--
Koichi Inoue, ARGV
E-Mail: inoue@...
ICQ UIN: 74900690