文字の表示に関するテスト

埋め込みフォント関連

ハングルの表示結果

　長年の懸案だった埋め込みフォントの表示ですが、ハングルの表示テストについては画面のように表示できています。なお、この直前のテストは文字が化けてしまっているのですが、ハングルのテストではOpenType形式のフォント（SourceHanSerif-VF）を埋め込んでいるのに対して、直前のテストではTrueType形式のフォントを使用しているのでそこの違いかも知れません。フォントを埋め込んだ場合に読者側で特に指定しなくても埋め込んだフォントが強制優先表示される挙動は他のデバイスのKidleアプリと同様です。

日本語で使われる漢字の字形（異体字）バリエーションの表示

Unicode IVSでの異体字表示

　CSSでのfont-variant-east-asian、同じくfont-feature-settingsでの異体字表示指定は効いていませんが、Unicode IVSでの表示はできています。他のデバイスのKidleアプリと同様の挙動です。以前のWindows版KindleではUnicode IVSの異体字表示文字が豆腐として表示されてしまう状態でしたので、ようやく使えるようになったというところでしょうか。

日本語EPUB 内での欧文イタリック字形の表示

イタリック字形の表示

　欧文イタリックを斜体ではなく本来のイタリック字形で表示させることも埋め込みフォントの使用を前提にすれば可能になっています。

サロゲートペア文字の表示

サロゲートペア文字の表示

　こちらも問題なく表示できているようです。このあたりの文字（Unicodeの基本多言語面に入っていないが商用日本語フォントに字形情報はある文字）を外字画像化しなければならない状況はそろそろ終わって欲しいところですのでほっとしました。

結合文字列の表示

結合文字の表示

　これは文字によって結果が分かれる状況でした。問題になるのは合成済みのダイアクリティカルマークがUnicodeに含まれておらず、合成可能ダイアクリティカルマークを利用せざるを得ないキリル文字やギリシャ文字、アルファベットの「下」にダイアクリティカルマークが入るベトナムなどアジア圏の人名地名の欧文表記等ですが、これらの表示に瑕瑾があると専門性の高い本の参考文献ページなどが外字画像の山になって相当以上にツラいので早くどうにかして欲しいところです。

組版処理に関するテスト

画像のサイズ指定

画面に対する画像サイズの％指定

　この項目は結構デバイスごとに対応している単位、していない単位があって複雑なのですが、Windows版Kindleも％での指定は効いていることが確認できました。これは他のデバイスも共通のため、画像サイズの画面に対しての％指定はできると考えて良さそうです。なお、Kindle以外のビューアの対応も考慮すると、「書字方向への％指定」が確実かと思われます。

実ページ番号表示テスト

　今回のテストではEPUB内に設定したページ番号（紙版と同じページ番号を電子版でも表示させる指定）の表示はできていませんでした。ただこれは元々紙版と電子版の双方が販売されているコンテンツで同じページを表示させるための機能で、Kindleパブリッシングガイドラインにもその記述があります。この本は同内容の紙版が存在しないため、効いていないのは当然と言えます。他の本では効いていた例があったという話を聞いたことがありますが、この条件に基づくものでしょう。制作側としてはできれば販売前に挙動を確認したいところですが、現状仕方がないところです。

カギ／句読点の前後のツメ・アケ制御／和欧間自動アキ指定

日本語約物の自動ツメ処理

　約物類が連続する部分の詰まり方を見ると自動ツメ表示はできているようです。他のデバイスのKindleと同じ挙動に見えます。Kindleの文字ツメ、アケ処理はCSSによる指定が効いた結果ではなく独自処理の強制適用のようなので細かい評価はできませんが、日本語のテキストが読みやすくなっていることは確かなので喜ばしいところです。

ルビ関連表示テスト

ルビの肩付き指定

　ルビの肩付き指定が効いています。これはKindle以外のビューアと比べてもかなり日本語対応できている部分です。一方で、通常と反対側のルビ（縦組みでの左側ルビ）の指定は効きません。他のビューアと同様ですが両側ルビの指定も効きません。

表テーブルセル幅／高さ指定テスト

表のセル幅の指定

　tableタグで表を作った場合に各セルの幅の指定は％、vw/vhの双方で効くようです。セルの幅が％とvw/vhで多少変わるのはビューア表示画面の周囲のマージンを含めて計算するかどうかで変わるということでしょうか。簡単な表組みであればtableタグで作っても問題ないと言えそうです。

