❶ Adobe-Japan1-6にしかない文字の外字化

　Adobe-Japan1-6の文字は、そのほとんどがCMapによってUnicodeと紐付けられていますが、ごく一部Adobe-Japan1-6にしか収録されておらず、Unicodeと紐付いていないために実質的にInDesign等のDTPアプリ内でしか使えない文字（参照：CID/GID番号のみしか割り当てられていない記号類）があります。これは外字画像にする以外の方策はありません。

（追記）事例画像には一部既にUnicode符号化済の文字を含んでいます。

❷ 中国語の人名など日本語フォントで現状表示できない字形を表示するための外字化

　簡体／繁体中国語の人名など、現状日本語フォントで表現できない字形を表現するために外字画像を使用しているケースです。これはUnicodeの符号位置としてはAdobe-Japan1-6内のものが多数含まれると思われますが、その場合でも日本語と中国語では符合位置が同じでも割り当てられている字形（グリフ）が微妙に違うことがあるため、外字画像にせざるを得ない場合があります。学術書などでは厳密な字形の再現が要求されるケースも当然出てくるため、そういったケースでは現状では外字画像にすることになります。

　将来的にEPUB内での部分言語指定を各RSがサポートし、デバイスが対応する各国語のフォントを搭載すればテキスト化できるかと思われます。

❸ Adobe-Japan1-6内の異体字の字形を保つための外字化

　InDesignなどのDTPアプリ内では使用できるものの、テキスト化するとGSUBの情報が消えてしまうために字形を維持できなくなる文字の字形を保持するために外字画像としているケースです。

　典型的なのはJIS90字形を保持するために外字画像としているケースです（参照：JIS90字形とJIS2004字形で変化する文字の一覧）。この問題は古くはJIS78→JIS83の字形変化の問題、いわゆる「新JIS旧JIS問題」にまで遡る話ですので、割に根は深いと思います。

　また、EPUBのビューアに搭載されているフォントは現状ほとんどがJIS2004字形の「Pr6N」などのフォントであるにも関わらず、JIS2004字形を外字化してしまっているケースもあるようです。おそらく元の印刷データでJIS90字形基準のフォント（Pro/Pr5/Pr6）が使用されており、InDesignなどDTPアプリの機能でJIS2004字形のグリフを割り当てていた（「印刷標準字体」を段落スタイルで割り当てるなど）ケースで電子化の際に字形の維持を図ったものと思われますが、これは明白に意味がないためやめた方がよいと思われます。

　将来的にUnicode IVSが標準的に使用できるようになれば微細な字形の再現はテキストで可能になるはずですが、まだIVSを付加した文字が縦組み時に横転してしまう実装のビューアがあったりするなどRS側の状況が不安定なこと、InDesignデータから字形情報を保持したままUnicode IVSのテキスト化することが技術的に難しいことなどから、厳密に字形を保持するには当分は外字画像化が必要になるでしょう。

　ただ、このあたりの文字はもともとがJISの「包摂」範囲で、本来は規格内に双方の字形を含んでおり、JIS2000からJIS2004では「例示字形」が変わっただけです。微細な字形差に留まるケースが大半ですので、人名などどうしてもやむを得ない場合以外はテキスト化を許容した方がよいと考えています。

　なお、このあたりの話は以前に私のブログで書いておりますので、併せてご参照ください。Unicode IVSに関してはこちら。WindowsやMacも既にOSレベルでのUnicode IVS対応は済んでいますので、あとはInDesignなどDTPアプリの対応待ちという印象です。

❹ JIS X 0213内だがUnicodeの基本多言語面外の文字の外字化

