‘EPUB3’ タグのついている投稿

IDPFのバリデータに叱られてみた

2012/10/16

 「バリデータ」。DTP畑の方には言葉に聞き覚えのない方がおられるかも知れませんが、これは納品データが一定の仕様に沿っているかをチェックする整合性チェックプログラムのことです。IDPFは制作したEPUB3が仕様に沿っているかをチェックするためのバリデータを提供しており、無償で誰でも使うことができます。

 紙の印刷物の場合には、最終成果物はあくまで出力された紙であり、同じ出力結果が得られるのであればデータはどのように作ろうが自由でした。しかし、電子書籍の場合は事情が異なり、最終成果物はデータそのものであり、それはきちんとした仕様に沿って作られたものでなければなりません。特にEPUB3の場合はXMDFやドットブックよりも閲覧環境が多岐にわたるため、仕様に沿ってデータを作ることは重要です。従って、納品前に最低限「ちゃんとIDPFのバリデータを通るかどうかをチェックする」ことが必須になってくるわけです。先日発表された『電書協EPUB3制作ガイド』にも「最新版の epubcheck でエラーの出ないデータを制作すること」との記述があり、これは今後ごく当然の要求としてデータの納品時に求められてくるものと思われます。

 IDPFのバリデータは、EPUB3の容量が10MB以下であればこちらでwebサービス版を利用できますし、こちらから最新版Epubcheckをダウンロードすれば大容量のEPUBをチェックすることも可能です。ただ、こちらのツールはコマンドラインから利用するCUIのツールですので、コマンドラインツールに慣れていない方には少々敷居の高い面があることは確かです。そういった方には、Mac環境で利用できるこちらのGUIアプリケーション「EPUB Checker」をおすすめしておきます。内部的にIDPFのバリデータを利用しており、簡単なドラッグ&ドロップ操作でEPUBファイルをチェックすることができます。残念ながらWindows環境向けにはまだこれといったGUIバリデートチェックツールはなさそうで、早期の登場が望まれるところです。

 さて、今回は、実際にEPUB3を制作し、バリデートチェックをする際に私が遭遇したさまざまなエラーメッセージと、それぞれのエラーへの対処方法について書いてみます(画面はwebサービス版のものです)。正しいEPUBデータ制作の一助としていただければ幸いです。

パターン1 XHTML内「<meta>」行のエラー

XHTML内「meta」行のエラー 「File」はEPUB3パッケージ内ファイルのうち、問題のあったファイルを差しています。「Line」は問題のあった行で、「Message」はエラー内容です。正規表現を用いて書かれているので若干わかりにくいですが、この場合は、「cover.xhtml」ファイル内5行目の「<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />」のうち、「http-equiv」の属性値が不正なので修正せよと言われています。これはJBasic08の公式サンプルをそのまま使用した場合に遭遇するエラーです。
 エラー内容をそのまま適用すれば、「Default-Style」もしくは「Refresh」に修正することになりますが、最近のサンプルではこの行は「<meta charset="UTF-8" />」となっているものを多く見かけますので(電書協ガイドもこの表記)、そうした表記に変更する形で良いと思われます。また、この行そのものを記述しなくてもそう問題はないようです。

パターン2 「navigation.xhtml」内「nav.css」のリンクエラー

「navigation.xhtml」内「nav.css」のリンクエラー オーサリングツールとしてFUSEeβを使用している時に良く遭遇するエラーです。目次ファイル「navigation.xhtml」内にスタイルシート「nav.css」へのリンクが記載されているのに、実際にはファイルが存在しないことによりエラーが出ています。これはFUSEeβのデフォルト設定のため、頻繁にこのエラーに遭遇します。
 一度EPUBパッケージを解凍して「navigation.xhtml」内の「nav.css」へのリンク行を削除するか、あるいは内容は空でも構わないので「nav.css」を作成してFUSEeβで再度EPUB3ファイルを書き出せばこのエラーは消えます。

パターン3 空の「images」フォルダがある

空の「images」フォルダがある 電書協EPUB3ガイドの仕様では、画像を収納するフォルダ名は「image」です。しかしFUSEeβの標準仕様では画像フォルダ名は「images」で、FUSEeβ内で画像フォルダ名を「image」に変更することはできますが、何故か書き出し時に空の「images」も書き出され、このエラーが出ます。
 一度EPUBパッケージを解凍し、空の「images」フォルダを削除することでエラーは消えます。

