‘未分類’ カテゴリーのアーカイブ

第39回出版UD研究会セミナーに行ってきました

2012/09/05

 第39回出版UD研究会「情報アクセシビリティの世界から見た本のアクセシビリティ」に行ってきました※1。ゲストスピーカーはIBMフェローの浅川智恵子さんで、中学校時代に事故で失明されていながら努力の末にIBMに入社され、点字翻訳システムや視覚障がい者用ホームページ読み上げシステムの開発など情報アクセシビリティの研究を続けてこられた方です。ちょっとどれだけの努力をすればそれが可能なのか見当がつきません。本当に頭が下がります。

 一般的にアクセシビリティの確保といいますと、高齢者・障がい者を含む誰もがサービスやコンテンツにアクセスできるようにすることを指し、わかりやすいところでは建物におけるバリアフリー設計などがそれにあたります。
紙と電子のアクセシビリティ 今回のセミナーでは、視覚障がい者向けの点字翻訳技術や音声読み上げ技術、スマートフォンなどを利用したクラウド経由での障がい者支援システムについての説明の後、書籍のアクセシビリティ確保のための電子化に関する話があり、なかなか興味深い話を聞くことができました。

 これまでの決められた判型・フォントサイズで印刷される紙の書籍では、アクセシビリティの確保と言っても、大きめのフォントサイズで印刷することや、高齢者向けに拡大版を出すといったような対策しか考えようがなく、コスト面での制約から商業ベースで多くの書籍をアクセシブルにすることは難しいものがありました。この結果、点字翻訳や音声録音といった視覚障がい者向けコンテンツの制作は、我が国ではもっぱらボランティアベースで行われてきたのが実情です。
 しかし、読者が手元の設定で文字サイズを変えられるリフロー型の電子書籍では、このあたりは商業ベースの出版物でもぐっと身近な考え方になってきます。むしろ、視覚障がいや老眼などの理由で従来の紙の書籍を読むことが難しい層であっても、電子書籍であれば読むことができるというのであれば、それはこれまで取りこめていなかった消費者層の取り込み、売り上げ増加に繋がってくる決して小さくないファクターになってくるとも言えそうです。
 これに加え、特に教科書などの公的性格の強いコンテンツは、今後法令によって一定レベルのアクセシビリティが求められる可能性があるとの話もあり、制作サイドがどういった考え方を持って電子コンテンツを作っていくべきなのか最初にしっかり確認しておくことはとても大事と思います。

 ということで、今回のセミナーの説明に入ります。最初にお話のあった黎明期の視覚障がい者向けリーディングシステムの話も面白かったのですが、今後のコンテンツ制作に直接つながる話ではないので省略させていただき、まずは視覚障がい者の音声認識スピード及び、音声読み上げ技術の話からです。

早く読む技術、ナナメ読みの技術

 まず、視覚障がい者は健常者に比べてずっと早いスピードの音声を認識できるという話があり、これはなかなか興味深いものがありました。実際に音声の高速読み上げデモも行われたのですが、私などでは到底何を言っているのかわからない2倍速での再生でも、視覚障がい者の方は普通に聞き取れてしまうとのこと。また、ホームページ読み上げに関連したナナメ読み/要約技術のデモもあり、ぐるなび等の口コミ評価サイトの要約デモが行われていました。これは投稿レビュアーによって書き込まれた各店舗の大量のレビュー記事の中から「良い/悪い」という言葉およびそれに類する言葉を含む段落だけを自動抽出し、読み上げる技術とのことで、実際に聞いてみると確かに大づかみにその店の評価を知ることができます。
 これは視覚障がい者向けだけではなく、例えば目で文章を追いにくい運転中に使うカーナビ等と連携した利用にもニーズがありそうかなと感じました。また、現状読み上げ技術は高齢者向けなどの実装が中心で、視覚障がい者向けの速読技術はニーズが限られているために技術開発が進みにくい面があるとのこと。このあたりは今後の対応に期待がかかるところです。

