‘フォント’ タグのついている投稿

EPUBのフォント埋め込みのライセンスについて

2015/05/12

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

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

 和文フォントを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)

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

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

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

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

(2015.5.12)

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

(2015.5.12追記)

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

(2015.5.13追記)

「フォントを含む画像」の変換テスト

2012/05/29

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

IIllustratorでなくPhotoshopで開いてみる

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

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

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

クライアントマシンに使用されているフォントがインストールされていないデータをIllustratorで開きますと、当然ですがフォント不足のアラートが表示され、文字が基本字形で表示されてしまいます。ところが、同じデータをPhotoshopで開いた場合、内部の字形が文字化けせずに表示できたりします。

他のアプリケーション用にフォントを埋め込む

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

これはIllustrataorでデータを保存する際に「他のアプリケーション用にフォントを埋め込む」チェックボックスをオンにしていた場合に、データにフォントデータが埋め込まれているために起きます。この埋め込まれたフォントデータを利用できれば、システムにフォントがインストールされていなくてもスキャンはしないで済みそうです。もちろん保存の際にフォントの埋め込みがされていなければどうにもなりませんが、スキャニング・色調整をしなければならないデータの数を減らせるだけでもそれなりに楽になります。

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で開く

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

3 解像度を調整する

解像度を変更する

解像度を変更する

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

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

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

画像を書き出す

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

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

(2012.5.29)

プロフィール
Jun Tajima

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

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