パターン4 目次ファイル内に「<ol>」タグが連続で記述されている

目次ファイル内に「ol」タグが連続で記述されている 目次ファイル内に「<ol>」タグが連続で記述されているとこのエラーが出ます。FUSEeβの環境設定の「カバー・目次」の項目で、「<h1>〜<h3>タグを目次に含める」(目次に含めるタグ範囲は任意選択可能)の項目をオンにしていると、目次ファイル内に<ol>タグが連続する形でデータが書き出され、このエラーが出るようです。
 一度EPUBパッケージを解凍し、目次ファイル内の<ol>タグのうち内側のものを消すかコメントアウトすればこのエラーは消えます。

パターン5 パッケージ内にOPFファイルに記述されていない画像がある

パッケージ内にOPFファイルに記述されていない画像がある 画像フォルダ内にOPFパッケージファイルに記述されていない画像ファイルがある場合のエラーメッセージです。FUSEeβなどのツールを使用しているとOPFファイルへのファイル名の自動登録を行ってくれるため、このエラーに遭遇することはありませんが、ハンドコーディングでEPUB3を作成している場合などに、OPFパッケージファイルに画像ファイル名を記述し忘れるとこのエラーに遭遇します。適正にパッケージファイルへの記述を行えばエラーは消えます。

パターン6 パッケージ内にOPFファイルに記述されている画像がない

パッケージ内にOPFファイルに記述されている画像がない パターン5の逆で、パッケージファイルには画像ファイル名の記述があるのに実際にはファイルがない場合です。画像ファイルを入れ直す、(必要なければ)OPFファイル内の画像ファイルの記述を削除するなどの操作をすることでエラーは消えます。

パターン7 パッケージ内にファイル「.DS_Store」が存在する

パッケージ内にファイル「.DS_Store」が存在する Macがアイコンの配置などを記録している不可視の設定ファイル「.DS_Store」がフォルダ内に存在する場合のエラーです。これは不可視ファイルですので通常Macでは見えません。ただし実際には存在するためバリデート時にエラーになってしまいます。「Ds Store Remover」などのツールを使うことで除去できます。

パターン8 パッケージ内にファイル「iTunesMetadata.plist」が存在する

パッケージ内にファイル「iTunesMetadata.plist」が存在する 校正などの目的でiBooksなどのiOS内アプリにデータをコピーする際に、iTunesの同期機能を使うとパッケージ内にメタデータの管理ファイルを作成されてしまい、エラーが出ます。一度EPUBパッケージを解凍し、「iTunesMetadata.plist」ファイルを削除することでエラーは消えます。EPUB3ファイルの校正にiPad等を用いる際には、クラウドサービス「DropBox」経由でファイルを転送すると、この問題は起きませんので、そちらの方法をおすすめしておきます。

バリデータ通過画面

バリデータ通過画面

 これらのエラーを全て解消し、IDPFのバリデータをクリアすると「Congratulations!〜」と画面に表示されます。バリデータではきちんとCSSが適用されているか、XHTMLの表記が適正かといった部分まではチェックしてくれませんのでそうした校正は別立てで行う必要は当然ありますが、とりあえずはこれで最低限の「エラーを引き起こさないファイル」になったと言えるでしょう。

 なお、緊デジでEPUB3を制作する際に出てくるさまざまな問題を制作者同士の情報交換である程度解決するために、情報交換wiki「緊デジWiki」を先日公開しました。ご利用いただければ幸いです。

(2012.10.16)

「電書ちゃんねる」に、epubcheckに関する記事が掲載されたようです。「エラーメッセージ一覧日本語訳」はとても参考になるありがたい資料ですのでぜひ参照することをおすすめします。

(2013.5.23追記)

固定レイアウト/リフロー混在EPUB3を作ってみた

