ワード(docx)からEPUBファイルへ下準備

2018/10/3 [22:07:34] (水)

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」

»電子書籍制作代行についてはこちら

電書協準拠easy_epub暫定版

2017/6/15 [10:09:17] (木)

EPUB電子書籍の最低限の条件は、epubcheckでエラーや警告の出ないきれいなEPUBファイルであること。
…んで、以前にも言ったように、これは最低限。
kindleや楽天kobo、ibookstore、角川BOOK WALKERなどの電子書籍ストアは各々独自のレギュレーションがあってそれに合わせる必要がある。
特に画像まわり。サイズや解像度がデバイスの進歩(?)にともなってレギュレーションも変わっていく。レギュレーションに合わないものはリジェクトされたり審査に通らなかったりする。
つまり、EPUB3でエラーのないファイルでも、電子書籍ストアのレギュレーションに合ってないと、店頭に並べられないことになる。
…てなことも、以前言ってるのでこのへんで。

これとはまた別の要件というかリクエストで、
「電子書籍協会のEPUB3制作ガイドに準拠」したEPUBファイルにしてほしい。
というのがある。

epub3ファイルとしてエラーも警告もないし、ストアのレギュレーションも最低のところに合わせてクリアしてるのに、さらにまたなんで電書協ガイドに準拠しなきゃいけないのか、いまいち意味不明なんだけど…現状、電書協の制作ガイドが広く使われているので、安心できるというところなんだろう。

『日本電子書籍出版社協会＞各種勧告・資料｜電書協EPUB3制作ガイド』
https://ebpaj.jp/counsel/guide

ただ、何をもって電書協「準拠」というのかよくわからない。
・ファイルやフォルダの構成と命名規則
・スタイルシート群
だとは思うんだけど、クライアントによって命名規則やフォルダが微妙に違ってることがある。

とりあえず、ファイル分割やxhtmlのヘッダの記述、全体のおおまかなclass指定なんかをスクリプトでやっておいて、後から微調整している、というのがわたしの現状。
『かんたんEPUB3作成easy_epub』https://t2aki.doncha.net/easy_epub
↑これの「電書協準拠」版を暫定で作って使っている。

「暫定版」としたのは、上記したように結局クライアントごとの微妙な違いを修正するのに、EPUBファイルを直接編集する必要があって、このスクリプトだけで完結しないから。

ダウンロードはこちら → https://t2aki.doncha.net/release/easy_epub-denshokyo.zip
※フリー(無料)ですのでご自由にどうぞ。

使いかたはeasy_epubとまったく同じ。原稿に「小見出し」などのキーワードを埋めこんでスクリプトに流しこむだけです。
詳しくは「https://t2aki.doncha.net/easy_epub」のページでご確認ください。

easy_epubオリジナルは「FUSEe」(フリーウエア版) https://fusee.fusenetwork.co.jp/ を元に作ったもので、たぶんフォルダ名なんかが一世代前のepub2で使われているものだと思う。

easy_epubオリジナルと電書協準拠版の大雑把な違い

フォルダ構成、OPFファイル名、ナビゲーション文書(目次)ファイル名、本文xhtmlファイル名が違っている。

電書協ガイドの肝はスタイルシート群。必要とされそうなスタイルがすべて記載されていてかなりデカイ。
easy_epubオリジナルのスタイルシートはほんと最低限のものだけなので、電書協準拠版はガイド資料にあったスタイルシートをそっくりそのまま利用させてもらっている。

電書協ガイド準拠の必須条件はパッケージファイル(standard.opf)のメタデータ部分。
ここはよくわからんけど、呪文みたいなもんで、そのまま転記すれば大丈夫。

この暫定版ですが、微調整の手作業が必要なものなので、バージョンアップの予定はいまのところありません。


ところで。twitterで教えてもらったんだけど。
easy_epubの改造版があって、どうもあまり筋のよろしくない改造をされているらしい。
なんか変だなあ、と思ったらウチのオリジナルをお使いください。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

