月別アーカイブ: 2012年11月

KindleGen のSVG変換　奇妙な動作にはまる

投稿日時: 投稿者:
返信

CAS-UBで作成したEPUBをKindleGen[1]でmobi形式に変換する処理の確認をしていたところ、Kindle Paperwhiteで表示されない画像があることに気がつきました。

何が起きているか、DRMのかかっていないmobiファイルをアンパックするツールMobi_unpack[2]を使って調べてみました。

結果を整理すると、次のようになります。

１．KindleGenでEPUBからmobiに変換すると、出来上がったmobiファイルの中には、mobi7とmobi8（KF8）形式の両方がひとつにパックされています。

画像について次のような処理を行なっています。
２．JEPGはそのまま両方にコピー

３．PNGはGIF形式に変換して、両方にコピー

４．問題はSVGです。もとのEPUBでは、SVGを<img src="SVGファイルへのパス" …/>として外部オブジェクトとして指定しており、SVGファイルの実体はimagesフォルダの中にあります。これをKindleGenで変換すると次のようになります。
(1)mobi7ではSVGがすべて削除されてしまいます。つまり古いKindleではSVGはまったく表示できないということになります。
(2)mobi8の中をみますと、EPUBと同じ方式でそのままコピーされているケースと、<p><svg xml…>….</svg></p>のように埋め込みになってしまうケースの2種類があります。そして、埋め込みにされたSVGがKindle Paperwhiteで表示できません。

５．そのまま複製されるSVGと埋め込み処理されてしまうSVGに、SVGの仕様からみて何かの違いがあるか、ということを調べたのですが、いまのところまったく相違点がわかっていません。

たとえば、次の二つのSVGファイル（ok.svgとng.svg）ですが、ok.svgは表示できますが、ng.svgは表示できません。この二つのSVGファイルは、ok.svg の途中に <!– xxxxx –>を入れて保存したのがng.svgです。コメントを一つ挿入しただけで表示できなくなってしまう、というわけです。

●データ　
a. ok.svg
b. ng.svg
c. EPUB3
d. mobi

KindleGenのバグではないかと思いますが、どうなんでしょうか。

[1] Kindlegen Windows版・バージョン2.7を使用
[2] Movi_unpack

EPUBのベストプラクティス　カバー画像の登録方法

投稿日時: 投稿者:
返信

多くのEPUBリーダーでは登録されている書籍のアイコンとしてカバー画像を表示します。このカバー画像の登録方法を調べてみました。

１．EPUB2
EPUB2ではカバー画像であることをEPUBリーダに伝えるために、metadateのmeta要素に次のように指定します。

【EPUB2の例】
metadata
<meta name="cover" content="cover-id" />

なお、manifestには、次のようにカバー画像に使用する画像ファイルが登録されていることが前提です。（metaのcontentの値とitemのidの値は一致していること。文字列は可変。）
manifest
<item id="cover-id" href="cover.jpeg" media-type="image/jpeg" />

２．EPUB3
EPUB3では、上の形式のメタデータは廃止されました。ただし、EPUB2のリーダ用との互換性のためにこれを残しておくことができます。そして、EPUB3リーダはmetaの方を無視しなければなりません。[1]

EPUB3の仕様では、manifestのitem要素のproperties属性に「cover-image」という値を指定することでカバー画像であることを示します。EPUB3の方がシンプルになったわけです。

EPUB3では、例えば、cover.jpgというファイルがカバー画像であることを示すには次のように指定します。（idの値は可変）。

【EPUB3の例】
<item properties="cover-image" id="ci" href="cover.jpg" media-type="image/jpeg" />

koboやiBooks3などの新しいEPUB3のリーダは、manifestのitem要素の属性を見ています。

３．Kindle
Kindleは、カバー画像をmetaとitem要素の両方に指定することになっています。

カバー画像を、仮に、id=”cover-id”、ファイル名=”cover_image.jpg” とするとき、Kindleは次のように登録します。