2012/08/21

 先日のJEPAのセミナーでもEPUB3の固定レイアウトについての話が出ていましたが、koboも発売になり、Readiumも出たことでEPUB3のリファレンス環境もほぼ整ってきた感がありますので、このあたりを参考に技術習得も兼ねてEPUB3のサンプルづくりをしてみました。
 今回はEPUB3固定レイアウト(EPUB3 Fixed Layout)にチャレンジです。とは言っても私の会社で作るようなコンテンツでは、全ページを雑誌的な固定レイアウトで制作するニーズはあまり無さそうですので、今回はカバーとタイトルおよび1ページ大の画像ページ「だけ」を固定レイアウト指定してみました。以下、おおざっぱな制作フローです。EPUB制作の参考にしていただければ幸いです。なにぶんまだ手さぐりもいいところですので、各箇所に間違った記述もあるかも知れませんがご容赦ください。と言いますかむしろツッコミお願いいたします。

1 InDesignからXMLを書き出し、XHTMLに変換

 今回のサンプルは青空文庫にもラインナップされている、宮武外骨「一円本流行の害毒と其裏面談」です。なかなかぶっとんだ内容で愉快です。詳しい内容の紹介は文末で。XHTML版もあったのですが、タグの付け直し作業が面倒そうだったのと、それを使うと練習にならないので、テキストファイル版を入手してInDesignのドキュメントに流し込み、こちらの手順でEPUB3用XHTMLデータを作成しました※1

2 FuseeβにXHTMLデータを流し込んでとりあえずパッケージ化

固定レイアウトEPUB3として書き出す

固定レイアウトEPUB3として書き出す

 作成したXHTMLデータおよび画像類をFuseeβに取り込み、EPUB3パッケージを書き出します。CSS(カスケーディングスタイルシート)等の設定は必要ですが、細かいパラメータは後から確認しながら追い込んだ方が効率が良いので、ここではとりあえずCSSのファイル登録、画像の登録、XHTMLデータ内へのCSSのリンクの登録などの形をおおざっぱに整え、パッケージとして書き出してしまいます。固定レイアウトもFuseeβからの書き出し時に指定できるのですが、これは全ページを固定レイアウトのEPUBとするための指定なので、特定ページだけを固定レイアウトにするためには後工程でソースの書き換えが必要になります。今回はひとまず、kobo用に縦800px、横600pxの全ページ固定レイアウトEPUB3ファイルとして書き出しました。

3 拡張子をEPUB→ZIPに変更してパッケージを解凍

 作成したファイルの拡張子をEPUB→ZIPに変更し、パッケージを一度解凍します。これにより、XHTMLなど各ファイルの修正、CSSの記述・修正が行えるようになります。

4 リフローページのXHTMLの修正

リフローページのviewport指定を削除

リフローページのviewport指定を削除

 OEBPS/text内にあるXHTMLファイルの中で、リフロー表示させるXHTMLファイルをテキストエディタで開き、ヘッダ部分の「<meta name="viewport"〜」の行を削除します(Fuseeが自動挿入する固定レイアウト用viewport指定です)。

5 content.opfの修正

content.opfを修正(1)

content.opfを修正(1)

 パッケージファイル「content.opf」をテキストエディタで開き、<meta propery="rendition:layout">pre-pagenated</meta>の行の「pre-pagenated」「reflowable」(ドキュメント基本特性を固定レイアウト→リフロー)に、<meta propery="rendition:orientation">auto</meta>の行の「auto」「portrait」(デバイスの向きを縦向きで指定)に修正しました。これらはFuseeが自動挿入する固定レイアウト指定プロパティですが、今回は特定ページのみ固定レイアウト指定しますので、修正しています。

content.opfを修正(2)

content.opfを修正(2)

 さらに、固定レイアウトを指定するXHTMLのspine指定に「properties=<rendition:layout〜」の部分を追記します。詳しいパラメータ等についてはこちらを参考にしました。この修正により、指定ページのみが固定レイアウトに設定されます。

6 CSSの記述・修正

 CSSの調整を行います。今回は固定レイアウト/リフロー混在のドキュメントですので、CSSファイルもそれぞれ別ファイルに分けています。CSSの設定に関しては、フリーで入手できる各種EPUBドキュメントや、公式サンプルドキュメントを参考にしました。固定レイアウトのCSS指定方法に関しては、こちらのサンプルドキュメントを参考にしています。今回、カバーページはSVGの固定レイアウト、タイトルページは固定レイアウトを用いてテキストブロックを左右中央に表示、1ページ大の画像ページは同じく固定レイアウトを用いて左右中央に画像を表示させることとしました。
 なお、CSS調整時の簡易画面確認は、XHTMLファイルをSafariChrome等のブラウザに放り込んで行っています。

