InDesignにおけるIVSの実装と運用上の問題点
- 前回述べたように、IVSはGSUBよりも新しい分、すっきりと論理的にできている。だから、「漢字の異体字指定に関してはGSUBからIVSに乗り換える」というような思い切った転換を行い、なおかつInDesignなどにおけるIVSの扱いが信頼できるものであるなら、みんなハッピーになれそうだ。
- しかし、たぶん現実には、「GSUBはそのまま残って、IVSも使える」ということになるだろう。というか、すでにそうなっている。要するに、もともと複雑な状況が、さらに複雑化したわけだ。加えて、もちろん今後改善されていくとは思うが、InDesignにおけるIVSの扱いには、まだまだ問題が多い。以下、InDesign CS4における実装あるいは運用上の問題。
- IVSとGSUBの競合・重複の問題。たとえばInDesign上で、ある文字にGSUBとVSを両方適用したらどうなるのか。詳しくは「InDesign CS4におけるIVSとOpenTypeタグのあやしい関係」や「IVSとaaltタグの競合や重複」に書いたとおりだが、平たく言えば、「どのグリフが表示されるかをパッと理解するのは無理」ということだ（下図）。
- InDesignにおける結合文字の扱いの問題。InDesignはIVSの親字とVSを独立した文字として扱い、両者の間にカーソルが入ってしまう。これは、IVSの実装としては誤りで、極めて危険である。下図は、VSを付けてハの字型に置換した「平」のあと（VSの前）に1文字ずつ「凡」「社」「の」「今」を入力していったときのグリフの変化。VSの付いている字を赤字で示した。4行目の「の」にはVSが付いているが、その効果が顕在化していない。このように潜在したVSも、事故の原因となるだろう。
- 非対応フォントの問題。IVSは、その仕様上（InDesignに限った話ではなく）、非対応フォントでは親字として表示される。前回「IVSはフォントの変更に強い」という特徴を挙げたが、それは対応フォントを前提とした話あり、IVS対応フォントの少ない現状では、GSUBよりもむしろIVSのほうが不安定だと思われる。
- InDesignにおける合成フォントの問題。下図は、IVSに対応している（Lionの）ヒラギノ丸ゴProNのみから構成される合成フォントを定義し、IVSを表示してみたもの。よくわからないことになっている。
- このような点を考慮すると、「プレーンテキストで異体字情報を交換できる」というIVSの最大の特徴さえ、災厄に反転しかねない。受け取ったテキスト原稿から、目に見えないVSが混入する可能性があるからだ。というわけで、今回のまとめ。IVSは、枠組みとしてはよくできているのだけれど実装・運用の面で問題山積み。
*1:ただしこの問題は、「基底文字とVSの両方をまとめて選択した上で（本当はモノルビなのだけれど）グループルビを振る」という方法で回避できるようだ。
