ちくちく日記

DTP系備忘録。真面目にやってます。

IVSとフォントの関係

Font 文字 セミナー

先日、飲み会の席で、フォントに詳しい人と、フォントメーカーの人と一緒のテーブルになった。
で、なんでそんな話になったのかは忘れたんだけどそのテーブル、酒を飲みながら、UnicodeだのAdobe JapanだのIVSだのの単語が飛び交うという、ちょっとまぁ、それどうなの、酒飲みながらする話なのというようなテーブルになってしまって、一緒に飲んでいたその他大勢の皆様をどん引きさせてしまってたのですが、個人的にはそこでの話が大変面白かったので、忘れないうちに書いておこうと思う。

テーブルでは主にIVSについて、いまいちわかっていない素人（私）が「IVSって、私たちのDTP業務で使うフォントにどう関係してくるの？」っていうのを、詳しい人やら、フォントメーカーの人に解説してもらってたのだけど。


私「IVS（Ideographic Variation Sequence）って最近ちらほら耳にするんだけど、つまりUnicodeで、コードがふられた文字に対して枝番をつけて異体字を管理する仕組みって事だよね？。」

▲こういう感じ。※イメージです


詳しい人「そうそう正解。」
私「で、異体字に番号をつけて管理するっていえば、AdobeJapanっていう規格もあるよね。AJ1-5とか1-6とか。あれは、Adobeが字形に対してキャラクターID（CID）をつけて管理できるようにしたものだよね。」

▲CIDはこう。※イメージです


詳しい人「そうだね。」

私「よくわからないのは、IVSっていう異体字を管理する仕組みがあって、今後それがフォントに取り入れられると、今つかってるPr5とかPr6ってフォントが、IVSフォントっていうフォントに変わるってことなのかな？たとえば、AJ1-7対応のPr7フォントってのはもうでなくて、代わりにIVS v1とかってフォントになるのかな？異体字の管理はもうAdobeJapanという規格じゃなくて、IVSっていう規格になるってこと？」

詳しい人「いや、そもそも、AdobeJapanとIVSの規格って全く違うものって訳じゃないよ。今制定されているIVSの規格はAdobeJapane1-6をまるごと取り入れたものだから。」

私「まるごと？同じものなの？」

詳しい人「そう。だからフォント対応っていうのも、結局文字と字形（グリフ）を結びつけるテーブルが、今AdobeJapanというテーブルしかないのが、IVSっていうテーブルを増やすだけだから、全く新しいフォントになるかどうかはわからない。極端な話、今あるフォントのバージョンアップで、IVSの対応テーブルをつけるだけって事も可能。」

詳しい人「OS X LionでバンドルされているヒラギノNフォントは、IVS対応してるけど、今までのヒラギノNフォントにIVSのためのテーブルが追加されているだけで、今までと変わらずに使えてるでしょ。」

私「そのアップデートされたIVS対応フォントがあったとして、IVSの機能ってすぐに使えるものなの？」

詳しい人「IVSの機能を使おうとしたら、フォントだけじゃなくて、OSとアプリケーション側もIVSに対応しないとだめだね。」

私「じゃ、今後、IVS対応フォントが増えて、アプリケーション側もIVSに対応したら、IVSを使った異体字切り替えとかができるようになるるって事か。で、そのIVSのテーブルって、この先字形が増えたりしないの？AdobeJapanが1-5、1-6ってグリフ数が増えたみたいに、IVSもVer1、Ver2みたいにアップデートされたりしないのかな。で、アップデートされてグリフ数が増えたら、フォント側はどういう風になるんだろう？Pr5、Pr6みたいに違うフォントになるのか、同じフォントで細かいバージョン違いになるのか。」

詳しい人「メーカーとしては、今後の対応をどうするかってとこまで決まってない。そもそもまだIVS対応してないし。IVS対応にしたって既に出ている1-4、1-5、1-6のフォントを対応アップデートするか、それとも全く別として出すかも決まってないし。」