【Kindleの例】
metadata
<meta name="cover" content="cover-id" />

manifest
<item id="cover-id" href="cover.jpg" media-type="image/jpeg" properties="cover-image"/>

４．まとめ
ややこしい話ですが、EPUB3にEPUB2形式のmetaがあっても特に害はないようなので、両方登録しておくとEPUB2/EPUB3で共通になりますので都合が良いと思います。

なお、EPUBの場合、印刷製本した書籍と異なり、①EPUBリーダの書架または書籍一覧に表示されるアイコンとしてのカバー画像、②リーダで表示するときの先頭ページ、③iBooksのように見開き表示したときに初めて表示される画像ページなどの役割が明確になっていません。このあたりについては別途まとめてみたいと考えています。

５．追加：EPUBリーダの実装

iBooks3.0、Readium(0.5)、Adobe Digital Editions2.0では、上記のmetaとmanifestのitem要素の両方に画像を登録しないでも、先頭のxhtmlファイルの内容としてimg要素に画像ファイルを指定すると、書架アイコンにその画像が登録されます。つまり、これらのリーダを対象にする場合はmetaにもmanifestにもカバー画像を登録する必要がなく、先頭のxhtmlページをカバー画像のページとすれば良いことになります。（2012/12/8追記）

６．訂正：Kindle
(12/15）Kindleでは、itemのproperties属性はつけない。つまり、EPUB2方式でした。

[1] 3.4.8 The meta Element (OPF2) [OBSOLETE]
[2] Amazon Kindle Publishing Guidelines
[3] Amazon Kindleパブリッシングガイド（Appendix）日本語サポート

EPUBのベストプラクティス　EPUB2用の目次NCXの出力はまだ必要か？

投稿日時: 投稿者:
返信

EPUB2では、目次にNCXという形式のファイルを使っていました。NCXはDAISY Consortiumによって標準化されたANSI/NISO Z39.86-2005, Specifications for the Digital Talking Bookという仕様の一部です[1]。

EPUB3では、NAV形式のXHTMLファイルを目次に使うことになっており、NCX形式の目次をEPUB2のリーダのために含めておいても良いことになっています[2]。

したがって、EPUB3リーダ専用のEPUBであればNCXを含む必要はありません。そこで、最近アップデートされたEPUB3リーダを対象として、NCXとNAV形式の両方の目次をもつEPUB3とNAV形式の目次のみ（NCXを含んでいない）もつEPUB3を作って、目次が表示されるかどうかについて比較してみました。

結果は次の表のとおりです。

(1) iBooks3.0、Kobo、ReadiumはNAVの目次を表示します。NCXの目次は必要としません。
(2) Adobe Digital Editions 2.0は、NCXの目次がないと目次が表示されないようです。
(3) なお、KindleのKF8形式については、「Kindle Publishing Guide」ではNCXが必須とされており、HTML形式の目次も必要とされています。実際の結果は後述の「Paperwhiteでの確認結果」をご覧ください(11/25追記）。

ということで、まだNCXを全廃というわけにはいかないようです。

表１　NCXとNAVの両方を含むEPUBと、NAVしか含まないEPUBの目次はどうなるか？

NCXとNAV NAVのみ
Readium 0.5 表示する 表示する
Adobe Digital Editions 2.0 表示する 表示しない
iBooks 3.0 表示する 表示する
Kobo 2.1.4 表示する 表示する
Kindle 2.71 NCXは必須と説明されている XHTMLの目次が必要とされている

表示する：目次が表示されるという意味。
表示しない：目次が表示されないという意味。

●Kindle Paperwhiteでの確認結果

１．NAVのみでNCXが存在しないEPUB3をKindleGen(2.7)でmobiに変換すると、「移動」メニュー「表紙」と「最後のページ」の間にグレー（無効）の「目次」が表示されます。NAVの内容は無視されているようです。
２．NAVとNCXと両方が存在するEPUB3をKindleGen(2.7)でmobiに変換すると、「移動」メニューの「表紙」と「最後のページ」の間に目次項目が表示されます。
３．１．と２．からKindle Paperwhiteは、NCXの内容を「移動」の目次項目として表示していることがわかります。
４．HTMLの目次[3]は、「表紙」の次の単独ページに表示されます。さらにHTMLの目次ページをガイドに登録すると「移動」の目次としても使われます。（ガイドの内容が「移動」の目次に表示されるのであれば、HTML形式の目次を用意した場合、NCXの目次は不要なのかもしれません。）

図１　HTML目次

図２　移動メニュー　（頁の上部にポップアップ）

図３　「移動」メニューの内容

[1] Open Packaging Format (OPF) 2.0.1 v1.0.1 Recommended Specification September 4, 2010
[2] EPUB Content Documents 3.0 Recommended Specification 11 October 2011
EPUB Navigation Documents
[3] CAS-UBのKindle生成メニューでは、EPUB3のNAV.htmlにスタイルシートを設定して、HTML形式の目次として作成し、先頭ページに登録します。

EPUBのベストプラクティス　linear=”no” のこと

投稿日時: 投稿者:
返信

EPUB2のベストプラクティスに、先頭ページに表紙（カバー）画像を登録して、spine要素のitemrefにlinear=”no”を設定せよ、という、つぎのようなものがあります。

Best practices in ePub cover images

ここでは、表紙のHTMLファイルを作り、manifestに次のように設定：
<item id="cover" href="cover.html" media-type="application/xhtml+xml"/>

そしてspineに
<itemref idref="cover" linear="no"/>

と設定せよとあります。しかし、これは採用できるでしょうか？

１年半程前（2011年春）、表紙をどうしようかと思案して、EPUBリーダの挙動を調べました。
しかし、iBooks2ではlinear=”no”を指定したページを表示するが、Adobe Digital Editionsの旧バージョン（1.5だったような）では、linear=”no”を指定したページを表示しない、という挙動の相違があったため設定を見送っていました。

最近、EPUBリーダが新しくなりましたので、何か変わったかと思い、もう一度調べてみました。次のようなコードのEPUBで試してみました。

manifest：
<item href="Text/opening.html" id="idopening" media-type="application/xhtml+xml" />

spine：
<itemref idref="idopening" linear="no" />　
（linear=”yes”版）も用意。

●linear=”no”とlinear=”yes”（既定値）とでEPUBリーダの表示を比較した表

linear="no" linear="yes"
Readium 0.5 表示しない 表示する
Adobe Digital Editions 2.0 表示する 表示する
iBooks 3.0 表示しない 表示する
Kobo 2.1.4 表示する 表示する
Kindle 2.71 表示しない 表示する

となり、やはり、EPUBリーダによって挙動がまちまちです。

先日、電流協のEPUB研究会で、このことを報告しましたところ、参加者の方から次のようなコメントをいただきました。

・linear=”no” は本文のページとして表示しない内容に対して使うもの。注釈のようなもの。順番にめくっていっても表示されない。ページとして扱わないものに設定するのだろう。

ところでEPUB3仕様におけるitemref要素のlinear属性についての説明は次の2箇所にしかありません。

3.4.13 itemref要素より抜粋

linear属性は参照された項目が主要素なのか付随要素なのかを示す。これによりRSは本体コンテンツの表示を補足コンテンツと区別するために使っても良い。後者は、例えばポップアップ・ウインドウにしたり、音声レンダリングで省略したりされるかもしれない。

3.14.12 spine要素より抜粋

RSは、spine中の先頭にある主項目（linear=”yes”)を出版物の主たる閲読順序の始まりとする。そして、spineの中の主項目を順番に可視化する。

説明もサンプルも少ないので、これでは解釈統一のしようがないように思えますね。困ったものです。

ある方からEPUB2.0では、guide機能があって、guideに登録することでlinear=”no”を指定したページにもジャンプできたが、EPUB3.0でguideが廃止されてしまったためlinear=”no”を指定したページを表示する方法がリンクぐらいしかなくなっているという指摘をいただきました（11/22追記）。

DITA Europe 2012 の第一印象

投稿日時: 投稿者:
返信

11月12日～13日の2日間、フランクフルトで開催されたDITA Europe 2012[1]に参加しました。前回2008年11月にミュンヘンで開催されたときに参加しましたので、DITA Europeは二回目です。

4年ぶりということで、下記に前回との違いを第一印象だけメモしておきます。今回の参加はDITA コンソーシアムジャパンの派遣視察団としての参加ですので、あまり詳しい話を書いてしまうのも問題。ということで詳しい報告は次回のDITA Festa 2013（2013年2月上旬開催予定）で行ないますので、ご期待ください。

で、昔のブログを調べましたが、どうもミュンヘンのレポートはビールを飲みにいった事ぐらいしか載っていません。前回の話は、記憶をたどっていますので、偏りがあるかもしれないですが。

１．参加者は前回より少し増えたような気がします。前回の冒頭講演はNokiaの方でしたが、今回もNokiaです。但し、部署が違っているようです。NokiaのDITAを採用する部署が増えているようなことを言っていました。

２．前回の発表では、DITAを使ったプロトタイプのシステムの報告がいくつか見られました。しかし、今回はプロトタイプの話は（私の聴講した中には）見当たらず実際に運用している報告のみでした。もう、プロトタイプを作ったというレベルでは、こうした専門のカンファレンスでの報告ネタにはならないということだと思います。
運用例も、製造業のマニュアル制作のみでなく、ヘルスケア分野とか、医薬品情報提供などの分野が報告されました。それだけ実用の幅が広がってきたということなのでしょう。

３．前回はマニュアルを中心に多言語化のコストダウンという話が目に付きました。しかし、今回はあまりそういう話はなく、再利用（Re-use）が大きなキーワードになっています。その再利用も、トピック単位だけではなくて、Conrefや、DITA 1.2で導入されたKeyref[2]などを利用して再利用性を高める例の報告が目立ちました。こうした技術的な報告が半分以上を占めていたようですが、このあたりはプレゼンの内容をもう少し詳しく調べる必要があります。

４．DITA 1.3の仕様開発が既に始まっています。DITA 1.3では機能を追加する案（ほしい機能を追加していく）と、もっと単純化しようという案もでています。両方とも妥当な意見と思いますが、今後の進展を見守る必要があります。

５．展示のほうも出展するベンダが増えています。特にCMS関係は前回とはだいぶ様変わりしています。こういう会議に参加するたびに強く感じるのは、特にDITAのようなニッチな分野では日本の国内だけではなくて世界中で展開しないとだめということです。

DITAは一言でいうと、ドキュメントを部品化して再利用する技術です。ある意味ではドキュメンテーションの工業化ということなのですが、ベルギーの方が、「CADの考え方をDITAに応用したらどうなるかという、要するにドキュメントを機械製品と同じように工業的につくれないか」というプレゼンをしたのには少々驚きました。自分のコンセプトを共有してほしいという趣旨であまり現実的な話ではないようですけど。このプレゼンは参加者も少なかったので、あまりまじめに取りあげるレベルではありません。

[1] DITA Europe 2012
[2] DITA 1.2 feature article: Keyref overview

エクスイズム、EPUBによるショートマガジンの販売を開始

投稿日時: 投稿者:
3

楽天、アマゾンなどEPUBによる電子書籍の販売が始まりました。これで漸く待ちに待った電子書籍元年が現実のものになりました[1]。EPUBを使えば誰でも電子書籍を制作販売できる、とはいうものの、実際のEPUB編集・制作と入稿・販売実務にはさまざまな知識と作業が必要で、手間もかかります。そこで、こうした煩雑な業務をまとめてサポートするサービスが必要になります。

アンテナハウスの関連会社　エクスイズムはCAS-UBで制作したEPUB版電子書籍を「エクスイズム・ショートマガジン」として販売するサービスを開始しました。

第1弾は、「税と社会保険を考えるメルマガ」（ディード経営税務事務所）の発行するニューズレター（メルマガ）を1号毎にEPUB化したものです。本日より、楽天のKoboストアにて販売しています。

■検索

エクスイズムが販売を予定しているコンテンツは、連載記事、メルマガ、ブログ、写真集などの比較的文字量の少ない「ショートマガジン」が中心で、エクスイズムとの電子配信許諾契約を締結できることが前提になります。

いままではこうしたコンテンツを簡単に販売する方法がありませんでしたので、コンテンツをもっている著者には大変便利になるでしょう。エクスイズムのはじめたサービスが、今後、大きく発展することを期待します。

なお、コンテンツは、CAS-UBを用いてEPUB3化しています。著者の方が、直接CAS-UBで編集作業を行なってEPUB化することもできますが、エクスイズムがCAS-UBを用いて制作代行を行なっています。それぞれで売上から支払われるロイヤリティが異なります。

□詳細は次へお問合せください。
株式会社エクスイズム　営業部　eXism Short Magazine係
電話　03-5229-8761
メール　exsales@exism.co.jp

[1] アマゾンはEPUBを入稿形式として利用です。

10月のブログ記事をEPUBにまとめました。

投稿日時: 投稿者:
返信

10月のブログ記事をEPUBにまとめました。

EPUBファイルは、こちらにございます。

○CAS-UBサンプル・ページ

○10月のブログ記事（EPUB3版）

もとの（この）ブログはWordPressです。

手順は次の通りです。

１．WordPressから投稿のエクスポート機能をつかって、1か月分のファイルをエクスポート

２．CAS-UBの［ドラフト]⇒[インポート]でインポートファイルの形式をWordPpress（WXR）とします。