7 カバーページにSVGデータをコピー&ペースト

SVGデータをコピー&ペースト

SVGデータをコピー&ペースト

 カバーページは全てSVGを用いた固定レイアウトページですので、Illustratorを用いて作成したカバー画像データをSVG形式で保存し、テキストエディタで開いて<svg>〜</svg>の部分をコピーし、カバー用のXHTMLファイルの<section>〜</section>の部分にペーストします。なお、Illustrator側でも指定ピクセル数サイズのファイルとして画像を作成しておく必要があります。
 SVGを用いた固定レイアウト指定の方法としてこの他に

1 opfファイル内でXHTMLファイルではなくSVG画像ファイルを直接指定する
2 通常の画像同様にEPUBパッケージ内のSVGファイルを指定する

 といったような方法もあるようなのですが、1はこの方法で作ったEPUB3ファイルを開こうとした際に、EPUBビューア「Murasaki」が強制終了してしまい、どうもまだ対応しているビューアが少ないようだとの話もありましたので断念しました。2はおそらく無難にやるならこちらの方がベターでしょう。少なくとも今回のようにカバー画像を普通に表示させたいだけであれば、わざわざXHTMLデータ内にソースとしてSVGを記述する必要性はありません(そもそもSVGである必要もないでしょう)。
 ただ、XHTMLデータ内に画像のデータをテキストとして記述できると言うことは、javascript等を用いて動的にパラメータを書き換えられるということを意味しますので、使い方次第では面白そうです。

8 EPUB再圧縮、kobo/Readiumで確認

Readiumでコンテンツを確認

Readiumでコンテンツを確認

 ひととおりの編集作業が済んだら、展開したドキュメントを再圧縮します。EPUB用の圧縮ではmimetypeファイルの圧縮率を0%にしなければならないのでちょっとだけ面倒です。今回私はこのあたりの情報や、EPUB 3 スタンダード・デザインガイドの情報を参考にMac OS X付属のターミナルで圧縮しました(スクリプト作りましたよ、ええ)。上記参考ページで紹介されている「ePub Packager」などの導入を考えてみても良いと思います。
 圧縮したEPUB3データをkobo/Readiumで表示確認し(koboでの確認時にはファイル名の拡張子を.epub→.kepub.epubに変えることでACCESSの日本語用レンダリングエンジンで確認できます)、おかしな箇所があれば元ファイルを修正して再圧縮を繰り返し、完成させます。
 なお、テスト途中でkoboの挙動がおかしくなったら、一度ファイルを捨てて空の状態で再認識させた上で再度ファイルをコピーすれば直ることが多いです。それでもダメな場合やそもそも画面がフリーズして帰ってこない場合は裏面の穴にクリップの先端を突っ込んでリセットしましょう。
 また、まだβ版ですので対応していないフィーチャーなどがあり、エラーが出ますが、IDPFのEPUB Varidatorもファイルチェックの役に立ちます。

 今回作成したサンプルドキュメントを以下からダウンロードしていただけます。ご参照ください。koboおよびReadium(Windows版)で表示確認を行っています。Mac版Readiumで表示した場合、タイトルのページで文字がずれて表示される不具合が出るようです(Mac OS X 10.7環境)。本文ページは問題無くご覧になっていただけます。また、murasakiでも表示可能です。なお、koboで最初にカバーページを表示した場合に画面の右端が欠けて表示されますが、一度ページをめくり、再びカバーページを表示すると正常に中央表示されるようです。SVG表示のバグでしょうか?不明です。
 また、Fixed Layoutで一部画面サイズを絶対値で指定しているため、その部分の表示が乱れるビューアが存在するようです。また、SVGの表示まわりもかなり不安定です。このあたりは今後研究が必要と思っています。