　JIS X 0213内の文字で、少数ですがUnicodeで基本多言語面（BMP）外のCJK統合漢字拡張Bのエリアに割り振られた漢字が存在します。特に注意が必要なのは「𠮟」（U+20B9F）および「𠮷」（U+20BB7）です。
　「𠮟」はJIS第3水準漢字ですが、類似の文字にJIS第1水準の「叱」（U+53F1）があるため、通常はこちらで代用可能でしょう。ただ、「𠮟」の方が常用漢字とされたため（参照）、厳密に常用漢字の使用を求めた結果、外字画像となっているケースはあるかも知れません。

　また「𠮷」は人名に用いられる漢字ですので、厳密な字形の再現が求められるケースはそれなりにありそうに思います。例えば元首相の「𠮷田茂」氏の「𠮷」がこの字形です。通称「ツチヨシ」と呼ばれる、割に一般的な人名の異体字です。

　基本多言語面（BMP）外の文字は、展開するために内部的に2つの符号位置を必要とする処理となる（サロゲートペア）ため、長く表示に問題のある状態が続いていました。具体的にはついこの間までWebkit系のエンジンを用いるRSで縦書き時に正常に文字が表示されないなどの問題がありましたので、現状市場に出ているEPUBにはこれを回避するための外字画像を含むものが多数あるものと思われます。

　2016年11月現在では、EPUBのサイドロードに対応しているメジャーどころのRSで正常に表示ができておりますのでほぼ問題は無くなったと考えていますが、サイドロード非対応のRSも数多く存在しますので、完全な確認は私も取れておりません。

❺ JIS X 0213外だがAdobe-Japan1-6内の文字の外字化

　そう数は多くありませんが、Adobe-Japan1-6には含まれるものの、JIS X 0213には含まれない文字が存在します。漢字では例えば「髙」（U+9AD9）がそれに当たります。通称「ハシゴダカ」と呼ばれるかなり一般的な人名の異体字です。この文字はJIS X 0213としては通常の「高」に包摂されると見なされたため、独自の符号位置を与えられませんでしたが、Unicodeでは日本以外からの要望によって収録され、結果的に使えるようになったために広く使われているという経緯があるようです。

　また、記号類が多く含まれ、例えば「㈠」「㈳」「㈪」「⑴」「⒜」などがあります。これらはかなり一般的に印刷物で使用されている文字です。特に縦書きの文章でよく見かけます。

　「髙」や「㈠」「㈳」「㈪」「⑴」「⒜」といったような文字に関しては、現状メジャーどころのほぼ全てのビューアで文字の表示が可能になっているようですので、現状そこまで神経質に外字画像にする必要はないと考えています。

　（追記）一部、日本語フォントとしてIPAフォントを採用しているRSがあり、IPAフォントにはJIS X 0213までのグリフしか収録されていないため、外字化せざるを得なくなるという話もあるようです。

❻ XMDF／.bookのデータを変換した影響での外字化

　過去に作られたXMDFや.bookをEPUBに変換したケースで、XMDFや.bookが符号化方式としてShift_JIS（文字集合はJIS X 0208）を用いていたために、使用できなかったJIS第3水準、第4水準の漢字が外字画像になっているケースがあります（正確にはXMDFはバージョン3でUnicodeに対応したが、ほとんど普及していない）。XMDF／.book由来以外にも、処理プログラムの一部にShift_JISベースのものを用いているケースで同様の事例はありそうです。

　文字としては既にテキスト化可能であっても、過去に制作して既に市場流通しているものに再度手を加えるには当然ながら相応のコストが見込まれますので、まだしばらくはこういったものも市場に残りそうです。

❼ 縦書き時に3桁以上の英文字／4桁以上の数字を縦中横で挿入するための外字化

　現状、EPUBで縦中横指定で表示対応可能な英文字／数字の桁数はRSによって大きな差がありますが（参考：項目3-1）、各RSの最小公倍数としては英文字2桁、数字3桁が最大値で、それ以上は外字としないと横転表示されてしまうRSが出てしまいます。このため、3桁以上の英文字／4桁以上の数字の縦中横組版の再現のために外字としているケースがあります。

