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

「Kindle パブリッシングガイドライン 2017.1」更新内容チェック

2017/02/21

Amazon Kindle向けコンテンツ作成の仕様書、「Amazon Kindle パブリッシングガイドライン」が更新されていたようですので、更新部分を含めてリフロー型電子書籍作成に関する部分をざっくりとチェックしました。英語版はこちら。以下、見出しは元文書の見出し項目そのまま、赤字はリジェクトの可能性があるなど特に重要と思われる箇所です。電書協ガイドとの互換性についての考察も入れています。ご一読ください。

“4.1 マーケティング用表紙画像は必須です”

Amazonの商品ページやアファリエイトリンクなどに表示される書影画像(マーケティングカバー画像)についての規定です。最低サイズ2700×1600px以上、解像度300ppi以上、サイズ5MB以下のJPEG画像が必要とあります。また、「価格やその他の一時的な販売促進の提供に言及する」表紙画像は使用できないとの文言があり、例えばオビに価格やキャンペーン情報を書いてあるケースに注意が必要そうです。

“4.2 内部コンテンツ表紙画像は必須です”

電子書籍の中に入れるカバー画像についての規定です。サイズに関してはここには特に指定はありません。なお、表紙画像のOPFでの指定方法に関しての記述がありますが、現状ではもう電書協ガイド準拠で大丈夫な模様です。過去には表紙画像が2回表示されたりしていました(Kindle側がEPUB3の標準的な記述に対応したために直ったと思われます)。

“5 ナビゲーションのガイドライン”

「すべての Kindle 本には、論理目次を含める必要があります」との記述があります。入っていないとリジェクトされる可能性があると捉えるべきでしょう。まあこれは電書協ガイドに最低限の論理目次は最初から入っていますので、それに沿ってデータを作っていれば問題はないです。

“5.1 HTML 目次のガイドライン”

コンテンツ内に通常のページとして表示される目次ページについての規定です。<table>タグを使ってのレイアウトはするな、元の本のページ番号は記述するなというような内容です。これはまあごく常識的と思います。

“5.2.1 toc nav 要素を使用して論理目次を作成する”

toc nav 要素を使用した論理目次の記述方法についてのガイダンスです。電書協ガイド含むEPUB3での一般的な論理目次はこのtoc navを使って作ることになっています。なお、リストのネストによる目次の階層表示のサンプルが載っていますが、これは以前チェックした時点では正常に表示できないRSが多数ありましたので、Kindle以外のストアでも販売することを前提としたEPUB3の中で使うのであれば、対象ストアのRSでの事前表示チェックは必要になるでしょう。

“5.2.2 NCX を使用して論理目次を作成する”

EPUB2の仕様であったNCX文書での論理目次の記述方法についてのガイダンスです。以前はKindleではこちらの方法で記述しないと論理目次が表示されませんでしたが、現在ではtoc nav 要素の記述だけで問題ありません。

“5.3 ガイド アイテム”

目次とは別に、コンテンツ内の論理的な構造を規定するためのガイドの記述方法です。Kindle内の目次(論理目次)に表示される「表紙」「目次」「最初のページ」などのリンクページ指定と思ってください。
今回新しく「読み始め開始位置は定義する必要なし」との記述が加わっています。また、以前にはあった読み始め開始位置の指定方法の項目が消えている模様です。おそらく以前にちょっと話題になっていたKindle Unlimitedでの読み始め開始位置を後ろに持って行き、読まれたとKindleに認識させることでKENPCを稼ぐ(アメリカでの)Kindle Unlimitedの悪質ハック対策としての対応でしょう。
つまり制作側での「最初のページ」指定の有無にかかわらず、販売時のAmazonサーバ側の処理で自動的に「最初のページ」の部分が決定されるようになったと思ってよいと思います。販売前に端末にサイドロードしてのチェックと表示結果が変わってくるケースもありそうですので、注意が必要です。

“6.3 スクリプトを避ける”