ダブルクリックでepubもmobiも開けるようになった

2016/6/30 [11:10:38] (木)

先月、WINDOWS10にしたら電子書籍ファイル、epubファイルもmobiファイルもダブルクリックで開くようになっていてビックリした。
…て、ファイルの関連付けというだけのことなんだけど。

Kinoppyをインストールすればepubファイルと関連づけされて、epubファイルをダブルクリックすればKinoppyが立ち上がって読めるようになってたのは知ってたんだけど、まさかmobiファイルダブルクリックでKindle for PCが立ち上がるとは思わなかった。いや、なんとなくダブルクリックしてkindleが立ち上がって仰天したのが、つい今さっきの話。

kindleというかKDPに登録、アップロードするための電子書籍ファイルはEPUB3ファイルをkindlegenというアマゾンの提供するコンバーターでmobiファイルに変換する。
mobiファイルに変換後、本文など中身のチェックのために、今までkindle previewerというビューワーで閲覧＆チェックしてた。

このプレビューワーは

1 Paperwhiteなどのe-ink端末やFire、iOSアプリの表示を切り替えて確認できる
2 目次やコンテンツ情報を確認できて整合性のチェックができる

と便利なんだけど。

1 実際に販売されているデータとmobiファイルが同一で実機でも同じ表示になっているのか、ビミョーで信用しきれない。
2 epub3ファイルの時点でepubcheckを通してエラーが出てなければ問題がない。

てことで、ウチの非力なネットブックじゃ動作ももっさりしてるので、本文のチェック(縦中横やルビ、圏点、太字など)だけの場合にはだるい作業だ。
でも、Kindle for PCなら、非力なネットブックでもさくさく問題なく読める。

Kindle for PCはもともとローカルのmobiファイルを所定のフォルダ(kindle_for_pc)に入れておけば読めるんだけど「mobiファイルをフォルダにコピーして」「Kindleを立ち上げて」「ライブラリで選んで」読むのは面倒くさかった。mobiファイルを修正したら、この手順を最初からいちいち繰り返し。ルビを一箇所訂正するだけでこの手順が発生する。

これがmobiファイルをダブルクリックでスグに読めるんだから大助かり、だ。
（もちろん、プレビューワーでの各デバイスごとの表示確認、というか表示の違いの確認は別途必要）

epubはKinoppyに、mobiはKindleに関連づけられている。

mobiファイルをダブルクリックするとKindle for PCが立ち上がる。



これまで、たとえば同人誌や個人出版などで電子書籍を作っても、いざ配布する時に、どうやって読むのかうじゃうじゃ説明しなきゃいけなかった。説明する方もされる方もなんだか面倒くさいし、まあいいや、になってなかっただろうか。
でも、それが「Kinoppyをインストールしてください」「kindle for PCをインストールしてね」だけでいいんだなあ。
(※mobiファイルはアマゾンの規格なので配布するのは利用規約的に微妙かな)

Kindle for PC
https://www.amazon.co.jp/dp/B011UEHYWQ
紀伊国屋Kinoppy
https://k-kinoppy.jp/

世の中、まだまだ知らないことばかりだ。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

InDesignが書き出すEPUBのモノルビの後始末

2016/6/30 [10:37:18] (木)

InDesignが吐き出したEPUBファイルを電書協準拠のEPUBファイルにしてね、という話。

電書協準拠というのは、フォルダ構成やファイル命名規則、スタイルシート群のことで、雛形に流しこめばほぼOK。
ただ、小見出しや圏点、縦中横などはInDesignで作成時にあてられたスタイルを確認してコンバートする必要があったり手作業がそれなりに積み上がる。
中でもルビがやっかいだった。

「No.36【CS5.5】EPUB関連 EPUB3.0対応」InDesignの勉強部屋
https://study-room.info/id/studyroom/cs5/study36.html
↑こちらに詳しい。

グループルビはそのまんま。
一文字ずつモノルビをあてた場合もそのまんま。