　通常例えば数字なら3桁あればほとんど組版の問題はなく、4桁の縦中横は相当なレアケースではありますが、Adobe-Japan1-6には等幅4分字形のグリフが収録されていたりもしますので、まったくのゼロではありません。そういったケースでは外字画像を利用することになります。

　将来的にRSが3桁以上の英文字／4桁以上の数字の縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❽ 化学式のようなものを縦中横で挿入するための外字化

　化学式のように上付き／下付き文字を含むものを縦中横で挿入するために外字画像としているケースがあります。「H₂O」のように3桁以上になるケースも多くあるため、複合的な要因で外字化せざるを得ません。

　将来的にRSがこういったものの縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❾ 一部記号類の正立／横転指定にRSが対応していないための回避措置としての外字化

　一部記号類の正立／横転指定にRSが対応していないために縦書き時に外字にせざるを得ないケースがあります。一例としてはKindleでの時計数字（Ⅰ、Ⅱ、Ⅲ・・・）の挙動があります。Kindleでは時計数字は必ず縦書きで正立する文字として扱われ、明示的に横転の指定（text-orientation: sideways）を行っても正立してしまいます。このため、例えば欧文との混植を行って欧文内に時計数字を含めるようなケースでは、横転させて表示するために外字とせざるを得ません。こういった文字は時計数字以外にも複数あります。（参考：KADOKAWA-EPUB PORTALでダウンロードできる資料内の「20150123-文字の向き確認用【全頁版】.pdf」）

　EPUB／Webにおける縦書き時の文字の向きの挙動のデフォルト値については、UTR #50で一応の標準化がされ決着がついているのですが、まだRSレベルでの差異はあり、また（過去のドキュメントとの互換性を考えれば簡単に変えられないのは当然ですが）InDesignやWordのデフォルト値とUTR #50の間にも差があります（参考）。このため、当分ある程度RSの挙動に差異が残るのは仕方ない部分はあると考えています。

　ただ、デフォルト値はともかく明示的に横転を指定しても正立してしまう挙動はちょっと困ります。Kindleは他の記号類を見る限りtext-orientationの指定自体には対応しているので、一部の文字のみ指定が効かない挙動を早く修正して欲しいところです。

❿ Kindleが縦書き時に一部文字の字形を誤って置換表示してしまうため回避措置としての外字化

　Kindleで縦書き時にダブルクォート（「“」U+201C 「”」U+201D）をダブルミニュート（ノノカギ／「〝」U+301D 「〟」U+301F）に強制置換して表示する挙動があるため、回避措置として外字としているケースがあります。行頭字下げなどの挙動を見る限りでは、どうやら字形のみを置き換えて表示しているようです。

　縦書きでダブルクォートの代わりにダブルミニュートを用いるというのは組版のルールとしては間違っていませんが、あくまで制作者が判断して行うべき措置で、RSが勝手に強制置換をしてしまうのは困ります。例えば縦書きの文中に欧文をダブルクォートで包んで表示したいようなケースでは、ダブルクォートは欧文の一部なので横転したダブルクォートとして表示させたいのですが、Kindleはこれも強制的にダブルミニュートにしてしまいます。このため、外字画像にせざるを得なくなります。

　なお、二重引用符には他にU+0022の「"」があり、こちらは問題なく表示できます。外字とせずこちらを使用しているケースもあるでしょう。

⓫ 一部記号を分離禁止で表示させるための外字化

　二倍ダーシ（U+2014「—」／U+2015「―」／U+2500「─」）や連続する三点リーダー（U+2026「…」）などを改行による分離を禁止して表示させるために、あえて外字画像としているケースがあります。個人的にはこれはやや神経質すぎだと思っていますが、二倍ダーシなどについてはもともと活版印刷の時代には通常のダーシとは違う約物として存在していたなどという話もあるようですので、そういった影響がずっと尾を引いているのかも知れません。