クラウド・アクセシビリティ/ソーシャル・アクセシビリティ

 コンピュータによる自動認識では足りない部分を、多数のボランティアによる人間の知能で補うことで総合的に優れたサービスを実現する試みも数多く試みられているようです。例えば視覚障がい者がスマートフォンの専用アプリで撮影したものをクラウドサーバーに送って自動画像認識し、音声で読み上げるようなシステムで、認識できなかったものはクラウドサーバー経由でボランティアの元に送られて人間の目で確認、文字入力されて結果が音声で読み上げられる、といったようなソリューションのデモが行われたのですが、なかなか興味深かった点として、単純にボランティアの補正によって補完するだけではなく、認識結果はコンピュータ側に記録としてフィードバックされて自動認識エンジンの改良に使われるとのこと。これはおそらく検索エンジンの画像認識など一般ユースへのフィードバックも含んだ考え方と思われます。ただ、こうしたクラウド連携サービスは現状英語ベースのサービスがほとんどで、日本語の認識という意味では難しい面があるとのことでした。

アクセシブルな電子書籍制作の課題

 さて、本命です。まずは電子書籍制作のコストのお話から。アクセシブルな電子書籍を制作するには、画像をスキャンしてパッケージングするだけではなく(レプリカフォーマット/緊デジフィックス型)、きちんとテキスト起こしをし、構造化する必要があるとのお話がありました。この「きちんとテキストベースで制作され、構造化された電子書籍である」ということが、実際のところ最低限のアクセシビリティの保証とほぼイコールになってくるようです。iBooksなどにはすでにEPUB3文書の合成音声読み上げ機能が実装されていますので、これは確かに頷けるところがあります。
 この構造化テキストの制作工程で特にコストがかかるのは、OCR処理されたテキストを校正する工程、構造化する工程とのことで、特に日本語は26文字しかないアルファベットに比べて圧倒的に文字数が多く、さらに縦組み/横組みの混在多言語混植ルビや圏点の存在など欧文書籍にはない要素が多数あるため、OCR処理の技術的ハードルがとても高いとのこと。従ってOCR処理後のテキストに必然的に間違いが多く、校正のコストが高くつくとのお話で、これは制作現場の経験からもその通りと思います。

 またこれは質疑応答の後に関係者の方に確認した話なのですが、現状日本語OCRソフトはShift_JISの範囲の文字認識がせいぜいで、Unicodeの範囲をきちんと認識できるものはおそらくないだろうとのこと。つまり、JIS第3・第4水準漢字は現状OCRでは認識できないと考えた方が良さそうです。さらに、以前のエントリーでも書かせていただいたように、印刷物の制作に使用できる文字の数はUnicodeで使用できる文字の数を上回りますので、こうしたUnicode領域外の異体字などは当然OCRでの自動テキスト化は期待できません。日本語書籍の電子化が遅々として進まないのはこうした部分にも一因があるのではないでしょうか。

 海外ではBookShareというサービスが存在し、国のサポート、ボランティアの支援によりベストセラー書籍が出版された翌日には点字/DAISYフォーマット化されて入手できるルートが整っているとのことなのですが、上記の理由により日本では同一のモデルの成立は困難だろうとのことです。こうした部分を解決するには、日本ではやはり出版社自身による紙書籍と電子書籍の同時刊行が必要になってきそうです。