一円本流行の害毒と其裏面談(宮武外骨/kobo・Readium) (1026)

 最後に今回のサンプル、宮武外骨「一円本流行の害毒と其裏面談」についてちょっとだけ。「円本」とは、大正年間末、関東大震災後に販売が始まった廉価な予約販売全集本のことで、一冊の価格が1円、これはそれ以前の本に比べて大幅に安価な値付けだったようです。いささかブームになりすぎた感のあったこの「円本」に対して、出版人としての立場から宮武外骨がもの申しているのがこのドキュメントになります。この外骨先生、自ら役所に掛け合って本名を「外骨」にしたという逸話のある相当にアクの強い人物だったらしく、特に官僚や政治家に対して幾度となく権力批判を行って投獄発禁処分を繰り返した反骨のジャーナリストです。この「一円本流行の害毒と其裏面談」でもそのアクの強さは如何なく発揮され、著者、版元、読者とほぼ全方向に向けてケンカを売りまくっています。この人が近くにいたら私はきっと近づかないようにするでしょう。いや、冗談じゃないです(笑)。

 電子書籍に関連して「本の価格」が話題にのぼることも多い昨今ですので、こうしたものに目を通してみるのも面白いのではないかと思い、電子書籍化してみました。今日の新古書店に当たる「ゾッキ屋」などというものもやり玉に挙げられていて、この当時から出版業界の抱える問題点はそう変わらないのだなと思わされます。なおこの「円本」に対するリアクションのひとつとして登場したのが「岩波文庫」であることは、岩波文庫の巻末の「読書子に寄す」で確認できます。つまり円本ブームが今日の文庫本の登場へとつながったわけです。

 技術的内容としては3種類の圏点が混在していること、行頭字下げが行われていないこと、かなり不規則な見出し後の字下げや文字修飾など、いわゆる通常の小説などとは随分性格の異なるコンテンツです。一部の見出しはページ上部に横書きで記述されていたようなのですが、さすがにこれは再現できませんでした。また、koboの画面サイズを考え、見出しの字下げ量を適宜調整しました。

 なお、このコンテンツ自体はkoboのストアにも青空文庫経由で入っていて、「1円」で購入できます。1円なんですよね、偶然にも

※1 セミナーでInDesignからのEPUB作成やめようよとか言っておいてInDesign使うのかよ、というツッコミをいただきそうですが、あれはそもそも数年先にそちらの方向を目指そうよ、という話ですので悪しからず。自分でつくったワークフロー使わないのももったいないですしね。いずれもっと効率的なEPUB制作ツールが出てくるまでの「繋ぎ」です。

(2012.8.22)

 サンプルEPUBファイルを更新しました。CSSのdisplay:table表記が原因でAdobe Digital Editions 2.0にて画像が表示されない問題の修正です。また、また、各xhtmlファイル内の<head>タグ内<meta>〜表記が原因でバリデートエラーが出ていましたので削除しました。

(2012.9.27)

JEPA第11回・12回セミナーまとめ

2012/07/31

 7月24日に飯田橋で行われたおよび、第11回セミナー「EPUB3と文字」および、JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」に参加してまいりました。と申しますか、光栄にもJEPA技術主任の村田真さんにご指名いただき、講師の一人として壇上で話すという人生初の体験をしてまいりました。ご来場いただいたみなさま、ありがとうございます。ということで今回は第11回および第12回セミナーのまとめです。

JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」

 後から急遽開催が決まった関係で、第11回セミナーと12回セミナーが同じ日に行われ、第12回セミナー「ISO国際標準と固定レイアウトWS」の方が早い時間に行われましたので、ここでも第12回セミナーについて先に書こうと思います。第12回セミナーはIDPF理事の小林龍生さんのご挨拶の後、村田真さんのセッション。2本立てで前後に区切って行われました。

前半:EPUB3のデジュール標準化の状況

 EPUBは2012年に急速な伸びを見せ、2013年にもやはり急速に伸びることが見込まれる、という説明からスタート。「デジュール標準」というのはJIS、ISO、IECのような公的な標準化機関によって制定された標準規格とのこと。EPUBはこれまで、IDPFという業界団体が制定した「フォーラム標準」という位置づけで、これをより認知度が高く、公的機関の文書、特に教科書での採用において必要となる「デジュール標準」へ格上げする道筋が整ったとのお話でした。

 デジュール標準化へ至る道には、標準化を希望する団体が複数存在したことや、フォーラムとデジュールの綱引き、EPUB3の基幹技術であるHTML5やCSS3がまだ完全には定まっていない不安定な状態であることなどさまざまな障害があったようですが、これらはほぼクリアの見通しが立ち、2013年中にはデジュール標準化へ向かうようです。

 これによって、今後は政府調達や教育市場でのEPUB採用が期待できるだろうとのことで、すでにデジタル教科書や問題集の標準化も始まっているとのことでした。