３．１．でエクスポートしたファイルを、指定してアップロード。

４．記事をすべて選んで「主原稿」に移します。

５．画像がエクスポートされないので、画像を直接アップロードします。

６．あとは細かい編集調整をおこなっってEPUB3に出力。

これで出来上がりです。大よそ1時間程度でできました。

EPUBリーダの数式サポート―iBooks3.0のMathML表示がかなり進化

投稿日時: 投稿者:
1

10月の主要EPUBリーダの新版登場でひとつ注目したいのが数式のサポート強化です。Readiumは3月にMathJaxを使ったMathML表示をサポートしました[1]。

これに対して、iBooksはMathMLの直接レンダリングを強化したようです。

表　メジャーなEPUBリーダのMathJaxサポート

項目 iBooks3.0 (iOS6) Adobe Digita
Editions 2.0 		Readium 0.5.3 Kindle Previewer 2.7
(Kindle Paperwhite モード）
MS明朝
MathMLサポート MathML直接描画 未サポート MathJaxによる 未サポート

１．iBooks3.0による表示例

(1) 図１の一番上の数式では最初の()が上下に伸びすぎています。二つ目の数式では「・」が親文字と離れすぎです。この2点を除くと大体使えると思います。

図１ サンプル数式のiBooks3.oによる表示１

(2) 図2についても（）が上下に伸びすぎている点を除くと使えると思います。

図２　サンプル数式のiBooks3.oによる表示２

２．ReadiumによるMathMLの表示

ReadiumはMathJaxで数式を表示しています。Readiumによる表示を次に示します。こちらの方はすべての数式が綺麗に表示されています。

図１ サンプル数式のReadiumによる表示１

図２ サンプル数式のReadiumによる表示２

３．総合的にみて

EPUB3.0になって数式MathMLの表示がEPUB3.0リーダの標準機能になりました。まだ、EPUB3.0リーダによる数式表示機能の実装は全体として遅れています。しかし、iBooksが数式のMathML表示をサポートしつつあることが分かります。現状ではまだすべての数式をサポートできていないようですが、このペースですとあと半年もあればMathJax並みになりそうで、かなり期待が持てます。

[1] Readium 0.19 update adds MathML support
[2] 数式のサンプル （CAS-UBで作成したもの）