AppleのAPGSがAdobe Japan1-5に統合された。「統合」したというより、「追認」したというのが正確なところかもしれない。もともとAdobeは、Adobe Japan1-4を決めたときに、これでDTP用の字形のセットは十分と考えていたはずで、Appleが独自に拡張したAPGSについては無視していた。
　Adobe Japan1-4を越えてAppleが字形を追加していったのは、当初からヒラギノは「二万字」というアナウンスをしていたことと、2000JISに対応することを目標にしていたからであろう。DTPで必要とする字形と、公用規格の2000JISに二つを満足させる字形セットをつくるためには、Adobe Japan1-4では十分ではないということであった。Adobe Japan1-4のグリフが決められたのは、2000JISの以前だからである。
　2000JISによって、補助漢字はうち捨てられて、新たに第三・第四水準の文字が採用された。「文字が少ない」という声が無視できなくなったからである。

　JISが示すのは「字体」であって「字形」ではない。JISのいう文字とは複数の異体字を含む「字体」であるが、代表として「例示字体」を表記する。ところが、一般にはこの「例示字体」がJISの採用字形として認知されるので、「例示字体」で利用されなかった字形は使えなくなる。
　補助漢字にあった「梯子高」は、もともと楷書体や草書体などのスクリプト系の書体のときに、「口高」が変化したもので、明朝体では「口高」、草書体では「梯子高」というのがトラディショナルな使い方であった。
　そのため、「梯子高」は「口高」に異体字の一つであり、フォントベンダーは明朝体では「口高」を、草書体では「梯子高」と実装時に使い分ければいいというのがJISの判断であった。
　しかし、ユーザーにすると、草書体で「梯子高」を使っていると明朝やゴシックでも同じように「梯子高」を使いたいというウォンツが発生する。これは文字の規格としてはどうあるべきかというということではなく、コマーシャルベースのものである。
　JISは規格に含まれていない字形は例外処理してくださいというのが考え方なので、作字して使えばいいわけである。DTPにおいては、例外処理は難しくない。
　しかし、文字を扱う場合、テキストコードでやり取りしても扱える字形を増やしたいというのが本当のところである。テキストファイルをMacintoshとWindowsと、あるいはUNIXでやり取りしてもより多くの字形を正しく認識できるようにしたいわけである。
　字形を増やすことは、JISの考え方にはない。しかし、字形を増やしたいという要求がある以上、それに対処するしかない。その結果が2000JISの第三・第四水準の追加文字というわけだ。とはいえ、字形を増やすと包摂基準が複雑になる。というより、文字によって包摂基準が変わる可能性があるから、統一した包摂基準を適用することはまずできない。

　日本語のフォントについては、どういう字形を使うのかということは、フォントベンダーの判断になるだろう。2000JISで追加した字形があっても、それを実装するときは、フォントベンダーが独自の包摂基準を採用する。同じ明朝体でも、書体デザインの考え方では、包摂の考え方が変わってしまうことはありうることだからである。
　たとえば、Mac OS X 10.2のヒラギノPro書体の最後から3番目の「蜃（グリフID＝［20296］）」の字形は、グリフIDの［6510（シフトJISで［E587］）］と全く同じ字形になっている。
　おそらく最初に字形をサンプリングしたときは、少し字形が違っていたのだろう。しかし、フォントとして実装するときに包摂されてしまったのだと考えられる。したがって、別のフォントベンダーがAdobe Japan1-5を採用するとき、この二つの「蜃」の字形は別の字形になる可能性はある。ただし、いまでもCIDフォント同士でも、フォントベンダーが異なると字形のディテールが変わるものもあるので、フォントが変わることで字形が変化することは、フォントデザインの観点から言うと避けられないことである。