詳しい人「それに、グリフ数を今後増やすかどうかってとこも難しい問題。今話してるIVSにしても、AdobeJapanを取り入れて作ったものとは別に汎用電子の規格ってのがある。」

私「汎用電子？IVSのテーブルがいろいろあるってこと？」

詳しい人「そう。これは戸籍とかそういう公の電子書類に対して使えるようにって事で、政府がやってる規格として登録されてる。この汎用電子の規格として登録されたグリフってのが、とにかくなんでもかんでも使えるようにって感じで登録されちゃってる。結構問題。」

私「でも使える字形数が多いのはいい事じゃないの？」

詳しい人「いや、そういう話でもないんだよね。」


まぁ酔っぱらいつつの話だからこんなにスムーズな流れで話してたわけではないんだけど、なんとなくこういう話を飲み会の席でやってた。で、話がいよいよ面白くなりつつあるところで、残念ながら時間切れでお開き。


もうちょっと詳しく知りたいなーと思っていたところ、IVS技術促進協議会というところで「UnicodeとIVSの基礎について」というセミナーがあるよ、という情報が！

▲タイムリー！


これは、ぜひ行ってみたい！ということで、行ってきた！
ここからそのセミナーレポートなんだけど、例によって長いので「長げぇよ！読めないよ！」って人は、最後に3行まとめをおいとく。そっちを読んでくれ。



IVS技術促進協議会セミナー「UnicodeとIVSの基礎について」


まずこのセミナー主催のIVS技術促進協議会っていうところは、IVSの普及促進をはかるという団体なんだよね。コンピューターでの日本語表示において、いままでいろいろと問題になってきた異体字処理を、Unicodeの規格でIVSっていう異体字処理の仕組みを作って、これを普及させることで問題の解決をはかっていこうということで、アプリケーションメーカーやフォントメーカー、印刷会社なんかが参加して活動してる。

で、今回のセミナーはそのIVSについて、知識の普及の一環としてUnicodeとIVSの仕組みについての基礎講座。

最初にまずUnicodeの基礎知識講座から。スピーカーは小林龍生氏。
小林氏は「ユニコード戦記 ─文字符号の国際標準化バトル」という、文字コードに関する本の著者で、この日の講座もこの本のダイジェスト版のような内容らしい。「この本を読んだ事ある人はこのセッション聞かなくてもいいです（笑）」といってた。
ちなみにこの本、1刷りでは「ちょっと致命的な誤植」があるそうで、買う時は2刷を買ってくださいとの事。（でもアマゾンとかで買うと、1刷か2刷かわからないよな…）

小林氏がIVS技術促進協議会に関わったのは「IVSの実装が始まったので、これを普及させて異体字問題の解決をしたい」という考えから。だけど、「その前にそもそもUnicodeの実装の促進が必要なのではないか」と。

たとえば、日本で普及しているガラパゴス携帯。ここでの電子書籍はいまだにJIS0208が使われている。電子書籍だなんだといっても、そこで使われる文字コードが未だにSJISである。この状態をなんとかしないといけない。本日はセミナー講師として、まずUnicodeについて基礎的な話をする。…が、（Unicode普及のために、基礎的な話をしようと思ってるのに）なんだか会場内には（基礎的な話なんか聞かなくてもいいような）詳しい人ばかり。（ここで、小形克宏氏が会場に入ってきて「また聞かなくてもいいような人が入ってきた！（笑）」みたいな事を言われていた）

確かに、こういうセミナーって、基礎講座と銘打ってあってもなんだか基礎なんか聞かなくてもいいような詳しい人ばかりが集まってたりするよね（笑）まぁ私みたいな素人も混ざってるから、足して2で割るとバランス的にはちょうどいいんだけど。

