文字の規格に関して改訂の議論が始まっているので、現在技術的な問題を残していそうな文字のリストを出して欲しいというボールを投げられましたので簡単にまとめてみました。なおどのレベルにどういう形で投げるべき問題なのかはこちらでは細かな分類はしていません。ざっくりとしたリストとして見ていただければと思います。

「全角ダーシ」の問題

　主にDTPデータからの電子化での問題です。私の把握している限りで、DTP等のデータで「ダーシ」として使われている文字は以下のものがあります。

　U+2014（EM DASH）
　U+2015（HORIZONTAL BAR）
　U+FE31（PRESENTATION FORM FOR VERTICAL EM DASH）
　U+2500（罫線素片）

　このうち、U+2014は、フォントによって縦書きで中央に来ないケースが多くあるため、DTPではこれを嫌ってU+2015を使用しているケースが多く見られるようです。
　U+FE31は中央に来るようですが、電子化に際して書き出すと自動で横棒にならず、縦棒のまま残ってしまうため別の文字に置換する必要があります。

さまざまな文字が「ダーシ」として使われている

　また、ダーシは1文字幅で使うだけではなく、2文字幅の「二倍ダーシ」として使用するケースが多く見られます。二倍ダーシとして連続入力した場合、U+2014/U+2015ともに文字間に隙間ができるデザインのフォントが多く、これを避けるために本来はダーシとして使うべきでないU+2500の罫線素片を使っているケースがあるようです。これは実質的に現状フォントの指定ができない電子書籍では通常の対応となっているのではないかと思います。
　DTPではU+2015を使い、縦200％の変倍をかけているケースが多く見られるようですが、これは電子化のためにそのままテキスト化すれば変倍の情報が飛んで1倍ダーシになります。このため置換処理が必要となります。さらにU+2015はJIS X 0213外の文字であり、厳密にJIS X 0213内での電子化対応を求める場合^※1には何らかの文字に置換しなければならないという問題もあります。

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

波ダッシュと全角チルダの問題

　Webを含めさまざまな場面で起きている問題です。過去のさまざまな経緯により以下の文字が混用されています。
　U+301C（WAVE DASH）
　U+FF5E（FULLWIDTH TILDE）

　現在多くの商用フォントではグリフで見分けがつきません。このためDTP的には問題は顕在化していませんが、U+FF5EはJIS X 0213外の文字のため、電子化では置換処理が必要になることがあります。なおこれ以外の文字混用問題も別項目で取り上げていますが、このケースはUnicodeの規格のミスなども絡んでいてだいぶ根が深いので単独で挙げておきます。参考リンク先の記述がかなり詳細ですので、この問題の概要はそちらをご覧ください。

波ダッシュと全角チルダはグリフでは見分けがつかない

（参考：https://qiita.com/kasei-san/items/3ce2249f0a1c1af1cbd2）

和文引用符の問題

　DTPデータからの電子化での問題です。U+201C/U+201Dのダブルクォートは、InDesignの機能によってダブルミニュート^※2として表示させることができます。ただし、バックグラウンドで持っている文字情報はU+201C/U+201Dのままなので、電子化に際してテキスト化するとグリフが変わってしまいます。このため置換処理が必要となります。U+301D/U+301Fのダブルミニュートをそのまま使えばこの問題はクリアできますが、これはInDesignの禁則文字に入っていない文字のため、InDesignで禁則文字のカスタマイズが必要となります。

InDesingからテキスト化するとグリフが変わってしまう

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

和文中の欧文引用符の問題

　DTPデータからの電子化での問題です。和文組版では通常、和文中の欧文であっても引用符にU+0022を使わず、U+201C/U+201Dをダブルクォートとして使うケースが多く見られます。同様に、アポストロフィとしてU+2019を使い、U+0027を使わないことも慣例となっているようです。
　これはU+0022/U+0027の字形が「間抜け引用符」などと呼ばれてデザイン的に嫌われたために起きたものですが、U+201C/U+201D/U+2019はUnicode上では全角幅／半角幅で異なるコードポイントを与えられてはいないため、テキストとして書き出した際に不自然なアキが引用符の前後に入るケースがあります。このため、電子化に際してはU+0022/U+0027に適宜置換して対応したりします。これはまた、Kindleが縦組み時にU+201C/U+201Dを強制的にU+301D/U+301Fのグリフで表示してしまうことへの対応策でもあります^※3。

Kindleでは縦組みでのダブルクォートはダブルミニュートとして表示される

グリフで見分けが付かないが使うべきでない文字の混用問題