問題なのが、モノルビを二文字など複数文字にあてた場合だ…ていうか「モノルビ」っていうぐらいなんだから複数の文字に使うのがどうかしてるだろ。

「準拠」にモノルビ(じゆんきよ)の場合、EPUBに書き出すと
<ruby>準拠<rp>(</rp><rt>じゆん　きよ</rt><rp>)</rp></ruby>
グループルビの中、ルビが「じゆん」「全角空白」「きよ」となってしまう。
(EPUBはモノルビの rbタグは使えないので、グループルビの rtタグになる)

ルビに意味不明な空白などありえない。きちんとひと文字ずつのルビにしてやる必要がある。
<ruby>準<rp>(</rp><rt>じゆん</rt><rp>)</rp></ruby><ruby>拠<rp>(</rp><rt>きよ</rt><rp>)</rp></ruby>

学術書系や小説なら時代ものなどはこのルビ修正だけで生き地獄。しくしく。
てことで、InDesignの吐き出すEPUBの変なモノルビを、ひと文字ずつの正しいグループルビに変換するサブルーチンを書いた。
my $_monoruby = sub{ my $str = shift; if($str =~ m!<ruby>([^<]+)<rp>\(</rp><rt>([^<]+)</rt><rp>\)</rp></ruby>!){ my @k = split(//, $1); my @r = split(/　/, $2); return $str if ! @r; return $str if( scalar(@k) != scalar(@r) ); my @mono_ruby; while(my $kanji = shift(@k)){ my $yomi = shift(@r); push(@mono_ruby, sprintf qq{<ruby>%s<rp>(</rp><rt>%s</rt><rp>)</rp></ruby>}, $kanji, $yomi); } return join('', @mono_ruby); } else{ return $str; } }; $line =~ s!<ruby[^>]+>!<ruby>!g; $line =~ s!(<ruby>[^<]+<rp>\(</rp><rt>[^<]+</rt><rp>\)</rp></ruby>)!$_monoruby->($1)!eg;
ソフトが書き出すものだからツールで変換するのが確実。ひとの手でひとつずつ修正してたら、まず間違いなくどこかでミス・タイポが入りこむ。

ほんとperlがなかったらと思うとぞっとする。



この手の細かいスクリプトがあちこちのフォルダに散らばってる。
そのうち整理してまとめなきゃと思いつつ、汎用、使いまわしを考えすぎると、結局使う時に面倒が増えたりして使い勝手の悪いものになるからなあ。悩みどころ。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

固定レイアウト型EPUBで消耗してるヒマがあったらPDFだろ

2016/5/18 [20:46:17] (水)

ほんとたまたま重なっただけなんだろうけど。先月末ぐらいから今月に入って「固定レイアウトのEPUB3について」という話が飛んでる。

EPUBにパッケージすることで電子書籍市場が広がるので、売ることを考えるならガタガタ言わずにEUPBにするべき。でも、企業のパンフレットやカタログなんかは売る必要もない。ただし、品質的に、レイアウト・デザインは絶対に譲れない。リフローで見た目が違ってくるなんて論外である、という類のものだ。

イラストレーターやインデザインで組まれてPDFに書き出されて印刷されたもの。それを、そのまんま電子書籍で再現してくれ、ということになる。

それって、そもそもEPUBの電子書籍にする必要はあるんだろか。
オーサリングとしてめちゃくちゃ頑張ってテキスト込みで組んだ固定レイアウトのEPUB3ファイルにするにしろ、PDFを画像にして安直な固定レイアウトのEPUB3ファイルにするにしろ、固定レイアウトのEPUB3のメリットが見えないんだよなあ。

印刷に使ったPDFがあるんならそのままWEBに上げてPDFリーダーで読んでもらえば、印刷物そのまんまだし、検索もできるし、それこそ「ふりだしに戻る」だけどプリントアウトもできる。

WEBでPDFを開くのは「PDF注意」などと書かれてるところがあるように、面倒くさいのは確かだ。でも、WEBで固定レイアウトのEPUBを開いて読むのは、おそらくリフローなどとはケタ違いのサイズのファイルを開くことになるだろうから、やっぱり重苦しい。
コーポレートサイトにアクセスしてパンフなんか、その場で見るならともかく、ダウンロードして電子書籍端末やアプリで読むというのも考えにくいだろう。

てことで、固定レイアウト型EPUBファイルのPDFに対する優位性がまるで見えてこない。というかそれ以前に固定レイアウト型EPUBファイルの存在意義すら疑問に思えてきた今日この頃だ。

生徒全員にipad支給というところもあって、教育の現場でibooks、電子書籍に注目が集ってきてるだろうし、実際、教育現場へのICT導入を推進する超党派の議連もあって金が流れ込みそうでもある。教科書なんかは固定レイアウトEPUBの出番なんだけど、無理矢理の電子書籍じゃないかなあ。PDFで何がいけないのかがわからない。
ひとつ利点があるとすると、電子書籍にすれば音声を付けられる。視覚に障害のある子やディスクレイシアの子にとって有用…でも、スクリーンリーダーもあって、そこに読み上げ部分をハイライトさせる機能をつけるのと、音声つき電子書籍の普及とどっちがどっちなんだろか。技術的なことはわたしは素人なのでわからない。

文字を、テキストを読むパッケージとしてリフロー型EPUB電子書籍はこれからの読書環境だと思うし、そうなるだろう。
でもなあ、固定レイアウト型EPUB電子書籍はどうなんだろう、これから頑張れるんだろうか。もっとも、PDFにはもう伸び代もなさそうだし、どっちもどっちなんかなあ。


ちなみに、最近ついったで流れたきた固定レイアウトのネタ
5/13
インデザの固定レイアウトEPUBはそもそもiBooksでの販売しか保障してません

5/17
でんでんコンバーターから固定レイアウトをつくってみた

5/18
5社全部に配信できる単一の固定型EPUBは作れない

いやもう固定レイアウト型EPUBファイル制作は「茨の道」である。
(とはいえ、macport経由でImagemagickも無事macにインストールしたので、画像書き出しでOKなら、PDFからの固定レイアウトもどんとこいですよっ／セールストーク)

ちなみに、神保町というか白山通り脇の天ぷら「いもや」だけは間違いがないなあ、と数年ぶりに食って実感。ここの春菊の天ぷらとしじみの味噌汁は鉄板だ。
 

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

なろうをタテにしてEPUB3電子書籍でヨム

2016/4/18 [20:15:41] (月)

カクヨムをEPUB3の電子書籍に変換してダウンロードするスクリプトを書いたんだけど、カクヨムはR18禁止なのでR18がOKのなろうに退避するケースもあるとかないとか。
カドカワもTL(ティーンズラブ)小説があったような気がするけど、エロではない、ということかな。

てことで、なろうに上がっている小説をEPUB3に変換してダウンロードするスクリプトをでっち上げた。
ttp://ncode.syosetu.com/XXXXXXX
↑小説トップページ(?)目次ページのURLを入力すると電子書籍としてダウンロードできます。

とはいえ、なんだかなろうは商標についてのページや利用規約やガイドラインなんかを見るとどうもややこしいところのようなので(印象)、ダメっぽかったら取り下げます。悪しからずご了承くださいませ。


ttps://t2aki.doncha.net/tmp/narou2epub.pl
↑例によって直リンクできないフォルダなのでこちらのリンクからどうぞ。
※終了

ちなみに。
なろうを電子書籍化するサービスやアプリはすでにあるので、ニーズにあったものを探して利用してみましょう。ウチのより高機能。

「なろうを電子書籍化」WEBサービス
https://narou.nyanpass.jp/

「Narou.rb」rubyアプリ
https://github.com/whiteleaf7/narou/wiki

「AozoraEpub3」javaアプリ
https://www18.atwiki.jp/hmdev/pages/21.html



カクヨムを電子書籍に変換してダウンロードするページはこちら
https://t2aki.doncha.net/?id=1457873699

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら