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

　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制作ガイドの改訂は紙の本のデータからの電子化に留まらない影響が出そうではあるのですが、それは本来何を求められているのかを考えた上で、個々の対応を柔軟に行っていくしかないかなと思います。

Vivliostyle CLIの環境構築

　まず、node.jsを入れます（参考）。homebrewは入っていることが前提です。ターミナルで

これだけ。

でnodeのバージョンが表示されればOKです。

　次にVivliostyle CLIを入れます。同じくターミナルで

これだけです。

Perl経由で自動化

　これを従来同様にPerlで実行できるようにしたのが以下のコード。

　ノンブル表示、見開き指定などのための追加CSSは –style オプションを使って外部ファイルを読み込む形としました。その方が修正もしやすいし（追加CSSの参考例はVivliostyle CLIのオンラインマニュアル内にある）。「vivliostyle preview」を指定しているので、Chromiumブラウザが起動してページが表示されます。あとはこれまで通り印刷ウィンドウでPDFを保存を選択して出力するだけです。だいぶ簡単になりましたね。
　なお、その後Chrome側でバグが修正されたとのことなので今は古い方のスクリプトでも問題なくPDF生成はできるようです。