この後、小林氏のセッションでは、文字コードの規格について、SJISやUnicodeの歴史的経緯などの説明があった。
この説明の間に挟まれる余談というか「この時こういうことがあって…」という話がすごく面白かったのだけど（例えば「カナダに漢字を使う少数民族がいて、この民族が使う漢字も登録しなければならないということで…」みたいな※これは冗談です）残念ながら、そういう面白い話については「メモを取らないように（笑）」という注意があったため、ここで公開するのは控えておく。
ただ、その面白い部分をのぞくと話は基礎的な文字コードの歴史の話や符号化文字集合による字形の違いの説明で、詳しくレポートするのも大変なので（ユニコード戦記をよめば全部書いてあるらしいし）省略。


小林氏から、基本的な説明を受けた後、Adobeの山本太郎氏によるIVS講座


「Ideographic Variation Sequenceの今後の課題」


セッションは最初に、文字、グリフ、書体といった用語の確認から。


【文字（Character）】
文字コードによって指定される、特定の文字集合の最小要素


【グリフ（Glyph）】
個々のデザインの違いを捨象（事物または表象からある要素・側面・性質を抽象するとき、他の要素・側面・性質を度外視すること）した識別可能な図記号


【グリフ・イメージ（Glyph Image）】
個別具体的なグリフの図形



ここでの用語定義はISO/IEC 9541-1、ISO/IEC 15285のテクニカルレポートを元にしたもの。ただし、このテクニカルレポートで定義されているグリフなどの考え方がそのまま漢字（日本語）に当てはめていいかどうかはわからない。
文字（Character）は文字コードによって指定されるものだが、同じ文字でも異なるグリフとなることがありえる。（これは異体字の問題）
同じグリフであっても、書体によって具体的な文字の形は異なる。（これは書体デザインの問題）
文字を（文字コードで）区別しているように、グリフも区別する必要があるが、その際に必要のない細かい字形差まで分けすぎていないか注意しなければならない。
書体を区別する必要もあるが、これは通常フォントによって区別される。


基本的な用語ばかりでこんなセミナーに来る人なら皆わかってるような用語なのだけど、文字に関して議論する時こういった用語ははじめにしっかり定義をしておかないと、話が噛み合なくなる。実際、この日もこの説明の途中に会場から「ここでいうグリフは、書体デザインの違いも含むのか」という質問がとんでいた。
山本氏の返答は「例えば明朝やゴシックといった書体デザインの違いによるグリフの差はある程度丸めて（ないものとして）考える。ここでは、明朝体のグリフを基本イメージとして考える」だった。


IVSとは

IVS（Ideographic Variation Sequence）とは、Unicodeの1文字（基底文字）に対して、字形を選択する番号（字形選択子）をつけて、グリフを指定しようというもの
いままでのユニコードは文字（Character）しか指定できなかった。これに字形選択子をつける事でグリフ（Glyph）を指定する事ができる

基底文字（BC）+ 字形選択子（VS）＝グリフ（glyph）

  • 基底文字（BC）には、あらゆる「CJK統合漢字」がなりうる
  • 字形選択子（VS）は、U＋E0100からU＋E01EFまで240の値のどれか（つまり一つの基底文字に対して240個までグリフがもてるのかな？）

VS17からVS256までが漢字用。U＋FE00からU＋FE0F（VS1からVS16まで）漢字用の字形選択子ではない（漢字外の字形ってなんだろう？ひらがなカタカナとか？）

  • 一つのIVSは一つのグリフを指示する
  • IVSは一つのグリフに対してユニークであり、他のグリフと衝突したりすることはない

IVSの登録は、登録手続きを経てUnicodeの規格として登録されるものなので、一つのIVSに複数のグリフが登録されたりといった（外字コードでよくあったような）問題はおこらない。

  • プレインテキストと同様の効力、安全性、信頼性をもち、異なる環境においても安心して利用できる


IVSをUnicodeで使えるようにする一番の主眼は、異体字を特定のアプリケーションや環境の機能に限らず、使えるようになる事。