Javascript非対応。元ソースに含まれていても自動で削除されるとのこと。

“6.4 ファイル参照は、ソースのスペルと大文字と小文字の区別を一致させる”

大文字・小文字を区別するので注意との記述。ハマったことが一度あります。

“6.6 サポートされる文字とスペースの使用”

サポートされているスペースは、通常のスペース、改行なしスペース (&nbsp;)、ゼロ幅の非結合子 (&zwnj;)です」という記述があります。英語コンテンツなどで使われることのある4分スペースなどは保証外なので注意が必要そうです。
また、「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください。」という一見意味のわからない記述があります
直前に「文字を書き表すときは、プレーンテキストの UTF-8 の文字を使用します」との記述もあるわけなのですが、Unicodeは本来符号化文字集合の国際規格で、UTF-8はUnicodeをコンピュータで使うための符号化方式のひとつですので、文字通りに取ると使える文字がひとつもなくなります。誤訳を疑って原文も見てみたのですが、「Do NOT use Unicode format characters, as they may cause problems.」とあり、原文の時点で意味が通りません。
おそらくここで「Unicode」と呼んでいるのはWindowsのメモ帳などで保存する際に出てくる(MSの呼称としての)「Unicode」形式の話ではないかと思います。つまり実際に指しているのはUTF-16エンコーディング非対応ということでしょう。となるとEPUB3は仕様上UTF-16も文字コードとして認めているようなので、AmazonとしてはUTF-8のみを用いるということで話はわからなくもないです。ただ、これは技術仕様文書なので技術用語は正確に扱って欲しいです。ちょっとこれを思い出してしまいました。

“6.7 電子書籍での読みやすさを重視する」を追加”

見出しの意味がちょっとわからないのですが(混入しているカギ括弧もママ)、原文は「6.7 Design for a Good eBook Experience」なので、まあ電子書籍制作の一般的注意として、原本のレイアウト再現にこだわりすぎるなという文言かと思います。レイアウトにこだわってフィックスで出すのではなくてリフローで出しましょう、と。

“7 外部リンクのガイドライン”

外部Webページへのリンクに関する規定です。「性的コンテンツへのリンク」「顧客情報の入力を要求する Web フォームへのリンク」「違法、有害、不正、不快なコンテンツへのリンク」はまあわかります。注意すべきは「Amazon 以外の電子書籍ストアへのリンク」でしょうか。これに引っかかるとリジェクトの対象になります。

“8.1 Kindle 本のテスト”

出版前の品質チェック方法に関しての記述です。まあ特に問題はないんですが、iOS版のKindleアプリでのチェックには.azk形式に変換してからiTunesで同期しないとダメ、みたいな話は書いておいて欲しいです。

“9.3.1 本文では必ずデフォルトを使用する”

リフロー型書籍の本文全体に対して文字サイズ(font-size)や行高(line-height)、文字色(color)は指定するなという規定です。部分的にはもちろんOKです。本文全体に対する地色(background-color)の指定もNG。まあこれはKindleに限らずダメですが。
要注意なのは、この規約に沿っていなかった場合、アップロード時にサーバ側で強制変換されるとの記述が追加されていることです。サイドロードしての表示チェックではOKだったものが、実際に販売されると内容が変わってしまう可能性があるため、注意が必要そうです。以下該当部分をそのまま引用します。

  • コンテンツの大部分に使用されているフォントサイズは 1em に正規化されます。
  • コンテンツの大部分に使用されている font-family はルートタグ (本文) に変更されます。
  • 本文に使用されている強制フォントカラーが削除され、テキストの色を変更できるようになります。
“9.3.3 大半の要素に固定値を使用しない”

ピクセル数指定などの相対値で値を記述せよとの規定です。Webサイトと同じ感覚で電子書籍を作るとハマりかねない落とし穴ですので注意は必要ですが、一般的な話です。なお、「改ページを確実にするために、Kindle ソフトウェアでは 1.2 em または 120% 以下の line-height 値の使用はお勧めしません。」との記述があり、ここは注意が必要そうです。

