─グーテンベルクの遙か彼方へ─このブログはEPUB3をはじめとした電子書籍制作の現場からの「現地レポート」を目指しています。電子書籍制作、アプリケーション開発など、多方面の方々からの積極的なご意見をお待ちしております。※『InDesign→EPUB3用XHTML作成ワークフロー』は通常エントリに移動しました。『ジャンル別まとめ/ダウンロード』からアクセスできます。指定したURL内&特定タグ範囲の画像をダウンロードしたい2020/01/23ここ数年、Web発の出版物が日本でも目立って増えてきました。昨年のJEPA電子出版アワードの大賞をピースオブケイクのnoteが取ったことに象徴されるように、日本でもようやくWebがかつて雑誌の担っていた「告知」の役割を果たし始めているということだと思います。コミックに関してはもうずいぶん長くそれが続いているのですが、それ以外のジャンルにもどんどん波及し始めたというのがここ数年の新しい動きです。なってくると、技術サイドとしてもWebサイトからデータを取得し、電子書籍データや最終的には紙の出版物を作るためのルートを整備しなければ、という気分になってきます。いうことでここ最近はWebスクレイピングの技術を学び始めているのですが、試行錯誤してどうにか指定したURL内&特定タグ範囲の画像をまとめてダウンロードできるようになったのでメモ代わりに置いておきます。「特定タグ範囲」が今回キモです。サイドバーとかに大量に並ぶアイコン類の画像はあっても困るので。ブログ等で各エントリー部分の画像だけを抽出したいわけです。画像保存先フォルダの順で指定すれば画像を一括でダウンロードします。最初にHTMLパーサーモジュールでパースし、その後XMLパーサーモジュールで再度パースしています。XMLパーサーモジュールにHTMLを食わせたらエラーで動かなかったためです。Validでない構文の読み込みには(オプションあるとは言え)弱いということなのでしょう。今回初めて使ったモジュール、HTML::Selector::XPathがスゴい便利です。CSSの指定構文で書けばXPathに内部変換してくれるとか素晴らしい。今回は抽出テストにこのブログ(システムはWordPress)の過去エントリを使ったので措定範囲が「.post」ですが、ここは抜き出し対象のサイトごとに書き換えが必要になる感じです。変数化して引数で指定できるようにしても良かったけどどういう絞り込み条件があるかわからんのでとりあえずはコレで。次は本文テキストだぜ・・・。»Adobe-Japan1-6およびJIS2004対応の外字チェッカーを作成2020/01/17日本語EPUBの作成で結構面倒なのが「使える文字と使えない文字のチェック」です。単行本1冊で10万文字くらいはあったりしますので、それを目視でチェックして使えない文字を見分けるなどというのは普通に考えて無理があるわけです。ベテランの作業者なら対処できるとしても、そういう機械的な処理に関しては極力機械に任せて省力化したいところです。0213:2004(JIS2004)」を対象として外字のチェッカーを作りました。チェックしたいEPUBファイルのパスのような形で指定すると、以下のようなチェックログのファイルを出力します。上の例はAdobe-Japan1-6用チェッカーの指定例ですが、JIS2004用チェッカーも使い方は同じです。普段ならリストを貼って公開するところなのですが、なにせ膨大な文字をリスト化しているためとんでもない長さになるため、ダウンロードリンクを貼る形とします。KBDownloadなお、Adobe-Japan1-6用のリストは@monokanoさんのご厚意により、テキストエディタ「浮紙」用の特定文字項目ファイル内のリスト(正規表現のパターン)を流用させていただいています。JIS2004用のものは自前で調べて書きました。Mac用のアプリに統合したものはこちら。Epubcheckのバージョンも4.2.2に上がっています。各社EPUBビューア日本語組版表示チェック」を公開しました。https://juntajima.github.io/XMLPub_EPUBRSCheck/日本印刷技術協会(JAGAT)XMLパブリッシング準研究会の2018-2019年の活動としてEPUBのビューアで日本語組版に関連する各種CSSプロパティ等が再現できているかのチェックを行い、その結果をまとめたものを公開するものです。ビューアにおけるCSS表示対応の公的な情報源が存在しませんので、コンテンツ制作時の参考になることもあるかと思います。以下、表示チェックを行うにあたって大変だった点、今後期待したいことなどを書いておきます。商用電子書籍ビューアの表示チェックはかなり大変な作業です。商用電子書籍ビューアは通常個々のデバイス環境ごとに「アプリ」として提供されており、サイトで購入した電子書籍をその中で読むことができます。ブラウザと違い、「ユーザーの指定した外部ファイルを読み込むこと」はその流れの外側の話になるわけです。外部ファイルを読むための機能は別途用意しなければならないものになるため、各ビューアごとに読み込みの方法がバラバラだったりします。KindleなどではiOS版で表示チェックを行うためには事前にファイル形式の変換が必要になったりもするため、実は結構予備知識が必要になります。XMLパブリッシング準研究会での共同チェック作業でも、そのあたりの知識の共有はかなり大変でした。そんな大変なことまでやって外部ファイルを読み込み、表示させる必要がなぜあるのかと言えば、これはひとえに「電子書籍を制作する際にきちんと表示できるかを制作者や発注者が確認するため」です。そもそも外部ファイルの読み込みをサポートしていないビューアも多数あるとはいえ外部ファイルの読み込みをサポートしているならまだ良い方で、読み込みをサポートしていないビューアがまだ多数あるのが現状です。これが何を意味するかと言えば「実際に販売してみるまできちんと表示できているかわからない」ことになるわけで、この点で表示を実環境でチェックしながら制作作業を進められるWebページ制作と電子書籍制作は全く状況が異なっています。電子書籍の実制作では枯れたCSSプロパティしか実質使えない理由がこれです。率直に言って発注者の最終確認が得られない状態で製品が販売まで行くことが健全とは全く思えないのですが、結果としてそうなってしまっているのが今の電子書籍の状況です。今回のチェックでは相当新しく、実装状況が危ぶまれるプロパティにも踏み込んでいますが、外部ファイルの読み込みをビューア側がサポートしていなければ、実質ずっと新しいCSSプロパティが電子書籍で使えないことになるでしょう。個々のプロパティのサポート状況を各ビューアに直接問い合わせればその限りではないのですが、これを個別のコンテンツごとにやるのは相当に敷居が高いです。販売時にはサーバサイドで変換処理がかかることもあるまた、外部ファイル読み込みできちんと表示ができていたとしても、実際に電子書籍を販売する際には別途サーバサイドで変換処理が行われ、表示が変わってしまうケースもあります。Kindleでの埋め込みフォントの例を挙げておきます。サーバサイドで変換がかかり、埋め込みフォントが除去されてしまったりするようなことが起きます。公的なEPUBビューア表示チェックの仕組みができることを望みたいWebの世界にはwpt.fyiのように、公的なRS表示チェックの枠組みがあります。現状、電子書籍ビューアは上記のような理由でそういった仕組みを利用して個々のCSSプロパティの対応状況を確認することができません。今後、電子書籍ビューアが継続的に発展してゆくためには、何らかの公的な表示チェックの仕組みが必要になると思います。制作サイドの一員として、そういった枠組みが整備されることを強く望みます。Tajimaこちらにて、電子書籍&Web制作を担当しています。このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。整うことを願って、現場からの声を発信していこうと目論んでおります。当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。License.『電書魂』のコンテンツはクリエイティブ・コモンズによりライセンスされています。記事名の記載と、記事へのリンクを貼って頂ければ、コンテンツを自由にご利用いただくことができます。