　Webを含めさまざまな場面で起きている問題です。よく見られるのが「康熙部首」としてUnicodeに収録されている文字（U+2F00〜U+2FD5）を、通常の漢字と混用しているケースや、キリル文字の「А」「В」「С」「Е」「О」「Р」などを通常のアルファベットの文字と混用しているケースです。また、漢字の「二」とカタカナの「ニ」の混用も時々見られます。
　これらはおそらくOCRの誤認識などが混入の原因と思われますが、グリフを目視で見分けて修正することが極めて困難であるため、何らかの機械的な処理で混用を防ぐことが期待されます。康熙部首などは特殊なケース以外では使用されない文字であるため、機械的な1対1の置換でかなりの場合カバーできるかと思います。

康熙部首と通常の文字は見分けがつかない

◇

　以上になります。当然他にも問題のある文字はあるかもしれません。今なら規格側での修正の可能性もあるようですので、どんどん意見を上げましょう。

※1　電書協ガイドでは現在、使用する文字の範囲をJIS X 0213の範囲内とすることを規定している。一部のリーディングシステムが厳密にJIS X 0213内のグリフしか持たないフォントを表示フォントとして採用しているため。

※2　「ノノカギ」「チョンチョン」などと呼ばれることもある約物。

※3　Kindleのみの将来解決されうる問題であるとして許容する解釈もある。

※4　例えば音声読み上げ時に「フォー」ではなく「アイブイ」と読み上げられてしまうため、アクセシビリティ的には問題。

（2020.8.24）

　コメントでご指摘いただいた点に関して修正しました。

（2020.8.25）

　最近何度か仕事で扱う機会のあった、EPUBでのフォント埋め込みに関してちょっと書いておこうと思います。
　現状、EPUBの表示フォントは、デバイス/ビューアの持っているフォントを使わざるを得ないため、コンテンツ制作側での指定としては、明朝/ゴシックおよび並字/太字の指定が行える程度で、DTP制作のように細かな書体指定は難しい状況にあります。
　まあ紙書籍と電子書籍はそもそも異なるものですので、将来的にDTP制作と同じように細かなフォント指定ができることが望ましいかといえばそれも疑問なのですが、それでもどうしても特定のフォントで表示を行いたいケースはあります。
　例えば「見出しに特太丸ゴシック体を使いたい」ですとか、「プログラミングソース部分を等幅欧文フォントで表示したい」、「中国語の人名を簡体字の字形で表示したい」などといった場合です。
　こういった場合、フォントそのものをEPUBに埋め込み、OPF、CSSに適切な記述を行うことで埋め込んだフォントの字形で表示させることができます。これ自体はEPUBの規格に入っていますし、既に多くのビューアでは技術的な対応を完了しているのですが（表示対応ビューアの参考はこちらの3-9）、残念ながらまだライセンス規約的な問題が残っており、自由に使える状況にはなっていません。以下、簡単なまとめです。

◇

　フォントのライセンスに関しては、基本印刷を前提としたものとなっており、webフォントや電書での利用例自体がまだほとんどありません。このため、現状リスクを回避するためにはどうしても（例えフリーフォントであっても）ライセンスを全文表記するといった冗長な対応を検討せざるを得ない状況にあります。書籍の種類によってはこれはかなり悩ましい話ではあり、今後気軽に利用しやすいライセンス形態が欲しいところです。

　今回のエントリを書くに当たって、達人出版会の高橋征義さんに助言および情報提供をいただき、とても助かりました。あらためてお礼を申し上げておきたく思います。

（2015.5.12）

IPAフォントライセンスについて追記いたしました。

（2015.5.12追記）

ご指摘いただき、LaTeX Project Public Licenseの略称を修正いたしました。また、GPLライセンスのFont Exceptionに関して追記しました。

（2015.5.13追記）

　前回のエントリーでInDesignのデータ内の異体字について書かせていただきましたが、こちらは現在出版デジタル機構の深沢さんのもとでオールスターのみなさんが対策中ですので、私は予想されるもうひとつの「文字化け」の検証をしてみることにしました。「フォントを含む画像の変換」です。
　DTPデータに挿入されているデータのうち、フォントを含むデータのほとんどはIllustratorで制作されたEPS形式の画像データと思われます。Illustratorの画像内に使用されている全てのフォントがクライアントマシンにインストールされていれば特に問題はないのですが、他社の制作したデータを受け入れて電子化することを考えなければならないコンテンツ緊急電子化事業（以下緊デジ）では、受け入れ側に「フォントがない」ことが十分に想定できます。さらに印刷に使用される和文フォントは決して安くはないため、緊デジの仕事のためだけに使われている可能性のある全てのフォントを購入することは、制作会社サイドにとってかなりの負担になってしまいます。
　緊デジ事業の制作仕様書Ver1.01によりますと、「画像はできるだけDTPデータの貼込画像から取り出すが、困難な場合は底本からスキャンしてもよい」とあり、最終的な逃げ道は「底本からスキャン」という形で用意されているのですが、紙の本からのスキャニング画像は（ドラムスキャナなど）よほど上等なスキャナを用いでもしない限り取り込み時に多少なりとも色が変化してしまいます。そのため、これの修正に少なからぬ時間を要するのが実情です。こうしたレタッチ作業の手間などを考えると、制作側としても可能であれば貼込画像を流用し、作業時間の短縮をはかりたいところです。以下、どういったパターンで画像を取り出すのが最も「文字化け」に悩まされず、短い時間で電子書籍用の画像を準備できるのかの検証です。参考にしていただければ幸いです。

