‘電子書籍’ タグのついている投稿

VR/ARでの読書について思うこと

2020/11/13

 先日、メディアドゥからVR/AR用の電子書籍ビューア開発開始というニュースリリースの発表がありました。また、Facebookはスタンドアロンで動作する普及版VRビューア、Oculus Questの後継機に当たるOculus Quest 2を販売開始し、これがいよいよ家電量販店で売られるなどという話も出ています。そろそろ本格的にVR/AR普及が見えてきた感がありますので、ちょっとVR/ARでの読書について期待するところを書いてみたいと思います。

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

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

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

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

 ただし、例えばもとの本が大判のものであった場合などには必然的にそれに収録されている図版のサイズもそれに合わせたサイズになりますし、その図版を画面の小さなスマートフォンで眺めることが快適な読書体験かと言われれば当然そこには疑問符が付きます。読めはすることと快適に読めることはイコールではないのです。これは、リフローでの電子化を仕事としてやっていると強く実感します。
 さらに、テキストリフロー化はその過程で多くの情報を強制的に削ぎ落とす行為です。例えば実用書などでは見開きの片方のページに大きく図を表示し、もう片方のページに解説文を載せるといったレイアウトのものがありますが、これはテキストリフローでは再現できません。このため、図版の挿入位置を工夫し、テキストの文言を調整するといった作業を行いますが、当然限界はあります。

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

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

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

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

 さらに、VRでは例えば今PC上でウィンドウを複数出しているように、仮想画面を複数並べて「読書」することも可能になるはずです。このメリットがピンとこない方は、今自分たちが(エンタメではない)本を読むときにいくつの「画面」を並行して見ているのかを考えてみればよいかと思います。

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

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

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

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

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

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

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

 今、GoogleはGoogle Glassプロダクトを継続的に進めていますし、スマートフォンでGoogle翻訳のアプリを起動すれば対象のテキストを写すだけでリアルタイムに翻訳文がスマホ画面の中で見られたりもします。また、Google ブックスの展開を見れば理解できるように、彼らは本の世界へのコミットにも熱心です。
 もちろん超えなければならない技術的な壁はまだいくつもあるでしょうが、もう想像できないほど先の話ではないように思います。5年後、10年後にはARメガネをかけながら読書している人はちらほら見かけるようになるのではないでしょうか。期待をこめてそういう世界の到来を待ちたいと思っています。

(2020.11.13)

日本語表現(組版)での文字の問題について簡単なまとめ

2020/08/24

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

「全角ダーシ」の問題

 主に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からテキスト化するとグリフが変わってしまう

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では縦組みでのダブルクォートはダブルミニュートとして表示される

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/三点リーダー)

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

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

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

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

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

(2020.8.24)

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

(2020.8.25)

先頭文字/行/正規表現スタイルの処理を考える

2012/07/09

正規表現スタイル

正規表現スタイル

 InDesignには、「段落スタイル」設定内の「ドロップキャップと先頭文字スタイル」から設定できる「先頭文字スタイル」および「行スタイル」、同じく「段落スタイル」設定内で使用できる「正規表現スタイル」といった便利な機能があります。これらは全て、段落スタイルの適用されている行内の文字のうち、設定した特定の条件に適合する文字に自動的に指定した文字スタイルを適用する機能です。例えば「先頭文字スタイル」であれば、文中の数字だけを自動的に斜体にする、「行スタイル」であれば1行目だけを太字にするといったような、通常長時間の反復処理が必要になる作業を段落スタイルの設定のみで処理できます。「正規表現スタイル」はさらに自由度が高く、正規表現を用いて適合する文字列を指定できます。例えば「A」「B」「C」だけを太字にする、いったような処理も簡単に行うことができます。ここでは正規表現そのものについては触れませんのでこちらをご参照ください。
 これら特殊スタイルはInDesign内では「段落スタイル」のみが適用されており、文字スタイルは「なし」になっているように見えるため、電子書籍制作時にきちんとした処理がされるのかどうかちょっと気になるところです。

 そこで、実際の電子書籍制作時の流れの中で、これら特殊スタイル類がどのように処理されるのか試してみました。

「スタイルをタグにマップ」で正常にタグが付加されないパターンがある

行スタイルのタグに問題が出る

