引き合わせ校正を目的とした場合に最適なEPUBビューアの条件

　ということで、紙の底本との引き合わせ校正を目的とした場合のEPUB閲覧環境の条件を考えてみます。条件としては

　といったところかなと思います。1行文字数をできるだけ底本のそれに合わせたいというのは、できるだけ底本と版面を同じ状態に持っていくことで間違いを発見しやすくなりますので、経験上これは必須です。

　また、一人でチェックして修正するだけならその場ですぐ修正すればよいので必ずしもハイライト機能は要りませんが、組織で仕事をしている際に他の人に校正を頼むとなると、当然「要修正箇所を他の人に伝達する」機能が必要になってきます。

　ページネーションに関しては1にも絡むのですが、DTPの元データで「見出しの前に改行が入っていたり入っていなかったりバラバラ」というのは良く見るパターンですので、カラ改行が挿入されているかいないかをチェックするためにはスクロール型ビューアもしくはスクロールモードを持つビューアが良いです。

　という感じで条件を考えてみますと、現状ではどうもiOS版のiBooksがこれに近いかなと思っています。タブレットで動くビューアでサイドロード（外部EPUB読み込み）ができて、スクロールモードを持つのはiBooksくらいですので、現状これがよいかなと。

　ただ、iBooksは文字のサイズをそう細かく制御できないので、その意味ではKinoppyも悪くないです。こちらは細かく文字のサイズ調整が効きますので、底本の版面に1行文字数を合わせるのがかなりラクです。現状EPUBビューアではこのあたりを使い分ける感じかなと思います。

　iPadの画面上でEPUBの文字列にハイライトを入れるのは指では結構ツラいものがありますが、質のよいタッチペンを使ってちょっとコツを摑めばそうストレスはない感じです。結局この場合必要なのは修正が必要な箇所にちょっとハイライトチェックを入れる程度の話で、細かい指示が必要ならメモも記入できますので、社内での校正ならこれでなんとか行けそう。Apple Pencilなど質の良いタッチペンの新製品も出てきていますし、いろいろと試したいところです。

　iBooksにはハイライトを付けた部分を一覧表示して、タップすれば該当箇所に飛べる機能もありますので、このあたりは紙での校正より確実に便利でもあります。

外部で校正してもらうにはPDF化が必要

　さて、社内の内部校正目的なら上記の方法でiPadでハイライトをつけて、iPadごと作業者に渡せばどうにかなりますが、出版社など社外に出したデータを校正してもらう時に同じ手は残念ながら使えません（iPad本体はいくらなんでも送れません）。
　このため、私が勤めている会社では現状Mac版iBooksをスクリプト処理で全ページめくってスクリーンショットを取ってPDF化し、これをEPUBと一緒に送って見てもらうようにしています。
　現状プリントができるEPUBビューアは少ないため、致し方ないところですが、全ページ画像化してPDFにする話になりますので、PDFのファイルサイズが巨大になってしまうのと、作成に結構時間がかかるのが悩みどころです。

Vivliostyle Formatterを試してみた

　このため、何かないかなと探していたところ、Vivliostyleさんが現在ベータ版公開中のVivliostyle FormatterでEPUBからPDFへの変換をサポートしたということのようなので、ちょっと試してみました。

　説明にあるように、ターミナルで

　と入力するとPDFを出力してくれます。

　現状ページの境にルビがかかった際にレンダリングが乱れること、ページ数が多い際に版面が段々下がってしまい、やがて次ページにはみ出してしまうなどの不具合があるようですが（縦組みのみか？）、出力時間が短く、ファイルサイズが小さくて済むのはなかなかの利点です。まあベータ版ですし多少は致し方ないところ。製品版での修正に期待します。

　今すぐ全てを代替というわけにはいきそうにありませんが、ルビのないものなど、コンテンツによっては現状でも結構便利に使えるのではないでしょうか。外部スタイルシートが読み込めるのもマルです。一時的に特定のプロパティの色を変えて確認などというマネができます。

　あとは1行文字数をできるだけ底本のそれに合わせるために画面で確認してからPDF出力したいところですが、まあこれは今後いろいろ試してみたいと思います。外部読み込みスタイルシートにいろいろ仕込んだり、Vivliostyle.jsと連携すればできるかも。

　あらかじめVivliostyle FormatterをApplicationフォルダなど任意のフォルダにコピーしてインストールし、.bash_profileにVivliostyle Formatterのフォルダへのパスを設定しておく必要がありますが、なかなか便利に使えます。

　なお、最近使いはじめているXojoの練習を兼ねてMac用のVivliostyle Formatterフロントエンドを作ってみました。Vivliostyleの村上真雄さんのご許可をいただきましたので公開しておきます。

ダウンロードはこちら↓

vivliostyleFormatter_EPUB2PDFOutput.zip

