VRによるデバイス画面サイズの制約からの解放

　今、私たちは電子書籍を例えばスマートフォンで、あるいは専用機やタブレットで、もしくはPCの画面で読んでいます。これらの「画面」は、いずれも物理的な実サイズを持っていて、必然的に表示できる文字やイラストの大きさにはデバイスの物理サイズによる制限がかかります。これを緩和するために行っている作業が「テキストリフロー化」で、そうすることで紙の本からの電子化であってもスマートフォンの小さな画面でもとりあえず読めるようにはなります。

リフロー型電子書籍では紙の版面情報の再現は難しい

　VRによってデバイスサイズによる縛りがなくなり、任意のサイズの仮想的な画面を展開できるようになればそのあたりの悩みは一気に解消されるはずです。なにしろ仮想画面なので、例えば「新聞の見開きサイズの画面を展開する」といったことも可能になるわけです。これはとてつもなく大きな進化です。

仮想画面はいくつ出してもよい

複数の「画面」を並べて行うPCでの読書

　まず、読書対象の本そのものの版面。用語がわからなければそれを調べるために辞書を引くこともあるでしょうからそれも「画面」の一つ。ネットを使って検索して調べることもあるでしょうし、文章中で他の本を引用している箇所があれば、その本を持ってきて該当箇所を調べるようなこともやるでしょう。内容を書き留めるための手元のノートも「画面」と見ることができそうです。
　さらには読書対象の本の中に注が設定されていれば、それと本文を相互参照しながら読むこともしますので、これもそれぞれ別の「画面」と見ることができるでしょう。つまり「読書」というのはそういう多くの「画面」を随時参照しながら行う行為なのだと思います。

　そう考えると、今電子版で売れているのが圧倒的にコミックスやライトノベルのような軽いエンタメで、カタい本が売れにくい状況になっているのも理解できます。コミックスやライトノベルを読むなら「画面」はひとつで済みますが、カタい本を読むにはひとつでは足りないのです。VR技術によって、物理的に多くの面積を専有することなしに多数の「画面」を並べて本を読めるようになれば、それはかなり幸せな読書体験になるのではないかなと思います。

必ずしも全てが仮想画面でなくてもよい

　さて、そうは言っても「やはり紙の本がいい」という方はたくさんいるのではないかと思います。でも例えば、紙の本を読みながら辞書や参考文献などを仮想画面として適宜呼び出せるとしたらどうでしょうか。単に別画面を見せるだけなら「スマホを横に置いておけばいいじゃん」という意見が出そうですが、おそらくGoogleやAppleあたりはそれだけでは済ませない世界を構想しているように思えます。紙の本を読みながら、わからない用語があったときにタッチペン的なものでなぞれば視界内に辞書の用語解説ページが仮想画面としてポップアップしてきて参照できる、そんな世界が来るように思うのです。

　そういった現実世界のものに電子情報をオーバーライドして見せる技術は「AR（Augmented Reality／拡張現実）」と言い、こちらは現在GoogleやAppleが熱心に研究を進めている分野です。今はまだ視界全てを置き換えるVRとは別物として開発されていますが、VR機器の前面のカメラで周囲の映像を取り込んで内部ディスプレイに投影すればAR的な表示ができますので、本質的に地続きの話です。なのでMicrosoftなどはMR（Mixed Reality）という用語を使っていたりもします。

Google翻訳ではスマホをかざすだけで翻訳文が表示される

「全角ダーシ」の問題

　主に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は中央に来るようですが、電子化に際して書き出すと自動で横棒にならず、縦棒のまま残ってしまうため別の文字に置換する必要があります。

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

（参考：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の置換でかなりの場合カバーできるかと思います。

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

絵文字の異体字表示文字の混入問題

　現在、Web等で絵文字が日常的に使われるようになってきており、それに伴って絵文字の異体字表示文字がDTPの元データや電子書籍のテキストに混入し、意図しない表示結果を引き起こすケースがあるようです。符号位置としてはU+FE00〜U+FE0Fがそれに当たります。

時計数字や丸数字などかつての機種依存文字対応の残滓

　現在、時計数字や丸数字などはその多くがUnicodeに独自のコードポイントが与えられており、テキストとして扱えるようになっていますが、かつて機種依存文字として扱われた経緯があるため、現在でも例えば時計数字の「Ⅳ」をアルファベットの組み合わせの「IV」で入力する等の対応をしているケースがあります。少なくともDTPデータや電子書籍では、アクセシビリティへの正しい対応のために本来のUnicodeの文字を使うべきと思います^※4。また、丸数字の外字での対応等も極力控えた方がよいと考えています。

その他問題がありそうな文字

　一部の文字が電子化の際に縦組みで左右中央に来ないため、別の文字に置換したり、場合によっては外字化しているケースがあるようです。確認できている文字は以下の通りです。こういったものはフォントのグリフに依存するため、まだ同種のものがあるかもしれません。
　「•」（U+2022/BULLET）
　「…」（U+2026/三点リーダー）