“9.3.7 埋め込みフォントを使用する”

埋め込みフォントの使用規定です。対応形式としてOpenType (OTF) およびTrueType (TTF) の形式が挙げられています。ただ、埋め込みフォントに関しては以前にOTFを埋め込んで作成したコンテンツが、販売時にはサーバ側処理でフォントが削除されて表示されていなかったという経験があり、現在まだ調査中です。日本語フォントはTrueTypeのみという話なのかも知れません。その場合、EPUB3の仕様での標準Core Media TypeにTrueTypeは含まれていないとの話(参考)もあり、いろいろと問題が出てくる可能性が捨てきれません。
また、等幅フォントのサポートについての記述があります。<pre>、<code>、<samp>、<kbd>、<tt>、<font face="courier">、<font face="monospace">のタグで記述すれば等幅で表示するとのこと。コンピュータ技術書などでは必要になりそうです。

“9.3.10 脚注のガイドライン”

脚注の相互リンクが推奨から要件に変わっています。これは影響が大きそうです。電子書籍では確かに現状リンクを貼らないと注が参照しにくいのですが、全ての本での対応となると工数がかなり増えそうな点が心配です。また、Kindle専用端末での脚注ポップアップ仕様は以前にテストした際にはだいぶ不安定でしたので、ちゃんとepubの標準仕様に沿った形で仕様改訂して欲しいところです。

“9.4.1 サポートされている入力形式を使用する”

対応画像形式についての規定です。、「GIF、BMP、JPEG、不透過 PNG、SVG 画像」とあります。透過PNGに相変わらず非対応なのは残念ですが、SVGに対応を公式に謳っているのですね。
なお、注記に「画像ファイルのカラープロファイルには RGB を指定してください。 Kindle は sRGB と CMYK をサポートしていません。」との表記があります。「sRGBをサポートしない」という文言はだいぶ意味がわかりません。CMYKカラーモデル非サポートの話とRGBカラーモデル内規格であるsRGBの対応の話を併記されても困ります。RGB色空間に関する規格にはsRGBの他にAdobeRGBがありますが、これはカメラマンが撮影した画像をきっちりカラーキャリブレーションを取ったモニタ環境で色補正する際などに使うもので、この場合に出てくる話とも思えません。タブレットやスマートフォンなど一般的な機器向けのコンテンツなら画像のカラーは通常sRGBになるはず。
詳しい方に確認を取った感じでは「カラープロファイル指定に非対応なので付けられてもそのままパススルーで出力するよ」くらいの意味だろうという話なのですが、それであればそういう表記が欲しいところです。

“9.4.2 画像のサイズおよび品質の基準”

