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

JAGATセミナー「EPUB制作現場の実態と今後の課題」を終えて

2013/06/28

 6月17日、JAGATにて「EPUB制作現場の実態と今後の課題」と題しまして、緊デジなど昨年度のDTPデータからの電子書籍作成の状況を実際に電子書籍制作を担当した現場の視点で語ってもらい、今後の制作環境の構築に役立ててもらおうということを狙いとしたトークセッションが行われました。こちらは私がJAGATさんにお願いしまして実現したイベントなのですが、有り難いことに多くの方にご来場いただき、ご好評をいただいたようで何よりでした。

 今回はセミナーでお話ししたことの振り返りとまとめです。以前に触れたことと重複する部分もあるかとは思いますがご容赦ください。

昨年度までの電子書籍関連トピックスの軽いおさらい

 昨年度は緊デジなどを含めて、電子書籍関連の大きなニュースがそれこそ日替わりで飛び込んできた感がありました。ここで緊デジ、EPUB3を中心として、昨年度までの出来事を時系列順に軽く振り返ってみたいと思います。

2011/10/10:EPUB 3.0 Final Specification(IDPF)

 IDPFによるEPUB3の最終勧告です。ひとまずこれをスタートラインとします。

2011/10/14:EPUB3日本語ベーシック基準 Draft1.0(ボイジャー/インフォシティ)

 EPUB3の最終勧告を受けて発表された日本語書籍向けEPUBガイドラインです。こちらはボイジャーさん、インフォシティさんが中心になってまとめたもの。

2011/11/24:JBasic08(イースト)

 同じく日本語書籍向けEPUBガイドラインです。こちらはイーストの高瀬さんが中心になってまとめたものです。この時の会議には私も参加させていただいています。

2012/3末:緊デジ説明会

 年度末の3月末に行われた「経済産業省コンテンツ緊急電子化事業」通称緊デジ事業の説明会です。沢辺さんがユニークな説明をされていたのを覚えています。この時に中核企業としてパブリッシングリンクさんが入ることが発表されています。

 この時に配布された資料からの抜粋です。

  • 「出版デジタル機構は100万タイトルの制作を目指す」
  • 「中間交換フォーマットと.book/XMDFの配布用ファイルの双方を納品」
  • 「緊デジフォーマットは出版デジタル機構でも採用する」
  • 「PDFは採用しない」

 ここで出てきた「中間交換フォーマット」は、三省懇で作られたもののことを指していたようなのですが、独自仕様のXMLです。これはこの時点では仕様がほとんど公開されておらず、後日発表の詳細な資料待ちと言った状況でした。PDFが不採用だった理由は各電子書籍ストアの販売体制の問題とのことだったように思います。

2012/4/2:出版デジタル機構正式に発足

 出版デジタル機構正式設立はこの日でした。当時の出版デジタル機構(仮称)準備会のサイトには、設立の目的として、

  • 「国内における電子出版ビジネスの公共的なインフラを整備することで、市場拡大を図る」
  • 「日本の電子出版物の国際競争力を強化する」
  • 「研究・教育・教養分野における電子出版物利用環境を整備する」
  • 「国内で出版されたあらゆる出版物の検索を可能にする」
  • 「電子出版・電子書店などへの新規参入を容易にし、誰でもが電子出版による言論表現活動に参加できるようにする」

 との文言があります。このニュースは、さまざまなメディアでかなり大きく取り上げられました()。

2012/4/10:電子化仮申請「93,725」点

 これは日本出版インフラセンター(JPO)が行った各出版社からの電子化希望数の集計数です。ただしこの時点では著作者サイドの二次使用許諾が取れていなくてもOKとしたため、あくまで「仮」の集計でした。

2012/5/10:電子書籍制作仕様書確定版公開

 コンテンツ緊急電子化事業電子書籍制作仕様書v1.01の発表です。この時点での規定内容をちょっと抜粋しますと

  • 「配信用電子書籍ファイル(XMDF or .book)」と「アーカイブ用中間作業ファイル」の納品
  • 「現状ではEPUB3の基準になる日本語用ビュアーが揃わないため、当初は制作・配信ともに実績のあるXMDFもしくはドットブック形式を出版社や電子書店の意向を受けて作成する」
  • 「同時にビルド(電子書籍パッケージ化)直前の状態のXMDF記述フォーマットやTTXなどの作業ファイルを納品してもらい、アーカイブ」
  • 「中間作業ファイルを保存しておくことによって、市場がEPUB3や次世代の電子書籍フォーマットを必要とした時点ですぐに再ビルドが可能な状況を目指す」

 とあります。ポイントは「中間交換フォーマット」が「アーカイブ用中間作業ファイル」に変わったことで、つまり独自仕様のXMLファイルの納品からXMDF/ドットブックの中間作業ファイルの納品へと方針が変化したわけです。現実味のある形になってきたと言えます。この時点でもまだ求められる納品ファイルはXMDF/ドットブックのみでしたが(リフロー型)、実際まだこの時点ではEPUB3を全面採用したストアはなく、信頼できるビューアもほとんど存在しない状況でしたので、まず現実的な判断だったと思います。

2012/6上:電子書籍制作発注会社公募説明会

 緊デジ電子書籍制作の「正規受注会社」の公募説明会です。東京会場、東北会場に分けて2回行われています。東京会場での説明会は講談社さんの社内ホールで行われたと記憶しています。このあと応募社に対して1次審査が行われ、通過した会社に対して試作コンテンツの制作依頼が発注されました。この時点ではリフロー型のEPUB3は採用されていませんので、ドットブックもしくはXMDFでの試作です。

2012/7/2:楽天Kobo日本市場参入発表

 2011年末に楽天に買収され「楽天Kobo」となったKoboの日本国内事業開始発表です。これは初のEPUB3全面採用ストアの登場基準になる日本語用EPUBビュアー(Kobo touch)の登場を意味していたため、EPUB3普及の決定的な分水嶺となる出来事だったように思います。

2012/7/25:緊デジタイトル申請条件緩和

 Kobo参入を受けて緊デジのタイトル申請条件の大幅緩和が行われています。内容は以下の通り。

  • 「上限を年間発行点数の2倍まで」という申請上限の廃止
  • 図書寄贈の義務化も「可能な範囲での寄贈」に
  • EPUB3リフロー型の採用
  • 制作会社の指定が可能に
  • PDFフォーマット指定可能に

 制作会社の出版社側からの指定が可能になり、EPUB3リフロー型が採用されたことで「ほとんど仕切り直し」になった感があります。この時点ですでに正規受注制作会社の審査中でしたので、なかなかやきもきさせられた記憶があります。

2012/8/10:電子書籍制作発注会社発表

 緊デジ制作会社の審査発表です。「なお、EPUBの制作と入力・校正に関する審査につきましては、後日改めて発表いたします」とありますので、これはあくまでXMDF/ドットブックの制作会社という扱いだったようです。「東北作業○○%以上」等の表記がかなり目立つことでわかるように、ここでの審査基準は東北との関連性がかなり重視されたようです。

2012/9/5:緊デジ更なる条件緩和

 ここで、更なる条件緩和が発表されています。内容としては

  • 「EPUB3へのコンバート対応」
  • 「第二次出版社申請受付」

 の2点です。コンバート対応は、すでにXMDFやドットブックになっているものをEPUB3に変換するのを1タイトルとして数えるというような話で、おそらく緊デジの制作物のうちかなりの割合がこれだったのではないかと思われるのですが、発表資料からは詳細な内容が読み取れないので分かりません。

2012/9/11:「電書協EPUB3制作ガイドver.1.0」発表

 電書協からEPUB3制作ガイドの発表です。このガイドの性格についてはさまざまな否定的な意見もあったのですが、「印刷物からの電子化」という目的に限って言えば、かなり制作現場の現実に即したガイドラインかと思います。

2012/10/5:緊デジEPUB3テンプレート公開

 電書協EPUB3制作ガイドの発表を受けて、緊デジのEPUB3が「電書協EPUB3 制作ガイド」に準拠することが発表されました。7/25の発表で緊デジでリフロー型EPUB3が採用されること自体は発表されていたのですが、どういったEPUB3を制作すべきかの指針は示されていませんでした。それがここで規定された形になります。

 これでようやく、EPUB3のビューア、マークアップ規定が揃い、実際にEPUB3を制作できる環境が整ったことになります。とはいえ、もうこの時点で制作期間は半年を切り、かつある程度誰もが制作に参画できるわかりやすいツールがあるわけでもありませんから、前途多難が予想されました。

2012/10/25:Amazon Kindle日本市場参入

 長らく参入がささやかれていたAmazon、Kindleが正式に日本市場参入の発表をしたのがこの日です。実質これで完全に「電子書籍」の市場形成が確立した感があるように思います。

2012/12/14:ボイジャー「BinB」による緊デジEPUB校正システム稼働開始

 ボイジャーの「BinB」を利用した緊デジの公式なEPUB3校正システムが、この日に開始されています。出版社サイド、制作者サイドが同じ環境でコンテンツを見ることが保証されなければ効率的なコンテンツ制作環境は期待できませんから、これは重要な一歩だったと思います。

 ただし、初期にEPUB3の表示の乱れが多く見られたことや、制作側が柔軟に何度もアップロードして更新できる仕組みになっていなかったこと、ボイジャー社が不具合を修正してもサーバのアップロードスケジュールとの兼ね合いですぐに修正が反映されなかったことなど、課題も数多く見られました。
 上記の理由で実際にはこちらの校正システムを使用せず、ストアのビューアなどを利用してEPUB3制作を進めた制作会社も多かったのではないかと思います。

2012/12/31:緊デジリフロー型底本/データ発送〆切

 緊デジタイトルの出版社からパブリッシングリンクへの発送〆切です。フィックス型は10日ほど余裕があり、1月11日に設定されていました。当然といいますか、ここにとても多くのコンテンツが殺到したようです。この時点での正式な納品最終納期は1月31日でした。正直軽くクラクラしました。

2012/1/23:制作納期の最終デッドラインの通知

 この日、制作会社のみに向けて、制作納期の本当のデッドラインが告知されています。

