epub3電子書籍制作作業メモ
今やってるepub3電子書籍制作仕事、というか作業に使ってるperlスクリプト類のメモ。
どのクライアントさんも、元データをいただいて、こちらでepub3ファイルに梱包するという作業。自分で原稿を集めて編集して、ということではなくて文字通り「電子書籍制作」で実態はファイル変換作業。
扱うのは、ほぼほぼ小説なのでデザインやレイアウトはシンプルなものばかり。
(以下はNDAに抵触しない、わたしの作業と使用スクリプトについて)
作業フローとしては
・事前確認
・変換作業
・事後確認
このために作って使ってるスクリプトは、元データ次第なんだけど、
事前確認に5本、変換作業に4本、事後確認に11本
だいたいこんな感じ。
元がひとの入力だし、表記表現の揺れがあったり、タイプミスもあるので、それをスクリプトでひっかけるために、確認用だけで16本のスクリプトが必要となっている。
最終的に目視するにしても、ひとの目視確認は信用できないので、スクリプトで対応できそうなものはスクリプトに任せたい…気がついたら確認用が次々と増えてきた。
もう大丈夫だろうと思っても、ひとのすることは例外処理だらけで、毎回何かある。
1)
原本がPDFの場合、pdf2textを使ってPDFとテキストを比べて確認。
PDFで見た目を調整されてる場合、元データのテキストと違いが出てしまう。違う箇所を引っ張り出して、元データを編集する必要がある。
2)
元データにスタイルが指定されている場合、どんな指定をされているのか確認。
縦中横などの漏れを防ぐためのすべてピックアップして確認をする。
3)
絵文字のチェック。
今どきはutf8なので機種依存についてはあまり気にする必要もないハズだけど、絵文字はさすがにアウト。エッセイなんかだとたまに入ってることがある。レアなケースだから目視で見落とすので、スクリプトにした。
4)
ルビのチェック。
ルビの使い方がわりとフリーダムなこともあって、これをルビにするの?というのを確認しておく。
5)
元データを変換しやすくするために、使わない部分を削除。
必要なのは本文部分で、それ以外が入ってるケースがあるのでスクリプトでカット。
その後、改ページの指定など手作業を入れて事前整形して変換用のテキストデータを作る。
6,7,8,9)
epub3ファイル群に変換する。
10)
半角文字の確認。
縦中横に指定されるべき半角文字列の確認。ついでに、感嘆符や疑問符の後ろに空白がひとつあるかないかの確認。
11)
半角縦中横のタグについての確認。
10で確認した箇所に意図通りのタグが当たってるか、あるいは意図通りタグが当たっていないことの確認。
12)
メタ情報の確認。
epub3に梱包するに当たっては書誌情報ファイルが必要。スクリプトで自動生成させてるので、その確認用
13)
全てのタグの確認。
epub3電子書籍というのはHTMLの集まり。変換スクリプトで正しくタグが当たってるか、どんなタグが当たってるか確認用。
14)
無用な空行、必要な空行の確認。
PDFとの目視確認だと見落としがちなので怪しいところをピックアップ。
15)
目次の確認。
5で改ページ指定などを手作業していて、ここでミスが入り込む可能性がある。ので、epubにした後に原本と目次があってるか確認が必要。
16)
圏点やダーシの確認。
ものによって、原本ままだったり調整が必要だったりするので、確認。
17)
変換後のルビの確認。
4でチェックしたものと差異はないかの確認
18)
変換後の目次の確認。
15とはまた別。こちらは表示用目次の確認。正しく設定されているか。
19)
句読点で終わってないのに改行されている箇所の確認。
見た目の改行とデータ的の改行で違う可能性がある。特にワードなんかが元データの場合。
20)
epubファイルからHTMLタグを削除してただのテキストデータにする。
5で作った変換直前のテキストファイルと差分を確認するため。
列挙してみるとやっぱり確認作業だらけ。確認でなにかひっかかると元データに戻って編集して変換スクリプトで変換してまた確認、というループになる。
スクリプトでやっつけてるので、機械的流れ作業に見えるけど、本(小説やエッセイ、俳句なんか)が好きで読んでなかったら見逃す見落とすケースの確認作業。それらをepub3ファイルにすり合わせるのがキモということになる。紙本と電子書籍、両方のことを知ってないとわからない、というか勘が働かないところだろう。
そこが面白いところだし、わたしが仕事をもらえてるところだと思う(思いたい)。
まだ確認すべきトラップというかご新規さんが出てくるだろうから、確認用スクリプトと目視確認作業は増えるんだろなあ。
ひとの入力は予想がつかないし手強い。
[2024/11/29 10:07:01]追記
スクリプトでもろもろ確認後
kinoppyとkindle previewerでの実際の表示、動作の確認。これが最終形態なので、ここでの目視確認の負担軽減がスクリプト類での確認作業、てことになる。
トーハクは庭園もおすすめスポットだった。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
電子書籍でエラーになる絵文字の検知
今回のエントリは。
経緯
・電子書籍でエラーになるのが絵文字だった。
・元データから絵文字を検知する必要が出てきた。
結論
・perlを使えば絵文字のチェックも簡単だった。
てことなんだけど、調べてみたらunicodeまわりが魔窟でびっくり。またハマりそうなのでメモ。
以下は、何を今さらという話が無駄に長くて、既知のかたには役に立たない内容です。
電子書籍に求められる基準はほぼ以下のふたつ
・Epubcheckでエラーはない。
・kindle previewerでエラーはない。
epubcheckでエラーがなければEPUB3の電子書籍として問題はないし、kindle perviewerでエラーをチェックするのは最大の配信サイトであるAmazonでエラーがあったら商売上よろしくないから。
上記2つのチェックをクリアしたのに、一部の配信サイトでエラーになるという指摘があって、追いかけてみると、問題になったのが「絵文字」
「😀」←こういうやつ
原稿に絵文字があったんで、あれ?これってイケるんだっけと思って作ってみて、上記2つのチェックにかけてもエラーはなかった。
文字コードがShiftJISの時代ならともかく、今どきはutf8。
utf8のおかげで文字化けなんかを気にする必要はほぼなくなった。機種依存、環境依存文字に神経質にならなくていいのはストレスフリーで、いい時代になったもんだとのんきに感慨深い今日この頃だったのに…。
文字として問題はないんだけど、配信サイトごとにビューワーが違ってたりして、そのビューワーが絵文字に対応してるかどうかのことだと思う。
「EPUB | CSS組版ブログ」
https://blog.antenna.co.jp/CSSPage2/archives/category/epub
↑絵文字なんかについて、縦書きのepub3が始まった頃に議論があったらしい。
(電子書籍元年当時の話が読めるのでオススメ)
「横倒しのまま」にするのか「正立させる」のか。文字の意味的に方向があるものは正立させる?とか。そのあたりのすり合わせが問題になってたっぽい(という理解でいいのかなあ)
これは縦書きの場合、見た目けっこう致命的なので、たぶん、絵文字の対応を見送ったビューワー=配信サイトがあったんじゃないかと思う(憶測)
あるいは、そもそも、絵文字は環境ごとで見え方も違うのでそこが問題なのかもしれない(憶測)
そんなこんなの名残りもあって、面倒なものは却下、ということで今でもエラーにする配信サイトがある、んだろう(めっちゃ憶測)
epubcheckでもkindle previewerでもエラーにならない文字を自前で検知する必要にせまられる事態となった。
電子書籍のボリュームを目で追ってその中から絵文字を見つける、目視で探すなどありえない。必ず漏れが出る。
なもんで、絵文字の文字コードを調べてみて改めて今さらびっくりのunicodeだ。
ちなみに、文字を表示させるためには、以下の2本立てになっている。
・unicodeの文字コード表で文字を指定特定していて
・文字コードをエンコードすることで文字を表現する
これ、けっこう勘違いするんだけど、utf8というのは文字コードではなくてunicodeの文字コードをエンコードする方法の名前のこと。
以下のサイトを読んでまたびっくりすることをおすすめする。
「文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう!」
https://en-ambi.com/itcontents/entry/2020/04/28/103000/
「書記素クラスタ - daiizfeel 2022」
https://isobe-yaki.hateblo.jp/entry/2023/07/20/194803
てのはともかく、読んでも難しいんで、なにか大変なことになってるんだなあ、でOK。
そもそもutf8でエンコードされた、日本語などは、ひと文字を表すのに、そのコードは3バイト使う。
ひとつの文字がアルファベットのように1バイトではないので
たとえば「日本語の文字」の6文字は、1つの文字に3バイトのコードが必要で、文字列の長さをバイト数でいうと18となる。
文字数いくつだっけ?て時に、バイト数の18ではなくて「正しく」6と数えるためにエンコードされている必要がある。
unicodeのコードをエンコードして初めて「文字として認識される」
このエンコードする方法がutf16だったりutf8とか呼ばれて、エンコードすることで初めて「文字として認識された文字を表示する=扱うことができる」という変な日本語。
perlの場合、utf8フラグというのを使うことで問題解決する。
my $str = '日本語の文字'
my $utf8 = Encode::decode('utf8',$str)
print length($str)
→18文字
print length($utf8)
→6文字
perlはこのおかげで、文字の扱いについて、普段はまずほとんど、こんな面倒くさいことを意識する必要はなくて、なもんで、すっかりわけがわからず混乱してしまったのが昨日今日の話、だ(とほほ
unicodeとutf8についてのおさらいができたところで、やっと本題。
じゃあ、絵文字を検知するには絵文字が使ってるコードを見つければいいだけじゃん。簡単だろ、と思ったらまたひと悶着。
ていうか、ここからが今回の本丸、一丁目一番地(死語)
utf8フラグだけでは解決しない「結合文字」というのがあった。
「1つの文字を表示しているのは、1つのunicodeのコードポイント」とは限らない。
ひとつの文字を表示、扱うのに、複数のunicodeのコードポイントを使ってるケースがあって、見た目のひと文字とそれを表すコードは1対1ではない、ということ。
perlでutf8フラグがついていてもutf8の文字コード(←unicodeコード表によるコードではなくてエンコード後の文字コード)2つ結合した文字はlength()では意図通りに取得できない。ひと文字として扱ってほしいのに、たとえば二文字としてカウントされてしまってお手上げ。
実のところ、書記素クラスタというのはこういう結合文字も含めた呼び方で、書記素クラスタに対応すれば「結合文字」も「ひと文字」として扱うことができる。書記素クラスタというのがなんだか「とても面倒くさい」というのはこのあたり。
こうなってくると、電子書籍でエラーをなくすために、なんでこんなことまで調べにゃならんのか。そもそもレアケースだし、配信サイト個別のクレーム対応でいいんじゃないのか。と思わないでもないけど。乗りかかった船だししょうがない。
話がそれた。
perlはこれも解決してくれる。て、テキストを扱わせたらperl最強じゃね?
「絵文字を含む文字列を分割~解説編~」
https://www.lemorin.jp/perl/3b_split_char.html
↑こちらのサイトに知りたいことのすべてがあった(多謝
my $line = Encode::decode('utf8', $_);
my $len = length($line);
print $len . "\n";
my @x = $line =~ m!\X!g;
print scalar(@x) . "\n";
length()では「見た目のひと文字」じゃなくて困ってたところ、perlでは「いい感じに」「ちゃんと」文字として認識できる文字のための正規表現「\X」が用意されてた。
「perlの正規表現」
https://perldoc.perl.org/perlrebackslash#Misc
ということで、やっと本エントリの締めとなります(長っ!
問題のない文字ダネを削除して残った文字を正規表現「\X」で配列に取り出して、「見た目のひと文字」をコードポイントにバラして16進表現して絵文字のコードに検索をかける。検索がヒットしたら、それはイコール絵文字。
「HTMLの絵文字 文字コード表」
https://gray-code.com/html_css/list-of-emoji/
↑絵文字のコードはこちらの一覧から拝借しました。
こちらで掲載されているコードを絵文字判定の対象としました。
これでやっと絵文字検知。
前から言ってるんだけど、人間の目視確認、手作業修正(目grep、手marge)なんて1mmも信用できない。特におれ。なので機械に頼めるなら機械に任せるのが正解。
↓こちらも参考になりました
「Perl 5.26 & Unicode 9.0 で変わる書記素クラスタ(grapheme cluster)のお話」
https://shogo82148.github.io/blog/2017/08/25/unicode9-grapheme-cluster/
「UTF-8の文字コード表」
https://orange-factory.com/dnf/utf-8.html
本エントリとはまったく関係ないけど。
この埼玉県八潮市の資料館はびっくりの充実。行く前は小学校の教室ぐらいなもんだろ、と思っててすみませんでした。
交通アクセスにちょっと難があって、気楽にとはいえないけど、行けるかたはぜひぜひ
https://www.city.yashio.lg.jp/kurashi/shisetsuguide/shiryokan/index.html
[08/25 16:58:54] いろいろ間違えてたので改稿
「文字につかうバイト数」と「コードポイント」を混用していた、という乱暴な理解だった(恥
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
縦書き電子書籍のための縦中横
青空文庫に限らず、縦書きのEPUB電子書籍を作る時に半角の英数字を縦にするための小ネタが今回のエントリ…なにを今さら、というネタで、縦書き文章で半角英数字の縦中横なんて当然。
それでもネタとして取り上げるのはビミョーに考えることがあって、たぶん、どんなことを縦中横にするのか、どうやってるのかがいろいろあるから。特にWEB経由の文章は半角英数字がてんこ盛り。全部対応するのはやってられないけど。
・一文字の英数字は全角の英数字にして縦表示にしたい。
・数字の3桁以上は縦中横にすると無理矢理感が強い。この場合はそのまま転がしておきたい。
↑このへんがこだわりどころ。
そのために使ってるのが以下のもの
置換する時にゴソゴソする必要があったのでメモ…「1 while〜」のあたり、たぶん5分後には忘れる
・perl
sub _tcy{
my $self = shift;
my $str = shift;
return $str if $str =~ m![0-9][0-9][0-9]+!;
$str =~ s!([a-zA-Z0-9\!\?][a-zA-Z0-9\!\?]+)!sprintf(qq{%s}, $1)!eg;
return $str;
}
sub h2z{
my $self = shift;
my $str = shift;
$str =~ tr/a-zA-Z0-9\!\?/a-zA-Z0-9!?/;
return $str;
}
sub add_tag{
my $self = shift;
my $str = shift;
$str =~ s!^([a-zA-Z0-9\!\?])([^a-zA-Z0-9\!\?])!$self->h2z($1) . $2!e;
$str =~ s!([^a-zA-Z0-9\!\?])([a-zA-Z0-9\!\?])$!$1 . $self->h2z($2)!e;
1 while $str =~ s!([^a-zA-Z0-9\!\?])([a-zA-Z0-9\!\?])([^a-zA-Z0-9\!\?])!$1 . $self->h2z($2) . $3!eg;
$str =~ s!([a-zA-Z0-9\!\?][a-zA-Z0-9\!\?]+)!$self->_tcy($1)!eg;
return $str;
}
・style sheet
.tcy {
-webkit-text-combine: horizontal;
-epub-text-combine: horizontal;
}
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
青空文庫をEPUB3電子書籍に変換
青空文庫の『罪と罰』(ドストエフスキー/米川正夫 訳)をepub3の電子書籍にした。
以前も何回かやってるんだけど、今回、割りと真面目にスクリプトを作ったのでメモしておこう、というエントリ。
青空文庫の資産は膨大だし、なんといっても青空記法が最強だろう。
それに、青空文庫の本を制作する姿勢は見ていて背筋が伸びるほどちゃんとしている。
底本の誤植の指摘、ルビや圏点はもちろん、字下げや地付きといったレイアウトについても底本を忠実に再現している。
「青空文庫」
わたしはmarkdownというかその手のなんちゃら記法には否定的で、そんなものを学習するヒマがあったらhtmlを読み書きできるようにしたほうが早い、と思っている。
それでも青空文庫の青空記法だけは別格で、全角文字で指示を入れる・可読性の優れた書き方、おそらく入力ボランティアさんにとても優しい。全角文字というのがポイントで、これによってプログラム的なタグやなんかとバッティングする心配がない。
これでほぼ表現すべきことを網羅、対応してるんだから改めてびっくりさせられる。
今回作ったのは。
・青空文庫で公開されている本のテキスト版、zipファイルをダウンロード
・ダウンロードしたzipファイルを所定のディレクトリに保存
・書誌情報(タイトルと著者名)を記載したファイルを作成
・カバー画像を作成して所定のフォルダに保存
以上で、あとはスクリプトを叩けば電子書籍の出来上がり、というもの。
そして、今回一番手こずったのが、JIS第3水準、第4水準の漢字の扱い。
青空文庫のテキストファイルは歴史的経緯もあって文字コードがShiftJIS。青空文庫が始まった時期的に当時としては最適だったんだけど、今から始めるならutf8だったろうなあ。
ということでシフトJISで扱えない漢字、第3水準、第4水準の漢字については
[#「木+吶のつくり」、第3水準1-85-54]
などと、青空記法で記載されている。
最初、コード変換なんて計算させればいいんだろう、ぐらいに考えてたら甘かった。
グーグル先生にお願いしてもそんなお手軽な方法は教えてくれない。
どうやらベタでコードと漢字のハッシュを作って対応するしかないっぽい。切り替えて検索方法を変えて探して見つけたサイト
JIS第3水準漢字一覧表【全1259字】(JIS X 0213:2004)
https://www13.plala.or.jp/bigdata/jis_3.html
JIS第4水準漢字一覧表【全2436字】(JIS X 0213:2004)
https://www13.plala.or.jp/bigdata/jis_4.html
(※どちらもhttpsではなくてhttpでアクセスしてください)
こちらに「テキストでコピーできる一覧表」があった。
こちらにも書かれてるように「使いやすい一覧表が無く、コピペできないPDFとかしか無かった」のはほんとその通りで、こちらのページには大感謝、だった。ありがとうございます。
これをスクリプトに仕込んでハッシュに読み込んで、青空文庫のJIS3、JIS4に対応することができた。
これさえクリアしてしまえば、EPUB3ファイルを作成するについては使いまわしの部品の組み合わせだけ。おかげで、青空文庫から電子書籍化が簡単になった。
手作業が必要なのは「タイトル・著者名を記載したテキストファイルを作成する」のと「カバー画像を作成する」の2つだけ。カバー画像はこだわらなければ真っ白の画像でもかまわない。
とはいえ、せっかくだし「本」「書籍」っぽくしたよなあ、という欲も出るんで、カバー画像を作るのに時間が一番かかる。
今どきはAIにイラストを発注することができるので、『罪と罰』のカバー画像もAIにお願いした。
年寄りの趣味として本作りは悪くない趣味じゃないかなぁ。
で、こんなネタで終わらせると申し訳ないので、上記サイトからいただいた漢字テーブルを貼り付けておきます。全部で3817行あります。未定義のところは「〓」を入れてます。
・jis3で始まるのは水準3。jis4で始まるのは水準4
・続く「-」で繋がってるのは面-区-点
・「,」の後ろが該当する漢字
※ネタ元のサイトはヒエログリフなんかもあって、めっちゃ充実しているんでぜひ飛んでみてみてください。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
WORDをテキスト保存した時のルビの捕捉
いや、あいかわらず雑なネタ。
.docx、ワードファイルではなくて、ワード文書を書式なしテキストで保存したテキストデータがたまにやってくる。基本的にシンプルなものが多くて流れ作業で済む。
…なんだけど、ルビのついたものがたまにあるのでその対応のメモ。
ワードの文書を書式なしtxtで書き出すとルビは
「これは漢字(かんじ)にルビがつく」
などと、ワード文書ではルビのところが、漢字と半角カッコでくくられたルビにわけられて保存されることになる。
そういや、以前もこんなことあったなあと思い出して、この雑記帖を検索したら出てきたのが
青空文庫のルビや傍点をHTMLタグに変換
https://t2aki.doncha.net/?id=1443167217
↑このエントリ。
青空文庫で使われている、青空記法は多くのひとに使われるように、よく練られているなあ、と感心した記事で、やっぱりさきほども改めて感心。
てことで、その時の記事からほぼ流用したのが以下のスクリプト。
perlで、Unicodeブロックを使った正規表現で漢字やかなを拾えるんで大助かり。
ただ、こいつはビミョーで、漢字に続いて半角カッコがあるのは、ワードが吐き出したルビだけとは限らないし、ルビの対象となる漢字の範囲がこれだけだと特定できない。
青空記法では問題にならないんだけど、ワードの吐き出しに多くは求められない。
なので、あくまでも初校作成時の手助け程度、かな。
にしても。
まだ5インチと3.5インチのフロッピーディスクが現役で、MSDOSは3.0が出た頃、NECの98シリーズが人気だった頃だからもう40年近く前の昭和の頃。日本ダービーでシンボリルドルフが皇帝になった頃。
Wizardryというゲームがやりたくてパソコンを買って、その後競馬データをこねくり回すために使いだしたawkやperl、unix環境。言ってしまえば、遊びでやってた当時の余録で、還暦すぎても小遣い稼ぎができるんだから、なにが役に立つのか立たないのかなんて、その時にはわからないもんだわな。
仙人の弟子の雑巾がけ庭掃除のネタは深いものがあるなあ(しみじみ)
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
Chromebookで電子書籍を読む
正規のChromebookはgoogle playからアプリをダウンロードして使うことができる。
デスクトップやノートパソコンでAndroidアプリが使えるということになる。
やりたいことは。
ASUSのChromebook CX1101で電子書籍を読む、というか表示確認をしたい。
今のところ、ChromebookというかChromeOSで制作した電子書籍を確認するためには、
・WINDOWSのノートパソコンを起動して
・電子書籍ファイルを共有フォルダに保存して
・WINDOWS版のKinoppyを立ち上げて読む
これだけっちゃこれだけなんだけど、この「これだけのために」が面倒くさい。
手元のChromebookでそのまま確認できればらくちん。
てことで、ASUSのChromebook CX1101でも電子書籍を読めるように電子書籍リーダーを探してみた。
google play storeで確認したところ。
kindleとkinoppyはChromebookに対応していない。
kindleについてはgoogle play storeではなくて、Amazon アプリストアから直接ダウンロードすれば使えるらしいけど、いくつか手順が必要でそこまでやる?
https://www.itmedia.co.jp/news/articles/2206/15/news181_2.html
↑chromebookにamazon アプリストアをインストールする方法
大日本印刷のhontoがChromebookでも使える
https://play.google.com/store/apps/details?id=jp.co.dnp.eps.ebook_app.android
問題なくgoogle play storeからインストールできた。
すでにhontoで購入済みの本も本棚に同期されていて、すんなり読める。
ローカルの電子書籍、epubファイルを読ませるには、リーダーごとに指定された保存フォルダにepubファイルを保存する必要がある。
Andoroidアプリのhontoの場合は
/storage/emulated/0/Android/data/jp.co.dnp.eps.ebook_app.android/files/epub/
↑ここにファイルを保存する。
chromebookではどこに保存するのか探してみた。
chromebookの「ファイル」アプリで「マイファイル」→「Playファイル」
「すべてのPlayフォルダを表示する」にチェックを入れると出てくる
/mnt/chromeos/PlayFiles/Android/data/jp.co.dnp.eps.ebook_app.android/files/epub/
↑ここにファイルを保存する。
とりあえずはこれでOKかな。
ほんとは本体に保存するのではなくて、作業しているSDカードをlinkしたいところだけど、
ln -s
で権限がないとはねられる。Playファイル以下にあるフォルダ側の権限の問題っぽい。
最終的に納品前にkindle previewerでの確認も必要なので、WINDOWSを立ち上げることになるんだけど、途中途中のちょっとした確認はこれで手間がずいぶん省ける。
電子書籍を自分が読む時はスマホなんだけどね。
昭和の書籍の文字サイズは老眼には厳しいんで、古本ではなくて、文字サイズを変更できる電子書籍がありがたいんだよなあ(ポンコツ)
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」