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

Kindleの埋め込みフォント対応状況をチェックする

2021/10/13

新フォーマットへの完全切り替えが秒読み

 Amazon Kindleの新フォーマットへの切り替えがだいぶ進んできているようです。Amazon Kindleは2012年の日本上陸からずっと出版社には「.mobi」形式のファイルの納品を求めてきたのですが、今年の6月あたりから「.epub」形式で納品してAmazon側で変換という形に変わっています。背景にあるのはAmazonが「タイプセッティングの改善」と呼んでいるものへの対応で、これは新しめの本を購入してKindleアプリなどで開いてみれば古いものと明らかに違うユーザーインターフェースで開かれるので区別ができます。つまり今のKindleアプリは新旧の表示エンジンを両方持っているのです。なお聞いた話では現状まだMac版/Windows版は「タイプセッティングの改善」に未対応とのことなのですが、これもおそらくは近々切り替わるのでしょう。先日既存コンテンツの変換も始まったらしいという情報が流れてきましたので、完全切り替え秒読みというところだろうと思っています。
.kpf形式

 今、Kindle Previewer3でEPUBを表示させて「エクスポート」を選ぶと、「.kpf」という形式でのエクスポートを選択できます。これが「タイプセッティングの改善」に対応した次世代フォーマットということかなと思います。

埋め込みフォント対応が気になる

 さて、新フォーマット対応でこれまで制作時に悩まされてきた様々なKindleの表示の不具合が解消されることを期待していますが、それはいずれ表示チェックするとして、今気になっているのが「埋め込みフォント」の表示対応です。
 現状、一般的に電子書店で販売されている電書協ガイド準拠のEPUBでは、制作者が明示的に表示フォントを指定することはできません。もしどうしても特定のフォントで表示させたければ、EPUBのファイル内に表示フォントを収録してそれを表示させるしかありません。Webと異なりオフラインでも表示できることが前提となるEPUBでは、外部サーバーのWebフォントにアクセスして字形データを取得して表示させるといった手段は取り得ないからです。このため、フォントのライセンスが大きな問題となり(ソフトウェアバンドル扱いになるとのこと)、現状まだ商用フォントを自由に埋め込んで利用できる状況ではないのですが、もしKindle全プラットフォームで埋め込みフォントの利用が可能ということになれば、例えばSIL Open Font Licenseなどで公開されているオープンソースのフォントを埋め込んで利用することを考えられますし、商用フォントであってもフォントメーカーに個別交渉をすれば利用が可能になるので製作物の表現の幅は広がるはずです。

星海社の本でフォント埋め込みの対応状況をチェックする

 埋め込みフォントにKindleの各プラットフォームが対応しているかどうかのチェックをどう行うかですが、星海社さんが自社でフォントを開発し、既にそれを埋め込んでいることを売りにしていますので、ありがたくチェック用として使わせてもらうこととします。現状手元のファイルを端末に転送してKindleのビューアで表示させても「タイプセッティングの改善」が適用された状態になりませんので、明確に埋め込みフォント対応を行ったことを謳った本が市場に出ていることはかなり有り難いです。
 なお今回は知人の著書の「迷宮駅を探索する」をチェック用に利用しましたが、星海社 e-SHINSHOはどれも埋め込みフォント対応のはずです。

 以下、各プラットフォームでの表示結果になります。

iPadOS版Kindleアプリ(バージョン6.46)

iPadOS版Kindleアプリの表示結果

表示結果:○ 効いている

※「出版社の選択したフォント」を選ぶ必要あり

 「出版社の選択したフォント」を選ぶことで、埋め込みフォントでの表示ができていると思われます。以後、このiPadOS版の表示結果と一致しているかを見ていきます。

Kindle専用端末(5.13.7(3762990075))

Kindle専用端末の表示結果

表示結果:○ 効いている

※「出版社のフォント」を選ぶ必要あり

 「出版社のフォント」を選ぶことでiPadOS版と同じ字形で表示されるのが確認できます。明朝体の見分けは難しいですが、「タ」や「さ」の字形が特徴的なので見分ける際に参考になります。

MacOS版Kindleアプリ(1.33.0(62201))