1 file(s) 9.62 MB

Download

　.bash_profileの追記はこちらなどを参考に。難しければこちらのアプリなどを使って不可視ファイルを一時的に見えるようにし、ユーザーのホームフォルダにある.bash_profileをテキストエディタで開いて

「export PATH=/Applications/vivliostyle-formatter-0.1.4-mac/vivliostyle:$PATH」

などと追記すれば大丈夫です（.bash_profileが見当たらなければ作りましょう）。

300〜400dpiが一般的な「印刷物に用いる画像の解像度」

写真などの画像（ビットマップ／ラスター画像）をオフセット印刷に用いる場合、スクリーン線数の1.5〜2倍というのが一般的で、スクリーン線数は133〜200線が広く普及しています。このため、適正な画像の解像度は300〜400dpiあれば十分だと言われてきました。もちろんこれ以上の解像度の画像を用いても良いのですが、データサイズが大きくなるなどのデメリットもあるため、現実的な運用として400dpi程度を基準としてきた会社が多かったのではないかと思います。また、長きにわたって「Webなどで使う画像はそこまで解像度は高くなくてよいから、印刷データ用の画像の流用で間に合う」というのが常識として定着していました。ですが、相次ぐデバイスの高画素化で差はどんどん埋まり、どうやら今回の発表でついに常識が覆ってしまったのではないかと思われます。

画像のピクセル数よりもデバイスの画面ピクセル数が大きいとどうなるのか

試みに、文庫判（148×105mm）サイズ、縦300dpiで作られた1ページ大の画像を考えてみます。この判型だとピクセル数は縦1748ピクセル、横1240ピクセルになるようです。iPad Proのパネルのピクセル数をかなり下回ることがわかります。
このサイズで作った画像を通常のリフローの画像挿入方法でEPUB内に挿入しますと、普通に考えればビューアでピクセル数が不足するために画像は画面の上部中央に表示され、左右および下部にアキが出てしまうはずです。つまり1ページ全画面配置のレイアウトが保てなくなるのです。

1ページ大の画像配置は固定レイアウト指定による強制引き伸ばしを

これを防ぐために、一部ページをSVGを用いた固定レイアウトで表示させる（フィックスドハイブリッド）方法^※1を用いることが出来ます。KADOKAWAさんなどが取っている手法^※2ですが、この手法を取れば、とりあえずカバーの書影などどうしても1ページ全画面配置で表示したいページを強制的に引き伸ばして表示させることが可能なはずです。
ただ、これはあくまで「強制引き伸ばし」ですから、画像が引き伸ばされて甘くなるのは避けられませんし、挿入画像など文中に挟み込む形で入る画像にはこの手は使えません。

各ビューアの実際の挙動

この「固定レイアウト指定による強制画像引き伸ばし」を実際にどこまでのビューアがサポートしているのかちょっと調べてみました。結果は以下の通りです。

https://docs.google.com/spreadsheets/d/1eGIkZVb7RWg-8DkMNPLS1fXH4ozGJMP1qmc2hKhnGdM/pubhtml

どうやら通常のリフロー形式で画素数不足の画像を挿入しても、強制的に引き延ばして表示するRSが相当数あるようで、例えばKinoppyのiOS版およびMac版、KoboのiOS版および専用端末版は強制的に引き延ばして表示するようです。Kindleは「カバー画像のみ」必ず引き延ばします。いずれにせよ挙動が各社バラバラで、「固定レイアウト指定をしないとビューアによってはアキが出てしまう可能性がある」くらいに考えておいた方がよさそうです。

高解像度化は今後どこまで行くのか

では、デバイスの高解像度化は実際どこまで行きそうなのか。中短期的にはおそらく4K（3840×2160px）までは行きそうかなと思っています（8Kはちょっとまだ待って欲しい）。仮にこのピクセル数に対応させるために印刷用画像の解像度を定めるとしますと、文庫判で659dpiの解像度が必要になる計算になります。これはかなりの高解像度化であり、ファイルサイズの大幅な増加が予想されます。

和文フォントのライセンス

　和文フォントをEPUBに埋め込む場合、一応技術的にはまるごと埋め込んで表示させること自体は可能なのですが、印刷用フォントと同じものをそのまま埋め込むことにフォントメーカーが首を縦に振るとは思えません。まだフォントメーカーのフォント埋め込みに関する統一見解は出ていませんが、現状見えている限りでは少なくとも「サブセット化」と「難読化」は必要になりそうです。「サブセット化」というのは、EPUB内で実際に用いられている文字のグリフだけを抽出した元のフォントの「サブセット」を作ること、「難読化」は容易にフォントデータの抜き出しが出来ないような処理を行うことで、これはどちらも例えばWebフォント用の技術としては確立されているようです。InDesignからEPUB書き出しを行った場合にも、双方の処置を行ったフォントが埋め込まれます。
　ただし、フォントメーカーとしての統一見解が出ていない以上、現状でフォントを埋め込みたい場合は各フォントメーカーの個別許諾が必要になるでしょう。
　例外としてAdobeとGoogleが共同開発した日本語フォント「源ノ角ゴシック」は、SIL Open Font License 1.1の規約に沿ってオープンソースで公開されていますので、フルセットでの埋め込み使用が可能です。

