ワード(docx)からEPUBファイルへ下準備
epubファイルを作成するのに元データがワードというケースがあったりなかったり。
電書オリジナルもそうだし、既存の本のOCRもデータがWORDファイルということになる。
このネタ、過去にも何度かここに書いていて、くりかえしになるかもしれないので、今回は途中で使うスクリプトをアップロードして差別化…ていうかやっとくだらないバグが取れたので(汚いケド)晒してもいいかな、と。
スクリプトを使って
・ワードファイル(.docx)を解凍(展開)
・ワードで指定されているルビ、縦中横、圏点、太字をxhtmlのタグに変換
・ルビのオフセットを出力
やることは以上3つ。
用意するものは。
・例によってperl
WINDOWSは https://www.activestate.com/activeperl/downloads からダウンロード、インストールが必要。
それ以外のOS、Macやunix系は特に必要なし。
・コマンドライン版のunzip
WINDWOSは https://github.com/bmatzelle/gow/downloads このへんからダウンロード、インストールが必要。
それ以外のOS、Macやunix系は特に必要なし、かな。
・以下のスクリプト
https://t2aki.doncha.net/tmp/docx2xhtml-tag.zip
ターミナルのコマンドプロンプトで
perl check_docx.pl word.docx
と叩くとdocxを展開して、ルビはxhtmlのタグに変換。縦中横や圏点は独自タグに変換。
「_docx-yyyymmdd.txt」というファイルを出力する。
同時に「check_docx.log」というルビとそのオフセット位置を記述したファイルを出力。
なんでこんなファイルを出力するのかというと。
ルビを削除したい時にオフセットをいじってルビを見えなくする、という凶悪なことをやってるケース。ワード上ではルビは見えないのにデータにはルビが殘っている、という迷惑なことが何度かあって ムカついたから オフセットが変なルビを確認するため。
次にターミナルのコマンドプロンプトで
perl _docx2xhtml-tag.pl _docx-yyyymmdd.txt
と叩いて、縦中横・圏点・太字をxhtmlのタグに変換。
「_docx-yyyymmdd-converted.txt」というファイルを出力する。
ワードファイルを真面目に解析すればワード上のレイアウト情報も取れるんだけど、そもそもepubファイルに変換する時に、ワード上のレイアウトを再現することを要求されることはほとんどない。
必要な情報はルビと文字装飾(縦中横・圏点・太字・傍線)ぐらいなものなので、これだけで実用には十分。
以上のことをwordを開いて目視確認(目grep)して、タグづけしてたんじゃとてもやってられんので、スクリプトにやらせることにした。このおかげで3〜4時間作業が20分作業となって取りこぼしも激減。
(スクリプトではwordのxmlを解析してごにょごにょやってるんで、そっち系のひとにはほんの少しは面白いネタかもしれない)
てことで、今日は家人と築地市場で海を食ってきた！
いや、なんというか、ほんとに美味かったなあ(涎)
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » perl(103) » 日常(903)
Androidタブレットでepubcheck
タイトルが大嘘ですみません。
AndroidタブレットZenpadにtermuxでLinux環境を作って仕事・作業もこれで間に合わせよう、というネタ。
電子書籍、EPUBファイルの作成仕事をいただいている。
作業環境というか制作に使うのはエディタとperl。
そして作ったepubファイルが正しくできているかチェックするのに必要なのがepubcheckというjavaで走るスクリプト(プログラム？)。これでチェックしてエラーや警告のないことが納品の前提となる。
wordやinDesign(の出力したepub)をエディタで確認、epubファイル生成用の独自タグを埋めこんだりその他タグの調整をして、perlのスクリプトに食わせてepubファイルのできあがり。
とりあえず作ったepubファイルをepubcheckにかけてエラーの確認。
使っているスクリプトは各クライアント用にカスタマイズ済なので、初めての案件でもない限り、ほぼエラーは出さない。
このエラーのないepubファイルを電子書籍リーダー(Kinoppy)に読みこんで確認・修正作業となる。圏点や太字の漏れや、字下げ、文字サイズ、空行の調整などを原稿(WORDやPDF)を見て、該当するxhtmlファイル(epubファイル)をエディタで開いて手作業での修正だ。
わたしは雑な性格なもんで、ここでエラーを紛れこませてしまう(なので、できるだけスクリプトにして極力手作業は避けるようにしている)
せっかくepubcheckでエラーのないファイルを作っても、その後の手作業修正でエラーにすることがある、ということだ。
ファイルを修正するたびに必ずepubcheckでエラーの確認をしている。
なのでAndroidタブレットでjavaがない、epubcheckが使えないのは致命的。
termuxでjava(jdk-8)を動作させているハッカーのひともいるけど、素人のわたしはパッケージとして用意してもらわないとまず無理。
歓喜の持ち歩けるLinux環境が宝の持ち腐れだ。
わたし得意の「とりあえず」の「やっつけ」で、epubcheckは無理だけど、できたファイルをチェックする程度のスクリプト(perl)を「でっちあげた」
前提として、epubcheckの通ったファイルであること。
手作業で紛れこませるエラーは、タグの不整合(閉じ忘れ・削除し忘れ)、追加や変更があってopfにファイルの登録し忘れ、といったところがほとんど。これらを潰せればだいたい問題はない。
タグの不整合チェックにperlのHTML Lintを入れてみたんだけど、ちょっと使い勝手が思ったのと違うので見送り。タグの数をチェックするだけで十分てことにした。
また、META-INFのcontainer.xmlから辿って、opfファイルを読みこみ、ファイルの有無、manifestとの整合もチェックする。
もちろん、この程度のものが業務実用になるとは思わないので、納品前にはepubcheckを通す。ただ、途中途中、外出先などでの確認作業はこれぐらいで十分だろう。これで急ぎの対応なんかも可能となる。自画自賛。
termuxのコンソールで走らせてニヤニヤした勢いでこの雑記を書いてるんだけど、こりゃただの日常雑記、何の役にも立たんな。
いや、ほんと申し訳ない。
ポケモンGOのイベントがひと段落したら、本格的に持ち歩きLinux環境の稼動だ。
[06/21 19:26:40]
EPUBファイルと同じ階層にスクリプトを配置。
引数にEPUBファイルを渡すと
1)unzipを呼びだして解凍
2)フォルダ構成を表示
3)opfに登録されているファイルが、EPUBパッケージの中で登録通りの場所に配置されているかチェック
4)逆にEPUBパッケージに配置されているファイルが、opfに登録されているかチェック
5)タグの不整合のチェック
・opfに登録されている「contents014.xhtml」ファイルが見当らない
・「cover00.jpg」「contents020.xhtml」がEPUBパッケージ内にあるけど、opfに登録されていない
・spanタグがおかしい。開始タグが1つあるのに閉じタグがない
・contents001.xhtmlの42行目あたり
てな感じ。
昨日書いたように、epubcheckの代わりになるものではない。あくまでも、とりあえず最低限(にも足りないけど)の確認だけ。epubcheckをちゃんと使って確認していることが大前提。
こっちのPCではepubcheckが使えるけど、こっちのPCだと使えない、というような場合の緊急避難的安心感を得るためのもの。いや、こんなんでもけっこう助かる、おれは。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
termux環境でXML::Simpleのインストール
Androidタブレットのlinux環境、termuxにperlをインストールして普段の仕事環境を構築していくネタ。
XML::Parserのコンパイルでハマったのでメモ。
結論からいうと、expat.h expat_external.hというふたつのファイルをexpatの本家サイトからいただいてきて/usr/include/に配置して解決。
expat本家→https://github.com/libexpat/
perlのXML::SimpleというXMLを解析するためのモジュールは必需品。
WEBで提供されるもろもろのデータのほとんどはXMLかjson形式なので、なくてはならないシロモノだ。
また、ワード(.docx)やエクセル(.xlsx)も、その本体はXMLファイルなので、ワードファイルの解析にもXML::Simpleは必須。というか、XML形式のデータは日常のあちこちに広く深く潜んでいる。
このXML::Simpleというモジュールは、MacOSXでも、WINDOWSのActivePerlでもデフォルトで入っている標準のモジュール(…って記憶が曖昧)
ところが、termuxのperlのパッケージには入っていないので、CPAN(perlのモジュールならなんでも揃う巨大なアーカイブ)から持ってくることにした。
CPANのインストール
pkg install cpan
makeのインストール
pkg install make
XML::Simpleをインストールするために必要なXML::Parserは(ていうか、XML::Simpleは被せもの・ガワでその実体はSAXとかParser)「.xs」ファイルを生成する必要がある、Cコンパイラが必要なので。
Cコンパイラのインストール
pkg install llvm
pkg install clang
これで準備完了。cpanのコマンドラインで
install XML::Simple
とやればインストールできるはずなんだけど、XML::Parserのインストールでエラーとなって止まってしまう。面倒くさいけどインストールのログを見ると
コンパイルに必要な「expat.h」が見つからない、というエラーで終了している。
「XML::Parser cpan expat.h」などとぐーぐる様に訊ねてみたらさくっと解答が出てきたので、expat本家サイトから「expat-2.2.5.tar.bz2」をいただいてきて解凍、その中に入っていたexpat.h(と、expat_external.h)を「/usr/include/」にコピーしたら無事インストールできた。
とりあえず今日はここまで。
というのも、termuxのlinux環境はファイルのpathが独特、というか閉じた中でやってるみたいで、スクリプトの中でファイルのコピー操作が意図どおりにいかない。これは調べなきゃ、だなあ。
termuxというAndroidのlinux環境。こりゃ久しぶりに面白いもの見つけたなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ひとりツイッター
久しぶりにスクリプトをでっちあげた。
前からちょっと欲かったシロモノ「ひとりツイッター」クライアント、だ。
この雑記帖ほどまとまった量でもなく、やること・やったこと・やらなきゃいけないこと・思いつき・考えたこと・忘れちゃいけないこと、なんかをただただメモするだけ。
だったらメモ帳でいいじゃん…てことだけど、それだとまず続かない、かなぁ。
ツイッターのように時系列で、ひとつずつの塊として記録して流していくのってけっこう面白いものだし、TODOっぽい機能をつけたので役にも立つ。
それに、そもそもスマホやPC、複数のデバイスからアクセスしたいのでメモアプリはちょっと違う。
だったらグーグルカレンダーやアウトルックでいいじゃん…てことだけど、どっちも大袈裟・ご大層。ちゃっちゃと開いてちゃっちゃと書くという感じじゃない。構えなきゃいけないのは続かない。
だったらgmailで自分宛にメールすればいいじゃん…てことだけど、いちいち件名とか入れるのが面倒くさい。だいたい、数時間とか数分ごとに書きこんだりするのに、大量のゴミメールがストックされるとうっとーしーのでメールそのものを見なくなる。
だったらツイッターで鍵アカを作って書けばいいじゃん…てことだけど、わたしはWEBサービスを信用してない。人に見せることを前提にしていないのだ。もし万が一にも書いたことが漏れたら大変だ。個人的なこと、ひとには言えないことなんかもあるかもしれない。
てことで、この「ひとりツイッター」あるいは「王様の耳はロバの耳の穴」とか「ライフログ」的なものとなる。
・何か思いついたら書きこんでチェックイン。
・書いたものが終ったら、片付いたらチェックアウト。
・書いたものは新しもの順に並ぶ。
・TODOとしてチェックしたものはトップの方に表示する。
・チェックアウトしていないものを抽出できる(TODOにする必要はない)
・検索ができる。
というのが最低限の仕様。
エントリの編集機能？
いやいや、ツイッターを見てくれ。投稿するか削除するかの二択で十分だ。
リマインダーのメールを飛ばす？
いやいや、いろいろとしんどい時もある、そんな時にリマインダーなんぞ見たいか？
カテゴリわけする？
いやいや、いちいちそんな整理整頓やってられるか？時系列で並べば十分だろ。超整理法とかって聞いたことないか？
しばらくこんな仕様で使ってみよう。
ボケ防止にもなる、はず。
[2016/12/01 21:33:22]
さっそく昨日から使いだした。思った以上に使い勝手が良い（自画自賛）
というか、スマホ前提にしたのが勝因かな。いつでもどこでもメモ、独り言、譫言だ。
こいつのデータベースはSQLiteなので、実体はファイルひとつ。今はlolipopに置いてるけど、レンタルサーバーを引っ越すことになってもひとつのファイルをコピーしてもっていけばいいだけだ。
下のスクリーンショットからもわかるように、誰の役にも立たない独り言。こーゆーのもいいもんだ。
 |  |