MacOS版Kindleアプリの表示結果

表示結果:× 効いていない

※フォント選択不可

 事前の情報通り、埋め込みフォントでは表示されないようです。Mac版では現状フォントの選択もできません。「タ」の棒が突き出ていないことで表示フォントが違うことが判断できます。

Windows版Kindleアプリ(1.33.0(62202))

Windows版Kindleアプリの表示結果

表示結果:× 効いていない

※フォント選択不可

 こちらもまだ埋め込みフォントでの表示はできていません。こちらは「さ」の字形が異なることで見分けられます。

 以上です。事前の情報通りMac版/Windows版はまだ埋め込みフォントの表示に対応していないようですので、この状況だとまだ、例えば語学書のような「埋め込みフォントでの表示を必須とする」ようなタイプのコンテンツに利用はできないかなと思います。また、Mac版/Windows版が対応したとしても、コンテンツ制作者側で特定のフォントでの表示を強制させるような作りにはできないようなので、目立つ場所に「出版社のフォント」を選んでください、という注意書きは必要になるでしょう。
 ただ「見出しを極太ゴシックで表示させたい」というような、例え埋め込みフォントの表示が適用されなくても読む分には問題がない表現は、今でも出版側が割り切れれば可能ではあります。
 なお、今手元にAndroidのテスト端末がないためAndroid版の表示チェックができていません。お手元の環境で確認できる方、教えていただけると助かります。おそらく問題ないかとは思うのですが・・・

(2021.10.13)

見出しにも埋め込みフォントが適用されているとの情報をいただいたのでテキストを修正しました。

(2021.10.14)

Kindleで画面内表示画像サイズを%指定する

2018/09/28

 各ストアビューア向けのEPUB制作で、画面サイズに対して%で画像表示サイズを指定することは長らくできておらず、悩ましい問題です。これは2014年頃にEPUB組版表現の対応状況を調査し始めてから状況がずっと変わっていません。特にKindleでは、PaperWhiteなどの電子ペーパー専用端末とAndroid版では%指定が効くものの、iOS版Kindleアプリで効かないという状況が続いており(参考/項目7-9)、このために画像を画面内の特定のサイズで表示させるために「余白部分込み」で画像化するというまるでWebの初期のようなTipsを使用せざるを得ませんでした。
 これをやってしまいますと、ビューア側の設定で背景色を変えた際に余白部分が白く表示されて見えてしまうので可能ならば避けた方が良いのですが、サイズ指定が効かないよりはマシということで使われてきたわけです。
 ただ、最近JAGATの研究会活動の一環として改めて挙動をチェックしてみたところ、%指定が効かなかったiOS版Kindleでもどうやら単位にvw/vh※1を用いたサイズ指定なら効くことがわかりました。であるならば、もしかしたら%とvw/vhを同じ値で指定してやることでKindleの全プラットフォーム共通のサイズ指定ができるかもしれません。ということで試してみよう、というのが今回の趣旨です。

iOS版Kindleでサイズ指定が効いた!

 以下のようにCSSの指定を書き※2、テストファイルを作ってテストをしてみます。

 iOS版Kindleでの表示結果は以下の感じ。

iOS版Kindleの表示結果

 KindleはiOS版以外では普通に%指定が効くため、iOS版でサイズ指定が効けばよいので目論み通り成功です。他のKindleデバイスでも不具合は出ていないようです。ただ他社のビューアで不具合が出る可能性がありますので、一応それも見てみなければなりません。

他社製EPUBビューアで不具合が出る

 ということで他社ビューアでの表示結果もチェックしたのですが、残念なことにあるビューアで表示の不具合が出てしまいました※3。どうやらline-height(行高指定)とtext-combine-upright(縦中横)が効かなくなるようです。さて困りました。