欧文フォントのライセンス

　一般的に認知度の高い「Helvetica」や「Futura」などといったフォントを使用するには、やはり日本語フォント同様に個別許諾が必要になるものと思われます。OSに含まれているからといって、それをEPUBに埋め込んで配布するのは明白なライセンス規約違反なので注意が必要です。
　また、いわゆる「フリーフォント」に関しても、EPUBに埋め込んで使用する場合には「ソフトウェアのバンドル」に相当するため、相応の注意は必要そうです。以下、私のわかる限りにおいて一般的なフリーソフトウェアのライセンス形態について書いておきます。

OFLライセンス（SIL Open Font License）

　自由に利用できるが、電書への埋め込みに関してはライセンス表記をコンテンツ内に含める必要はあるかも。

GPLライセンス（GNU General Public License）

　誰でも自由に複製・改変・頒布することが許可されている。ただし、制作物もGPLライセンスで配布しなければならない。利用した制作物全てに関してのソースコード公開が必要になるため、実質商用の電子書籍への埋め込みでは利用できない。
　ただし例外として、Font Exceptionの文面が付記されている場合には成果物をGPLの規約に従って公開する必要はなくなるため、使うことができる。

LGPLライセンス（GNU Lesser General Public License）

　GPLとほぼ同じだが、利用部分のソースコード公開のみでよい。ただ、商用の電子書籍は通常DRMがかかった状態で配布されるため、やはり利用できないと考えた方がよさそう。
　ただし例外として、Font Exceptionの文面が付記されている場合には成果物をGPLの規約に従って公開する必要はなくなるため、使うことができる。

修正BSDライセンス（New Berkeley Software Distribution）

　3条項BSDライセンスとも呼ばれる。自由に利用できるが、電書への埋め込みに関してはライセンス表記をコンテンツ内に含める必要はあるかも。BSDライセンスについては他に宣伝条項の記載を義務づける4条項BSDライセンスと簡易BSDライセンスとも呼ばれる2条項BSDライセンスがある。

MIT License

　2条項BSDライセンスとほぼ同じと考えてよさそう。

LPPL（LaTeX Project Public License）

　自由に利用できるが、電書への埋め込みに関してはライセンス表記をコンテンツ内に含める必要はあるかも。

Apache License 2.0

　ユーザーがそのソフトウェアにApache Licenseのコードが使われていることを知らせる文言を入れる必要がある。

IPAフォントライセンス

　独立行政法人情報処理推進機構 (IPA) によって配布されているIPAフォントで使われているライセンス。FAQにフォントの再配布について「入手時に添付されている「IPAフォントライセンスv1.0」の写しを再配布するIPAフォントに添付しなければなりません。」とある。かなり長文になるため書籍の種類によっては躊躇してしまうが、とはいえこの条件を満たせば埋め込み利用自体は問題なさそう。
　IPAフォントには一般的な商用フォントに含まれていないグリフも収録されているため、異体字等を多く利用するようなコンテンツではニーズはあるように思われる。しかし現状ユーザ側でフォントを切り替えた場合に埋め込みフォントの字形が保持されないビューアが多くあるため、ビューアを選びそうなのは悩ましいところ。

PD（Public Domain）

　著作権を放棄しているものなので自由に利用できる。クレジット表記も不要。

CC（Creative Commons）

　フォントで使われることはあまりなさそうだが一応。基本的に権利者に許諾を得ずに使用できる条件がどこまでなのかを著作者が事前に決めておくためのもの。著作者のクレジット表記は必要そう。また、条件を超えた利用には個別許諾が必要。

　以上です。特に注意が必要そうなのはGPLとLGPLで、このライセンスで配布されているフォントに関しては、基本的に商用の電子書籍では使用できないと考えた方が良さそうです。GPL規約に関しては（フォントでのケースでも電子書籍でのケースでもありませんが）、ソニー・コンピュータエンタテインメントが発売していたPS2のゲームソフト「ICO」のGPL規約違反発覚を原因とした生産終了、廃盤などの例もありますので、十分な注意は必要そうです。
　また、複数のライセンス規約で配布される「ダブルライセンス」という形態もあるようで、こちらなどはそれに当たります。OFLとGPLのダブルライセンスで配布されており、この場合はどちらかのライセンス条件を満たしていれば問題ないようです。