　このほか、古い文献で多く見られる繰り返し記号にも2つの文字を組み合わせて用いる前提のものがあり（U+3033「〳」+ U+3035「〵」／U+3034「〴」+ U+3035「〵」）、これを確実に分離させずに表示させるために画像とするケースがあるようです。
　現状多くの出版社は一般的にはそこまで厳密な記号類の分離禁止を求めていないと思われますが、学術書などで厳密な組版の再現を求められるケースでは外字にせざるを得ないという判断はあり得るでしょう。

　これらはいずれCSSでの特定の文字の分離禁止指定がほぼ全てのRSで効くようになればテキストで表現できるものと思います。

⓬ 合字の組版再現のための外字化

　現状、多くのRSではまだ、DTPアプリ内では合字（リガチャ）として表示できるものが分離して表示されてしまう挙動が見られます。このため、組版再現のために外字とせざるを得ないケースがあります。

　具体的には通常濁点や半濁点を付けないカナ文字にU+309Bの合成用濁点やU+309Cの合成用半濁点を付けて特殊な表現を行うケース（例：「あ゛あ゛あ゛あ゛あ゛」）や、英語以外の欧文でアクセント組み合わせ済みのグリフを持たない文字へアクセント類を付加したいケースが考えられます。

　これらのケースはいずれほぼ全てのRSで合字の組版再現が可能になってくればテキストで表現できるものと思います。

⓭ 数式組版の再現のための外字化

　現状、多くのRSではまだ、MathMLによる数式の表示再現はできていません。また、MathJaxなどもJavaScriptを使用できないRSが多数ありますので使用できません。このため、数式の組版を再現するために外字もしくは画像として挿入しているケースがあります。

　いずれほぼ全てのRSがMathML等に対応すればテキストで表現できるようになっていくものと思われます。

⓮ 日本語での斜体を再現するための外字化

　EPUBでは文字に対して「font-style:italic」を指定することでイタリック体として表示されますが、日本語の部分に対する指定は斜体になるRSとならないRSがあります。

　日本語にはイタリック体はないからこれが正しいという意見もあるようなのですが、斜体自体は写植の時代からあった機能であり、DTPでもこれを引き継いで実際の印刷物の中で使われている以上、場合によってはどうしても再現しなければならないケースは出てきます。このため、外字もしくはブロックごと画像としています。

　いずれほぼ全てのRSが日本語の斜体指定に対応すればテキストで表現できるようになっていくものと思われます。

⓯ 特定のフォントデザインを保持するための外字化

　特定のフォントのデザインをEPUB内で保持するために、外字もしくはブロックごと画像とするケースがあります。これはどちらかと言えば見出しなどをブロックごと画像とするケースの方が多いでしょう。

　現状、日本語のEPUBではゴシック体と明朝体のそれぞれ平体と太字、合計4種類の書体バリエーションしか使えません。モリサワパスポートのようなサブスクリプション契約をもとに多種多様なフォントを自由に使って表現できるDTPの世界とは雲泥の差があります。フォント埋め込みで対処できればよいのですが、現状まだフォント埋め込みに対応していないRSが存在し、また商用フォントのEPUBでの使用ライセンスに目処が立っていません。このため、外字とせざるを得ないケースが出てきます。

　いずれほぼ全てのRSがフォント埋め込みに対応し、商用フォントのライセンスに目処が立ってDTPに近い形で自由にフォントを使えるようになればテキストで表現できるようになっていくものと思われます。

⓰ アイコンなどもともと文字でないものをインライン表示させるための外字化

　その他、もともと文字ではないアイコン類をインラインで表示させるために技術的手段として外字としているケースがあります。これは実用書などでは多々あります。これらはDTPのデータ内でも画像として挿入されていたケースが大半ですので、将来的にも外字として残るものと思います。こういった類のものは「もともと文字ではない」ので仕方がないものと思われます。