
%　　・発注仕様書の内容と違いはないか。
%　　　　特に、発注仕様書に記述されている言葉と表現の異なった
%　　　　言葉を使用するときは、対応がわかるように対応表を作成して
%　　　　下さい。
%　　・技術開発の目標が記述されているか。
%　　・技術開発項目の内容がわかるか。
%　　　　内容は、第三者が読んでもわかる内容（平易な文）にして下さい。
%　　・目標を達成しているか。また、その根拠が妥当であるか。
%　　・開発したものに対する評価基準、評価方法、評価内容が
%　　　記述され、妥当であるか。
%　　・技術開発全体の総括が記述されているか。

%\IPAref{XXX} のラベルは @latexonly \IPAlabel{XXX} @endlatexonly で付ける。

\section{Unix/Linux 汎用多言語処理機能ライブラリの開発の概要}

\subsection{技術開発の目標}
%発注仕様書「背景と目的」からコピー
%2002/2/25役員会用説明資料から追加
\subsubsection{背景と目的}

%多言語処理とは何か

ソフトウェアにおける多言語化とは、あるソフトウェアのうえで、いろいろな
文字、言語などの文化的慣習を混在させて使えるようにすることを指す。世界
規模での情報の発信や共有を支えるためには、英語のように利用者の多い言語
だけではなく、それ以外の言語も統一的かつ容易にサポートできる計算機環境
が求められる。

%多言語処理向け汎用ライブラリとは何か。

一方、ソフトウェア開発者の側から多言語化について見ると、現在開発されて
いるソフトウェアのほとんどにとって、多言語化自体、あるいは言語の扱い自
体はソフトウェアの主な目的ではなく、枝葉末節である。それにもかかわらず、
多言語化部分をまとめて処理するライブラリがないために、個々のソフトウェ
アで個別に多言語化機能を開発するという非効率な事態が起こっている。実際、
mozilla, Perl, Ruby などのソフトウェアでは、現在それぞれに多言語化機能
を開発している。

このようなソフトウェアや、その他多言語化機能を必要とするソフトウェアに
おいて、多言語対応を必要とする部分は比較的容易に切り分けができる。一方
多くのソフトウェアが多言語化に関して共通に必要としている機能がたくさん
存在する。そこで、そのような機能を集め、複数のソフトウェアから共通に利
用できる多言語化ライブラリがあれば、多くのソフトウェアの開発をより効率
的に行ない、開発コストを削減できると考えられる。

多言語処理向け汎用ライブラリの分野においては、Unicodeをベースにするこ
とにより、世界中の文字を含んだテキストを取り扱うことができるものが開発
されつつある。しかしこれはあくまでテキストを単なる文字列として扱うため
のライブラリであり、実際に多言語テキストを入力、表示、編集する上で必要
となる情報、たとえば、どのような方法で入力するか、どの種類のフォントで
表示するか、どのような手順で検索するかは、各アプリケーションプログラム
で取扱わなければならないのが現状である。

本開発は、多言語テキストを単なる文字列としてではなく、上記のような多く
の情報を含んだオブジェクトとして統一的に取扱うことを可能とし、しかも計
算機を利用する様々な場面で用いることができるLinux/Unix 用汎用ライブラ
リを開発するものである。

本開発は、この汎用ライブラリをオープンソースソフトウエア
として提供することを目的としており、今後、世界にまだ残る、計算機利用に
おける言語的障壁を軽減することを目指すものである。


\subsubsection{Unix/Linux 汎用多言語処理機能ライブラリの位置づけ}

本開発で実現するUnix/Linux 汎用多言語処理機能ライブラリの最終目標は、 
Linux/Unix 上の GNOME (GNU Network Object Model Environment)
\footnote{GNOMEプロジェクトは、ユーザには完全にフリーで使いやすいデス
クトップ環境を、ソフトウェア開発者には強力なアプリケーションフレームワー
クを、提供するものであり、ほとんど全てのBSDやGNU/Linux ディストリビュー
ションに収録されている。} の上で、多言語対応ソフトウェアの開発がで
きるようにすることである。このため、本ライブラリは Gnome が利用する 
Toolkit から、また多言語化フレームワークの開発者から利用され、それらの
間の橋渡しをすることを想定している。本ライブラリを Multilingualization
(= 多言語化)の最初と最後の文字をとって「m17n ライブラリ」と呼ぶことが
あり、本ライブラリの要素を「m17n 基本 C ライブラリ」などと呼ぶことがあ
る。