MathML 数式表示テスト

MathMLによる数式表示

　MathMLによる数式表示はできているようです。これは簡易的なテストに過ぎないため実際に数学方面の本の作成に使えるかどうかはより網羅的な調査が必要でしょうが、そちらは門外漢のため専門の方に任せたいと思います。

画像関連テスト

SVG 表示テスト

SVG画像の表示

　SVG形式の画像の表示もできています。SVGはベクター画像のため画面を拡大した際にグラフ等がきれいに表示できることが期待できます。

クリッカブルマップ動作テスト

　クリッカブルマップの動作はできていません。これは他のデバイスのKindleも同様なため、Amazonの方針と見てよいのかもしれません。

気になった部分

囲み罫の角丸指定

角丸は表示できず

　これは11/25の資料には入れていなかったのですが、Windows版Kindleで囲み罫の角丸指定（border-radius）が効いていなかったので指摘しておきます。他のデバイスでは問題なく表示できているので、いずれ修正されることを期待したいところです。
　追記：1.0.18632（最終更新日2026年7月6日）で表示が確認できたとの情報をいただきました。修正されたものと思われます。

制作者向けの更新点は少ない

　EPUB制作者向けの更新ポイントは少なめです。以下に列挙します。

・パッケージ文書（standard.opf）内の接頭辞の宣言に「dpfj: https://www.dpfj.or.jp/」が追加された。
・パッケージ文書（standard.opf）内、著作者名のカナ表記および整列順の指定を削除
・同じくパッケージ文書（standard.opf）内、出版社名のカナ表記の指定を削除
・画像形式にWebP形式が追加された（ビューアの対応は要確認）

　これぐらいかと思います。少ないですね。まあパッケージ文書等を見れば簡略化と言ってよいかと思います。とは言え、OPFの記述が変わりましたのでEPUB制作アプリの更新は必要で、どのタイミングで切り替えるかは各電子取次等の対応状況を見ながら判断していくことになるかとは思います。

EPUBビューア向けの要望は…

　一方で、各EPUBビューア向けの要望ですが、電書協ガイド1.1.3にあった「RSによる対応を想定しないHTML要素とCSSプロパティ」項目がまるごと削除されています。さらっと削除と書いてありますが、ここには1ページ半にわたって詳細な記述がありましたので、それが消えたことには相当以上のインパクトがあります。いくつか例を挙げると、HTMLでは「セクション」（section等）、「組込コンテンツ」（SVG形式の画像、MathMLによる数式等）、「テーブルデータ」（tableによる表組）、CSSでは「セレクタ」（::first-letterなど）、「リスト」、「回り込み」（float）など、Webではごく普通に使われる要素もここに相当入っていました。これを消したということは、「そろそろもうWeb基準で普通に使える要素は使えるようにして欲しい」という各EPUBビューア開発会社へのメッセージと見てよいのかなと思います。言うなれば「補助輪を外した」くらいの感じでしょうか。

　また、電書協ガイド1.1.3に引き続いて今回も「今後のRSに期待する項目」が別文書として付加されています。内容的には1.1.3のものとほとんど変わらないのですが、変わらないということはEPUBビューア側の対応状況がほぼ10年間変化がなかったということの反映かと思われます。各種の文字の表示対応やCSSの表示対応など、先にEPUBビューア側の対応が必要で、それが対応できていることを踏まえて初めて配信データ側が対応できる性質のものですので、各EPUBビューア開発会社の対応が望まれるところです。

今後に向けて

　以上が電書協ガイド1.1.3から電書連ガイド1.1.4への更新の概要になります。なおフィックスについては今回は更新なしということのようで、当面は現行のままになるようです。　
　今回の更新内容は従来の制作指針を大きくは変えない保守的な指針と言っていいかと思いますが、これは電書連（協）ガイドが各出版社、制作会社向けの実制作の基準として機能していることを考えれば無理からぬことと思います。また、電書連のサイトには「電書連への変更と EPUB 3.3 にて変更された内容に合わせて、本ガイドならびに別紙、サンプルファイルを修正しました。ただし、EPUB Accessibility 仕様への対応は含まれていません。」との記述があり、今回は読み上げ対応や実ページ数表示などアクセシビリティ関連の追加対応は見送られたようです。各EPUBビューアの現在の対応状況を踏まえての判断かと思います。とは言え、ほぼ10年間更新が途絶えていた電書連（協）ガイドが再び更新される状況になったことは朗報で、今後ビューア側の表示対応が一定のレベルに達すればそれに準じて電書連ガイドも更新されていくものと思います。