　こうして包摂された字形は、おそらく使えなくなってもあまり実害はないかもしれない。一般的な文書では字形のディテールの違いはまず問題とならないからだ。
　もし包摂してしまっても問題のない字形であれば、本当は無視してもよいことになる。過去において利用されていたということだけで、リストアップされているのであれば、今後は利用されない可能性はあるだろう。
　いずれにしても、野放図に字形を増やしていくと、使われない字形ばかりが増えていく怖れがある。そう考えると、標準の字形は必要以上に増やさないほうがよい。いや、増やすべきはないだろう。人名漢字は別として、いたずらに字形を増やすのは誰にとってもメリットはない。
　字形をどんどん増やしていったとき、フォントの開発費用もアップするわけで、その高くなったフォント買う人がたくさんいれば、もちろん、現実的には可能だろう。しかし、実際に「文字がたらない」という声はあっても、「フォントが高くなっても文字を増やせば買うぞ」という声はほとんど聞かれない。金は出さないがサービスはたっぷり、というのであれば、現在の枠組みのなかでできる範囲でするしかない。

　だから、字形セットを決める立場で言うと、これ以上は増やしたくないというのは当然なのである。APGSがでたとき、Adobeが「Adobe Japan1-5の予定はありません」といったのは、「本当に必要なのか」ということが見えないからだろう。
　今回、APGSがAdobe Japan1-5になったのは、2000JISで決めてユニコード化された字形は無視できないと判断したからだろう。テキストで使われる文書交換の文字コードが今後ユニコードになるのであれば、字形セットの最大公約数を目指すAdobe Japanと1-xしては、APGSを包含するしかなくなる。
　Adobe Japan1-4では「土吉」はユニコード化されていなかったが、10.2のヒラギノでは、サロゲートペアでのユニコードマッピング（u20BB7［D842+DFB7］）が行われている。つまり、2000JISに対応したユニコードアプリケーションでは、「土吉」は文書交換可能なのだ。

　今後Appleは日本語の字形は増やさない可能性が強い。「公約」は果たしたのだから、当分は「日本語DTPでの文字が足りない」という意見がかりにあっても、それに耳を傾けることはないだろう。
　Adobeも、Adobe Japan1-5はそれほど本意ではなかったとみえて、「5146.Adobe-Japan1-5.pdf」では、小塚フォントを使わずにヒラギノで作成した。ということは、オリジナルはApple（あるいは大日本スクリーン製造）が提供したものと考えたほうが自然だ。
　Adobe Japan1-5が決まったことで、これからAdobe Japan1-4の対応は加速化するように思う。1-4がスタンダードになったとき、はじめてDS以外のフォントベンダーは、Adobe Japan1-5に対応するかどうかの態度を明確にするのではないか。

　ただし、2000JISの文字をすべてユニコードで文書交換するためには、Adobe Japan1-5への移行は必要となる。ユニコードでの文書交換というウォンツが本当にあるのであれば、1-5への移行は思ったより早いかもしれない。
　たとえばEGWORD12で試してみると、先程の「土吉」はAdobe Japan1-4に含まれているが、ヒラギノで入力すると、ユニコードで指定される。しかし、Adobe Japan1-4のフォントに差し替えると、「土吉」はグリフIDしか持っていない。そのため、Adobe Japan1-4が認識できないユニコード「土吉」はトーフで表示され、正しく変換できなかったりするのだ。
　そうすると、2000JISで完全な文書交換を果たすためには、Adobe Japan1-5は必須となる可能性はある。2000JIでの文書交換が本当に必要かどうかは別として、それを望む声は大きくなるに違いない。もっとも、EGWORD12でもテキスト形式でユニコードそのものを保存するオプションがないので、テキスト形式で保存するといっても、当分はシフトJISのままかもしれない。
　いずれにしても、文書交換でユニコードが使われるかどうかということが、Adobe Japan1-5の価値になりそうである。そうなると、Windowsで利用できるユニコードフル対応のアプリケーションと、Adobe Japan1-5フォントがが必要かもしれないけどね。そしてブラウザがユニコードに対応すれば、Adobe Japan1-5の存在価値はもっと明確になるのではないだろうか。

◆「大きく変貌する日本語文字セットの最新状況」セミナーレポート［お宝鑑定団］
http://www.tcp-net.ad.jp/danbo/jpc2002/index.html