行スタイルのタグに問題が出る

 最初に、私がこちらのブログ内で紹介しているあらかじめ各文字に段落スタイル・文字スタイルを適用しておき、「タグ」パレットの「スタイルをタグにマップ」でタグを付加してXML書き出しを行う方法をテストしました。

 まずはシンプルに「先頭文字スタイル」「行スタイル」「正規表現スタイル」を単体で適用してみます。「先頭文字スタイル」および「正規表現スタイル」についてはきちんとタグが付加されているようですが、「行スタイル」に関しては、最後の一文字に正常なタグ付加がされていないようです。

重ねがけで正常にタグが付加されない

重ねがけで正常にタグが付加されない

 次にこれら特殊スタイル類の重ねがけを試してみます。「行スタイル」を含んだ段落のタグが全て1文字ずつずれて適用されている他、「先頭文字スタイル」と「正規表現スタイル」との重ねがけに関しても、「先頭文字スタイル」のみがタグ付加され、「正規表現スタイル」の部分にはタグが付加されていません。これではちょっと危なくてタグの自動付加はできません
 なお、「行スタイル」の最後の1文字にタグが付加されないのは、バグの類ではないかと思われます。

IDMLには文字スタイルが書き出されない

XMDFビルダーに文字スタイルが取り込まれない

文字スタイルが取り込まれない

 次にIDML(InDesign Markup Language)形式でデータを書き出し、XMDFビルダーに取り込んでみます。これは緊デジのXMDF制作ガイドラインで想定されている制作方法です。

 どうやら、特殊文字スタイル類は完全に無視され、段落スタイルのみが取り込まれるようです。つまり、XMDFビルダー内で全ての文字スタイルを再割り当てすることになってしまいます。これはちょっと作業量的に避けたい流れです。

文字カラーを変更し、検索置換パレットを使用して文字スタイルを再適用する

 さて、結局どちらにしても文字スタイルの再適用は避けられそうにありませんので、出来るだけ楽をしてスタイル再適用の作業を行いたいところです。とりあえず以下のようなワークフローを考案してみました。なお、このワークフローを使用したことに伴うトラブルに関して、私として一切の責任は負いかねますので、こちらの作業を行う前には必ず元データをバックアップしておき、コピーしたデータで作業を行うことをおすすめします。

1 文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

 まず、先頭文字/先頭行/正規表現スタイル内で使用されている文字スタイルの「文字カラー」を変更します。多色刷りなどのデータの場合には、登録済みのスウォッチカラーがドキュメント内のいずれかの箇所に使われている可能性を考慮し、トラブルを避けるためにもスウォッチを新規作成して割り当てることをおすすめします。

2 先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭文字/正規表現スタイルを手動処理

 先頭行スタイルと先頭文字/正規表現スタイルが混在している場合は、まず先頭行スタイル内の先頭文字/正規表現スタイルに手動で通常の文字スタイルを再適用します。これは、3の検索置換処理で先頭行スタイル内の先頭文字/正規表現スタイルが検索にヒットしないためです。

3 パラメータを設定し、検索置換を実行

検索置換パラメータを設定

検索置換パラメータを設定

 検索置換パレットの「検索形式」に1で設定したカラーを、「置換形式」に1で文字カラーを変更した文字スタイルをそれぞれ指定し、ドキュメント全体に対して置換を実行します。全ての文字スタイルに関して同様の置換を実行します。

 これでとりあえず文字スタイルの再適用はできます。「行スタイル」内の先頭文字/正規表現スタイルを手動処理しなければならない問題はありますが、幸い「行スタイル」はそれほど頻繁に使用されているわけではないように思えますので、実作業的にそこまでの問題はないかと思います。
 また、「タグ」パレットの「スタイルをタグにマップ」でタグを付加する際のトラブルを防ぐため、文字スタイルの再適用を行った後に「スタイルをタグにマップ」を使用する場合には、全ての特殊スタイル類をあらかじめ削除しておいた方が良いでしょう。

 なお、「正規表現スタイル」の通常文字スタイルへの置換に関しましては、市川せうぞーさんが「正規表現スタイル由来の文字スタイルをリアル文字スタイルとして適用する」というエントリーで自動処理スクリプトを発表されておられますので、そちらを利用されるのも良いかと思います。

(2012.7.9)

市川せうぞーさんより、「正規表現スタイル」2つ以上を重ねがけしている場合でも「スタイルをタグにマップ」で正常にタグが付加されないとの情報をいただきました。例え「正規表現スタイル」だけしか使われていない場合でも、文字スタイルの再適用が必須になると考えておいた方がよさそうです。

(2012.7.9追記)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。