| 最上部のテキストエリアに記入したらチェックイン | こんなくだらないことを書くわけだから「ひとりツイッター」というか「独り言」 |
 |  |
| 日付順に並ぶ。まだチェックアウトしてないものも混じる。チェックアウトしてないものはゴミ箱に捨てられる。 | テキストエリア左下のチェックアイコンをクリックしてチェックアウトしていないものをリストアップ(リストアップ状態ではチェックアイコンがリロードアイコンとなる) |
 |  |
| 虫めがねアイコンにチェックいれて、テキストエリアに検索ワードを入力してチェックインすると（ここでは「検索」） | 検索結果と検索にヒットした件数も表示 |
こんな独り言アプリはすでにあるらしい。
SNS、ソーシャルとかでひとと繋がりたいばかりじゃない。そういうのがめんどいとかしんどいとかって時はブツブツ独り言でいいんじゃないかな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
InDesignが書き出すEPUBのモノルビの後始末
InDesignが吐き出したEPUBファイルを電書協準拠のEPUBファイルにしてね、という話。
電書協準拠というのは、フォルダ構成やファイル命名規則、スタイルシート群のことで、雛形に流しこめばほぼOK。
ただ、小見出しや圏点、縦中横などはInDesignで作成時にあてられたスタイルを確認してコンバートする必要があったり手作業がそれなりに積み上がる。
中でもルビがやっかいだった。
「No.36【CS5.5】EPUB関連 EPUB3.0対応」InDesignの勉強部屋
http://study-room.info/id/studyroom/cs5/study36.html
↑こちらに詳しい。
グループルビはそのまんま。
一文字ずつモノルビをあてた場合もそのまんま。
問題なのが、モノルビを二文字など複数文字にあてた場合だ…ていうか「モノルビ」っていうぐらいなんだから複数の文字に使うのがどうかしてるだろ。
「準拠」にモノルビ(じゆんきよ)の場合、EPUBに書き出すと
グループルビの中、ルビが「じゆん」「全角空白」「きよ」となってしまう。
(EPUBはモノルビの rbタグは使えないので、グループルビの rtタグになる)
ルビに意味不明な空白などありえない。きちんとひと文字ずつのルビにしてやる必要がある。
学術書系や小説なら時代ものなどはこのルビ修正だけで生き地獄。しくしく。
てことで、InDesignの吐き出すEPUBの変なモノルビを、ひと文字ずつの正しいグループルビに変換するサブルーチンを書いた。
ソフトが書き出すものだからツールで変換するのが確実。ひとの手でひとつずつ修正してたら、まず間違いなくどこかでミス・タイポが入りこむ。
ほんとperlがなかったらと思うとぞっとする。
この手の細かいスクリプトがあちこちのフォルダに散らばってる。
そのうち整理してまとめなきゃと思いつつ、汎用、使いまわしを考えすぎると、結局使う時に面倒が増えたりして使い勝手の悪いものになるからなあ。悩みどころ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » 電子書籍(278) » perl(103)
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
http://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
http://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
http://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
http://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。
【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト
【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から
→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID（＝データベースで決められたID）を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。
→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL：ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」
→「即時支払い通知」(IPN)
・通知URL：IPNを受信するスクリプトのURL
・メッセージの配布：有効
→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」
【PayPalとのやりとり】
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。
ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。
購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。
3)PDT(Payment Data Transfer)
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる
このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム＝バリュー」形式、NVP形式のデータとなっている。
※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。
PDTデータ取得＆解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。
PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「～様」や「～をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。
4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム＝バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。
IPNデータ取得＆解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)
※データ確認の部分やメールの部分以外はサンプルコードのまんま。
【ダウンロードについて】
ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所＝URLをそのままユーザーにお知らせできない。
ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。
また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。
以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。
残念なことに(法律的に？)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