校正作業のゲーム化、パスワード認証との連携

 日本語書籍に比べればまだマシとは思いますが、アルファベット圏でも過去の印刷物のテキスト化に伴う校正のコストに頭を悩ませているのは同じです。そうしたコストを削減するための海外でのさまざまな試みの紹介がありました。
 オーストラリア国立図書館の校正作業の一般開放の試み(Trove)や、フィンランド図書館の校正作業をゲーム化して一般公開する試み(Digitalkoot)などの紹介があったのですが、特に面白かったのはGoogleが買収したパスワード認証システム、reCAPTCHAについての説明です。

 ゆがんだテキストを目で確認して入力することでサイト認証を行う仕組みはすでにあちこちで目にするところなのですが、reCAPTCHAはこれを一歩進めて、パスワード認証用の画像と並べてOCRでの文字認識に失敗した画像を配置し、利用者に双方を入力してもらうことで無数のユーザーに無意識のうちに校正作業に参加してもらうというシステムで、これはすでにGoogle Booksでの書籍電子化にも利用されているとのこと。集合知によって厖大な作業量をカバーする、いかにもGoogleが好みそうなアプローチです。
 Webで調べた限りではこのreCAPTCHAの出題項目に日本語や中国語が出てくることもあるようです。これはGoogle Booksプロジェクトで電子化するためにスキャンしたテキスト画像が自動で振り分けられているものと思われます。英語文化圏の住人に日本語文書の校正入力をきちんと行える人がそう多くいるとも思えないので、あるいは国別に割り振りが行われていたりするのでしょうか。

 また、OCRの認識精度向上のために人間の入力結果を利用する試みもヨーロッパの図書館や公共研究機関を中心に盛んに行われているとのことで、これは是非、日本の研究機関や関連企業にも頑張っていただき、せめてJIS第3水準、第4水準漢字レベルの認識が可能なOCRソリューションに早く登場して欲しいと思っています。素人考えですが、一度文字レベルで自動認識させた仮テキストを、辞書と連携した熟語認識エンジンで整合性チェックする、といったような仕組みでOCR処理の精度アップが図れないものでしょうか?

 最後に、電子書籍のアクセシビリティ確保について制作サイドが心がけるべきことを、以前のセミナーでDAISY関係者の方にお聞きした話なども含めて簡単に箇条書きしておきます。

  • きちんとテキスト化し、きれいに構造化されたEPUB3であれば読み上げは可能。最低限のアクセシビリティは確保できている。
  • 読み上げ対応EPUB3の構造化言語はDTBookでなくて良い。XHTMLでOK。
  • 画像のalt(代替文字)属性に、適切な内容を入力しておくことが重要。画像ファイル名とかはNG。
  • 「○○ページ上図参照」などの書籍内の位置に依存する表記はアクセシビリティの確保に支障をきたす。
  • 今後、高齢化や法によるアクセシビリティ確保の義務化などにより、アクセシビリティ対策は重要度を増していく可能性が高い。

※1 第39回出版UD研究会 togetterまとめhttp://togetter.com/li/366078

(2012.9.05)

固定レイアウト/リフロー混在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もファイルチェックの役に立ちます。

 最後に今回のサンプル、宮武外骨「一円本流行の害毒と其裏面談」についてちょっとだけ。「円本」とは、大正年間末、関東大震災後に販売が始まった廉価な予約販売全集本のことで、一冊の価格が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)

 Wordpressの更新に伴い、ダウンロードファイルを削除しました。古い情報のためもう必要ないものと判断したものです。

(2020.1.17)

InDesign出力XML→XMDF変換スクリプト公開

2012/08/10

 「緊デジ」でリフロー型EPUB3の制作受け入れが決まりました。同時に出版社サイドからの制作会社指定が可能になり、PDF制作にも対応、申請点数の上限を年間発行点数の2倍までとした規定の廃止など、申請条件を大幅に変更した旨のお知らせが、緊デジサイトに掲載されています。EPUB3の制作ガイドラインの内容告知、EPUB制作会社の選定準備等は9月1日以降になるとのことで、XMDF・ドットブック形式の制作会社はすでに決定しはじめていると思われるものの、8月7日現在での申請数が未だ目標の6万点の半分にも届いていない状況を考えると「一度仕切り直し」感は否めません。

 ほとんど前例のないプロジェクトですので関係者の方を一方的に責める気にはなれないのですが、制作サイドの会社に所属している一人としては、ここまでスケジュールが遅れている現状でなお当初の予定通り3月末までに6万冊を揃えることが可能な見通しなのか不安があります。おおざっぱなものでも構いませんので、早い時期に今後の制作スケジュールの見通しを示していただくことを望みたく思います

 さて、私の所属している会社は結局XMDF・ドットブックの緊デジ制作会社には選ばれなかったのですが、制作に向けてXMDF変換スクリプトの準備は進めておりました。制作者としてこのまま無駄にするのも忍びない思いがありますので、会社の許可を得てこれを公開してしまうことにしました。以下よりダウンロードいただけます。

InDesign CS5 XML→XMDF変換スクリプト

(XMLファイルを「ID5XML2xmdf.bat」にドラッグ&ドロップすると置換されます)
(XMLファイルをテキストエディタ「mi」で開き、スクリプトを実行すると置換されます)

 なおこれは、私のブログに掲載されております「InDesign→EPUB3用XHTML作成ワークフロー」の手順に従ってタグ付け作業を行ったInDesignデータから書き出したXMLデータを、XMDF本文用のXMLデータに変換するためのスクリプトです。手順19までは共通の流れとなりますのでご了解ください。また、配布スクリプトをWindows環境でご使用いただくには、あらかじめActivePerlのインストールが必要になります。
 割り当てるタグの名称等は上記ワークフローのそれに準じます(つまり、同一のXMLソースからスクリプトの切り替えだけでEPUB用XHTMLとXMDF用XMLの双方の出力が可能です)。