印刷、出版において異体字処理は重要な課題だった。
いままで、日本語の異体字を表現するには、特定のアプリケーションで特別の機能を利用しなければならなかった（たとえば、InDesignで異体字切り替え機能を使わなければ表現できなかった）
入力から出力までの課程において、専用システムなどを組んで処理したとしても、どこかで1つでも間違えれば、（異体字）情報の欠落が起きてしまう。
これはAdobeにとっても長年の課題だった。


UnicodeのIVSは、ただの文字コードであるので、特定のアプリケーションや機能に縛られない。シンプルなテキストファイルのままで、異体字が処理できる。
グリフ情報をシンプルなプレイン・テキストとして交換可能にできる。

これがIVSの一番の目的である。


IVDコレクション

（何らかの用途、出自によって）登録されたIVSの集合体をIVDコレクション（Ideographic Variation Database）という

  • IVDコレクション、Adobe-Japan1は、（グリフセットである）AdobeJapan1-6を元に作成されたIVSの集合体
  • 2007/12/14にAdobeJapan1-6の14,647グリフをIVSとして登録、14,645の漢字に対応している
  • 2011/09/20に32のIVSを追加登録してレビュー（登録審査）が終了予定。


これが「そもそも今制定されているIVSの規格はAdobeJapane1-6をまるごと取り入れたものだから」っていう話だね。なるほど。Adobe Japan1-6として整理されたグリフを、そのままIVDのコレクションにしたということか。
レビューがもうすぐ終了ってことは、Adobe-Japan1というコレクションはこれでfixなのかな。今後グリフが増えたりしたらどうなるんだろう？（と、思ったんだけど、IVDコレクションってのは、一度登録されたら、追加とか削除はできないらしい。だったら今後修正が必要になったら、新たなコレクションとして登録し直しになるんだろうか？）

Adobe-Japanの説明のなかで、山本太郎氏はAdobe-Japaneというグリフ集合の規格が1-4、1-5、1-6と増えてきた経緯を説明。「（ Adobe-Japanへの）グリフの増加はできるだけやめたいが、1-6についても、必要に迫られて追加した。Adobeとしては、すべてのフォントがAJ1-6のグリフを持つ必要はないと思ってる」


IVDコレクションは、Adobe-Japan1だけではない

今現在登録されているIVDコレクションは、Adobe-Japan1だけではなく、もう一つある。

  • 2010/03に「汎用電子」IVDコレクションが登録
  • 汎用電子コレクションは、経済産業省により住基ネット・戸籍システム・登記システムなど、公のシステムで使う事を想定して登録されたIVDコレクション。
  • 汎用電子コレクションの字形はどこからきたものかというと、日本国内の行政システムに含まれる漢字を収集して整理したものがベース。


おお、汎用電子っていうのもこないだの話の中で出たやつだ。
日本語のIVSの規格にはAdobe-Japan1と汎用電子と2種類があるってこれのことかー。


複数のIVDコレクションの独立性

2つのコレクション、Adobe-Japan1と汎用電子は、相互にまったく干渉しない。
それぞれが全く別のコレクションで、その中のIVSについても、同じ物は存在しない。（IVSはすべてユニークである）
なので、Adobe-Japan1の中と汎用電子の中で同じグリフが違うIVSを割り当てられて存在することはありえる。


複数のIVDコレクションがそれぞれまったく別のものとして独立している理由

IVDコレクションは、それぞれ異なる目的、用途の為に作られたもので、そのグリフ集合が似たようなものであったとしても、まったく同一のものであるとは言えない。

つまり、Adobe-Japan1と汎用電子の中で、同じグリフを含んでいるように見えても、その文字に対してどのぐらいグリフを含むか（例えば、渡辺の辺に対して何種類の異体字を用意するか）や、その文字を含めた典拠（なぜその異体字を含めたか）が違うので、これを同一のものとはできない。

