%% -*- coding: euc-jp; -*-

\section{評価基準、評価方法、評価内容}

本開発で実現するUnix/Linux 汎用多言語処理機能ライブラリは、 Linux/Unix 
の上での多言語対応ソフトウェアの開発を容易にすることを目標としている。
つまり、このライブラリがターゲットとする利用者は Linux/Unix 上のソフト
ウェア開発者である。そこで外部の多言語文書情報処理関連ソフトウェア等の
開発者によるレビューを受けることとした。

また、本年度の開発内容は API の設計であるため、実際のライブラリを試用
してレビューしてもらうことはできない。そこでAPIの仕様に関するドキュメ
ント（本開発報告書の１章から６章相当部分の２００２年１月末時点での版）
を送付し、それについて評価を依頼した。

\subsection{評価基準ならびに方法}

評価者は以下の４名である。
\begin{itemize}
\item 樋浦 秀樹 (Chair, Li18nux/Linux Internationalization Initiative, Free Standards Group
                Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA)
\item 末廣 陽一 (li18nux system architecture subgroup leader, Li18nux//Linux
Internationalization Initiative, コンパックコンピュータ株式会社/ソフトウェア製品開発部)
\item 沼田 利典  (li18nux2000 Specification Editor, Li18nux/Linux
Internationalization Initiative, 富士通(株) ソフトウェア事業本部 プロジェクトA-XML XML 応用技術部)
\item 守岡 知彦 (CHISE (Character Information Service Environment) プ
ロジェクトリーダ, 京都大学人文科学研究所附属漢字情報研究センター)
\end{itemize}

評価に当たっては、以下の項目について１〜５の５段階評価 （1: 悪い 2: や
や悪い 3: 普通 4: やや良い 5: 良い）およびコメントを依頼した。

\begin{description}

\item[新規性] \

   他の多言語処理技術と比べてどの程度のレベルにあるか?

\item[有用性] \

  このライブラリが多言語処理を行うアプリケーションにとって役に立つか？

\item[標準化の可能性] \

  将来において国際標準になれる可能性は？

\item[妥当性] \

  多言語処理を実現するという目的に対して、本ライブラリの手法は妥当であるか？

\item[ドキュメントの質] \

\item[継続の必要性] \

  （継続が決まれば、来年度以降、GNOME (GNU Network Object Model
    Environment) アプリケーションの多言語化のために GTK に本ライブラリ
    を統合するための研究を実施する予定です。）
\end{description}


\subsection{評価の内容}

\begin{tabular}{|l|c|c|c|c|c|c|}
\hline
評価者&  新規性 & 有用性 & 標準化の可能性 & 妥当性 & ドキュメントの質 & 継続の必要性 \\
\hline
末廣 陽一 &  5 & 4 & 2 & 3 & 3 & 5 \\
\hline
守岡 知彦 & 3 & 3 & 1 & 3 & 2 & 4 \\
\hline
樋浦 秀樹 & 3 & 5(2/3) & 1(4) & 4 & 3 & (5)\footnotemark\\
\hline
沼田 利典 & 3 & 5 & 2 & 4 & 2 & 5\\
\hline
\end{tabular}

\footnotetext{評価結果に点数が入っていなかったので、コメントの
「ぜひ継続してください」を 5 を意味するものと受け取った。}

\subsubsection{評価者：末廣 陽一}

\begin{tabular}{|c|c|c|c|c|c|}
\hline
新規性 & 有用性 & 標準化の可能性 & 妥当性 & ドキュメントの質 & 継続の必要性 \\
\hline
5 & 4 & 2 & 3 & 3 & 5 \\
\hline
\end{tabular}

\ \\

各観点に関するコメント
\begin{description}
\item[新規性]~\
	文字コードを中心とした多言語処理技術の議論が多い中で，
	新たな体系を築こうというアプローチの新規性は評価できる。
	ただし，その優位性が十分に説明されていないのは残念である。

\item[有用性]~\
	高度な多言語処理を目指すアプリケーションにとっては，自前で
	用意する必要がなく，役に立つと思われる。拡張性もあり，
	応用範囲は広いと思われる。