2012/2/19:EPUB制作時の参考資料「正立指定が必要な文字」の公開

 EPUB3およびWebで長らく懸案となっていた縦組み時の記号類の正立/横転表示が各ビューアによって異なることに対処するための基礎資料の公開です。この資料自体は大変有用なもので、私もとても助かったのですが、この時期にこういった「基礎的な資料」が公開されていること自体、実質的にはEPUB3制作のフロー自体がこの時点でも未完成であったことを示唆しているように思います。(参考:Draft Unicode Technical Report #50 UNICODE VERTICAL TEXT LAYOUT

2013/2/27:緊デジ制作仕様書v1.8の発表

 この日に発表された緊デジ制作仕様書v1.8には、「納品するファイルを明確にするため、ファイル/フォルダ保存・命名ルールを詳しく規定し直した」という記述があります。実際にはこのあたりにデータの納品が集中していたことがわかると思います。

2013/3/1:重要なお知らせ:制作納期の期日につきまして の告知

 ここで制作納期が「3月18日まで」、とはっきり線引きがされています。ここが本当の最終デッドラインということでしょう。窓口担当者は相当大変だったろうなと同情を禁じ得ません。

2013/6/3:タイトル申請数と達成状況の最終確定値ならびにタイトルリストの公開

 緊デジ事業終了後の資料公開です。総タイトル数は64,833とのことでした。資料が取り回しにくいPDFで、また出版社名すらない「タイトルのみの羅列」だったことなどからかなり批判も出ました。これに関しては、今後の電子書籍制作環境の整備のためにも、より詳細なきちんとした資料を、できればCSVデータなどのより二次利用がしやすい形で出して欲しいと個人的には思っております。

登壇者の発表内容

 今回は私が登壇者の一人ということもあり、他の登壇者の方の発表内容のメモが追いつかなかった部分があります。記述に間違いなどありましたらご指摘ください。速やかに修正させていただきます。

(株)三陽社メディア開発室 田嶋セッション

 最初は私のセッションからでした。
 私の所属する三陽社という会社は、創業が1949年の比較的古い活版印刷系の印刷会社で、学術系や文芸系を中心として比較的伝統的な出版社さんからお仕事をいただいています。その関係で社内に保管されている大量の印刷データの電子書籍化をどうにかしようというのが会社としての電子書籍の取り組みのスタートラインでした。また、クライアントさんからも比較的古い時期にSONYのリブリエ用データ制作の依頼などもあり、そういう経緯を踏まえて2012年にメディア開発室という部署を立ち上げ、電子書籍制作の研究を本格的に始めています。

 2011年あたりに危惧していた点としまして、私の会社の場合、メインの組版ソフトがAdobeのInDesignではなくモリサワのMC-B2であるため、これを起点としてのEPUB3制作はちょっと一般ルートで進みそうにないということがありました。そのため、自社である程度まで進めるしかないと考えていました。そこでまずはMC-B2のデータをInDesignタグテキストに変換してInDesignで読み込める形にし、当時、将来できるであろうと想定していたInDesignからのEPUB3制作ルートに乗れる形を整えました。
 ただ結局、InDesignからの電子化もそう簡単ではないことが徐々に判明し、かなりの部分を自力でワークフロー構築することとなりました。

 電子書籍の形式としては最初はモリサワのMCBookの研究から始めています。これはMC-B2/Indesignのデータを読み込めることが売りのひとつでしたが、結局元データの事前の整備が必要になり、かえって手がかかることから、MC-B2→InDesignでデータを整備→XMLでタグ付けして書き出し→PerlでMCBook用XMLデータに変換、の形でデータの制作フローを整えました。
 MCBookは注や異体字関係の機能が充実しており、また組版も非常にきれいだったためかなり期待をしました。しかし、当初Appleのアプリ型ソリューションだったことから外資相手の契約が必要になり、出版社サイドの会計処理が煩雑だったこと、結局特定メーカーへのロックインになってしまうことなどの問題点もありました。
 このため、結局残念ながら会社的にはビジネスには結び付いていません。

 ただ、このMCBookの制作の際に開発した変換スクリプトをもとにして、JBasic08準拠のEPUB3用にInDesignデータからXHTMLを生成するワークフローを発表したりしまして、EPUB3制作のノウハウに結びつけることはできました。

 緊デジについては受注価格的には会社的に厳しいラインになるのはわかっていたのですが、ノウハウの蓄積を考えると貴重な機会と思えましたので、業務の延長線上にあるリフロー型の制作のみに絞って受注を目指すことにいたしました。当初はEPUB3のみを想定してフロー構築をしていたのですが、XMDFもしくはドットブックでの納品が求められるとの話が3月末にあり、また独自形式のXMLでの納品も必要との話もあったため、InDesignからXMDFにも変換できるようにスクリプトを制作しました。

 2012年の6月には電子書籍の外字問題に関するエントリをブログに書いたのをきっかけにしまして、当時出版デジタル機構の技術アドバイザーだった深沢英次さんにお声がけいただき、InDedignから電子書籍を制作した際に文字化けを起こす文字のレポートを書きました。これは非常に勉強になりました。こちらのレポートは今、出版デジタル機構さんのホームページの「技術部だより」にありますので、興味がある方はぜひご覧いただければと思います。

 8月には緊デジ正規受注会社の発表があり、私の所属する会社は結局正規受注会社には選ばれなかったのですが、もともとお付き合いがあり、紙の書籍の制作をさせていただいていた出版社さまからの「制作会社指定」の形で緊デジ事業に参加することになりました。
 従って私の所属する会社で緊デジで制作したコンテンツの元データはほとんど自社に保存されていたもので、MC-B2のデータや、古いものでは電算写植のデータもありました。後から数点、他社制作データの電子化依頼もいただいたのですが、これもMC-B2のデータがほとんどでした。

 電子書籍の形式としては全てリフロー型のEPUB3なのですが、学術系などの組版の複雑な書籍が中心でしたので、底本に割注が含まれていたり、多数の索引があったりして、それのリンク設定にかなりの時間を取られました(文書内の注リンクは緊デジでは出版社独自仕様拡張の扱いでした)。
 また、もともと付き合いのある出版社さんのコンテンツが中心ということで、正字対応など字形にもかなり細かく対応する必要があるのはわかっていましたので、底本と引き合わせて校正をしたりもしました。そのあたりの厳密な校正はもともと会社的に強い部分なので、ここは社内リソースをかなりアテにすることができました。

 制作上大変だった点として、もとのデータの作り方が制作者によって異なるので、制作時に適宜判断しなければならなかったといったような点が挙げられるのですが、これはおそらく全ての制作会社にとって労力が必要だった部分なのではないかと考えています。
 InDesignに限らずDTPソフトというのは「紙の本」を効率良く制作するために機能拡張を繰り返してきています。紙の書籍の制作というのは結局書籍として完成した状態の見た目が全てで、そこに至る経路はどんな道を辿ってもいいという世界なので、当然制作会社ごとにノウハウも違いますし、人によっても違ってきます。100人オペレータがいれば100通りのやり方があるくらいに考えても良いくらいだと思います。

 もちろんきちんとした印刷会社は社内でミスを減らすためにワークフローを統一しているとは思いますし、私の会社もそれはやっているのですが、例えば緊デジのようにどこで作られたかわからないデータを受け入れて電子書籍にするような話ですと、元データがどう作られているのかをそれぞれ分析し、必要に応じて修正することを考えなければなりません。見かけは同じでもどの機能を使ってそれを実現しているかというのは正直データを開けてみないと分かりません。そうしないと例えば、意図しない箇所で改行がかかり、ビューア上で組版が大きく乱れるなどといったことが起きてしまいます。まずこの元データ整理の部分の自動化はできないと思います。

 また、全般に「紙の本の組版をそのまま再現したい」という出版社サイドの要望が強く、これの対応も大変でした。正確な組版の対応は「ページの概念がない」リフロー型電子書籍ではどこまでいっても限界がありますし、当然できないことや「やらない方がいいこと」も沢山あります。それを出版社さんに説明し納得してもらうために、何故やらない方がいいのかを説明して、代わりの選択肢を箇条書きにして送って選んでもらうなど、かなり神経を使いました。

 校閲用のビューアに関しては、Kobo touchとReadium、Kinoppyを併用する形で制作を進めました。KoboとKinoppyで校閲を行った理由は、この二つのストアは当時すでに出版デジタル機構からのコンテンツ供給が確定していたからです。また、ビューアが当時もうかなり組版的に安定していたという事情ももちろんありました。他にはiBooksなども使っていましたし、社内での読み合わせ校正用としてはMurasakiからプリントアウトし、底本と引き合わせたりもしていました。

 また当時は、それぞれのビューアごとに表示が微妙に異なるといったようなことがあり、あるビューア向けに表現を追い込んでも別のビューアだと崩れてしまうといったようなことがありました。これはWebが辿ってきたのと同じ道だと思います。電書協ガイドはそういうビューア間の「方言」を吸収するために作られた側面があり、電書協や出版デジタル機構が各ビューア開発会社にガイドに沿った形でビューアの改訂を要請し、同時に制作者としてはこの電書協ガイドの仕様に沿ってコンテンツを作ることで近い将来にはほぼ全てのビューアで同じ表示が得られる、というのが緊デジでの電書協ガイド仕様採用の意図だったと思います。
 しかし、ビューア自体の改訂が緊デジの制作期間内に間に合うかと言えばそれは無理なわけで、校正者としてはどうしても目の前の、まだ表示が不完全なビューアの表示に引っ張られます。これはまあ仕方ないことだったかなとは思います。
 今は大分各ビューアの改訂も進んできており、まあ正直当時この状態だったらなと思わなくもないのですが、これはいわゆる「鶏と卵」的な話でもあるので、生みの苦しみ的な部分はやはりくぐる必要はあったのかなと思います。

 スケジュール的には当初は出版関連業における閑散期にあたる夏場に人数を割いての作業を想定していたのですが、結局冬場の繁忙期に完全に重なってしまったことが痛かったように思っています。

 EPUB3制作の流れのおおざっぱなまとめとしては、MC-B2のタグテキストをPerlでInDesignタグテキストに変換し、タグ付けを行ってXMLで書き出し、それをまたPerlで変換してXHTMLにし、自社制作ツールでOPFパッケージングファイル、目次ファイルなど必要なファイルを生成してEPUB3に、というような感じで制作を行っています。
 このあたりの流れについては7月に出展の決まりました電子出版EXPOでも展示を行っておりますので、ご来場の際はぜひお立ち寄りいただければ嬉しく思います。

 今後は印刷物の制作とも連携させたワークフローを整え、会社全体で効率良く電子書籍を作れる体制を整えたいと考えております。

(株)デンショク 営業部課長 石倉章晴さんセッション

 デンショクさんは私が所属していますJAGATの研究会でお世話になっている会社さんなのですが、もともとモトヤの関連会社で、InDesignでデータベース組版の仕組みを構築し医学書を中心とした制作を行われています。また、書籍だけではなく、同じデータベースからiPadや各種タブレット類へのアプリ制作などもされているとのことです。必ずしも一般販売される書籍だけではなく、病院内で医師や看護スタッフが利用するソリューションの提供がかなりの比重を占めるとのことで、こうしたマルチな展開はぜひ見習いたいところです。

 緊デジではドットブックとEPUB3の制作依頼、技術指導の依頼があり、主担当1名ほか、システム開発・タグ付け担当各1名で作業を行ったとのこと。
 元データは電算写植機データからのドットブック制作がかなりの冊数にのぼった他、EPUB3も6点ほど制作されたとのことでした。エディタとしては当初はFUSEeを検討したものの、結局Dreamweaverをメインに使ったとのことです。また、私の作ったスクリプト・アプリ類をかなりご活用いただいたとのことで、これは作成者として嬉しい限りです。

 制作時の問題点として、技術的には「確認したい箇所を底本から探す手間」を挙げておられました。これは大いに頷けるところです。元データがInDesignであればDTPデータをPDFに変換し、検索するなどの方法も考えられますが、もとが電算写植機のデータなどではちょっと方法が思いつきません。

 また、営業面での課題としては、Web制作会社なども電子書籍制作に進出してきていることなどからすでに電子書籍制作の値崩れが始まっており、効率を良くして人件費を落としても利益が出せそうにないことなどを指摘されており、これに対する対策として、「電子書籍技術を含めたビジネスモデルの開発」「会社における電子書籍の位置づけの明確化」「印刷物と電子書籍が効率的に制作できるワークフローの確立」などを挙げておられました。このあたりは大いに参考にしたいです。
 さらに、「非販売系書籍の電子化」も将来的には対象になってくるのではないか、と話されておられ、特定組織内でのみ流通する文書類や、役所などが無料配布する資料などの存在を考えると、確かに決して軽視できない分野であるように思いました。

(有)眺(ティアオ) 代表 野知潤一さんセッション

 九州で電子書籍制作の会社を営まれている野知さんのセッションです。電子雑誌トルタルにも参加されています。今回は私からお願いしてご登壇いただきました。
 電子書籍の制作には2001年から関わっておられ、最初はメディアワークスのライトノベルHPでの立ち読み版制作だったとのこと。縦書き、ルビ対応が必要だったため、当時その技術を持っていたボイジャーのソリューションを採用し、2年間で200冊ほど制作されたとのことでした。
 2003年には九州のシティ情報誌の文芸賞の電子化、2004年から始めた自社文芸サイトの作品をドットブックにして2005年から理想書店で販売、2007年には女性向け官能小説(ケータイ向け)などのお仕事をされていたものの、どれも大きな売り上げには結び付かず、iPhoneの上陸を機に現在の流れに至るとのお話です。

 緊デジでは九州の出版社に積極的に営業をかけたのですが、参加したのは海鳥社だけで当初は50〜70冊というような話だったものの、出版社サイドでの著作者への許認可に時間がかかり、最終的に16タイトルの電子化という話になったのが12月末とのこと。

 データ形式としては旧バージョンのEDICOLORデータがほとんどで、中国や九州の歴史ものが多く、文字コード外の地名・人名がたくさん出てくるもので外字対応に追われた他、ルビの点数がとても多く、大変苦労をされたとのことでした。外字に関しては、当初出版社から要望のあった形式が文字コードがShift_JISのドットブックだったため、文字コードがUTF-8のEPUB3なら外字化しないで対応できるJIS第3・第4水準の漢字まで外字画像化して対応せざるを得なかったとのお話でした。

 さらに画像が350点以上ととても多い本もあったとのことで、画像をコンテンツ内のどこに配置するかにかなり苦心をされたようです。
 現状EPUB3でも画像の回り込みの対応は十分とは言えず、どうしても文章が画像で寸断される箇所が出てしまいます。これは結局文字の拡大縮小ができる「リフローの利便性」「厳密な組版」がぶつかる部分なので、多分将来的にも完全な対応は難しいのではないかと思います。

 全てドットブックのコンテンツを納品したところで制作業務が終わったと思っていたところ、2月28日の時点で「EPUB3も作って欲しいという要望が判明」し、対応に大わらわだったとのこと。ここではドットブックからEPUB3への変換および、UTF-8で外字から外れる文字の非外字化が技術的課題になったようです。
 聞くだに大変なお話で、本当に苦労が忍ばれました。

 野知さんが語っておられたことで特に印象的だったのが、「単純に広く読者を獲得する目的でパブリッシュ(出版)するのなら無料のWebベースの方が、Kindle Direct Publishingのような有償コンテンツ販売よりも向くのではないか」という言葉で、さらに「パッケージで固め、値付けしたとたんに圧倒的に読者が減るのが大きな問題」とも言われていました。今後はブラウザベースでタテ書きでコンテンツを公開できる方向性を考えたいとのこと。

 私も現在のセルフパブリッシング(プチ)ブームがどこまで続くのかは少し疑問には思っており、まずWebベースで無料公開し、一定の人気を集めた後に有償コンテンツ販売に移行するというルートが定着する可能性は十分にあると考えています。

(株)シーティーイー 新規事業推進プロデューサー 鎌田幸雄さんセッション

 シーティーイーの鎌田さんのセッションです。鎌田さんもJAGATの研究会でお世話になっており、今回登壇をお願いしました。シーティーイーさんは43年の歴史を持つDTP制作会社とのことで、鎌田さんはQuarkXpress向けのAppleScriptをかつて積極的に発表され、著書も書かれている方とのこと。私は不勉強で知らなかったのですが、どこかでコードのお世話になっていたかも知れません。

 モリサワのMCBookを中心にし、現在MCBook、EPUB3の同時納品フローを構築しているとのこと。理由として、もともとシーティーイーはDTPの制作会社であり、会社全体としてCSSの知識は浸透していないことを挙げておられました。緊デジは主に価格面での判断で受注は見合わせたとのことで、現在月産50冊程度の電子書籍制作体制を構築しておられるそうです。

 DTPを中心とした制作会社にとってCSSの知識が壁になるのは私も痛感しているところで、緊デジが電書協ガイド仕様を採用した理由も「CSSがあらかじめ規定されているフレームワークだから」という部分が大きかったように思います(担当者が勉強すれば、という声も聞こえてきそうですが、「社内に一人詳しい人がいる」のと、「会社としてほぼ全員に一定レベルの知識が期待出来る」のは大違いです)。
 また、MCBookでのフロー構築は私も検討はしたのですが、鎌田さんのお話によると結局MCBookが電書協ガイド仕様のEPUB3書き出しにきちんと対応できたのは5月あたりだったとのことなので、これは見送って正解だったようです。

 出版社さんとあらかじめ相談して作り方を規定し、異体字はMCBookの機能で対応、現在WordからMCBookへのフローも構築しているとのこと。人員としては管理スタッフは2名ほどに留め、制作自体は単価の安い地方で行っているとのお話でした。
 また、最近は電子と紙の同時発行の依頼が増えているとのことで、今後増えてくるタイトな制作スケジュールに対応するために、DTPも含めたデータ作成のあり方を考えておられるとのことでした。

 とても興味深かったのは、MCBookは結局プロプライエタリ(特定メーカー依存)のツールなため将来的に継続してのコンテンツ制作のベースにするにはコピー&ペーストができないなどの問題点もあり、IDML経由でのコンテンツ制作を考えているとのお言葉です。
 IDMLはInDesignから書き出せる互換ファイル形式の一種で、通常はCS5→CS4など下位バージョンへの互換目的などで使用します。これはZIPパッケージ内にXMLが収められているもので、一応原理的には全ての要素をXMLで書き出すことが可能です。ただし、あまりに複雑すぎるため、私などはこれをハンドリングすることは早々にあきらめ、InDesign内でXMLタグを付加し、書き出して変換する方法を選びました。もしIDMLから変換してEPUBを制作できるのであれば、タグを付加する手間を省くことができ、かなりの省力化が期待出来るのではないかと思われます。

 以上、セミナーのまとめでした。長文にお付き合いいただきありがとうございます。この後質疑応答も行われたのですが、いささか長くなりすぎましたし、私自身が登壇者で詳細なメモは取れていませんので、省略させていただきます。今回会場には深沢さん、沢辺さんをはじめ、緊デジ制作でお世話になった方々もご来場いただき、活発な質問も飛び交いました。これを機会として、リアル、ネットを問わず活発な議論が継続して行われるようであれば、これに勝る喜びはありません。

 ご来場いただいた方々、本当にありがとうございました。

(2013.6.28)

緊デジ(電書協)仕様のリフロー型EPUB3を作ってみる

2012/12/03

 AmazonのKindleストアもついに日本展開を開始し、Google Play Booksもサービス開始するなど、いわゆる「黒船」陣営も軒並み出揃ったことで、ついに本当の意味での「電子書籍元年」が始まった感があります(Apple iBookStoreが未だにロールアウトしないのが気になるところではありますが)。こうした中でpubridgeと紀伊國屋書店、楽天koboとの電子書籍配信・販売合意が発表され、緊デジ事業で制作されたコンテンツの提供先も確定しました。これから先も次々に提供先が増えていくことになるのでしょうか。

 緊デジ仕様のEPUB3は、まだ校正用ビューア等の仕組みが発表されていないため正式には制作開始前の状態ですが、「電書協EPUB3制作ガイド」に準拠するという方針は発表されており、「緊デジ版EPUB3テンプレート」も発表されているため、既に制作自体は可能です。

 ということで、以下は緊デジ仕様のリフロー型EPUB3コンテンツ制作の具体的な流れです。あくまでまだテスト段階ではありますが、ご参照いただければ幸いです。

1 本文用のXHTML/CSSファイルを準備する

本文用のXHTML/CSSファイルを準備

本文用のXHTML/CSSファイルを準備

 本文用のXHTML/CSSファイルを準備します。私は今回、テキスト部分に関しては以前のエントリで発表させていただいたInDesignでXMLのタグ付けをしてXMLを書き出し、Perlで変換する方法でXHTMLファイルを制作しましたが、これは印刷用データからの変換を前提としたワークフローですので、もとがテキストデータであれば初めからDreamWeaverなどweb系のツールを利用したほうが効率は良いかと思います。XHTMLファイルのタグ付けルールは前述の「緊デジ版EPUB3テンプレート」及び準拠している「電書協EPUB3制作ガイド」に従います。

 画像のみで1ページのページに関しては、「kinidigi_reflow_template」内の「p-005.xhtml」(1ページ画像テンプレート)を元に、タイトル、ファイル名、alt(代替名称)を書き換えてファイルを準備します。

 「電書協EPUB3制作ガイド」は基本的に紙書籍の電子化を目的としたガイドラインで、印刷データや.book、XMDFといったレガシーフォーマットからの変換を念頭に置いているものと思われ、全体的に現在もしくは近い将来に各ビューアが実装可能なプロパティだけに絞り込んだ、かなり保守的な仕様です。そのため電子ならではのインタラクティブな表現などはほとんど期待できませんが、その分ビューアの側の表現の揺れなどはそこまで気にしなくても良さそうな印象があります。緊デジ用EPUBに用いるためのXHTMLファイルは、この「電書協EPUB3制作ガイド」に従い、基本的に支給されたCSSファイルの記述を利用する形で制作します。通常書籍で必要とされる表現はほぼ網羅されていますので、書籍(文章もの)のコンテンツであればほぼ事足りるものと思います。自分でclass名を定義する必要はほとんどありません。

見出しid番号を連番で振っておく

見出しid番号を連番で振っておく

 もし、各作品ごとにCSSの追記が必要な場合は、必ず「book-style.css」内の作品別カスタマイズ領域内に記述します。その場合でも電書協ガイド(17ページ)で規定されている「RSによる対応を想定するHTML 要素とCSSプロパティ」の範囲内での記述に留める必要があります。

 本文用のXHTMLファイルは最終的に「p-001.xhtml」「p-002.xhtml」といった形で連番のファイルにリネーム※1し、目次に表示させたい見出しには「id="toc-001"」といった形でユニークな見出し番号を振っておきます。なお、IDの属性番号は1文字目は必ず英文字である必要があります。これはXHTMLを含むXMLの属性名命名規則の縛りです。数字は2文字目以降にしか使用出来ませんので念のため(私は一度やらかしました)。

2 カバー/注意書き/奥付/本扉などのXHTMLファイルを準備する

テンプレートをコピーし、書き換える

テンプレートをコピーし、書き換える

 「緊デジ版EPUB3テンプレート」のファイルをコピーし、書き換える形で、カバー/注意書き/奥付/本扉などのファイルを整えます。

 カバー「p-cover.xhtml」は、タイトル名を書き換え、イメージファイルのalt領域にタイトル名を記述すればOKです。カバーに用いる画像ファイルは「cover.jpg」の名前で準備しておいてください。

 電子化にあたっての注意書き「p-caution.xhtml」は、タイトル名と縦/横の記述を書き換えればOKです。

 奥付は通常、電子化クレジット「p-credit.xhtml」と、底本奥付(テンプレートの「p-006.xhtml」を参照)の2種類が必要です。電子化クレジットは各出版社から支給されるデータをもとに入力することになります。底本奥付は画像を用意し、タイトル名とファイル名の連番(p-xxx.xhtml)、目次用のid番号を書き換えればOKです。底本奥付用の画像ファイルは「original_credit.jpg」の名前で準備しておいてください。

 本扉「p-titlepage.xhtml」も基本的には画像ページでOKですが、出版社からの指定があった場合はテキストで準備することになります。画像の場合はテンプレートの「p-005.xhtml」(1ページ画像テンプレート)を元にファイルを整えます(ファイル名は「p-titlepage.xhtml」にリネーム)。テキストの場合はテンプレートの「p-titlepage.xhtml」を書き換えてください。

 書き換えが必要な箇所は、「電書協EPUB3制作ガイド」(26ページ〜)に色文字で示されています。ご参照ください。

3 作成した各ファイルをEPUB圧縮用のフォルダにまとめる

 「kinidigi_reflow_template」のフォルダをまるごとコピーし、フォルダ名をリネームしてから、作成したXHTMLファイルを「xhtml」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKですが、次のステップで「OPFパッケージファイル生成アプリ(緊デジ用)」を使用する場合は、「p-toc.xhtml」はそのまま残しておいて下さい(名前の抽出用です)。画像ファイルは「image」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKです。

4 OPFパッケージドキュメントを準備する

ファイルごとの見開き表現の有無を記述

ファイルごとの見開き表現の有無を記述

 OPFパッケージドキュメントを準備します。OPFパッケージドキュメントは、書誌情報やユニークIDの記述、EPUBパッケージ内に収納する全ファイルの登録、コンテンツの並び順や右綴じ/左綴じの規定、見開き表現の有無などを規定するもので、電書協ガイド/緊デジのテンプレートでは「standard.opf」の名称で規定されています。基本的にこのファイルを書き換えることになります。なお、このファイル名は「META-INF」フォルダ内の「container.xml」に登録されていますので、変更するとEPUBファイルとしてパッケージングができなくなります。

 今回私は、以前のエントリで発表済の「OPFパッケージファイル生成アプリ(緊デジ用)」を使用してOPFパッケージドキュメントを準備しました。image/xhtmlの登録作業や書誌情報やユニークID入力補助を目的としたアプリです。なお、このアプリを利用した場合でも、ファイルごとの見開き表現の有無(spine項目内「properties="page-spread-left"」記述部分)は手動で書き換える必要があります。
 ちなみに緊デジ仕様のEPUBでは、ユニークIDにJP-eコードを用いる部分が電書協ガイドのそれとは異なります。もし上記アプリを用いて緊デジ仕様以外のEPUBを制作する場合は、JP-eコードはuuid等に置き換える必要があります。

5 目次(p-toc.xhtml)ファイルを準備する

目次ファイルを準備する

目次ファイルを準備する

 目次ファイル「p-toc.xhtml」を準備します。なお、ここで言う目次ファイルは本文内にページとして表示される目次ファイルです。リーディングシステム内メニュー表示用の目次ファイルは「navigation-documents.xhtml」ですが、こちらには「表紙」「目次」「電子化クレジット」のみが登録され、緊デジでのEPUB3制作では通常書き換える必要はありません。この「p-toc.xhtml」も「OPFパッケージファイル生成アプリ(緊デジ用)」で自動抽出が可能です。ただし、目次は各書籍ごとに底本の体裁が異なるため、いずれにせよ後から細かな部分の編集は必要と思われます。

 目次のリンクの確認は、ファイルをSafari/Chrome等のブラウザで開くことで行うことができます。目次に限らず体裁の確認は、実際にEPUB圧縮するのと同じ構成のフォルダにXHTMLファイルを収納した上で、ブラウザで行うのが便利です。

6 EPUB圧縮を実行する

epub packagerを用いたepub圧縮

epub packagerを用いたepub圧縮

 OPFファイル、目次ファイルを上書きし、EPUB制作に必要な全てのファイルが整ったところで、EPUB圧縮を実行します。macで作業をしている場合は、フォルダ内の不可視ファイル「.DS Store」を除去する必要がありますので、まず「Ds Store Remover」にEPUB圧縮するフォルダをドラッグ&ドロップし、「.DS Store」を除去します(同種のアプリは複数あるようです)。

 その後、実際にEPUB圧縮を行います。ターミナルでコマンドを打ち込んで圧縮することも出来るのですが、私は普段「epub packager」を利用しています。ドラッグ&ドロップで圧縮できるので便利です。

7 エラーを修正する

epub Checkerでバリデートチェック

epub Checkerでバリデートチェック

 epub内のエラーを修正します。xhtml内idの二重登録、画像ファイル名の記述ミスなど、epub制作には間違いは付き物です。これをチェックし、全てのリーディングシステムできちんと表示されるepubを制作するために、バリデータでepubをチェックする必要があります。

 前出の「epub packager」では、epub作成時にバリデートもしてくれるのですが、実際にどういった部分に問題があったのかまでは表示してくれませんので、「Not Valid」と表示された場合は、バリデータでepubデータをチェックし、エラー部分を修正する必要があります。私は同じ会社から出ているアプリ「epub Checker」に、生成されたepubをドラッグ&ドロップし、バリデート作業を行っています。これはIDPFのepubcheckを内部的に利用したGUIアプリですが、epubcheckに関してはIDPFからCUI版のコマンドラインツールも配布されていますので、Windowsなどの環境でもそちらを利用してバリデート作業を行うことができます。epubcheckのエラーメッセージについては、前エントリ「IDPFのバリデータに叱られてみた」をご参照ください。

 全てのエラーを修正し、バリデータをノーエラーで通過できれば、epubファイルはひとまず完成です。

※1 電書協ガイドでは、ファイル名/id番号共に版元ごとに変更可能な項目として指定されていますが、本エントリではサンプルコンテンツの表記に従って「連番」としています。項目があまりに多数に及ぶ場合など、修正がしやすいような命名法を採用しても特に差し支えはありません

(2012.12.3)

 ファイル名/ID名の命名方式に関してご指摘をいただきましたので、追記いたしました。

(2012.12.10)

OPFパッケージファイル生成アプリ(緊デジ用)を公開します

2012/10/25

uuid自動生成、kindle用パラメータ入力に対応した新バージョン『電書協EPUB3用OPFファイル生成 2.0』をリリースいたしました。どうぞご利用ください。

 EPUB3をゼロからハンドコーディングで制作するにあたって比較的敷居が高いと思われるのが、パッケージファイル(opfファイル)の作成です。すでにご存じの方も多いかと思いますが、EPUB3はおおざっぱに言ってWebの標準技術であるXHTML(HTML5)とCSSを用いて制作したドキュメントをZIP形式で圧縮したものですが、含まれる画像やXHTML文書などの各種ファイルはパッケージファイルに所定の形式で記載しておく必要があります。また、ページの並び順や綴じ方向、出版社名や著者名などの各種書誌情報も全てパッケージファイルに記述しておかなければなりません。

 先日発表された電書協EPUB3制作ガイドでもこのパッケージファイルの記述方法はきちんと規定されており、このガイドの仕様を採用した緊デジでのリフロー型EPUB3制作でも、当然きっちりと規定通りにパッケージファイルを記述する必要があると思われます。これは慣れない人間にとってはXHTMLやCSSの記述以上に取っつきにくい作業になりそうで、電書協EPUB3制作ガイドで書き換えの必要な箇所を色分けして指示しているとはいえ、入力時の間違いが多発しそうな感じはあります。
 私の所属している会社でもこれは当然他人事ではありませんので、間違いのない記述を行うために専用の入力フォームアプリを制作し、対処することにしました。こちらを今回公開させていただきますので、制作時の役に立てていただければ幸いです。

仕様・ダウンロード

アプリ名:OPFファイル生成(緊デジ用)
対応環境:Mac OS 10.4〜10.8
動作チェック済環境:Mac OS 10.5(PowerPC)/Mac OS 10.6/Mac OS 10.7

入力画面
※ビルド自体はMac OS 10.4までをターゲットにIntel/PowerPC両環境を対象としたユニバーサルバイナリ対応で行っていますが、当方にテスト環境がないためOS 10.4での起動チェックはできていません。おそらくOSにプリインストールされているperlのバージョンにも依存します。

※Mac OS 10.8でのチェックも出来ていないのですが、10.8には「Gatekeeper」という非登録デベロッパのアプリを実行出来なくするセキュリティ機能が搭載されているため、おそらくデフォルトの設定では起動できません。「システム環境設定」→「セキュリティとプライバシー」で「Gatekeeper」の設定をオフにすれば起動できるかと思います。将来的には対応を検討中です。

※こちらのアプリは、電書協EPUB3制作ガイド_ver1.1及び、緊デジテンプレート(2012年10月22日発表版)の仕様に沿って制作されたリフロー型EPUB3コンテンツ専用のOPFパッケージファイル作成アプリです。他の形式のEPUB3コンテンツ制作に使用していただくことは可能ですが、ファイル構成、パス指定などは異なっている可能性があり、それぞれのケースにあわせて書き換える必要があります。あらかじめご了承ください。また、こちらのアプリを利用したことによって生じた損害等に関しまして、私として一切の責任は負いかねますので、あくまで自己責任でご利用ください。

>>OPFファイル生成(緊デジ用)ver 1.2.3 ダウンロードはこちら

※ダウンロード先を私の所属する会社のホームページ内ダウンロードコーナーに移動しました。内容の改訂等は行っていません。

>>電書協EPUB3用OPFファイル生成ver 2.0 ダウンロードはこちら

※uuid自動生成、kindle用パラメータ入力(kindlegen2.8にて検証済)に対応した新バージョンです。

使い方

page-spread-left指定

page-spread-left指定

 画面上の各項目を入力もしくは選択し、「OPF生成」のボタンを押せばファイルの出力先を尋ねるダイアログが出ますので、保存先を指定すればそちらに「standard.opf」の名称でOPFファイルが出力されます。簡単です。なお、画像フォルダ及びXHTML文書の収納フォルダはフォルダ名を取得してパスに組み込みますので、実際にEPUB内に収納するものと同じフォルダを指定してください。CSS及びナビゲーション文書は電書協EPUB3ガイドの仕様に従ってファイル名・パス共に決め打ちで出力します。EPUB3圧縮時には、規定の場所にそれぞれのファイルを配置しておくようにしてください。

 出力後、OPFファイルをテキストエディタで開き、以下のポイントをチェック・修正してください。

  1. 改行コードは「CR(Mac)」で出力されます。電書協EPUB3制作ガイドでは、パッケージ内の各文書の改行コードを統一することを推奨していますので、必要であれば修正してください。
  2. 全てのXHTMLドキュメントを見開き時片ページ始まり指定で出力します。出力された「standard.opf」ファイルの「<spine>」指定内、各「<itemref〜」行末尾の「properties="page-spread-left"」(左綴じではpage-spread-right)記述部分がそれに相当します。各XHTMLドキュメントの内容を確認し、片ページ始まりが必要なければこの部分の記述を削除してください。
  3. 「<itemref〜」行のファイルの並び順は、EPUB文書としてのページングの順番に相当します。ファイルの並び順を確認し、必要であれば入れ替えを行って下さい。
  4. 緊デジでのコンテンツ制作以外の目的でこちらのツールを利用する場合、JP-eコードに関する部分の記述をuuid等に差し替える必要があります。JP-eコードはそれぞれの電子書籍に対して与えられるユニーク値ですので、JP-eコードを適当に入力した電子書籍を配布することは絶対に避けてください。uuidの生成に関してはこちらが参考になります。また、ヘッダ行にもJP-eコードに関する記述がありますので、記述を変える必要があります。電書協ガイドに沿ったコンテンツ制作の場合は、電書協ガイドのサンプルのヘッダ部分の記述を引き写せばOKです。
    →uuid自動生成に対応した「電書協EPUB3用OPFファイル生成 2.0」をご利用ください。

 なお、電書協EPUB3制作ガイドでは、カバー、本文など各文書に用いるXHTMLのファイル名をきちんと規定しています。電書協EPUB3制作ガイドおよび緊デジテンプレートの記述の規則に従ってファイル名が付けられていた場合、こちらのアプリが自動で望ましいと思われる順番に文書を並び替えて出力します。規則から外れていたファイルについては、「<itemref〜」行末尾にシステムのソート順に従って記述されます。外字ファイルなどの命名規則もこれと同様です(緊デジテンプレートの記述規則に従います)。

 電書協EPUB3制作ガイド/緊デジテンプレートのXHTMLファイル名命名規則は現状、以下の通りです。

  • カバー:p-cover.xhtml
  • 前付け:p-fmatter-00x.xhtml(連番) ※1
  • 本扉:p-titlepage.xhtml ※1
  • 電子化注意書き(底本組方向の記述):p-caution.xhtml ※1
  • 目次:p-toc.xhtml ※1
  • 本文:p-00x.xhtml(連番)
  • 底本奥付:p-colophon.xhtml
  • 広告:p-ad-00x.xhtml(連番)
  • 電子化奥付:p-credit.xhtml
  • 白紙ページ:p-white.xhtml(連番になるパターンもあり) ※2

また、特にファイル名を規定しているイメージファイルは以下の通りです。

  • カバー:cover.jpg
  • 底本奥付:original_credit.jpg ※1
  • 外字:cid-xxxxx.png(Adobe-Japan 1のCIDコード番号を指定)※1
  • 底本奥付:i-colophon.jpg ※2
  • 電子化奥付:i-credit ※2
  • 本文ページ:i-xxx.jpg(連番) ※2
  • 白紙ページ:i-white.jpg(連番になるパターンもあり) ※2

※1 リフロー型のみ  ※2 フィックス型のみ

 緊デジでのリフロー型EPUB制作では、本文用のXHTMLを作り、画像を整えてOPFパッケージファイルを生成するところまで出来てしまえば、あとはテンプレとして支給されるCSSを割り当て、カバー、目次、クレジット等のテンプレHTMLを書き換える程度の簡単な作業でEPUB3は作れます。

(2012.10.25)

 @lost_and_foundさんのご指摘をいただき、「役割(role)」のドロップダウン項目リスト内容及びヘルプ文書を修正しました。

(2012.10.25追記)

 左綴じコンテンツ出力時のパラメータが「ltl」となってしまっていたのを「ltr」に修正しました。また、image/xhtmlフォルダ未選択時のエラーメッセージを追加しました。

(2012.10.26追記)

 緊デジフィックス型EPUB3用のOPFファイル出力に対応しました。「EPUB3のタイプ」トグルボタンでリフロー/フィックスの選択ができます。

(2012.11.1追記)

 緊デジリフロー型EPUB用の目次用xhtmlファイル「p-toc.xhtml」の同時生成に対応しました。事前に各見出し要素にid属性を付加しておく必要がありますが、目次ファイルを自動生成します。

(2012.11.5追記)

 タイトル名・著者名等に半角スペースが含まれていた場合に正常にファイルが出力されない問題、目次ファイルが正常に出力されない場合があった問題などに対処しました。

(2012.11.19追記)

 章扉が画像のパターンに対応しました。

(2012.11.26追記)

 「電書協EPUB 3 制作ガイド(Ver.1.1.1)」の公開に伴い、緊デジテンプレートも修正されましたので、これに対応する修正を行いました。メニュー選択でver1.1.1とver1.1を選択して出力できます。他、タイトル名に半角スペースが含まれていた場合に正常にファイルが出力されない問題の修正を行いました。
 なお、この更新に伴う修正点は、「ebpaj:guide-version」のバージョン番号表記(1.1→1.1.1)、フィックス型出力時のfallback記述の削除の2点です。

(2012.12.17追記)

ダウンロード先を私の所属する会社のホームページ内ダウンロードコーナーに移動しました。内容の改訂等は行っていません。

(2012.12.25追記)

ファイルIDのuuid自動生成対応、Amazon kindle用mobiファイルの自動生成に新たに対応した新バージョン「電書協EPUB3用OPFファイル生成 2.0」を公開いたしました。

(2013.4.4追記)

「電書協EPUB3用OPFファイル生成 2.0」のメニュー及びアラートの「〜読み(カタカナ)」を、「〜カナ(整列用)」のような表記に修正しました。機能的な変更点はありません。変更を適用した最新バージョンは2.0.1です。

(2013.5.9追記)

「電書協EPUB3用OPFファイル生成 2.0」で、リフロー型、Kindle対応の場合に出力されるOPFファイル中文内の表紙ファイルのリンク先を「cover.jpg」から「p-cover.xhtml」に修正しました。これはEpubCheck3.0.1でエラーが出力されることに対応したものです。変更を適用した最新バージョンは2.0.2です。

(2013.6.27追記)

「電書協EPUB3用OPFファイル生成 2.0」で、フィックス型、Kindle対応の場合のオプション「画面ロック方向を指定」で「縦長画面」を選んだ際に設定が反映されなかった問題を修正しました。変更を適用した最新バージョンは2.0.3です。

(2013.7.8追記)

「電書協EPUB3用OPFファイル生成 2.0」で、GIF形式のファイルの処理に対応いたしました。変更を適用した最新バージョンは2.0.4です。

(2013.8.22追記)

プロフィール
Jun Tajima

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

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

最近のコメント