そもそもEPUB内の「ページ番号」とは

　まず、そもそも「リフロー型電子書籍」は本来、固定されたページ番号を持ちません。「ページ」は各デバイスでEPUBを表示した際にEPUB内のXHTMLファイルの内容が分割されて動的に生成されます。これは鷹野凌さんも説明されている通り。画面の小さなデバイスで表示すればページ数は増えますし、画面の大きなデバイスで表示すればページ数は減るでしょう。電子書籍アプリでリフロー型の電子書籍を読むときに画面下にページ番号（ノンブル）が表示されているかも知れませんが、これは通常「そのデバイスのサイズ、文字のサイズに対応して生成されたページ番号（ノンブル）」であって、それを根拠としてその本の特定の箇所を指し示すことはできません。ちょっと専門性の高い本を読めば、割と当たり前に既存の書籍の特定ページへの参照は出てきますが、「参照されている本を電子版で所有していた場合に、参照先が不明になってしまっている」のが現状なわけです。このため、「リフロー版EPUBにも電子化元の紙の本のページ番号を入れましょう」という話になっています。

「他のEPUB内の特定の場所を指し示す電子的な技術」はまだ発展途上

　EPUBは電子データなのだから既存の本のページ数にはこだわらず、EPUB内の特定位置を指し示す技術（epub-cfiなど）を使うべきだという意見もあるようですし、それはそれで意義があることも十分分かるのですが、そちらにも簡単には解決できない問題があります。
　現在商業流通しているEPUBが個々のファイルを指し示す個別のIDで一元管理されている状況ではないこと、がそれです。もちろん各ストアごとに商品のIDは振られているでしょうが、「ストアAの商品X」と「ストアBの商品X」が同じタイトルであることの紐付けはなされていません。紐付けるためには双方のストアのデータベースを突き合わせて紐付ける作業が必要になってしまっているわけです。
　つまり、「特定のEPUBの特定の箇所」を指し示したい場合に、「特定のEPUB」の方で参照先不明になります。これを解消するには、たとえば電話番号のように全世界的な番号管理の仕組みが必要になるはずですが、これがまだどこにもありません。これは国単位での調整も必要そうな大きな話なので、解決できるとしてもかなりの時間がかかるでしょう。
　また、これが解決できたとしても、紙の本から電子書籍の特定の箇所を指し示すことはできないため、紙の本と電子書籍との間で断絶が起きてしまいます。これはもちろん良くありません。「リンクを機能させたければ電子版をあらためて買いなさい」というような話になってしまいますし、それくらいなら読者が自分でページ数を見て該当ページを開く手間があるとはいえ、ページ数そのものを情報として入れた方が現実的と言えそうです。

全てのEPUBが対象というわけではない

　さて、では全てのリフロー版EPUBに紙の本のページ番号を入れる必要があるかというと、それも当然違うかと思います。小説のようなものには普通は必要ないでしょうし、紙の本から「電子化」されていない本にも元々ないものは入れようがありません。これは、「他の本の特定の箇所を参照したり、特定の箇所を参照されたりする可能性がある、紙の本から「電子化」された本」のためのものです。具体的には新書や、学術文庫などはこれに該当するでしょう（ハードな専門書は現在PDFベースで仕組みが作られているため事情が異なるかもしれません）。ストア側のアプリの対応も、そういった類の本の販売を重視しているストアは早く対応して欲しい、ということになるかと思います。

　そういった事情なので、これを要件として記述するのは「紙の本のデータからの電子化の仕様書」として作られた「電書協EPUB3制作ガイド」の改訂で、となるのは自然かなと思います。現在、電書協EPUB3制作ガイドを日本語EPUB表示の要件として各ストアがアプリを作っている状況なので、電書協EPUB3制作ガイドの改訂は紙の本のデータからの電子化に留まらない影響が出そうではあるのですが、それは本来何を求められているのかを考えた上で、個々の対応を柔軟に行っていくしかないかなと思います。