 |
 |
記事検索 |
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
特別編23 JIS X 0213の改正は、文字コードにどんな未来をもたらすか（6） 改正の影響：MSフォントのデザイン変更とその波紋について |
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|||||||||||||||||||
|
■最も社会に影響を与える変更は、例示字体を変更した部分 前回まで5回にわたって今回の改正の具体的内容をお伝えした。では、これが我々の暮らしにどのような影響を与えるのだろうか。そうした視点で改正の内容を再び振り返ってみると、キーになるのは前回の特別編22で述べたような非互換変更の部分ではない。なぜなら、追加された10字は以前からUCS（≒Unicode）に符号位置を持っており、符号化方法にUnicodeを採用する実装では問題にならないからだ。JIS X 0213の文字セットは、ほとんどUCSの符号化方法で実装が進められているのが現実だ。この非互換変更が問題になるのは、JIS X 0213で定められた符号化方法を実装したシステムのはずだが、幸か不幸かそのような実装はかなり限られる。 では、現実にインパクトを与えるのはどこかというと、例示字体を変更した部分だろう。これにより関係各社は、自社プロダクトの仕様変更をするかどうかの決断を迫られることになる。となると興味は、どのベンダーが変更をし、どのベンダーが変更をしないかとなる。 こうした未来の業界地図を一望することができたのが、改正に先立つ2月6日に行なわれたイベント『PAGE2004』（主催・日本印刷技術協会）におけるセッション「拡張する文字コード標準化と実装」だった[*1]。 ここでは、新JCS委員会で幹事を務めた小林龍生氏が司会を担当した他、同委員会の委員であり、規格原案を作成した2002年度WGで幹事を務めたマイクロソフトの阿南康宏氏、あるいはDTP業界で大きなシェアと影響力をもつアップルコンピュータの米本社から木田泰夫氏が出席するなど、改正JIS X 0213の内容をいち早く知ることができるのはもちろん、その実装がどうなるかを占う上で非常に興味深いメンバーが含まれていた。 最初にマイクを握った阿南氏は、ユーザーの要求を、表外漢字字体表の印刷標準字体が「意識することなく容易に」そして「文字化け・字体化け[*2]することなく」表示、印刷、そして情報交換できることと分析した。その上で、これらの要求を満たすため、搭載フォントの文字デザインを印刷標準字体に置き換えるだけでなく、IMEで優先的に候補表示されるようチューニングすること、さらに印刷標準字体に対応したフォントがOSやアプリケーション上でまず最初に選択されるようになるべきとした。 他方で情報交換、つまり符号位置を交換しても文字が化けないためには、送受信する双方が文字コードを合意することが必要となる。そのためには自社の対応だけでは限界があり、サードパーティやユーザーコミュニティとの連携が重要であることを訴えた。このために同社は、関連技術情報の開示やパートナー各社との連携を強める意向であることが表明された。 ■MSフォントの文字デザインを、改正JIS X 0213に合わせて変更 ここまでは「考え方」の部分だ。では具体的にどのように実装するのか。マイクロソフトは次期クライアント版Windows（以下、本稿ではLonghorn）で、改正されたJIS X 0213の文字セットをフルサポートする。そのためにMS明朝、MSゴシック、MS UI Gothic等のMSフォント[*3]において、以下に挙げる変更を行なう。
・TrueTypeからOpenTypeフォント仕様準拠に変更 さらにLonghornで実装予定の、よりバージョンの高いレンダリングエンジン『Uniscribe』（Unicode Script Processor）により、Windows XPまでは表示不可能だったJIS X 0213の結合文字、アイヌ文字、発音記号などを表示できるようにすることが表明された[*4]。もちろんMS-IMEも、新しいMSフォントと連携して印刷標準字体を優先的に候補表示するようになる。 以上に加えて、私がマイクロソフトに問い合わせて判明した事実を簡単にまとめておく。新しいMSフォント（以下、新MSフォント）はフォント名を変更しない。また、Longhornではデフォルトで新MSフォントがインストールされるが、ただちに新フォントへ移行できない利用者やシステム向けに、旧来のMSフォントもインストール可能にする。もっともこれは旧フォントか新フォントかの二者択一であり、新旧を併用することはできない。 ■なぜマイクロソフトは、新MSフォントのフォント名を変更しないか？ こうしたマイクロソフトの対応策の中で最も注目されるのは、同社が新MSフォントをデザイン変更する点だ。これにより150弱の符号位置については、新MSフォントとWindows XP以前に搭載されている旧MSフォントとの間で、包摂の範囲内であるにせよ字体が化ける。 これは「文字化け・字体化けのない表示・印刷・情報交換を目指す」とする同社の方針と矛盾するように思われるかもしれないが、むしろ彼等にとっては、〈今回の改正で起こり得る字体変更による混乱は、将来の字体の安定のための過渡的な混乱〉（追補規格票 解説 p.39）なのだ。マイクロソフトは新JCS委員会と同様、この実装が普及するにしたがい、混乱は収束に向かうという考え方をとっている。 ついで目を引くのがフォント名を変更しないことだ。新MSフォントのバージョンは「ver.3.00」になるはずだが、一般にOSやIME、アプリケーションはフォント名は判別しても、そのバージョンまで認識しない。したがって、例えばMS明朝が使われたファイルをWordで開いたとして、そのMS明朝が変更前なのか、変更後なのかをWordはわからない。ところがしかし、もしそのWordがインストールされたシステムに新MSフォントがあったとすれば、ユーザーは「意識することなく容易に」印刷標準字体を使うことが可能になるというわけだ。 またこれとは別に、多くのWindows対応アプリケーションは、かなりの頻度でフォント名を決め打ちして作られており、デフォルト設定のままなら、まずMSゴシックやMS明朝等を探しにいくという現実がある。こうした状況の中では、仮に旧来からのMSフォントと別に印刷標準字体対応フォントをバンドルしたとしても、ユーザーが意識的にアプリケーション設定を変更しない限り、印刷標準字体対応フォントは利用できない。マイクロソフトは、これでは「意識することなく容易に」印刷標準字体を利用できないと考えた。 次回で述べるアップルコンピュータの姿勢と比べるまでもなく、文字の形の変更が即座に就業時間の増加につながるような、例えばDTPの世界などから見れば、こうしたマイクロソフトの対応策は大変なハードランディングと映る。もちろん、今回の新MSフォントの変更はJISの改正に基づくものだ。特別編20で既述の通り、変更された例示字体はすべて包摂の範囲内であり、同様に新MSフォントの変更もJISが許容する範囲に収まる。 しかし、過半のシェアを占めるOSにバンドルされ、多くのアプリケーションでデフォルト選択されるフォントが、フォント名を変えないまま同じ符号位置の文字デザインを変更するとなれば、互換性を重んじる立場からは、話は単純に「JISの仕様通り」とはいかなくなる。それが本当に過渡的なものかどうかは置き、多かれ少なかれ実際に社会的な混乱が発生することは、新JCS委員会とマイクロソフトが等しく認めるところなのだ。 ■マイクロソフトの対応策の「根拠」 もっとも、こうした考え方は決してマイクロソフト独自のものではないことには注意したい。例えば2001年度新JCS委員会での配付資料のうち、日本書籍協会が提出した文書[*5]。ここではマイクロソフトとまったく同じ文脈で〈単に印刷標準字体が出せる、使えるというだけでなく、普通に入力すれば（仮に字体のことを何も知らない人が無意識に使ったとしても）まず最初に印刷標準字体が出てくるということ〉とある。おそらく日本書籍協会ならば、今回のマイクロソフトの対応策に両手をあげて賛同するはずだ。私からの問い合わせに答え、マイクロソフトはその根拠として「ユーザの要望」を挙げているが、具体的にはこうしたものが含まれているはずだ。 じつのところ阿南氏は、かつて2001年度新JCS委員会において、当時発売されたばかりのWindows XPを使い、表外漢字字体表の前文そのものをスクリーンに映し出しながら、そこで「ワープロ等で打ち出せない」として問題にされていた「鴎」「祷」「涜」の印刷標準字体は、すでに1998年時点から表示・印刷可能であり、Unicodeを基本的な文字コードとして使うWindows XPならば、ごく近い将来に1,022文字の印刷標準字体すべてを容易に実装することも可能であるというデモンストレーションをしたことがある[*6]。 このUnicode（≒UCS[*7]）を実装の主軸におくという考え方にしたがえば、ごく近い将来JIS X 0221（＝ISO/IEC 10646≒Unicode）に、すべての印刷標準字体が収録されるのを待つだけで[*8]、他には特にJIS文字コードを変更する必要がないことになる。次回で詳述するが、実際にアップルコンピュータはこの考え方により、すでに改正JIS X 0213には対応済みとしている。 しかし、この時のデモンストレーションの結果を阿南氏の言葉により振り返れば、
というものだった。ここまで述べたマイクロソフトの対応策には、こうした苦い経験も踏まえられていると考えるべきだろう[*9]。 ここで思い出してほしいのは、表外漢字字体表は常用漢字表など他の国語施策のように内閣告示訓令ではなく、法的裏付けを欠く審議会答申でしかないという事実だ。つまり以上の検討から浮かび上がるのは、マイクロソフトは表外漢字字体表の正統性や影響力を最大限度に強めた解釈をし、それに基づいた実装を目指したということになる。そしてこうした姿勢は、例示字体を「あえて」変更し、非互換変更を「あえて」行なった改正JIS X 0213の原案作成者、新JCS委員会の姿勢にぴたりと重なる。 報道によるとLonghornは一部機能を縮小した上で2006年内の発売を目指すが、現実的には2007年前半が無理のないスケジュールと言われている[*10]。これが正しければ、新MSフォントが世の中に出回るようになる「Xデイ」は2006年以降、おそらくは2007年前半、つまり約3年後ということになる。 次回は、引き続きPAGE2004にフォーカスを合わせ、その席上で発表されたアップルコンピュータの対応策について考える。これと今回説明したマイクロソフトの対応策をあわせ考えれば、「Xデイ」以降、Longhornとこれ以外のほぼすべての実装との間に、いわば「字体の壁」というべきものが出現することがわかるはずだ。やれやれ。
◆追記 「JIS X 0213 Mail List」（http://wakaba-web.hp.infoseek.co.jp/jisx0213-ml.ja.html）におけるUCHIDA Akira氏の投稿による。同氏に感謝。
（ 小形克宏 ） 2004/06/02 - ページの先頭へ-
|