GNOME で用いられているテキスト処理機能は GTK (GIMP\footnote{GNU Image
Manipulation Program} ToolKit) の上で実現されており、 GTK はさらに C 
ライブラリ 及び X ライブラリの上で実現されている。したがって、GNOME の
上で多言語対応ソフトウェアを開発するためには、GTK の多言語化が必要
であり、そのためには、そのベースとなっている C ライブラリ 及び X ライ
ブラリの多言語化が必要である。

現在 GNOME の多言語テキスト処理では、表示だけを行なうことのできる枠組み 
PANGO (Παν語)が用いられている。しかし m17n ライブラリ 実現後には、
PANGO の多言語テキスト表示エンジンを GTK の下位実装層に用い、PANGO 自
身は GTK の API （アプリケーション・プログラム・インタフェース）を利用
できるようにすることを目指している。

GNOME を用いることなく X Windows 上で直接動作するソフトウェアは、 
X Windows ToolKit を使用している。しかし m17n ライブラリでは、X ライブ
ラリに対応する部分の機能提供だけを行ない、ToolKit の多言語化は行なわない。


\subsubsection{本ライブラリの特徴}

%必要なものはM-textにテキストプロパティとしてぶっ込もうというのが本ライブラリの売りである。

多言語処理に限らず、テキスト処理を行なう際にしばしばおこる問題は、文字の
列、あるいは文字コードの列が持つ情報だけでは、必要な処理を行なうには不十
分であるということである。実際にテキスト処理を行なう際には、言語情報、ス
クリプト情報、フォント情報、グリフ情報などが必要になる場合がある。それ
にもかかわらず、これらの情報は文字コードの列には含まれていない。これま
でのソフトウェアでは、この点を解決するために、補足的な情報を直接引数と
して与えたり、補足的な情報も含めてテキストを表現する構造体を独自に定義
して、それを引数として持ち回したりしている。

本ライブラリ設計上の特徴は、補足情報をも含んだテキストを表わす構造体を定
義し、それを処理の基本単位とすることである。この特別な構造体を M-text、
補足的な情報を付加するための仕組みをテキストプロパティと呼ぶ。

M-text において補足的な情報は、テキストプロパティという決まった枠組み
を使って表わされる。このため、文字コードだけでなく補足情報も、複数のソ
フトウェアやルーティンの間で共有できる。この仕組みはさらに、関数に情報
を渡すためだけではなく、関数から情報を受け取るためにも使用できる。たと
えば、表示ルーティンに表示をコントロールするための制約情報を与える際に
もテキストプロパティを用い、表示ルーティンがその制約の中で具体的にどう
いう表示を行なったかの情報を別のテキストプロパティとして返すことも、簡単
に実現できる。

このようにテキスト処理の基本単位として、これまで「補足的」とされていた
情報も含む M-text を用いること、そしてその結果テキストの情報を多くのア
プリケーションが同じ方法で扱うことは、多言語化を必要としないものを含め
テキストを処理するソフトウェアすべてに転換をもたらすことが期待できる。

\subsubsection{設計の戦略}

本ライブラリでは、多言語処理機能の新たな体系を確立することを目指してい
る。この体系を「多言語化アーキテクチャ」と呼ぶ。しかし、現存のソフトウェ
アは当然現時点でのテキスト処理のためのアーキテクチャに依存している。こ
の状況に鑑み、「多言語化アーキテクチャ」への移行を容易にするため、でき
るだけ現在の「テキスト処理アーキテクチャ」との対応関係が明確な方法で設
計を行なうという方針をとる。

以下ではこの対応関係を説明する。

C ライブラリが提供するライブラリ関数は UNIX 98 （Unix の標準化を手がけ
ている The OpenGroup の最新の Unix に関する仕様）によれば 734 あり、そ
のうち「テキスト処理」に関するものは 101 個である。これらのうち平成１
４年度後期〜平成１５年度に開発作業を行なう予定である「m17n 基本 C ライブ
ラリから既存のロケール機能を利用する手法の設計」に含まれるべきものを除
くと、54 個が残る。そこで、「m17n 基本 C ライブラリ」ではこれら 54 個
の関数に対応する関数を提供する。

%appendix を概要の最後にいれるのかなぁ。。。
%mule:/project/mule/m17n-lib/README の APPENDIX A に UNIX 98 
%の全 API と m17n 基本 C ライブラリとの対応を書いてあります。

また X ライブラリが提供するライブラリ関数は 512 あり、そのうち、「テキ
スト処理」に関するものは 70 個である。「m17n X ライブラリ」ではこれら 
70 個の関数に対応する関数を提供する。ただしそのうち 29 個は「m17n X ラ
イブラリ」が内部的に処理するため API として定める必要がない。したがっ
て、残りの 41 個の関数を設計する。

%mule:/project/mule/m17n-lib/README の APPENDIX B に X
%library の全 API （と思われるもの）と m17n 基本 C ライブラリ
%との対応を書いてあります。

「m17n 言語情報ベース」はこれらのライブラリから利用されるものとして設
計する。もちろんこれらのライブラリを利用するアプリケーションプログラム
の開発者は、必要に応じて自由にデータベースを定義し、アプリケーションプ
ログラムから利用することができる。

本開発での設計の対象は、データベースの内容ではなく、その枠組み、つまり
データベースが提供すべき情報の種類と形式、そして m17n ライブラリがその
情報を取得する方法である。

情報の取得方法については、階層性を利用して効率的な検索を行なうことができ
るよう設計する。多言語処理を行なう際には、言語、ロケール、スクリプト、入
力方式などさまざまなタグで索引づけられた、階層性を持つデータベースから
の情報取得が必須である。これに対応するため、階層性を表現する複数のタグ
によって情報の種類を指示できる枠組み（もちろん単数タグにも用いることが
できる）を実現する。

データベースが持つ情報の種類と形式に関しては、最も汎用的な形式を提供し、
同時に特に効率を必要とする場合に特定の情報に対して用いられる特別な形式
を提供するという方針をとる。これによって汎用性と効率性を両立させている。
具体的には、アプリケーションプログラムがデータベースを直接、情報の種類
について制限なしに利用できる一方で、文字毎の情報のような大量データにつ
いてはデータベースからの一括取得が可能になっている。

この「m17n 言語情報ベース」の枠組みを検証するために、m17n ライブラリ自
体が実際に使うデータベースとして、文字セット、文字のプロパティ、フォン
ト、入力メソッドに関するものの一部を試作する。これらの試作の際には、現
Unicode 文字については Unicode コンソーシアム
\footnote{http://www.unicode.org/}の提供するUnicodeData.txt,
Unihan.txt, SpecialCasing.txt、非 Unicode の非 CJK 文字については、そ
の種の文字セットのマップ情報をもっとも網羅的に集めている IBM の ICU
(International Components for
Unicode)\footnote{http://oss.software.ibm.com/icu/}、CJK 文字について
は、それらのマップ情報をもっとも網羅的に集めている、安岡孝一氏による漢
字テーブルと文字集合テーブルのリスト
\footnote{http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK.html} をソースとする。

\subsection{本作業年度における技術開発項目の内容}

ここでは「m17n基本Cライブラリ」の基本機能の設計、「m17n Xライブラリ」
の基本機能の設計 、「m17n 言語情報ベース」の設計の各項目ごとにその内容
を説明する。

\begin{enumerate}
\input{m17n-basicC.tex}
\input{m17n-X.tex}
\input{m17n-database.tex}
\end{enumerate}


