[Top 側へ一つ移動]

  座長/発表者
(敬称略)
内容
余談    本日のシンポジウムが始まる前に同時通訳をする人が私のところに来て(!)
「IIIMECF って何でしょうか?」
「UTF-2000 ってやはり unicode のことでしょうか?」
「Devanagari って何でしょうか?」
 などと聞いてきた。全部知らなかった(!!)
 新部さんにきけば良いだろうということで二人して説明を聞いた。新部さんは
『やはりまずいな』
 と思ったようで、後で川端さん (Devanagari の件の発表者) がきた時に
「あらかじめ通訳の人にプレゼン資料を渡しておいてください」
 と言っていた。
オープニング 新部  
Status of Thai Supports in GNU/Linux/X Teppitak Karoonboonyanan  内容はタイトルのとおり。
  • ロケール部分の開発の歴史を紹介
  • 文字入力方法の実装の紹介
    • X11R6 時代、X11R6.1 時代…
    • フォントセットとして tis620 (-0: std, -1: w/ Mac ext, -2: w/ Win ext) が標準になった
  • TEX
    • Babel BASE の ThaiTEX
    • テレタイプフォントがまだ用意されていない
    • Ωはまだ対応していない?
  • Word Breaking の実装
    • SWASH: Smart Word Analisys for THai (昨日 Yanis Haralanbous 氏が使いたいといっていたツール)
    • Word Breaking Lib
Word Breaking はレンダリングエンジンの中にあったほうがいいだろう。
フォントセットは unicode のほうには動いてないのか?という質問には、そういう部分もあるが tis620 とパラレルに進むと思う、とのこと。
IIIMECF Hisashi Miyashita  IIIMECF (Internet Intranet Input Method Client Framework) の紹介。

 IIIMECF の必要性
  • ネットワーク透過性
  • クライアントサイドをサーバーサイドから完全に分離する
  • 多くの言語に対して中立なしくみを作る
 新プロトコル IIIMCP の内容
  • イベント・フォワードモデル
  • エージェント/ブリッジ/カスケードモデル
    • サーバー側からクライアント側に対して何でもできる要素があるとのこと
  • オブジェクトダウンロード機能
  • unicode ベース (この部分のみ特定の規格に依存している)
サーバーサイドについて
htt サーバーは実現している。 カスケード/エージェントサーバーはまだ?

クライアントサイドについて
  • IIIM Java Client Framework (IIIMJCF)
  • IIIM emacs Client Framework (IIIMECF)
    • 100% pure emacs Lisp Program
    • Library part is independent of IM Part
  • IIIM X Client Framework (IIIMXCF)
実演実施
  • Linux 上で ATOK X と中国語の IME を用意 (IIIMSF を通じて通信する)
  • 同じ PC 上で VMWare を使って Windows を起動。emacsを動かす
  • IIIMECF を通じて Linux 側の IIIMSF と通信し、文字入力を行なった
将来の予定
  • Multi Context
  • IIIMECF with IIIMSF の改良
    • サーバー側からの download 機能を emacs LISP で実現しようとするとセキュリティの問題が発生するので困っている
  • Bridge
(Li18nux) Hideki Hiura  前の宮下氏の話を含めた Linux の国際化の話。ロケールの話そのほかをしていたようですがついてゆけませんでした。

X に絡んで、国際化を進めるに当たり、古いプレゼン用のフォーマットの対応をやめることにした?(このセッションでの話だったと思うのですが…)

 国際化に対応させる Linux として RedHat, Kondara, (ともうひとつ何か)を先行させ、次に Debian を考えている。

 unicode について。発表者は country tag の設置には反対票を投じ (でも採択された) variation tag の設置には力を入れていると言っていた。これは私も正しいと思う。

 先日の文字鏡にかかわっている人から同じ質問が出た。
  • 中国語の unicode font には中国で使うだけの文字しか入っていない。日本の unicode font は日本で使うだけの文字しか入っていない。日本語・中国語が混在した文章を表示させようとするとどちらのフォントを使っても豆腐 (□) が出てしまう。これは何とかならないのだろうか?
    • 全文字種が入ったフォント作成のプロジェクトは考えている
  • ゴシックその他のデザインを取り揃えることを考えたら unicode で DTP はできないのではないか?
    • DTP をやろうと考えているのなら (既存の?) font をアプリケーション側で切り替えるのが正しい。DPT は“表示”の範疇を超え“レンダリング”の領域に入っている
    • 例えば Word (これが DTP ソフトかといわれると困るが) はフォントを切り替えて表示・印刷する機能を実現している。ああいう風にすべきだ
Bilingual Emacspeak Platform and Accessible Information Technology Koich Inoue, Takayuki Inoue  基盤技術は誰にでも使えるものでないと取り残されてしまう。技術は弱者 (障害者や老人など) をアシストできる。また近未来に日本は老人大国になる。こういった中での Emacspeak の二ヶ国語化は意義ある試みである。

Emacspeak
  • Raman 氏が開発 (「Blue Screen は嫌だ」ということで本人は Windows 版を作るつもりはないらしい)
  • emacs 上で動作 (screenreader ではない)
    • html を読んだとき <H?> のレベル変化やリンクの部分で声色を変えられる
    • 一字ずつ読むモード・文章を読むモード・表を読むモード
  • 英語のみ
  • Auditory Use Interface を通じで Speach Server にデータを送る