後半:Advanced/Hybrid Fixed Layoutsワークショップ報告

 後半はEPUB3固定レイアウトワークショップについての報告です。
 今回は「Advanced/Hybrid Fixed Layouts」とのことで、より高度で、紙のレイアウトを超えるような固定レイアウトに関してのお話でした。

 まず、EPUBのレイアウトの現状確認の中で、より複雑なページテンプレートを用いたリフローに関するお話がありました。これは、Adobeから提案があったものを仮実装したものがIDPFにはあるとのことだったのですが、まだEPUB3のコアモジュールと見なされてはいない状態で、今後どうなるかも不透明とのこと。

 本番のEPUB3固定レイアウトに関しては、まずは現状の各種固定レイアウト方式、固定レイアウト語彙の説明からだったのですが、これはいわば「おさらい」ですので、詳しくは述べません。こちらなどが参考になるかと思います。
 さて、本番セッションですが、

1. 村田真:Three Types of Digital Comics

 コミックの電子化には、
 ・紙→デジタル
 ・デジタル→紙
 ・デジタルのみ、紙を考えない
 この3つの分類があり、3番目のものではそもそもコンテンツとしての語法が大きく変わってくる、とのお話。ちなみに韓国ではすでにもう3番目のパターンがほとんどになっているとのこと。日本でも遠からずデジタル先行になっていくのでしょうか?

2. Aquafadas:Fixed Layout Reading Experience for Comics, Children Books, Table Books

 フランスのAquafadas社の発表内容の紹介で、レイヤによって日本語版のマンガに他社別売の英訳を電子書籍端末上で重ね合わせる、マンガへのアニメーション効果を重ねあわせるといったようなことや、シーンとショットを別レイヤで定義しておくことで、画面の小さな端末でも快適なコミック閲覧ができる、といったような内容でした。
 これは単に技術面のお話だけではなく、訳やエフェクトを他社が制作して読者が端末上で重ね合わせて読める、といったようにビジネスモデルにまで踏み込んでいるあたりがなかなか面白く感じられました。

3. 集英社:Introduction to the OMF format

 OMFとは「Open Manga Format」とのことなのですが、集英社の作成したEPUBの仕様に乗っ取ったマンガ配信フォーマットということのようです。JPEGを並べただけのBasic.opfの他に、Javascriptですべてを記述したAdvanced.opfという仕様があるとのこと。Basic.opfが電子ペーパー端末用、Advanced.opfがiPadのような液晶タブレット用といったような位置づけでしょうか。同一パッケージ内に双方の文書を格納し、デバイス毎にどちらかを選択して読むというような仕様とのこと。

4. Barnes & Noble:Rendition Mapping

 イメージ画像とHTMLによるリフローを使い分けて表示する方式とのことで、イメージの中に対応するHTMLへの情報を埋め込む方式が「Rendition Mapping」とのこと。これはすでにB&Nの端末で使われている方式のようです。ちょっとモリサワの「MCMagazine」に近い印象を受けました。もちろん「MCMagazine」はEPUBではないわけですが。

5. ソニー:EPUB 3 Rendition selection

 ひとつのEPUB文書の中に複数のパッケージ文書を入れ込む仕様のお話でした。EPUBでは複数のパッケージを同一文書に入れ込むことができるとのことなのですが、これにCSSのメディアクエリを組み合わせることで、サイズの異なる端末用に複数のパッケージを入れておき、自動的に切り替えて表示するといったようなことが可能になるようです。これが実現すれば、iPhoneとiPadの双方に同一パッケージで対応できる固定レイアウトEPUB文書が制作できるようになってくるわけで、なかなか期待感があります。もっともその分制作サイドは大変になりそうですが。