メディアクエリで適用範囲をKindleのみに限定できないか

 ここで思い出したのがKindleのメディアクエリです。メディアクエリは一般的には表示ウィンドウサイズに応じて異なるCSSを当てる際などに使う技術ですが、Kindleでは「@media amzn-kf8」「@media amzn-mobi7」などの形で、デバイスごとに表示を切り替えるための独自の値を定義しています※4。これを利用してCSSの適用範囲をKidleのみに限定できないでしょうか。ということでCSSにメディアクエリを追記して再テストをしてみます。CSSは以下のような感じ。

 はい、成功です。

 ということでひとまず目的は達しました。とはいえ%でのサイズ指定が効かないのはKindleだけではなく、Mac版iBooks(もうApple Booksですが)でも同様だったりしますので、出来るなら将来的にはメディアクエリは外したいところです。各電書ストアビューアの表示対応を期待します。

※1 vwは表示中の画面(ビューポート)の横幅に対しての%指定、vhは高さに対しての%指定の意味。参考記事はこちら
※2 電書協EPUB3制作ガイドのCSS記述を参考にしている。
※3 中の人に報告上げてブログ記事作る間に該当のビューアで修正がかかった模様。対応が早くてありがたい。とはいえ不具合が出るビューアが1社だけとは限らないので記事としては残しておく。
※4 参考:http://epubsecrets.com/media-queries-for-kindle-devices.php

おまけ
EPUBで電書協ガイドの規定クラスに追記するには以下の形になるはず。book-style.cssの作品別カスタマイズ領域に書けばよい。

(2018.10.1)

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

2018/08/03

Amazon Kindle向けコンテンツ作成の仕様書、「Amazon Kindle パブリッシングガイドライン」が更新されていたようですので、更新部分をざっくりとチェックしました。英語版はこちら。以下、見出しは元文書の見出し項目そのまま、赤字は特に重要と思われる箇所です。ご一読ください。

“2.1.1 Kindle Create”

 Kindle Createについての表記追加。.doc/.docx形式のファイルからKindleドキュメントを生成できるもの。ただし現状まだ日本語には未対応のよう。

“3 フォーマットの比較”

 「タイプセッティングの改善のコラムを追加」とある。ここでのコラムは表組みの「列」の意味と思われる。

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

 「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください」とあるが、「Unicode 形式の文字」は英語版ドキュメントでは「Unicode format characters」とあり、「Unicodeの制御文字」と訳すべき箇所。
 おそらくU+0000 – U+001F(C0制御コード)、U+007F(削除文字)、U+0080-U+009F(C1制御コード)などを指していると思われるが(参考)、U+2028(LINE SEPARATOR)、U+2029(PARAGRAPH SEPARATOR)なども制御文字であるため注意が必要。また、U+0000〜U+001Fの制御文字のエリア内でもU+000A(LF)やU+000D(CR)などは改行コードであり、これを使うなというのは現実味がない。具体的に使うべきでないコードポイントを明示して欲しい。

“7.1 内部リンクに関するガイダンス”

 「意図しない脚注のポップアップが表示されないようにするには、脚注ではない内部リンクに双方向ハイパーリンク (A から B へのリンクと B から A へのリンク) を設定しないでください。」とある。作り方としては一般的だが、制作指針に縛りをかける要望ではある。
 また「現在、電子書籍端末の固定レイアウトの本では、内部ハイパーリンクはサポートされていません。」とあり、ここはずっと変わっていない。

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

 「本から外部Webサイトへのリンクは、読者体験とAmazonによって定められた本のコンテンツをより一層意義あるものにし、それらに直接関係のある場合に限ります。」とある。外部へのリンクは技術的に可能でも規約上の制約がかかるため注意が必要。
 「Amazonはリンクを独自の判断で削除する権利を有します。」ともある。

“9.1 メタデータのガイドライン”

 「<dc:language>」および「<dc:title>」が必須、ページめくりの方向が左から右ではない場合、メタデータまたは背表紙に「<meta name="primary-writing-mode" content="horizontal-rl"/>」のような形でページめくり方向を明示する必要がある、との記述。これはAmazon独自のメタデータなので注意が必要。従来これはフィックス型のEPUBでのみ必要な措置だったように記憶しているのだが、リフロー型でも必要になったようにも読める。だとすればメタデータの追記が必要になるだろう(ちなみにこの「horizontal-rl」という記述も以前からある罠で、「horizontal-lr」もしくは「vertical-rl」になると思われる。一度引っかかった)。なお、 「背表紙」は「Spine」をそのまま訳してしまったミス。OPFのSpine項目への記述のことと思われる。「<spine page-progression-direction="rtl">」の記述で代替できるということか?