このソフトを元に Bilingual Emacspeak Platform (BEP) の開発をオープンソースで実施
  • 二ヶ国語化 (日本語発声部は商用ソフト)
  • Meadow 上で動作
  • ジャパニーズイングリッシュの発声が可能
    • 単語ごとに読まれるときはこちらが聞きやすい、とか
    • 英文を Native なのとジャパニーズで読み比べたとき「ジャパニーズのほうが聞きやすい」という冗談…だと思う…もでた
  • 読み分け
    • 漢字のホモニム (会:"a-woo no kai"、階:"kaidan no kai")
    • 全角半角読み分けA:"zenkaku no alpha"、B:"han-kaku no bravo"
デモ
  • メールを読み書きした
  • エラーが入ったプログラムをコンパイルし、エラー情報に従って修正・再コンパイルした
問題点
  • speech server の向上
  • 発声部が free でない
  • emacs をよく知らない人に教えなければならない
将来の予定・希望
  • 点字ピンディスプレイへの出力
  • 多言語環境の構築
  • 音声認識
  • Linux を視覚障害者と対話できる OS にする
  • …いろいろ…
これらの発表やデモは視覚障害者の方が行なった (その場にいたら自明なことでも文字だけではわからないのであえて記載した)。

“emacs はエディタでなく環境だ”という言葉を聞いたことがあったが、この発表で非常によく認識できた。
Usage of Meadow by Japanese visually Impaired Users Mitsugu Sakamoto  outSPOKEN という screen reader が日本語版になった。これを Meadow で利用しようとすると、カーソルの位置と発声位置が異なっていた (Focus の問題だとかなんとか)。Meadow の作者、宮下さんにお願いしてこの問題を解決してもらった。

デモ
  • 旧版 Meadow と改良版 Meadow での発声状態の違い
  • メールを書く
BEP があったら outSPOKEN はいらないんじゃないの?といった質問も出たが…
  • 点字ピンディスプレイへ出力可能
  • emacs 以外の Windows アプリケーションでも使える
というように outSPOKEN を手放せない点も多々あるようだ。また洋もの readerは Windows image を取り込んだ上で発声しているのではないかと思われるような、望んだような発声をしてくれるそうだ。
Progress in UTF-2000, and perspective of UTF-2000000000000 Tomohiko Morioka これまでの文字セットは整数値の番号に割り付けられた上で現実社会と関連していた。
[文字セット]→[キャラクタコード]→[現実社会]
そこで文字にオブジェクトとしての属性を持たせようと考えた。

[文字セット]→[オブジェクト]→[キャラクタコード]
             +−−→[現実社会]

UTF-2000 の 2000 はミレニアムということと UTF-7 や 同8 などに比べて景気よく行こうというところからつけた。その後継は UTF-二兆 (ということなので本物のレジメは 0 がひとつ足りない)。

この発表ではオブジェクト属性を emacs LISP で定義していた。UTF-2000 を定義するためには定義用の…要はメタな…文字セットが最初に必要ではないかと質問され、発表者はそれを認めていた。しかし、いったん定義が終わるとメタな文字セットは不要になるとのこと。
Devanagari implementation in emacs Taich Kawabata  Devanagari とはタミル語の文字のことらしい。←間違い。デーヴァナーガリーはヒンディー・マラーティー・サンスクリット・ネパール語などを表記するのに使う文字だそうです。(益山さんありがとうございます)

 以前発表者は emacs に Devanagari 文字処理系を移植しようとしたが、独自の文字セットを利用せざるを得なかったり、固定幅フォントしか利用できないなど不完全な結果に終わった。今回の発表では unicode を利用し、プロポーショナルフォント利用の許可を得るなどした上で新しいバージョンの emacs 上に移植を行なった。

 インドの文字のリガチャはかなり複雑…ほとんど変形合体ロボット並…で、emacs LISP 上で定義したテーブルを用いて変換する。変換テーブルはこれまであちこちで研究されたもの 3 種類を実装している。

 他のインド文字への展開は?という質問が出たが、発表者の興味の度合いと時間の余裕 (本業ではない) が問題だという返事だった。希望者が Devanagari 用変換テーブルにならってほかのインド文字のテーブルも作ってほしいとのこと。
Software patents and Europe Hartmut Pilch  ヨーロッパでは特許と認められる要件として“自然力を使ったもの”といった定義があり、ソフトウェア特許は認められなかった。しかしながら近年これを覆そうという動きがある。この動きを進めているのは弁理士や企業内の特許部が中心ではないかと考えている。企業として、あるいは会社員としてソフトウェア特許にメリットを見出さないことろは多くある。

 ソフトウェア特許の問題のひとつに、誰もがソフトウェア特許に賛成する特定の人物に話が言ってしまう状態になっていることが挙げられる。日本政府がビジネスモデル特許の有効性のためにヨーロッパに調査をしにきたときも彼と相談をした。日本側は
「ビジネスモデル特許の反対派の意見も聞きたいから呼んでくれ」と頼んだが、当然のことながらそれは実現しなかった。

 ヨーロッパの特許は日米の特許よりもしっかりしていると聞いており、またそう信じていたが調査を進めるにつれ、そうでもないと感じるようになった。請求範囲を非常に広く取った特許がたくさんある。このシンポジウムの議題である多言語環境に触れている特許も多く、ここの参加者の活動も縛られることだってありうる。

 そこで Federation For Infomational Infrastructure という団体を設立した。特許庁は特許を公開しているが、それはイメージデータでの公開であり、また一ページ一ファイルであり非常に使いづらいものである。FFII ではそれらを入手し、継ぎ合わせた上で公開している。

 しかしファイルサイズが非常に大きく (全部で数百 GB)、FFII へのアクセス数も増えており、活動が維持しづらくなっている。そこで、これらのデータのインデックスなど一部だけでもよいからミラーしてくれるところがないか探している。

[Top 側へ一つ移動]