それぞれのIVDコレクションが、まったく別のものとして扱われるというは、理論的には正しいことのような気がするよね。
だって、これを一緒にしてしまうと、また今の（SJISなどの）文字コードみたいに「同じ文字のはずなのにグリフが違う！」とかの問題になっちゃうし。
だけど、そうなると、今度はアプリケーション側やフォント側で複数のIVDコレクションに対応していかなければならないってことで、それはそれで大変そう。ユーザーがどういうふうに使うことになるのかはわからないけど、いちいちコレクションを切り替えたりしながら使うことになったら面倒だな。
IVDコレクションが違うっていっても、Adobe-Japan1と汎用電子、同じ日本語なんだし、共通しているグリフもたくさんありそう。
となると、異なるIVDコレクション間でIVSを共有したりできないのか？という考えがでてくるわけだけど…


異なるIVDコレクション間でIVSを共有できるか

IVDコレクションが同一言語、同一文字体系、同一環境、類似ユーザーで構成されている場合は、技術的には、IVDコレクションの中のIVSを複数のコレクション間で共有する事は可能。
中国語と日本語でIVSの共有は難しいが、日本語環境同士のIVSなら、共有することは可能である。

では、Adobe-Japan1と汎用電子、同じ日本語で、似たような文字範囲のグリフ集合なのだから、二つのコレクションでIVSの共有は可能なのではないか
つまり、同じグリフを指定しているIVSを共有できれば、そのグリフを使う時に、どちらのIVDコレクションの物なのかを区別しなくてよいので、（フォントやアプリケーションが）対応するのが容易になる。

しかし、実際には、同じ日本語環境のIVDコレクションであっても、共有は簡単ではない。
一つには、粒度（りゅうど）の問題。
その文字に対して、どのぐらいグリフを含んでいるか（どのぐらいの異体字をもち、どこまでの異体字を包摂したか）というのを粒度（りゅうど）というのだけど、IVDコレクションによって、粒度の違いというのがあり、必ずしもすべてのIVSを共有できるとは限らない。


実際にAdobe-Japan1と汎用電子で、粒度がどんな風に違うのか。

この例は節という文字だけど、節という文字に対してAdobe-Japan1は3つのグリフを当てているのに、汎用電子では2つのグリフしかあてていない。

▲E0101のグリフはAdobe-Japan1にしかない


逆にこちら、籠という文字では、Adobe-Japan1は1つのグリフしかないのに、汎用電子では4つのグリフをあてている

▲E0101、E0102、E0103、E0104は汎用電子にしかない

こういう風に、コレクションの中で持っているグリフに違いがあるので、簡単に共有できない。

もう一つ、共有について当事者の合意が得られなければ共有できない。各IVDコレクションが異なる目的、用途で設計されているので、共有したいといってもできない場合がある。

つまり、Adobe-Japan1と汎用電子では、同じ日本語のコレクションだといってもその中身にかなり違いがあるし、目的、用途も違うので共有するといっても難しい部分がある。
（じゃ、例えばAdobe-Japan1に追加とか修正を加えたAdobe-Japan2というコレクションを作ったとしたら、そこではAdobe-Japan1のIVSを共有してアップデートとかが可能って事かな？）


相互運用性WGの活動

共有は難しいといったけど、そうはいっても、複数のコレクションがまったく別ものとして存在するのは（アプリケーションやフォント実装の上で）不便なので、相互運用するための調査も行われている

  • IVDコレクション間のグリフの対応関係調査

・類似・対応関係が不明瞭なグリフのペアを記録
・疑問点がある場合は、典拠など調査可能な場合には調査
・粒度の相違等、注意を要する事項を記載して文書化
・対応関係が明らかなグリフのペアを含め、フォントやアプリケーション開発上の参考文書として活用可能にする