\item[標準化の可能性]~\
	国際標準になるためには，この技術が一部の特定のアプリケーションで
	のみ使われる技術ではなく，広く普及する必要がある技術かどうかが
	問われると思われるが，その点の説得力にかける。
	どのような思想のもとに設計されているか，それによって既存のものでは
	実現できないどのようなことができるのか，それが世の中に
	必要なものなのか，などの考察が十分でないように思われる。

\item[妥当性]~\
	多言語処理を実現するという，ただそれだけの目的としてはおおむね
	妥当だと思われる。ただ，既存の C 言語 API をベースに考えられている
	部分があるが，ロケールの扱いや関数の動作への影響，ファイル入出力や
	ファイル内での文字の表現がどうなっているのかなどの説明が不十分，
	一般のプログラマ向けの仕様としては難しすぎないかなど，
	いくつか気になる点がある。

\item[ドキュメントの質]~\
	API の仕様書としては，よいと思う。しかしながら，
	「多言語アーキテクチャ」とは何なのか，「多言語処理」とは何なのか，
	「文字」をどのようにとらえているのか，などなど，
	おそらく設計者の間では同じ概念を共有できているのだろうが，
	報告書のドキュメントだけからは，その目指している世界が
	よく理解できなかった。そのあたりの概念やプログラミングモデルなどを
	整理してまとめたものがあるとよいと思う。

\item[継続の必要性]~\ 
       多言語化は，今後必要な技術なので，是非とも研究を
        継続していただきたい。今後進めていく上で，既存技術の延長で 
        Unicode 処理の API を備えたICU との明確な差別化が必要だと考え
        る。目指すものが違うということであれば，その区別がわかるような
        説明が必要だと思う。

\end{description}

\subsubsection{評価者：守岡 知彦}

\begin{tabular}{|c|c|c|c|c|c|}
\hline
 新規性 & 有用性 & 標準化の可能性 & 妥当性 & ドキュメントの質 & 継続の必要性 \\
\hline
 3 & 3 & 1 & 3 & 2 & 4 \\
\hline
\end{tabular}

\begin{description}
\item[新規性]

新規に設計した割には旧来のもの (Mule) に因われ過ぎているように思われ
（ほとんど Mule そのままであり、Mule で経験した利便性・問題点の分析が
十分になされているように思われない）、API や多言語処理技術としての新規
性の点ではあまり評価できない。

\item[有用性]

システムの適応範囲、および、併用されるべき他のシステムとの機能分担が不
明確であり、一概にはいえない。抽象化が不十分ないしは抽象化と利便性がア
ンバランスな点があり、複雑なアプリケーションを記述する上ではやや問題が
あるかもしれない。また、plain text で十分な対象に対してはオーバースペッ
クであると思われる。モジュール化・スケーラビリティーに対する配慮も十分
でないように思われる。しかしながら、XML parser などと併用して構造化テ
キストを処理したり、多言語文字列を編集可能なまま表示するようなアプリケー
ションを実現する上では一定の有用性が認められる。

\item[標準化の可能性]

モデル・用語等が結果的に独自のものになっており、国際標準やデファクトス
タンダードとあまり調和していないように思われる。そのため、（Mule や
Emacs を知らないものにとっては）このままではやや理解しにくいものになっ
ていると思われる。この技術の適応範囲や主要な対象、および、現在の需要と
の関係も不明確である。

\item[妥当性]

多言語処理の内、各種符号化に関わる部分やレンダリングに関する低レベルの
処理、データベースによる情報の管理に関しては妥当性がある。しかしながら、
このあたりは最近段々と整備されつつある分野であり、多言語処理にとって欠
くべからざる部分ではあるもののその一部に過ぎない。現在多く使われるよう
になった XML などの構造化テキストを扱うための界面や、こうした構造化文
書を解析・加工するための支援（ないしはそうしたことを目的としたモジュー
ルとの界面）、あるいは、こうした構造化文書をある程度の品質で多言語組版
表示するといった課題を解決していない、ないしは、その方向性を示していな
い。

\item[ドキュメントの質]

この API の背景やモデル、適用範囲・対象等が十分に述べられていない。こ
の API の重要なポイントは M-text と思われるが、そのことが十分に強調さ
れていないし、構造化テキスト等を扱う上での有用性もあまりアピールされて
いない。さらにいえば、M-text を主眼に据えるならば多言語処理をする上で
の plain text の問題点・限界なども主張してはどうか？

\item[継続の必要性]

新規性や仕様の点では幾つかの問題点はあるものの、開発者の実装能力は高い
ので実装には期待したい。

\end{description}

\subsubsection{評価者：樋浦 秀樹}

\begin{tabular}{|c|c|c|c|c|c|}
\hline
新規性 & 有用性 & 標準化の可能性 & 妥当性 & ドキュメントの質 & 継続の必要性 \\
\hline
3 & 5(2/3) & 1(4) & 4 & 3 & (5)\\
\hline
\end{tabular}

各観点に関するコメント
\begin{description}
\item[新規性]

私がまだ全貌を把握していないので勘違いしている可能性もありますが、
これから API set として皆が adapt していく新規性があるのかがまだ
わかりません。

一方、M17N 化を目指す人向けの、パーツ実装集として、mule で培った
実装を再利用できる部品にすることには意義を感じています。

\item[有用性]

パーツ実装集として、mule で培った実装を、再利用できる部品にする
ことは役にたつと思います。
ただ、application を直接の consumer とするのか、それとも toolkit
などを直接の consumer とするのか、I18N framework 実装者を consumer と
するのかで有効性は変わると思います。

application を直接の consumer とする場合:     2: やや悪い\\
toolkit などを直接の consumer とする場合:     3: 普通\\
I18N framework 実装者を consumer とする場合： 5: 良い\\


\item[標準化の可能性]

このカテゴリーは、library としてできよりも、政治的・マーケット的な側面
が大きいと思います。したがって、 API set がとして見た場合m17nlib が国
際標準になれる可能性は悪いと考えます。Niche な market では熱烈に受け入
れられると思いますが。

API set としては、徹底的な Unicode 特化が、および XML 処理系の
backend としての親和性が、今後世界で望まれる方向性だと思います。

たとえば、ICU が STSF と IIIMF （すべて UTF-16 ベース）を取り込んで、
I/O(2D text)を含む、Java I18N framework すべての C/C++ port になった
とき、多数を占めるだろう Unicode API set を望む側の人々が、m17nlib の
方を国際標準として選ぶ強い理由が必要だと思います。 

Open Source の国際化関係の部分で活動をしている標準化団体といえば
今は Free Standards Group/Li18nux になると思いますが
その観点から見て、標準化 track に乗せるのは in general とても険しいです。

UNIX では TOG, さらに International Standard となると ISO になり
ますます険しい。

「普及の可能性」なら	4: やや良い


\item[妥当性]

繰り返しになりますが、API set として受け入れられることに重点をおくので
はなく、mule で圧倒した「なんと言ってももう動く実装があるもんね」方式
のほうが、これからスタートするプロジェクトとしてはより有効なのではない
でしょうか？（部品化ということです）

\item[継続の必要性]

ぜひ継続してください。

m17n とは architecture 的にどうあるべきか、人々が望んでいるものとの 
conflict をどうおりあわせていくか、API set としてなにをどのレベルでど
う抽象化して見せるか、複雑で一貫性のない怪物と化していく Unicode をど
うあつかっていくかなど、理想と現実のバランスを商業的成功に縛られる人々
とは独立して追求していっていただけたらと思います。

\end{description}

\subsubsection{評価者：沼田 利典}

\begin{tabular}{|c|c|c|c|c|c|}
\hline
新規性 & 有用性 & 標準化の可能性 & 妥当性 & ドキュメントの質 & 継続の必要性 \\
\hline
3 & 5 & 2 & 4 & 2 & 5\\
\hline
\end{tabular}

\begin{description}

\item[新規性]

　私自身，最近の動向をそれほどよく分かっているわけではないので，
他と比べて新規かどうか判断できません．

\item[有用性]

　Unicode を生のまま見せて，それ以上の処理はプログラマに任せるライブラ
リや，Unicode を自分ですべて解釈して処理したりするアプリケーションも多
いようですが，Unicode も複雑化する一方なので，その方法では破綻すること
は目に見えています．そういう意味で，このようなライブラリの存在は有用だ
と思います．もちろん，Unicode 以外の方向性を目指す場合にも．

\item[標準化の可能性]

