IVSとGSUBはどう違うのか
- 異体字シーケンス（IVS）の特徴について、OpenTypeフィーチャのグリフ置換（GSUB）と比較しながら考えてみた。重要だと思われる点をメモしたものであり、IVSの体系的な説明ではない。
- IVSの概念は、下図のようなかんじ。符号位置に包摂される複数のグリフ（集合）のなかから、ある特定のグリフ（集合）をVSによって指定する、というイメージ*2。
- 上図はUnicodeの視点から描いたものだが、Adobe-Japan1フォントではデフォルトのグリフはcmapで指定されているので、実装としては下図のようなかんじ。IVSでは、原則として基底文字（親字）の包摂範囲を超えたグリフは指定できないので、VSを付けることによって「區」が「区」になったり「区」が「區」になったりすることはない。
- VSは「default ignorable」であり、IVS非対応アプリはVSを無視する。このとき、「別の字」に化けることがないよう、「基底文字の包摂範囲を超えない」という条件が必要となる。*3。
- 「区」の図のまとめ。IVSは、非対応フォントや非対応アプリで表示しても、原則として「文字」のレベルで化けることはない。
- 「辻」のIVS（下図）。Pr6フォントとPr6Nフォントではデフォルトのグリフが異なるが、VSを付ければ、その違いは消える。Pr6でもPr6Nでも、U+E0100が付いてれば一点しんにょうになり、U+E0101が付いてれば二点しんにょうになる。
- 「辻」のGSUB（下図）。GSUBは、グリフを「特定する」というよりは「変える」発想であり、デフォルトの（置換されていない）グリフを明示的に指定する手段がない。このためGSUBでは、フォントをPrNからPr6Nに（あるいはPr6NからPrNに）変えたときのグリフのブレを避けられない。
- Adobe-Japan1のIVDコレクションにフル対応したフォント間なら、（実際にやるかどうかはともかく）「すべての漢字にVSを付ける」という運用をした場合、「フォントを変えてもグリフが変わらない」という世界が実現する。
- 「辻」の図のまとめ。GSUBは（発想としては）グリフを「変える」仕組みだが、IVSはグリフを「特定する」（字形の範囲を限定する）仕組みであり、フォントの変更に強い*4。
- 「骨」のIVS（下図）。Adobe-Japan1には、「骨」のグリフは1つしかないので、VSを付けてもグリフは変わらない。それでも「骨」のためのIVSが用意されている。この話はややこしくなりそうなのでここでは深追いしないが、IVDコレクションとしてのAdobe-Japan1と汎用電子の違いを考える上で重要なポイントだと思う。
- 「骨」の図のまとめ。コレクション中に異体字のないグリフに対しても、IVSを与えることができる。
- 「櫛」のIVS（下図）。IVSではCJK互換漢字（下図ではU+2F8ED）は基底文字（親字）になれない。したがって、IVSはUnicode正規化によって置換されてしまうことがない。
- ちなみに「櫛」のGSUBは、下図のようなかんじ。CJK互換漢字も親字になる*5。
- 「櫛」の図のまとめ。IVSは、非対応アプリによって無視されることはあっても、データとして置き換えられてしまうリスクは（CJK互換漢字よりは）小さい。
- GSUBにおける漢字の扱いは、まだUnicodeが存在しなかった時代のしがらみを引きずっており、また、JISのたび重なる変更などのとばっちりを食って、化け物のように複雑化している。その点IVSは、（これまで見てきた図からもわかるように）シンプルにできている。では、IVSによって明るい未来が開かれるのだろうか。次回「IVSの問題点」（仮）に続く。