グリフセットというのは歴史の積み重ねがあってそのグリフが採用されているので、その経緯なども調査しつつこういった調査をやっている。
これは、現在のAdobe-Japan1と汎用電子コレクションの関係において、関係性が不明な部分も多いので、その点を調査して文書化することで、IVS利用の相互運用性を高める為の資料とするもの。

これ…聞くだけで結構大変な話だよね…だって汎用電子のコレクションって、多分今戸籍とかで使われている文字をごそっっと（あまり精査せず）もってきちゃってるんじゃないの？
その文字をひとつひとつ、採用された経緯から調査してるってことか。大変だ。


IVS対応フォントの構成

ここからフォントやアプリケーションの対応の話に。
IVSでの異体字切り替えを利用するにはフォントやアプリケーション側の対応が必要になる。

では実際に、フォントをIVS対応フォントにするには何が必要なのかフォントの要件とその構成について説明があった
（一応セミナーの記録として書いとくけど、私はフォント作成に関しては素人なので、この手順が何をやってるのかはよくわからない。）

・必要なグリフ（Adobe-Japan1-6範囲内）
・Format12のcmapサブテーブル（UTF32）とFormat14のcmapサブテーブル


AFDKO（Adobe Font Development Kit for OpenType）というツールを使ってcmapのテーブルを更新する
難しいのは世の中にはJIS90対応フォンととJIS2004対応フォントの2種類があるので、それぞれ対応しなければならない。


JIS2004基準フォントの場合

KozMinPr6N-Light.otfフォントのcmapを調べる

% spot -t cmap=7 -C2 KozMinPro6N-Light.otf | grep 8fbb
[e0100 8fbb]=<\3056>
[e0101 8fbb]=<->

U+8fbbのe0101のグリフはデフォルトのグリフ（2点しんにょうの辻）なので、Format12を参照せよの意味

% spot -t cmap=7 -C1 KozMinPro6N-Light.otf | grep 00008FBB
[00008FBB]=<\8267>

U+8fbb e0101のグリフはCID 8267であることがわかる

JIS90基準フォントの場合

KozMinPro6-Light.otfフォントのcmapを調べる

% spot -t cmap=7 -C2 KozMinPro6-Light.otf | grep 8fbb
[e0100 8fbb]=<->
[e0101 8fbb]=<\8267>

U+8fbb e0101のグリフはCID 8267であることがわかる

% spot -t cmap=7 -C1 KozMinPro6-Light.otf | grep 00008FBB
[00008FBB]=<\3056>

U+8fbb e0100のグリフはCID 3056であることがわかる

また山本氏はこの説明の中で「新しいフォントを出しても、古いものが消える訳ではない。そこはよく考えてほしい。今までも新しい（フォーマットの）フォントをだしたからといって、古いフォントが消えた訳ではなく、古いフォントもあって、新しいフォントが増えたというだけだった。両方が残ってしまうのだということをよく考えなければならない」「こういう違いのある文字があった、という話をするためには、その古い文字を表示できるようにしなければいけない、結果的に古いフォーマットであっても残さなければならない」
と話していた。


アプリケーションその他のIVS対応

フォントだけがIVS対応しても、アプリケーションやOSが対応していないと使用できない。
Adobeのソフトウエアの対応としては、

  • テキストエンジンでの対応（Adobe Flash Player10）
  • PDFのFormでの対応（Adobe Acrobat/Reader 9以降）Formのみ対応なのは、PDFで公的書類の入力したりする時の人名、地名の入力対応のため。
  • グリフの表示等の基本機能（Adobe InDesign CS4以降）あくまで基本的な機能のみの対応。たとえば、正規表現検索でIVSが使えるかといったらそこはまだ使えない。コアな部分から取り入れていって、徐々に使えるようになればと思う。

他に

Adobeは文字の入力部分（IM）の部分を持っていないので（そこを提供することはできない）そこが対応しないと、IVSがどんどん使われる事にはならない。


IVSのこれから

IVSはいわゆる異体字の指定、再現、印刷における長年の課題に対する解決策であり、出版・印刷および今後の電子書籍に効果を発揮する。
IVS技術促進協議会の活動を通して開発者を支援し、IVSの有効利用を促進したい。

IVSが異体字問題がすべて解決できるかというとそうではない。
そもそもIVSで異体字を指定するにはもともとのUnicodeのコードがふられていないとならない。Unicodeの番号がふられていない文字はIVSを指定することができない。
それでも今後の電子文書のやり取りにおいて、異体字処理問題の解決にIVSが重要な役割を果たすだろう。


IVSの問題点

異体字処理の解決策として期待されるIVSだが、問題点もある

それは重複するグリフの問題。

  • ある文字の異体字としてIVSを登録したが、実はその文字がすでに違う文字としてコードポイントがふられている場合
  • 今後Unicodeに登録される文字がすでにIVSとして存在する場合


高と髙、吉と𠮷などのように、本来同じ文字として包摂されるべきものがすでにコードポイントをふられて別の文字として扱われている。これにIVSをふろうとしても、それぞれコードポイントをもっているので、IVSとして登録できない
これらをどう扱うかは2種類の考え方がある。
一つは、無理矢理それぞれお互いのグリフを異体字としてIVSをふってしまうという方法
しかしこの考え方はunicodeの包摂基準から外れてしまう。コードが違う文字なのだから、お互いのグリフを与えるのは間違いであり、IVSを使って区別するべきではないとする考えもある。


ここまでが山本氏のセッション。この後会場とのQ&Aに。

【会場とのQ&A】

Q.
IVDコレクションとして登録されるグリフは、登録の際審査されないのか？どんなグリフを登録しても採用されるのか？今のAdobe-Japan1と汎用電子にしても同じような字形が登録されているようだが、申請すれば（その字形に対する審査などなく）どんどん登録されるのか？

A.
（山本氏）レビュー期間はある。（字形の正当性についての）審査というものはない。
似たような字形の重複については、協議して合意すれば統合する事は可能だ。


Q.
朝日新聞社です。（住基ネットや戸籍登録などの）文字処理問題について取材しています。IVDコレクションはAdobe-Japan1と汎用電子の2つで、出版書籍はAdobe-Japan1、戸籍などは汎用電子という風になるのかと思いますが、これはアプリケーション側で切り替えて使う事になるのでしょうか

A.
（山本氏）電子政府的な用途とAdobeなどが一般的に使うアプリケーション上の用途は現時点では交わらない（同時に使うというシチュエーションにならない）と思う

（小林氏）IVSのメカニズムがどのぐらいのスピードで普及するか、一番早いのは出版印刷関係だろう。InDesignの異体字機能などがシームレスにIVSを使えるようになる。
一方、電子政府関係はIVSが普及しても自治体のシステムに取り込まれるかどうかがわからない。
なので現時点で（出版と官の使い分けを）どう両立させるかというような話はまだ早いと思う


Q.
（同じ質問者から）エンドユーザーから見た時に、アプリケーションごとにIVDを汎用、Adobe-Japan1と切り替えたりするのは大変かなと考えたのですが

A.
（日本マイクロソフト 田丸氏）
個人的な意見を申し上げると、先進国のなかで行政サービスがネットでできないという部分で日本は大分遅れている（エンドユーザーに対する）負担が大きいと思う。

（小林氏）
記事を書くのであれば、認識しておいてほしいのだが、使える文字が増えるということが、本当に便利なのかどうかをよく考えてほしい。
ある人のわがままで増えた文字が誤字であってもそれを削除する権限が行政にない。それがたまりたまってこれだけの数になって、全部そのまま符号化されている。
それがどれだけコストがかかることか、 そこをちゃんとした議論をせずにそのまま使っている、その事をよく考えて欲しい。

（山本氏）
私は、自分の意見をいう立場ではなく（この規格を）説明する立場だが、文字セットがどこまでいるかという事について、ユニコードに関していうと、ユニバーサルという言葉、unicodeのなにがユニバーサルであるのかというと、そのコードを見さえすれば、世界中どこでもその文字が表せる、というのを目指している。
異体字に関してもそれがユニコードで定義されるのであれば、同じ理想を目指すべきだと思う。グリフについても同じ事だ。
現実にはいろいろな事情があるので、個別対応もあると思うが、それは最低限に押さえて、グリフはユニコードの理想に沿うべきだと思う。


Q.
相互運用性ワーキンググループについて、いつからあって、どんなメンバーがいるのか

A.
去年の秋から発足した。詳しくはIVS技術促進協議会Webサイトを見て欲しい



【感想】
面白かった！IVSの基礎、IVSが目指すもの、それを取り巻く環境と問題点が、初心者でも理解できるように説明されていてわかりやすかった。

異体字問題について苦労し続けているDTP関係者としては、IVSの普及によってこの問題が解決されることを期待したいのだけど、実際に使われるようになるのはいつ頃になるだろう。
OS、アプリケーション、フォントそれぞれがIVSに対応する必要があるというような話を聞くと、先は長そう。
OSの対応については、最新のOSはWindowもMacもIVSに対応してるようだし、DTPで使うアプリケーションにしても、Adobeソフトは対応しつつある。でも、テキストを入力するソフトとして考えると、テキストエディタやMS Officeとか、あとデータベース関連ソフトが対応してくれないと、難しいよね。それと、フォントの対応。

よくある業務に置き換えて考えると、得意先がWindowsで入力したExcelファイルの名簿があるとする。これをMacでテキストファイルにして、InDesignに流し込んで組版して出力！って業務だと、得意先が使ってるOS、フォント、アプリ（Excel）、こちらで使ってるOS、フォント、アプリ（Excel、InDesign）そのすべてが対応していないとだめって事だものね。

それに、字形の重複や複数コレクションをどう扱うかというような問題がある。
字形の重複については、文字コードそのものの問題も含んでいるので解決は難しそう…。私なんかは「とりあえず重複してるぶんもお互いのグリフをIVSであてちゃえばいいじゃんか」と思っちゃうんだけど、そう簡単な話ではないんだろうな。
あと、複数コレクションの問題について「（Adobe-Japan1と汎用電子を）同時につかうようなシチュエーションにはならない」って話がでてたけど、でも、公のデータベースからはかれたテキストを使って、印刷物を作るといった業務とか発生しそうだよね。そういうときどうなるんだろう。まぁまだ実際の運用に至る所までいってないから、そこまで心配しなくてもいいのかもしれないけど。

IVSについて、いろいろとわかったのはいいんだけど、その分他の疑問もわいてきてしまった…。
この知識がある状態で、こないだの飲み会に参加してれば、もっといっぱい質問できたのにな。NAOIさん、もう一回飲みません？（笑）


それと、こういう日本語特有の字形の問題において、Adobe-Japanというアメリカの企業で作られた規格が採用されるっていうところに複雑な思い…。
別に嫌だとかそういう事じゃなくて、どうして同じようなグリフセットが日本で作られなかったのかな…と。日本でそういう（グリフをあつめて番号をふるような）作業をするところがなかったんだろうか。それが汎用電子だっていう事なのかもしれないけど。


では、最後にIVSについて3行で。


【3行まとめ】
IVSはUnicodeで異体字を指定するための技術。これを使えばシンプルなテキストファイルで異体字情報を含めたテキストのやり取りが可能に！

でも使うには、アプリケーションやフォント、OSがIVSに対応してなくちゃだめだよ。DTP関連ではAdobeソフトは対応しつつあるけど、フォントの対応はまだ！

できたばっかりのIVSなのに、すでに字形の重複や複数コレクションをどう相互運用するかといった問題もでている。これですべて解決ってわけではない。先は長そう！