　他の仕様にくらべてアピールする点が少ないのがつらいところです．特に 
Unicode に特化したものと比べて，Unicode も含むけれどもそれだけではない，
というところが，国内はともかく国外にどう受け止められるか．

\item[妥当性]

　テキストデータを M-text として仮想化されているのですが，それでも 0〜
10FFFFh は Unicode と同じ，となっているところが気になりました．それだ
と，Unicode との親和性は高くなるのですが，一方で Unicode の作りに引き
ずられるが出てくるのではないかと思います．(「文字」の定義とか．)

\item[ドキュメントの質]

　他のコメントにもあるように，説明不足です．

・設計上，どういう方針をとったか\\
・どのレベルのプログラムから呼ばれることを想定しているか\\
・ICU など，他の類似ライブラリとの関係をどう考えているか\\
・既存のロケール機構との関係がどうなっているのか\\

など，あとでメールで補足された部分が書かれていればよかったと
思います．

\item[継続の必要性]

　継続すべきと考えます．
\end{description}


\subsection{評価者からのコメントに関する回答ならびに対応}

\begin{enumerate}
\item  新規性について
\begin{itemize}
\item 差別化のポイント

評価者からの指摘は、他の手法に対する優位性が明らかでないという点に集約
できる。

評価を依頼した版のドキュメントが API の仕様に終始し、ライブラリとして
の全般的な性格、戦略等を説明していない不十分なものであったため、評価者
たちの理解を得られなかった部分がある。たとえば、樋浦氏および沼田氏から
評価は、「判断できない」という理由で「普通」となっている。

以下本ライブラリのセールスポイントについて述べる。（現在の版では、この
内容は第１章でも説明しているが、再掲する。）

このライブラリの技術の新規性は、文字／文字コードの列としてテキストを扱
うのではなく、テキストプロパティという補足的な情報を含めた構造体を定義
し、すべての関数がそれを処理の基本単位とすることにある。既存の技術との
差別化は、「テキストの情報を統一した方法で扱う」という点に集約できる。

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

M-text では、補足的な情報はをテキストプロパティという統一的な枠組みを
用いて表わされる。このため、文字コードだけでなく補足情報も、複数のソフ
トウェアやルーティンの間で共有できる。この仕組みはさらに、関数に情報を
渡すためだけではなく、関数から情報を受け取るためにも使用できる。また、
複数のテキストをつなげたり、部分テキストをとりだしたりといいた編集を行
なっても、元のテキストに付加されていた情報は保存される。関数 A, B, C,
D を順次呼び出してテキストを加工させるような場合にも、途中の関数 B, C 
にテキストに関する補足的な情報を引数として与えたりする必要はなく、テキ
ストプロパティ付きのテキストだけを渡して、A から D までの処理を行なう
ことが可能となる。

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

\item 何に対する新規性か

\begin{quote}
「新規に設計した割には旧来のもの (Mule) に因われ過ぎているように思われ
（ほとんど Mule そのままであり、Mule で経験した利便性・問題点の分析が
十分になされているように思われない）、API や多言語処理技術としての新規
性の点ではあまり評価できない。」（守岡）
\end{quote}

本ライブラリは、本開発従事者がこれまでに Mule というエディタに特化して
蓄積してきた技術を、 C のライブラリとして整理するものである。したがっ
て過去の Mule と比べての新規性ではなく、他の C ライブラリと比べての新
規性を主張する。

\end{itemize}

\item  有用性について

評価者からの疑問は、ライブラリ利用者として想定している層が明らかでない
という点である。

\begin{quote}
 「ただ、application を直接の consumer とするのか、それとも toolkit
 などを直接の consumer とするのか、I18N framework 実装者を consumer と
 するのかで有効性は変わると思います。」（樋浦）\\
「システムの適応範囲、および、併用されるべき他のシステムとの機能分担が不
明確であり、一概にはいえない。」（守岡）
\end{quote}

本ライブラリでは、toolkit と I18N framework （＝国際化フレームワーク）
との橋渡しを主な目的とする。そのために、toolkit と I18N framework 実装
者の両者を利用者として想定する。

\item 標準化の可能性について

評価項目の説明が曖昧であったため、来年度以降の研究開発計画である「GTK 
との統合」としての国際標準となる可能性ではなく、一般的な単独の API と
しての国際標準規格となる可能性の評価となった。結果として、本開発の評価
項目としては、適切でないものとなってしまった。

\begin{itemize}
\item マーケットの設定

 \begin{quote}
 「API set としては、徹底的な Unicode 特化が、および XML 処理系の 
 backend としての親和性が、今後世界で望まれる方向性だと思います。」（樋浦）
 \end{quote}

本ライブラリは利用者としてライブラリ作成者を想定しているため、Unicode 
に当然対応はしても、特化することはあまり必要でないと思われる。また XML 
処理系のバックエンドとしての親和性は後年度の開発で実現する予定である。

\item Unicode 対応および ICU との関係

\begin{quote}
「ICU\footnote{(注：International Components for Unicode
(http://oss.software.ibm.com/icu/)）} が STSF \footnote{（注：Standard
Type Services Framework (http://sourceforge.net/projects/stsf/)）} と 
IIIMF \footnote{（注：Internet/Intranet Input Method Framework
(http://www.li18nux.net/subgroups/im/IIIMF/index.html)）} （すべて 
UTF-16 ベース）を取り込んで、I/O(2D text)を含む、Java I18N framework 
すべての C/C++ port になったとき、多数を占めるだろう Unicode API set 
を望む側の人々が、m17nlib の方を国際標準として選ぶ強い理由が必要だと思
います。 」（樋浦）
\end{quote}

ICU を差別化をはかる対象ではなく、m17n-lib をより高機能なものにするた
めのサポートライブラリと捉え、利用できるところでは ICU を利用して 
m17n-lib を実装する予定である。特に Unicode 処理のうち、正規化や照合な
どのように現在手を着けていない困難な部分については、既存のライブラリを
用いる方針である。

\item 用語等

\begin{quote}
「モデル・用語等が結果的に独自のものになっており、国際標準やデファクトス
タンダードとあまり調和していないように思われる。そのため、（Mule や
Emacs を知らないものにとっては）このままではやや理解しにくいものになっ
ていると思われる。この技術の適応範囲や主要な対象、および、現在の需要と
の関係も不明確である。」（守岡）
\end{quote}

ドキュメント内の不適切な用語は修正し、対象等について説明を加えた。

\end{itemize}

\item 妥当性について

\begin{quote}
「ただ，既存の C 言語 API をベースに考えられている部分があるが，ロケー
ルの扱いや関数の動作への影響，ファイル入出力やファイル内での文字の表現
がどうなっているのかなどの説明が不十分，一般のプログラマ向けの仕様とし
ては難しすぎないかなど，いくつか気になる点がある。」（末廣）
\end{quote}

ライブラリが想定する利用者層に関して記述するなど、説明を加えた。

\begin{quote}
「繰り返しになりますが、API set として受け入れられることに重点をおくの
ではなく、mule で圧倒した「なんと言ってももう動く実装があるもんね」方
式のほうが、これからスタートするプロジェクトとしてはより有効なのではな
いでしょうか？（部品化ということです）」（樋浦）
\end{quote}

新規性の項で説明した「テキストの情報を統一した方法で扱う」という優位性
を強く主張していく予定である。「実際に動く実装」の実現は来年度以降の開
発計画に含まれている。

\begin{quote}
「現在多く使われるようになった XML などの構造化テキストを扱うための界面
や、こうした構造化文書を解析・加工するための支援（ないしはそうしたこと
を目的としたモジュールとの界面）、あるいは、こうした構造化文書をある程
度の品質で多言語組版表示するといった課題を解決していない、ないしは、そ
の方向性を示していない。」（守岡）
\end{quote}

構造化文書に対応する M-text は、もとの構造をそのままテキストプロパティ
として保持することが可能であり、テキストプロパティはまさにこういう場面
にも有効な支援である。

\item ドキュメントの質

新規性の項でも述べたように、評価を依頼した版のドキュメントが API の仕
様に終始し、ライブラリとしての全般的な性格を述べていない説明不足なもの
であった。評価終了後、この版では第１章で本ライブラリの特徴についての節
を追加した。

\end{enumerate}

評価者と本開発担当者との間で本開発の方向性について検討するメイリングリ
スト {\tt m17nlib@m17n.org} を発足させたところ、一週間で60通近いトラ
フィックがあるほど活発な議論が行われている。今後、API仕様に関するドキュ
メントと評価者からのコメントを叩き台として、仕様自体とその表現について
改良していく予定である。

\section{技術開発の総括}

Unix/Linux汎用多言語処理機能ライブラリの開発作業項目のうち、平成１３年
度実施予定であった以下
\begin{enumerate}
\item 「m17n基本Cライブラリ」の基本機能の設計
\item 「m17n Xライブラリ」の基本機能の設計 
\item 「m17n 言語情報ベース」の設計
\end{enumerate}
について技術開発を行なった。

\begin{description}

\item[本技術開発の特徴]~\\ 
ソフトウェアにおける多言語化とは、あるソフトウェアのうえで、いろいろな
文字、言語などの文化的慣習を混在させて使えるようにすることを指す。この
際には入力、表示、編集にあたってさまざまな情報が必要である。本開発では、
多言語テキストを単なる文字列としてではなく、これらの情報を含んだオブジェ
クトとして統一的に取扱うことを可能とし、しかも計算機を利用する様々な場
面で用いることができる汎用ライブラリを実現する。このライブラリの設計上
の特徴は、補足情報をも含んだテキストを表わす構造体を定義し、それを処理
の基本単位とすることである。このようにテキスト処理の基本単位として、こ
れまで「補足的」とされていた情報も含む構造体を用いること、そしてその結
果テキストの情報を多くのアプリケーションが同じ方法で扱うことは、多言語
化を必要としないものを含め、テキストを処理するソフトウェアすべてに転換
をもたらすと期待できる。

\item[本技術開発の戦略]~\\ 
本開発で実現するUnix/Linux 汎用多言語処理機能ライブラリの最終目標は、 
Linux/Unix 上の GNOME (GNU Network Object Model Environment) の上で、
多言語対応アプリケーションの開発ができるようにすることである。このため、
そのベースとなる C ライブラリ 及び X ライブラリの多言語化を行なってい
る。本ライブラリでは、多言語処理機能の新たな体系を確立することを目指し
ているが、現時点でのテキスト処理体系に依存した現存のソフトウェアの移行
を容易にするため、体系相互の対応関係を明らかに保つことに留意して設計を
行なった。

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

\item[本技術開発の内容]~\\
\begin{itemize}
\item 「m17n基本Cライブラリ」の基本機能の設計

C ライブラリが提供する「テキスト処理」に関するライブラリ関数 101 個の
うち、後年度に開発を行なう予定の「m17n 基本 C ライブラリから既存のロケー
ル機能を利用する手法の設計」に含まれるべきものを除くと 54 個の関数が残
る。これらについて、対応する多言語版の関数のAPI を設計した。

\item 「m17n Xライブラリ」の基本機能の設計 

 X ライブラリが提供するライブラリ関数は 512 あり、そのうち、「テキスト
処理」に関するものは 70 個である。これらのうち「m17n X ライブラリ」が
内部的に処理するためのものを除いた 41 個について、対応する多言語版の関
数の API を設計した。

\item 「m17n 言語情報ベース」の設計

上記ライブラリから利用される「m17n 言語情報ベース」の枠組みを設計し、
検証のために、文字セット、文字のプロパティ、フォント、入力メソッドに関
するデータベースの試作を行なった。試作に当たっては、Unicode コンソーシ
アム、IBM、 京都大学安岡孝一氏によるデータを用いた。

\end{itemize}

\item[本技術開発の評価]~\\
API の仕様書を外部評価者に評価を依頼した。この結果 API 仕様書という形
では設計の方針が不明確であるという問題があるものの、アプリケーション開
発者向けの汎用多言語化ライブラリ開発の意義は大きいという評価を受けた。

\end{description}

本開発で実現された API の設計に沿って汎用多言語処理機能ライブラリの実
装を行うことによって、多言語テキストを単なる文字列としてではなく、多く
の情報を含んだオブジェクトとして統一的に取扱うことが可能となる。

多言語化機能を必要とするソフトウェアは、今後ますます増加する。複数のソ
フトウェアから共通に利用できる多言語化ライブラリを、オープンソースソフ
トウエアとして提供することによって、多くのソフトウェアの開発をより効率
的に行い、開発コストを削減し、結果として計算機利用における言語的障壁が
世界的に軽減されることが期待できる。

