図1 モンゴル語を含む縦書きと横書きが混在したページの表示例
このように情報技術の発達と共にWorld Wide Web (WWW)や電子メールなどで使 用可能な言語は増えてきている。しかしながら、開発効率やコストの兼ね合いな どもあるため、サポートされる言語は利用者数が多いと考えられるものや、既に サポートされている言語と似通った性質のものが中心となりがちである。その結 果、利用者数がさほど多くなく、既にサポートされている言語とは性質が大きく 異なる場合にはなかなかサポートされないのが実際である。
インターネットでは様々な人々が自分の都合にあった機材やソフトウェアを用 いているため、新たな機能を追加しようとしても、特定の環境でのサポートは比 較的容易に実現できるが、他の環境までサポート範囲を広げるのはなかなか難し い。このことは様々な言語をサポートしようという場合にも当てはまる。
著者らのグループではかつて海外で日本語の WWWページを読めるようにしたい という要求をきっかけに様々な言語の WWW ページを様々な環境で読むことを可 能にする MHTML Browser[1]の開発を行った。現在は既に一般的に利用されている 環境の多言語サポートの水準が MHTML Browser相当以上になりつつあるが、まだ まだ前述のようにサポートから取り残されている言語がある。
以上のような問題を踏まえて著者らが最近進めてきた、多言語サポートをより 進めるために必要な機能、そして最大限の表現能力を保ちつつ多様な利用者環境 に適応して文書を提供する枠組に関して検討し、試作を行ってきた。
MHTML Browserにおいては多言語の情報提供において、問題点を以下の2点に絞っ て開発を進めた。
90年代後半では既に Unicode 規格の策定が行われていたが、インターネット やコンピュータで用いられている例が実際にはまだ少なく、各国で定められた個 々の言語に対応した文字コードを用いるのが主流であった。例えば、日本語の場 合、JIS X0201またはASCIIのいわゆる半角英数字と、JIS X0208 の第1、第2水準 の漢字や仮名を同時に使用する、ISO-2022-JPやシフトJIS、EUC-JPなどの文字コー ドが主に使われていた。
MHTML Browserではこのような各国で用いられている個々の文字コードを解釈 する機能を備えており、そしてそれらの各コードに含まれる文字を表示するため に必要な文字フォントの図形（グリフ）データを文書に添付することで各利用者 の端末での表示を可能にしている。文字フォントを添付した文書形式は独自に定 義しており、その閲覧のためには専用のビューワを必要とするが、これを JavaAppletとして供給することで特にソフトウェア等をインストールすることな しに一般的なWWWブラウザでの閲覧を可能にしている。
このような文書データに表示に必要な文字フォントデータを付加する方式はそ れほど特殊ではなく、例えばAdobeが定義・公開している PDF 形式にも備わって いる(Adobe製品では日中韓の漢字フォントを埋め込まないが、フリーソフトや他 社品では埋め込むことが可能である)。
MHTML Browserでは特に日中韓の仮名や漢字の表示を第一目標としており、欧 州語やタイ語などもサポートしていた。文字の表示として単純に文字フォントデー タを並べて表示するものであり、改行や文字の進行方向に関しては特に言語依存 の処理は行わなかった。そのため、次の2点の問題が残された。
後者についてはともかく前者の問題は対応への要望が多かったものの、MHTML Browserの基本的な原理である「言語依存の処理を行わない」という原則の範囲 での対応が難しく、未対応のままとなってしまった。つまり、プレーンテキスト 程度の文書表示においても、単純に文字フォントデータを並べるだけでは不十分 である。
このような MHTML Browser開発成果を受けて著者らは多言語XML文書表示のた めのブラウザの開発を行った[2][3]。この開発では表示のための基本的な機能を設 計し、実装が可能であることの確認を主たる目的としていた。言語依存の処理を サーバ(ゲートウェイ)側で行い、クライアント(ビューワ)側では言語独立な処理 のみを行うような構成となっている。これにより、クライアント側に手を加えず に対応言語を増やすことを可能にしている。
このXML文書ブラウザでは、日本語の禁則処理や欧州語のword wrappingに対応 するために改行の可否を表す制御コードと、アラビア語などが交じった場合のた めの文字の進行方向を表す制御コードを導入している。元のXML文書に対して、 サーバが文字フォントを付加すると同時に言語に依存した解釈を行い、改行可否 コードと進行方向のコードを文字コードの間に埋め込む。クライアントはそれら の制御コードに基づいて機械的に改行の可否と文字を表示する際の進行方向を判 断するので、言語に依存した処理を行わなくて済む。
サーバにおいては言語依存の処理を Unicode のコード範囲に応じて行うよう にプログラムコードで直接記述していた。そのため、サーバにおいて新たな言語 への対応をするにはプログラムコードの変更を行う必要があるため、あまり容易 に追加することができない。また、サーバ側での追加作業を行っても対応できな い言語が存在することがわかったので、それへの対応が必要となることもわかっ た。その典型的な事例が縦書きの言語である。
キリル文字を用いる場合にはコンピュータによる処理や表示については大きな 問題とはならない。しかしながら、古くからモンゴル語に用いられていたモンゴ ル文字については次のような2つの特徴があり、コンピュータ処理・表示につい て工夫が必要となる。
1番目の特徴については、アラビア語などにも見られることであるため、対応 は難しくはない。しかしながら、Unicodeなどでは字形の違いに関わらず同じ文 字コードを付与しているため、表示や印刷の際は文字コードの並びを解釈して、 単語のどの位置（語頭、中間、語尾）にあるかを判断した上で文字の字形データ を選ぶ必要がある。そのアルゴリズム自体は定まったものがあるので実装が難し いわけではない。しかしながら、通常のソフトウェアは1文字毎の文字コードの みで字形も一意に定まることを前提としており、アラビア語などの一部の文字コー ド領域の部分については追加処理をするようにしている。そのため、文字フォン トデータを追加するだけでは正しい表示は行われず、表示ルーチンの追加なども 必要となる。
より大きな問題となるのは2番目の特徴である。縦書き自体は日本語や中国語 でも行われるので珍しくはないが、日本語や中国語の行が右から左へと改行して いくのに対して、モンゴル文字では逆に改行することになる。また、現代では日 本語も中国語も英語などと同じ横書きも行われているため、コンピュータや WWW ブラウザでの表示も通常横書きになっている。これは、日本語や中国語で用いら れている文字が横書きにしても文字そのものを横倒しにする必要がなく、それほ ど可読性が失われないので、横書きが受け入れられているためである。
一方、モンゴル文字で記述するモンゴル語（以降、単に「モンゴル語」と記す） については、文字を連ねる「続け字」であるために、縦書きであるものを横書き にしようとすると、文字ごと横倒しにする必要がある。もし、文字を正立させた まま横書きにするとすれば、文字同士の連なりも切断することになり、字形を大 幅に変えることになりかねない。
以上のような点から縦書きによる表示・印刷はモンゴル語をサポートする上で は必須である。ところが、縦書き機能をブラウザに単純に組み込むだけでは済ま ず、文書を表示する際のレイアウトが問題になる。つまり、文字を書き進める方 向や改行していく方向が90度異なるものが混在すると、画面上での配置、そして ブラウザとして考えるとスクロール機能などにも影響が出る。
このような観点から著者らは WWW において情報提供側や利用者に大きな負担 を強いることなく、横書きの言語と同様に縦書きの言語での情報提供も行える環 境整備が必要であると考える。現状では Microsoft Internet Explorer (MS-IE) など一部の WWWブラウザでは縦書きのサポートは始まっており、Cascading Style Sheets (CSS)に従って、WWWページ内をブロック単位で縦書き表示させる ことが可能となっている。しかしながら、アラビア語やヘブライ語など横書きで 文字の進行方向が異なるものが交じっている場合には Unicode における Bidirectional Algorithm (Bidi)のような一般的な規則は定められているが、縦 書きと横書きの混在の場合には前述のレイアウトの問題もあるために、そのよう な一般的な規則は定められていない。その結果、縦書きと横書きの言語が混在す るような場合には、CSS等で詳細な指定をしなければ読み易い表示を行えない状 況にある。
そこで、本研究では縦書きと横書きが交じりあっている文字列を表示する際の 一般的な規則を定め、それに従って自動的に表示ブロック内の文字表示を行うこ とを提案する。具体的に規則を定めるためには、様々な条件を精査し、検討を重 ねる必要があると考えられるが、本研究ではその大要として以下のように定めた。
このように定めた規則に従った表示が可能となった場合、どの程度アプリケー ション等の開発が楽になるかを確かめるために、今回は JavaServlet用のクラス ライブラリの試作を行った。本ライブラリは WWWブラウザとしてMS-IEを想定し ており、表示しようとする文字列を走査し、適切な表示を行えるように CSS 記 述を生成する。この結果を JavaServlet の出力とすれば、MS-IE上では縦書きと 横書きが混在した表示が行われる。
今回試作したライブラリでは縦書きとしてモンゴル語の表示を取り扱っている。 前述のようにモンゴル語の表示には2つの問題があるが、今回は Unicodeとは異 なる各字形毎に独立した文字コードを付与した独自のコード体系に基づく文字フォ ント[4]をクライアントPCにインストールし、本ライブラリでその文字フォントを 使用するCSS記述とHTMLにおける文字参照記述を生成することによって文字表示 を可能とした。なお、モンゴル文字の入力環境は一般的ではないので、暫定的に 独自のタグ<mongolian>で囲みローマ字で記述した部分をモンゴル文字として 扱っている。
書字方向についても現在のMS-IEでは日本語や中国語のための「tb-rl」つまり、 右から左へと改行していく方式には対応しているが、モンゴル語に用いられる 「tb-lr」には未対応である。そのため、本ライブラリでは表示領域を仮定して 各行毎の小さな表示ブロックに分割して、それを左から右に並べることによって 代用している。
以上のような機能を準備することによって図1のように縦横混在の表示が可能 となった。
前節では多言語文書表示における縦書きと横書きが混在する場合の解決案とそ のための試作ライブラリについて述べた。そのライブラリではブラウザを Windows上のMS-IEと仮定しており、他の環境では正しく表示されないことがある。 これは何も多言語サポートに限らず、HTMLタグやCSS記述の解釈の違いなどによっ て日常的に生じている。例えば、最近はAjaxと呼ばれるブラウザのJavaScript処 理機能を活用して対話機能を高めたサービスが注目を集めているが、この JavaScriptについても環境による違いが問題となり易く、WWWベースのシステム 開発者を悩ませ、開発効率を落す原因ともなっている。
このような同一規格・形式に則っているにも関わらず互換性問題が出る一方で、 そもそもデータ形式そのものが多様化しているものもある。電子図書はその典型 であり、ビジネスモデルの影響もあるが、業界団体などにより様々なデータ形式 が定義され、電子図書提供に使用されている。それぞれのデータ形式の図書を読 むためには、それに対応した閲覧ツールを用いる必要があり、利用者の手を煩わ せるほか、利用者の環境ではそのようなツールを用いることができない場合もあ る。T-Time[5]は WWW ページなどの形式で提供される図書を読み易く表示するた めの独立した閲覧ツールである。また、画像データに変換することで多様な環境 での閲覧を可能にする機能を備えている。しかしながら、それは利用しようとす る端末の仕様に合わせなければ読み易さが損なわれてしまう。
このようにデータ形式の多様性やその互換性の問題に加えて、閲覧に用いる端 末装置の仕様の影響も無視できない場合がある。特に携帯型の端末では物理的制 約が強いため、その影響は大きい。例えば、ディスプレイの解像度や物理的な表 面積、閲覧操作に用いるためのキーボードなどの入力デバイスなどによって制約 を受ける。最近の携帯電話では C-HTMLやHDMLなどの携帯端末向けのマークアッ プ言語に対応しており、それらの言語はそれぞれで規格が定められているが、実 際に使用する携帯電話のディスプレイなどの仕様が読み易さに大きく影響する。
現状では利用者が自分の使っている閲覧環境に合わせて電子図書購入の際に適 切なデータ形式等を選ぶ必要がある。著者らはそのような手間を省き、かつコン テンツ提供者が利用者環境毎に合わせて電子図書を準備しなくても、自動的に変換 することができれば、電子図書閲覧をより気軽にできるのではないかと考え、そ のシステムの試作を行った。
基本的には入力となる電子図書をまず共通の中間形式に変換し、そして中間形 式のものを利用者の環境に合わせて変換する。その際、中間形式の表現能力が貧 弱であると入力電子図書や利用者環境の特性を十分に活かせなくなる。そこで、 中間形式の必須機能として文書構造を表すものとし、端末などの今後の技術開発 等によって向上していくと考えられる文字装飾などの表示スタイル指定等につい ては拡張部分として、その記述文法を定義しておく。これによって将来もその拡 張記述を行うことによって表現力を補うことが可能となる。今回のシステムでは 中間形式としてJepaX[6]を採用し、それに元々備わっているクラス・タイプ定義 記述について形式的な記述を導入することにした。
入力側の変換器と出力側の変換器はそれぞれ入力電子図書の形式と利用者環境 によって選択されるが、データ形式等は共通でも詳細な機能の使い分けや対応状 況の違う複数の候補があることが考えられる。その際は拡張記述で互換性のある ものが多いものを優先して選ぶことになる。
試作システムの構成は図2のようになる。試作システムは HTTPによって利用者 端末と通信するものとしており、利用者環境情報はその HTTP リクエストに含ま れるヘッダ情報によって得るものとする。しかしながら、リクエストに含まれる ヘッダでは情報が不十分な場合があること、読み易さについては単純にソフトウェ アやハードウェアだけでなく、利用者の好みの反映も必要なことから、利用者環 境のパラメータは利用者自身によって修正可能なユーザインタフェースも準備し ている。
利用者環境のパラメータ、例えばディスプレイの大きさなどはHTTPリクエスト には含まれていないことが普通であるが、携帯電話のような場合、リクエスト中 に機種名などが含まれている場合が多く、その機種の仕様等をあらかじめ登録し ておき、機種名等を手がかりに検索、使用する。しかしながら、この手法では限 界があり、特にPCのような柔軟性の高い環境では不十分であるので、本システム の手法を実用化するには HTTPリクエストなどによる利用者環境情報の送り方な どを規格化・普及させる必要がある。
また、多様な利用者環境への対応という問題はインターネットでは本質的なも のであると考えられる。その一方で、これはビジネスも絡むために解決は簡単で はないが、図書館と同様に様々な利用者が気軽に情報をアクセスするためにも可 能な限り技術的な障壁を取り除くことが重要ではないかと思われる。
なお、本研究は日本学術振興会科学研究補助金基盤研究C(課題番号16500049) の助成を受けて行った。
[2] 阪口哲男, 永森光晴, 杉本重雄, 田畑孝一. 多様な利用者環境で多言語文書表示を可能にするXMLブラウザ. ディジタル図書館, No.19. 2000. URL: http://dl-lab.aist-nara.ac.jp/DLjournal/No_19/3-saka/3-saka.html (2006/2/16参照)
[3] 阪口哲男, 樋爪育恵, 加藤大博. メタデータブラウザの多言語対応に向けた課題への取り組み. 情報知識学会第11回(2003年度)研究報告会講演論文集, pp.13-16. 2003.
[4] CMs / Classical Mongolian script / TrueType fonts. URL: http://www.geocities.com/geseree/cms_gallery.html (2005/2/16参照)
[5] 株式会社ボイジャー. T-Time. URL: http://www.voyager.co.jp/T-Time/index.html (2006/2/16参照)
[6] 日本電子出版協会. JepaX. URL: http://www.jepax.org/ (2006/2/16参照)
[7] 片岡裕, 片岡朋子, 上園一知, 大黒谷秀治郎, 大矢俊夫, 小原啓義. 全世界の文字と言語の完全混在処理環境: Internationalized Multilingual System - The Waseda I18N & ML System. ディジタル図書館, No.6. 1996. URL: http://www.dl.slis.tsukuba.ac.jp/DLjournal/No_6/kataoka/kataoka.html (2006/2/16参照)