IIllustratorでなくPhotoshopで開いてみる

　XMDFビルダーにはIDML（InDesign Markup Language）経由でInDesignデータ内の貼り込み画像を自動インポートする機能があるのですが、緊デジの仕様書に「図表のキャプションやクレジット文字などは画像と一緒にビットマップ化する」とあることや、取り込まれる画像サイズや挿入位置のコントロールが難しいことから、この機能は使わずに画像を別に用意しておき、原本を参照して後からあらためて挿入する方向性で考えることにしました。

フォントがないと警告が表示される

フォントを埋め込むチェックボックス

InDesignからPDFを経由してPhotoshopへ

　ただ、多くの場合、画像のキャプションはデータ作成時に再校以降の修正のやりやすさを考慮し、InDesign側で挿入されていることが多いように思います。前述したように緊デジの仕様書には「図表のキャプションやクレジット文字などは画像と一緒にビットマップ化する」とありますので、可能であればInDesign内のキャプションもIllustratorの画像データと同時にデータ化したいところです。そこで、InDesignから一度PDFで画像を含むページごとデータを書き出してしまい、これをPhotoshopで開き、トリミングすることでキャプションを含めて画像化する流れを考えてみました。写真データなどフォントを含まない画像データであっても「キャプションを含めて画像化」することは必要になるため、これができれば画像作成の流れを統一することが可能になります。以下、簡単なワークフローになります。

1　InDesignからPDF X-1aで書き出す

書き出し時にフォントがなければ警告が出る

「ファイル」メニュー「PDF書き出しプリセット」から、「PDF X-1a:2001（日本）」を選択し、画像を含むページの組版データをPDFで書き出します。PDF X-1aでの書き出し時点でフォントがなければ警告が出ますので、プリフライトチェックにもなります。

2　PDFをPhotoshopで開き、必要な部分だけをトリミングする

PDFをPhotoshopで開く

書き出されたPDFをPhotoshopで開き、必要な部分だけをトリミングします。Photoshopで開く際に解像度などを入力する必要がありますが、中間作業ファイルですので解像度は高めで構わないと思います。今回は「900dpi」に設定しました。電子書籍用ですので、モードは「RGBカラー」です。トリミング後、「レイヤー」パレットメニューから「画像を統合」を選択し、背景を透明→白にしておきます。

3　解像度を調整する

解像度を変更する

緊デジ仕様書に「ビットマップ画像のサイズは、ターゲットデバイスである長辺1536ピクセル以内とする」とあるので、これに従って画像サイズを調整します（画像サイズに関しては仕様書の記述にまだあいまいさが残っており、もう少し具体化して欲しいところです。底本で版面サイズ一杯に配置された画像の場合に「長辺1536ピクセル」という理解で良いのでしょうか？）。

4　「Webおよびデバイス用に保存」で画像を書き出す

画像を書き出す

「ファイル」メニューから「Webおよびデバイス用に保存」で画像を書き出します。電子書籍用の画像ですので、普通に保存するより「Webおよびデバイス用に保存」を使って保存するほうがファイルサイズ的に有利です。緊デジ仕様書には画像形式として「JPEG／PNG」の指定がありますので、今回はPNG-24を選択して書き出したのですが、仕様書にもどういった場合にJPEGを選び、どういった場合にはPNGを選ぶべきかの簡単な記述はあった方が良いかも知れません（連続階調の写真→JPEG／単色塗りつぶしイラスト→PNGと理解していますが）。

◇

　以上、緊デジ用「フォントを含む画像の変換」の流れです。結論として、保存時にフォント埋め込みがなされたIllustratorデータであれば、クライアントマシン側に該当するフォントがインストールされていなくても画像化は可能と思われます。ただし、InDesign側でキャプションに使われているフォントの互換の問題はありますし、画像コンバートにはフォント以外の問題もありますので（特色とか・・・）もちろんこれだけで画像制作における問題点がすべて解決するものではありません。また、上記はあくまで現時点（5/29）でのテストであることも付記しておきたく思います。

（2012.5.29）