XMDFビルダー側で必要になる作業

 本文をXMDF形式のXMLデータに変換した後、実際にXMDFコンテンツとして書き出すためにXMDFビルダー側で以下の作業が必要になります。なお、XMDFビルダー内での詳細な操作に関しましては、XMDF情報スクエアにてログイン後ダウンロード可能な説明書をご参照下さい。また、緊デジでの作業内容に関しましては、公式サイトのガイドライン等をご参照いただければ幸いです。

1 テキストをコピー&ペーストします

テキストをコピー&ペースト

テキストをコピー&ペースト

 変換済のXMLファイルをメモ帳等で開き、一番上の「<?xml version="1.0" encoding="UTF-8" standalone="yes"?>」の行を除いた全てのテキストを、XMDFビルダー「ワークスペース」内の「フロー」にコピー&ペーストします。また、画像・外字画像等を使用している場合は、「パーツマネージャー」からコンテンツ内に取り込んでおきます。

2 スタイルを設定します

スタイルを設定

スタイルを設定

 「文書構造スタイル」「文字スタイル」を設定します。書き出されたタグのうち、「<structure style="○○">」の「○○」が文書構造スタイル名(InDesignで言うところの段落スタイル名)に相当します。同じく「<font style="××">」の「××」が文字スタイル名です。
 XMDFビルダー内「基本構成」メニュー内「スタイル」にて設定できますので、適宜適切な値に設定します。各スタイル名をスクリプトが自動出力する値以外に設定したい場合は、あらかじめテキストエディタの一括置換機能などでXMLファイル内のスタイル名を置換した上で、XMDFビルダー側に置換後の名称を設定することで対応できます。
 なお、「コンテンツテンプレート」機能を用いて各種パラメータをインポート/エキスポートできますので、見出し/本文等のスタイル設定を保存しておくことは可能です。

3 画像の回り込みなどを設定します

画像の回り込み等を設定

画像の回り込み等を設定

 必要であれば画像の回り込み、表示方法などを設定します。

4 文書内リンク等を設定します

文書内リンクの設定

文書内リンクの設定

 文書内リンクは「<char_id char_id="■">※</char_id>」といった形で出力されますので、「■」を選択して「装飾編集」パレット「イベントID」からID番号を入力し、「基本構成」メニュー内「イベント編集」で移動先のページ等を設定します。なお、こちらの作業は手順として、一冊分全てのフローを設定した後で行った方が効率的と思われます。

5 外字の代替文字を入力します

 外字は「<external_char alt="〓" alt_img=”cid-0000.png” />」のような形で出力されますので、「〓」部分に適宜代替文字を入力します。代替文字を入力しなくても、外字画像が適切に設定されていれば通常表示に問題はありませんが、将来的な変換や読み上げ等の対応を考えた場合、入力しておいた方が何かと流用が効きやすいデータになるように思います。

InDesign内で外字ファイル名にルビを設定

InDesign内で外字ファイル名にルビを設定

 なお、外字にルビをかける場合は、InDesignドキュメント内にインラインで記述されている外字ファイル名(「InDesign→EPUB3用XHTML作成ワークフロー」手順3参照)にグループルビとしてルビを入力しておくことで、自動で変換出力されます。
 なお、EPUB3出力でも同様の外字ルビ処理に対応するため、そちらのスクリプトも改訂いたしました。適宜ダウンロードしていただければ幸いです。

 緊デジでの画像サイズの設定、ファイル名の規定等に関しましては、公式ガイドラインをご参照下さい。また、こちらのスクリプトを使用したことによるデータ破損等の損害に関しまして、私としては責任は負いかねますので、あくまで自己責任でご使用ください。

(2012.8.10)

Mac用置換スクリプトで「<p.indent>〜」等の記述が正常に変換されないケースがあった問題を修正しました。

(2012.9.6)

プロフィール
Jun Tajima

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

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