画像のサイズに関しての規定です。なおここはリフロー型電子書籍内の画像に関しての記述なので、hon.jpのこの記事は誤報です。通常写真集はフィックス型で作ると考えられますので。どうも元記事内に「写真集」という記述も見当たらないようで、どこから出てきたのか謎です。あとこれはそもそもKDPのガイドラインではなくて、KDP以外の出版社からのコンテンツにも影響が及ぶ「Amazon Kindle パブリッシング・ガイドライン」の改訂ですしね。元記事にはしっかり “Amazon Kindle Publishing Guidelines” の表記があります。
肝心の画像サイズに関しては、全ページに表示する場合で「300 ppi で 1200 x 1800 ピクセル以上」との記述があり、この数値自体にそう無理はないと思います。ただ、「9.4.5 写真は高解像度の端末用に最適化する」に「端末の画面いっぱいに表示する画像ならば、画像の幅を 3,200 ピクセル (最高解像度の端末である Kindle Fire HDX 8.9" の画面幅の 2 倍) にします。」との記述があり、これは相当な高解像度です。素直にこれに従って作ってしまいますと、Appleのガイドライン文書、iBooks Asset Guide「画像のサイズは400万画素以下」という規約を簡単に超過し、iBookStoreでは販売できないEPUBが出来上がりそうです。注意が必要でしょう。上記の数値はあくまでAmazonの推奨に過ぎないので、現実的には現状では長辺2000px程度に止めた方が良いと思います。

“9.4.3 レスポンシブ レイアウトの画像サイズ”

「width スタイル属性でパーセンテージの値を使用して、ブロック画像とフロート画像をスタイル化することをお勧めします。 これにより、端末の解像度に関係なく、画像が画面の大きさに対して同じパーセンテージで表示されます。」との文言があります。こちらでテストした限りでは、現状まだKindle iOS版ではサイズの%指定が効きません。仕様として推奨するのであれば、RSの改訂もそれに準じて進めて欲しいところです。

“9.5.1 大きな表を避ける”

「表形式のコンテンツには、表を画像として表示するのではなく、HTML の <table> レイアウトを使用することをお勧めします」との文言があります。アクセシビリティの観点からテキスト検索できる形で表を挿入すべきという話はわかりますが、iOS版Kindleでセル幅の%指定が効かないという問題が現状ありますので、そこは直して欲しいところです。
また、「すべてのサイズの端末に最適となるように、表の大きさを 100 行 x10 列以内にすることをお勧めします。」との文言もあるのですが、元データにある列の数を勝手に弄れるなら苦労はありません。

“9.5.3 必要に応じて表を分割する”

画像としての表を分割する場合のガイドラインです。ヘッダを両方の表につけるようにという記述があります。ちょっと手間はかかりそうです。

“9.5.4 タイプセッティングの改善による表機能”

これはKindle専用端末のアップデート 5.8.2で追加された「タイプセッティングの改善」機能に準じてのテーブル作成ガイドライン文書のようです。<thead><tbody><tfoot>タグで論理構造をしっかり書くようにとの記述があります。この機能はまだちゃんと試していないのですが、iBooksでのテーブル組みの表ポップアップ表示的な機能かと思います。

リフローに関してはこんなところかなと思います。正直、制作仕様の規定文書としては粗い記述が目立ち、またこちらで推奨されている方法でコンテンツを作成してもRS側の実装が追いついていないためにレイアウト等が乱れるケースが出てきそうです。十分な注意は必要でしょう。

(2017.2.21)

Kindle Paperwhiteがいつの間にか調べ物最強デバイスに化けてた件について

2015/02/25

 数日前の昼間、こんなネタが流れてきました。amazonkindleは存在自体知らなかったんですが、デバイスで付けたハイライトを同期させてWebページから一覧で見られ、しかもPC用のビューアをインストールしてあれば該当箇所に簡単に飛べると。忙しさにかまけてMac版Kindleの動作チェック後回しにしていたんですが、こんな話を聞いては試さずにはいられません。

さっそくやってみた

ハイライトしたい範囲を選択 まずはMac版Kindleをインストールしてログインし、同期対照の電子書籍をダウンロードしておきます。そしてKindle PaperWhiteでハイライトしたい範囲を選択します。

ハイライト箇所を同期 次にインターネットに繋がる環境で、設定メニューの「同期してアイテムをチェック」でハイライト箇所を同期。

ハイライトした箇所が一覧で出てくる その上でamazonkindleにログインし、「Your Hilights」をクリックすると、今ハイライトした箇所が一覧で出てきます。そのテキスト末尾の「Read more at location〜」をクリックすると、見事にMac版Kindleが立ち上がってハイライトした箇所が表示されました。

 素晴らしい!未来、来ましたね。これなら紙の本に付箋を貼りながら読み込み、大事な箇所にマーカーで書き込むのと手間は変わりませんし、ハイライトした箇所を一覧で見られることを思えばむしろこちらの方が利便性は上です。amazonkindleの画面上からならコピー&ペーストもできますから、調べ物的な読書ならこれは相当に便利です。もちろんハイライトをつけることはiOS版、Android版などのKindleアプリでもできます。最高。

そしてさらに気づいてしまった

串刺し検索の一覧表示 そして昨日、Kindleの表示チェックをしている時に、さらにとんでもないことに気づいてしまいました。いつの間にか、Kindle PaperWhiteのホーム画面上の検索機能から、手持ちのデバイス内に入っている電子書籍全てに対しての串刺し検索ができるようになっていたことを。
 これ、いつごろから実装されていた機能なんでしょうか。ちょっとわかりませんが、どうもそれなりに前からあった機能のようです。PCならそう難しくもないでしょうが、Kindle PaperWhite程度のデバイス処理能力でこれを実装するのは相当大変だったはず。
 これができれば、上記のハイライト同期と合わせて、現状調べ物的な読書には最強の環境が整ったと言えるのではないでしょうか。Amazonが地道に整えてきた単体ではそこまで目を引かない地味な機能の集積が、ここにきてついに繋がり始めた感があります。ここは素直に開発チームに賞賛の気持ちを送りたいです。ついに電子書籍はここで紙の本を超えました。

 さて、そうは言っても私も欲張りな読者の一人ですので、まだまだ不足を感じる点はあります。ということで、ここでAmazon開発チームおよび、他ストアのビューア開発者に対して「次」に望みたい点に関しての要望を出しておきたく思います。

一括検索機能をPC/Mac版Kindleでも使えるように

 まずは当然、Kindle PaperWhiteだけでしか一括検索が使えないという点には不満を覚えます。率直に言いまして、一括串刺し検索はむしろPC/Mac版のKindleアプリと親和性の高い機能なのではないでしょうか。複数の書物にまたがって調べ物をする際に、キーワード一括検索をかけ、該当箇所に自在に飛んだ上でハイライトをつけ、それを自在に抜き出してまとめ文を作るといった行為をする際に、PC/Mac単体で完結させたいと思うのは私だけではないはずです。ぜひ、PC/Mac版のKindleアプリにも早期の機能追加を望みたいところです。

PC/Macアプリ上で選択テキストをコピー&ペーストしたい

 さらに言えば、現状のPC/Mac版Kindleの「選択箇所のテキストのコピー&ペーストができない」という仕様も不満点です。おそらくこれは海賊版の流通を警戒する出版社に対して配慮した結果だろうとは思うのですが、長文のコピー&ペーストをできなくすれば海賊版の流通が減り、出版社の利益が増えるはずというのはおよそ幻想に過ぎないように思えます。利用者の利便性を損ねることで利益が増えるわけがありません。大体OSが標準で持っている機能を制限するということ自体、相当な無理筋です。こういう意味の無い機能制限は早く撤廃して欲しいところです。

書棚内のグループ分け/グループ内検索機能の追加

 現在Kindleで実装されているのは、デバイス内全ての本のみを対象とした一括検索機能のみです。ただこれでは、手持ちの本が1000冊、2000冊と増えていった場合には、検索結果があまりに多くなりすぎ、利便性を損なうことになりそうです。また、そうでなくともKindleのビューアは本の分類や並べ替えといった部分の機能が貧弱で、すぐに本がどこに行ったかわからなくなりがちです。そこで、まずは手持ちの本の分類機能を実装し、合わせて分類したグループ内の本に対しての串刺し検索機能を希望したいところです。

 といったところでしょうか。まああとは「他のストアで購入した本を含めた串刺し検索・ハイライト抽出」なんですが、まあこればっかりは一朝一夕には無理そうかなと・・・

(2015.2.25)

Kindle PaperWhite2013のリンクが脚注として表示される現象について

2014/03/14

 検証機としてKindle PaperWhite2013を入手したのですが、どうやら大きめの地雷を発見してしまったっぽいので報告です。

 どうもPaperWhite2013の新機能の脚注ポップアップ周りにバグがあるらしく、通常のリンクを脚注として表示してしまうことがあるようです。なお、Kindle PaperWhiteのファームウェアは「Kindle5.4.2(2155730032)」です。一方で正常にリンクが動作する場合もあり、正直条件が確定できませんでした。以下、その報告です。

普通に記述したリンクタグが脚注として表示されてしまう

 リンクのタグは例えば以下のような感じです。

リンク元:

<p>二 遠野の町は南北の川の落合にあり。以前は<a class=”cyu” href=”p-009.xhtml#ref-002″>七七十里<span class=”key” id=”key-002″>(2)</span></a>とて、七つの渓谷おのおの七十里の奥より売買の貨物を聚め、その市の日は馬千匹、人千人の賑わしさなりき。四方の山々の中に最も秀でたるを早池峯という、北の方附馬牛の奥にあり。東の方には六角牛山立てり。石神という山は附馬牛と<a class=”cyu” href=”p-009.xhtml#ref-003″>達曾部<span class=”key” id=”key-003″>(3)</span></a>との間にありて、その高さ前の二つよりも劣れり。大昔に女神あり、三人の娘を伴ないてこの高原に来たり、今の<a class=”cyu” href=”p-009.xhtml#ref-004″>来内<span class=”key” id=”key-004″>(4)</span></a>村の伊豆権現の社あるところに宿りし夜、今夜よき夢を見たらん娘によき山を与うべしと母の神の語りて寝たりしに、夜深く天より霊華降りて姉の姫の胸の上に止りしを、末の姫眼覚めて窃にこれを取り、わが胸の上に載せたりしかば、ついに最も美しき早池峯の山を得、姉たちは六角牛と石神とを得たり。若き三人の女神おのおの三の山に住し今もこれを領したもう故に、遠野の女どもはその妬を畏れて今もこの山には遊ばずといえり。</p>

リンク先:

<p id=”ref-002″><a class=”cyu” href=”p-003.xhtml#key-002″>(2)</a>この一里は小道すなわち坂東道なり、一里が五丁または六丁なり。</p>
<p id=”ref-003″><a class=”cyu” href=”p-003.xhtml#key-003″>(3)</a>タッソベもアイヌ語なるべし。岩手郡玉山村にも同じ大字あり。</p>
<p id=”ref-004″><a class=”cyu” href=”p-003.xhtml#key-004″>(4)</a>上郷村大字来内、ライナイもアイヌ語にてライは死のことナイは沢なり、水の静かなるよりの名か。</p>

 特に変わった書き方をしている訳でもないごく当たり前のリンク指定で、タグは電書協ガイドのものをそのまま用いています。普通に考えればこれで脚注にはならないのですが、手元のPaperWhite2013では以下のように脚注として表示されます。

リンクが脚注として表示されてしまう

まあこの箇所に関しては注釈へのリンクですので結果オーライとも言えるのですが、これが例えば目次のリンクでも発動してしまいますので困ったことになります。

目次でも・・・

別の実機でもテストしてみた

 ちょっとラチがあきませんので、Kindle PaperWhite2013をお持ちの、ブログ見て歩く者を運営されているライターの鷹野凌さんにご協力をいただき、別の実機でもテストを試みました。結果はほぼ同じでした。ただ、全く同じコンテンツで正常に動作したリンクと脚注として表示されてしまったリンクに差異が見られ、正直法則性が全く読めません。鷹野さんのPaperWhite2013のファームウェアは「5.4.2.1(2187320002)」とのことでしたので、もしかしたらファームウェアの差によって挙動が変わるのかも知れませんが、率直に言ってそんなことで「リンク」などという基本的な部分の動作の挙動が変わられてしまっては困ります。

 別のマークアップ方式ではどうなるだろうということで、電書ちゃんねるの高瀬拓史さんにもご協力をお願いし、でんでんコンバーターの生成した注釈相互リンクコンテンツでもテストを行いました。こちらのソースは以下の通り※1

リンク元:

<p>一 女鹿たづねていかんとして<a id=”fnref_1″ href=”#fn_1″ rel=”footnote” class=”noteref” epub:type=”noteref”>1</a>白山の御山かすみかゝる<span class=”upright”>〻</span></p>
<p>一 うるすやな<a id=”fnref_2″ href=”#fn_2″ rel=”footnote” class=”noteref” epub:type=”noteref”>2</a>風はかすみを吹き払て、今こそ女鹿あけてたちねる<span class=”upright”>〻</span></p>

リンク元:

<div class=”footnotes” epub:type=”footnotes”>
<hr />
<ol>
<li>
<div id=”fn_1″ class=”footnote” epub:type=”footnote”>
<p>して、字は〆てとあり。不明&#160;<a href=”#fnref_1″>&#9166;</a></p>
</div>
</li>
<li>
<div id=”fn_2″ class=”footnote” epub:type=”footnote”>
<p>播磨檀紙にや。&#160;<a href=”#fnref_2″>&#9166;</a></p>
</div>
</li>
</ol>
</div>

 こちらではリンク元の側がそもそもリンクとして動作してくれませんでした。もちろんどちらのコンテンツも、他のEPUBビューアでは少なくとも相互リンクとしてはきっちり動作してくれています。なんだかもうわけがわかりません。

そもそも脚注のマークアップ記法説明ドキュメントが見あたらない

 そもそもKindle PaperWhite2013の脚注ポップアップ対応は先日の制作者向けセミナーでもPaperWhite2013の新機能として説明されていましたが(鷹野凌さんのレポート記事)、最新のKindle Publishing Guidelineにも記法の説明がありません。
 制作者サイドとして切に望みたい対応は、epubの標準的な脚注記法に合わせて実装してくれることなのです。ですがどうもそうはなっていないようです。実際に「<a epub:type=”noteref” href=”p-000.xhtml#ref-000″>○○</a>」のような形でIDPFの脚注仕様に合わせたマークアップもやってみたのですが、この方法で明示的に脚注指定した箇所だけでなく、通常のリンクとしてマークアップした箇所まで脚注として表示されてしまいました(参考:「iBooksの注ポップアップを試してみた」)。現状、Kindle向けコンテンツでは明示的に脚注リンクを指定する方法が提示されていない状態です。

 また、もうひとつの問題は、Amazonが校正用ビューアとしてリリースしている「Kindle Previewer」上ではこの現象は再現せず、あくまでKindle PaperWhite2013の実機上でのみ発現する現象であることです。つまり、「Kindle Previewer」がプレビュー用ツールとしての役目を果たせていません。Kindle Previewerできっちり校正をかけリリースしたコンテンツが、実際の読者の手元で見たときにはエラーになってしまう可能性があるというのでは、何のためのプレビュー用ツールかわかりません。

 少なくとも今回のケースで、コンテンツ制作側での対処は無理です。何しろごく当たり前のリンク指定が脚注として表示されてしまい、発生条件が機械によって変わるのですから。この件に関しては、Amazonには早急な原因究明と、とりあえずの処置としての注釈ポップアップ処理の停止措置を望みたく思っています。

検証に使ったファイルはこちら
>>サンプル用epub (663)

 Kindleに限らず、現状電子書籍のビューアはまだまだ不具合が多く、機能面も必ずしも十分とは言えません。ただ、これは積極的に声を上げ、修正・改良を促すことで将来的にきちんとしたものを提供してもらうという気構えが制作者サイドにも求められるのではないかと思います。Amazonのフィードバック窓口はこちらです。みなさんどしどし意見を寄せ、修正すべき点はどんどん修正してもらうのが良いのではないかと思います。

※1 EPUBの仕様に従って明示的に脚注を指定しているマークアップとのこと。

(2014.3.17)

プロフィール
Jun Tajima

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

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

最近のコメント