6. 富士フイルム:Rendition Mapping for Manga – Fujifilm Proposal

 マンガにおけるRendition Mappingの実際における発表だったようです。見開きのページはひとつの画面として扱わないと表示が破綻してしまうとのこと。確かにページをまたいだ書き文字などを見ると、そのあたりは想像がつきます。

 といったような説明がありました。
 また、論点として、Javascriptを積極的に使ってEPUB3固定レイアウトの記述をすべきかどうか、HTMLやCSSといったWeb技術を表示に多用するとバッテリー消費が激しくなるため、表示には画像を利用するべきではないか(B&N)、規格策定の優先順位をどうすべきかといったことが上がってきたようです。
 今後、年末までに何らかの成果を出すべく規格策定の動きが始まるとのことで、引き続き要注目です。

JEPA第11回セミナー「~EPUB3と文字~」

 IVS技術促進協議会とJEPAの共同開催という形で行われたセミナーでした。IVS(異体字セレクタ)は電子書籍で使用できるテキスト上で人名漢字などで用いられるような漢字の異体字字形を再現するために期待されているテキストの拡張仕様で、今は電子書籍の立ち上がり時期にあたるだけに関心も高く、結局150人を超える参加者が来場されていたようです。

国語施策と漢字コード:小林龍生

 まずはユニコードコンソーシアムのディレクターで、IDPFの理事でもあるIVS技術促進協議会の小林龍生さんから、JIS、ユニコードなどの変遷と今後の問題点についての基本的な説明がありました。
 最初に、字種/字体/字形の説明から。「学」と「學」は同じ字種だが異なる字体で、さらにその下に細かな字形の差異があるとのお話がありました。情報交換の観点から見た場合、符号化は字種のレベルにとどめるのが理想だが、実際には字体レベルでの包摂/統合は不可避で、ただ字形のレベルにまで踏み込むと本当にきりがないとのこと。
 また、そもそもの字形の揺れ問題の発端は、78JISと83JISの改訂に端を発するのではないかという意見を述べておられ、これは現場サイドとしても良くわかるお話です。

 さらに、表外漢字字体表と印刷標準字体の話の絡みで、策定時期の関係でJIS2000の例示字形には表外漢字字体表が反映されなかった経緯についての説明がありました。これにより、JIS2004で168文字の例示字形変更が必要になったとのことです。この168文字の変更には微細なデザイン差の変更も含むとのことで、字体レベルでの変更は100の符号位置に留まるとのこと。この100符号位置の字形をテキスト上で変えるにはIVSが必要になってくるようです。

 ただ、そうした区別が本当に必要かどうかは、検索の利便性などの観点から、利用者は良く考え、最低限に止めるべきなのではないかとのご意見を述べておられ、これは外字の画像化にも通じる論点ですのでとても共感できます。あまりも多様な漢字の字形差全てを電子書籍上で再現しようとすることは、制作コストにも直結してくる大きな問題と思います。

マイクロソフトが実現する新たな文字の世界:田丸健三郎

 マイクロソフトの田丸さんからの、第一世代Shift_JISからJIS2004対応に至るOSの文字コード対応の歴史次期Windows、OfficeでのIVS対応についてのお話でした。
 さらに基本文字+IVSシーケンスで異体字を表現するIVSの基本的な仕組みや、フォントやアプリケーションがIVSに非対応であっても基本文字は表示されることが期待できるために、完全な文字化けと言ったようなことにはならないIVS技術の特色などに関してもひととおりのご説明がありました。
 また、ユニコードの符号化方式(UTF-8/UTF-16)と符号化文字集合(Unicode 6.0 etc)の関係に関しても説明があり、基本的な部分ですがきちんと押さえておく必要はありますのでなかなか面白く聞かせていただきました。

 マイクロソフトのOSにおける日本語文字コードの変遷は、1982年のMS-DOS2.0におけるShift_JISの採用に始まり、Windows3.1でのマイクロソフト標準キャラクタセット(cp932)採用Windows98以降でのユニコード対応へと進み、Windows Vista以降でサロゲートペアを含むJIS2004に対応したという流れとのこと。

 マイクロソフトは次期WindowsではIVS文字の入力にOSレベルで対応するとのことです。デフォルトでIVSが入力できる状態ではなく、チェックボックスをオンにする必要はあるとのことですが、いずれにせよ外部からデータを受け入れる可能性のある印刷会社/制作会社は、今後IVSが使用された原稿の受け入れ体制を整える必要がありそうです。
 また、Officeでの対応に関しては、次期Office製品でIVSに正式対応するだけでなく、Office2007/2010でもデータ互換のためにOffice IVS Add-inによる移行パスが提供されるとのこと。

 今後電子書籍の時代には、編集者・校正者・作業者が同一の文字環境で作業するような環境を構築し、OSやフォントに起因する字形の揺れをあらかじめ抑止することが、スムーズな作業の流れのために最低限必要となってくるように思います。