“9.3.11 Real Page Number の有効化”

 実ページ番号のサポート。教科書など教育関係の本で要望がずっとあったもので、iBooksなどではかなり前からサポートされていた(参考)。
 「出版者は、電子書籍のReal Page Numberをその電子書籍と最も一致度の高い印刷版(ハードカバー、ペーパーバックなど)にマッピングし、ISBNをhttp://kb.daisy.org/publishing/docs/navigation/pagelist.html#descに従いメタデータに指定する必要があります。」とあり、紙版の書籍と電子版の双方を刊行する前提の本で使うことを想定したものであることがわかる。米国などでのKindleの教育市場へのニーズを伺わせる機能追加。おそらくは電子教科書用だろう。
 なお、「サイドロードでプレビューできませんが、電子書籍が出版されると表示され、詳細ページにも記載されます。」とあり、残念ながら実際の挙動を確認することはできなかった。

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

 「脚注のマーキングには HTML5 の aside 要素を epub:type 属性と組み合わせて使用することを強くお勧めします。その場合、アクセス可能な端末では指示が追加されていない限り脚注を無視することができます。」とある。脚注を通常の画面内では非表示にし、リンクを叩いた際にだけ表示させるという意味かと思う。
 脚注のポップアップ表示にも対応したとのこと。なお脚注のポップアップ自体はiBooksや楽天KoboのiOS版、Microsoft Edge(同一xhtmlファイル内に脚注のジャンプ先がある場合のみ)では既に対応済み(参考)。Kindleでは専用端末のKindle PaperWhiteなどで脚注表示の挙動は見られたが、これはepub:type 属性を無視して相互リンクを脚注と見なす極めて不完全な対応だった(参考)。
 KindleがEPUBの脚注の正式な規格であるaside要素およびepub:type属性への対応を謳ったのは今回が初である。どう変わったのか挙動を見てみたのだが、現状Kindle FireおよびKindle PaperWhiteでポップアップの挙動は見られなかった。また、Kindle PaperWhiteではリンク自体が動作しないという挙動があり、これは早急に修正して欲しいところ。

“9.4.11 サポートされている SVG タグと要素を使用する”

 SVGの項目自体は以前からあったが、「タイプセッティングの改善」に関係する記述が追加されている。ここだけでなく影響はありそうなので注意が要りそうだ。

“9.5.2 シンプルな HTML の表を作る”

 ここにも「タイプセッティングの改善」に関する追加記述がある。

“9.6 MathML のサポート”

 数式のMathML表記をサポートしたとのこと。

“15.1 タイプセッティングの改善について”

 今回の更新内容の多くの項目が「タイプセッティングの改善」機能に絡むものだが、日本語はまだ対応言語に入っていないようなのでまだ考えなくてよい模様(15.5 
サポート対象の言語)。

“16 付録 B: タイプセッティングの改善でサポートされている属性とタグ”

 サポート対象のCSSプロパティ、HTMLタグが列挙されている。

今回、Real Page Number対応やepub:type 属性での脚注ポップアップ対応、MathML対応など大きな追加ポイントがありましたが、潜在的に最も大きな変化は「タイプセッティングの改善」(まだ日本語非対応ですが)に関するものでしょう。これは改訂履歴の項目の大部分がこれ絡みであることからわかります。
どうもずっとこの機能は謎のままだったのですが、今回の改訂から推測する限りでは、フォントサイズや端末の種類に伴う画面サイズなどの変化に応じてKindle側が随時CSSの値の調整を行う機能であるように思われます。つまりメディアクエリ的なことをKindleが自動でやるということです。これは日本語コンテンツでも使えるようになれば相当以上に大きな変化がもたらされるものと思います。ただし実機でのコンテンツ表示チェックは相当以上に大変になりそうです。Amazonがレンダリングエンジンの不具合を長期放置している理由もこれの対応が絡んでいるような気はします。

(2018.8.6)

プロフィール
Jun Tajima

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

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