DTPデータから電子書籍を制作する際の「外字」問題:田嶋 淳

 田丸さんのあとが私のセッションでした。内容的にはこちらのブログに掲載したものと重複する点が多くありますので詳述はしませんが、InDesignのデータからテキストを抜き出した際に起きる字形変化の理由および、どういったパターンの字形変化が存在するのか、今後電子書籍・印刷データ双方の制作環境はどういった方向性を目指すべきかといった点に関していささか拙いながら述べさせていただきました。

 当日配付させていただいた資料を以下からダウンロードいただけますので興味をお持ちの方はご覧いただければ幸いです。また、epubcafeのページにYoutube動画へのリンクもありますので、あわせてご覧下さい。

7/24セミナー配付資料 (1924)

 なお、この内容に関連して、小形克宏さんの制作された技術者・ソフトウェア開発者向けのより詳細な資料が、出版デジタル機構ホームページ内「技術部だより」より、近日中にダウンロード可能になります。

 この外字の問題につきましては、「では現状どうすればよいのか」というご質問を何度かいただいたのですが、ソフトウェアを用いて完全に対処することが難しい以上、最後は目視での校正作業に頼らざるを得ないのが現状です。こうした作業を少しでも軽減するために、InDesignの「代替字形」チェックボックスの活用や、スクリプトを用いて内部文字をチェックすることで対処が必要な文字をある程度洗い出すことは可能ですが、いずれにせよ最終的にきちんとした品質を確保するには全文の目視校正作業が不可欠と思われます。

IVSとのつきあい方:狩野宏樹

 株式会社イワタの狩野宏樹さんのセッションで、現状でのIVS対応フォントの状況OSの対応状況IVSを使用する上での基本的な注意点についてのお話でした。

 IVS対応フォントは、小塚明朝Pr6N小塚ゴシックPr6NがInDesign CS4にバンドル提供されたのを皮切りに、2011年1月にイワタから発売された52書体游明朝体Pr6/Pr6N R筑紫明朝Pr6/Pr6NイワタUDゴシック/イワタUD丸ゴシックなど、現状100フォント以上が利用可能になっているとのことです。

 OSとしてはWindowsは7以降で異体字が表示され、Vistaでは異体字は表示できないもののIVSシーケンスが無視されて基本文字が表示されるため、読み取り自体は可能とのこと。XPではIVSの文字自体が文字化けして表示されてしまうようです。Mac OSは10.6以上で表示に対応、10.7以上ではバンドルフォントのヒラギノProNがIVSに対応しているとのことです。

 また、アプリとしてはInDesignはCS4でIVSに対応していますが、IVS文字を親文字とは別々に選択できてしまう仕様のため、IVS文字だけが残ってしまう危険がある点を指摘されていました。また、IVS文字にルビをかけた場合、直前の文字にルビが存在しない場合、IVS文字が化けてしまうバグが現状で存在するようです。直前の文字に全角スペースのルビを振ることで対処療法として回避は可能ですが、将来的に改善を期待したいところです。

 さらに、IVSは漢字のみにしか使えないものであること、IVSが必要な文字がどれなのか直感的な区別が難しいこと、IVSのコレクションにはAdobe-Japan1以外にHanyo Denshiがあり、双方で異体字の重複があること、IVSでは異体字が表示されない場合でも基本字形は表示され、特に文字化けの警告等は表示されないため、InDesign等で文字変化を発見しにくい危険があることなども指摘されており、このあたりは今後の課題として十分な注意が必要そうです。
 加えて、フォント側として全てのIVS仕様文字への対応が求められるわけではないため、フォントが目的の異体字に対応していなければ基本字形に変化してしまうといった状況が起こり得るとのこと。

 さらには、IVSとGSUBを併用することは避けるべきで、IVSならIVSで統一すべき、とのお話もあり、本格的な運用までにはまだ若干の課題が残っているようです。

(2012.7.31)

プロフィール
Jun Tajima

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

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

最近のコメント