はじめに
電子書籍というと「結局は Word とかで書いた方がいいんでしょ？」といったイメージがありますが、Markdown で書くこともできそうです。とはいえ Pandoc のように専用ツールを使うのも、それはそれで大変そう。
色々調べたところ、手軽に書ける方法があったので、試しに一冊書いて出版してみました。ハマった点やノウハウなどを雑多にまとめたいと思います。
なお環境は Windows を前提とします。他の OS でも基本的に問題はありませんが、一部 Windows を前提とした手順やツールなどを含みます。
全体イメージ
執筆から出版までの全体の流れは以下のようになります。
- (1) 出版先は KDP( Amazon Kindle Direct Publishing )なので最初にアカウント登録する
- 著者情報や振込先など
- (2) 原稿はテキストファイルに Markdown で書く
- 画像は同じディレクトリに jpg で配置
- css や yml ファイルを置いて見栄えやメタデータの設定も可能
- (3 )原稿は でんでんコンバーター で epub ファイルに変換する
- ブラウザから原稿ファイル(リンクしている画像など含む)を選択してアップロードすると、しばらくして epub ファイルのダウンロードが開始するというサービスです
- プレビューは Kindle Previewer に epub ファイルを食わせることで行える
- (4) epub ファイルを KDP にアップロードして出版
本記事では KDP 部分の手順（アカウント登録や出版時の値段設定など）については取り上げません。
必要な知識・スキル
- Markdown
-
でんでんマークダウン
- といっても Markdown に追加文法があるだけです
- 追加文法例1: 改ページ
=== - 追加文法例2: ルビ
{電子出版|でんししゅっぱん}
- (見た目を整えたいなら) CSS
- (カッコイイ表紙をつくりたいなら) 画像編集ソフトウェアの知識
今回の成果物
書いた本
「ファイル名を指定して実行」のすべて という本です。
元ネタは過去記事 「ファイル名を指定して実行」を極める になります。最初は 1-2 万文字以下を予定していましたが、結果的に 5 万文字になってしまいました。 とはいえ Markdown 文法やファイルパスなどもあるので、純粋な文章量はもっと少ないです。
以下、この本のことを「本書」と書くことにします。
データ
テンプレートという形で GitHub にアップロードしてみました。
stakiran/eBook_sample_with_markdown
でんでんコンバーターのメリット・デメリット
でんでんコンバーター は Markdown ファイルを epub ファイルに変換するウェブサービスです。
メリット
とにかく手軽です。
- 操作が簡単
- ブラウザから参照ボタンでアップロードしたいファイルを複数選択するだけ
- KDP へのアップロードにエラーにならないよう、ちゃんとした epub に変換してくれるため、変換作業に苦戦しない
また、ある程度のカスタマイズもできます。
- CSS ファイルで見た目を整えることができる
- ddconv.yml で書籍情報を定義しておける
- このファイルをアップロードすると、でんでんコンバーター上のフォームにいちいちタイトル等を入力せずに済みます
デメリット
変換を自動化できない、大きな書籍には使えない、かゆいところに手が届かないなどデメリットも色々あります。
- いちいちブラウザから参照をボタンを押す手間があり、変換が面倒くさい
- サーバーの混み具合によっては変換に30秒以上待たされることもある
- 10万文字以上など中規模以上の書籍を変換できない
- CSS の限界
- シンタックスハイライトされない
- フォントを変更できない
- ファイルを他ディレクトリに配置できない
- ファイルはすべて同じディレクトリ内に配置する必要がある
でんでんコンバーター応用編
CSS
アップロード時に CSS ファイルを指定することで、文書のスタイルをカスタマイズできます。
ポイントは以下二点です。
- (1) デフォルトの CSS は Downloads - でんでんコンバーター の default.zip を見て確認する
- (2) いじった CSS がどう見た目に反映されるかは 電書ちゃんのでんでんエディター 上で確かめると早い
- 変換後の HTML もチェックできるので便利です
デフォルトのままだと色々だと気に食わないので、自分なりにあれこれ修正していくことになると思います。
私は このようなCSSファイル を作りました。内容のいくつかを挙げておきます。
リテラルと整形済みテキスト
リテラルは <code> で囲まれ、整形済みテキストは <pre> と <code> で囲まれるので、この二点を意識してセレクタを指定します。黒背景に白文字で表示させてみました。
/* 黒背景白文字ベースと, 左寄りすぎで見づらいのを少し離す.
code 単体だと pre 内の行毎に適用されるのでセレクタ指定は工夫する. */
pre {
margin-left: 2px;
padding-left: 4px;
color: white;
background-color: #333333;
border: 1px solid silver;
}
p > code, li > code {
margin-left: 2px;
padding: 4px;
color: white;
background-color: #333333;
}
ちなみに Qiita や GitHub みたく、言語毎にハイライトするといったいわゆるシンタックスハイライトには対応していません。
見出しを強調
私は見出しを視覚的に見やすくしたいタイプなので、ボーダーラインで強調させました。
h1 {
border-left: 8px ridge #000000;
border-bottom: 4px ridge #000000;
}
h2 {
border-left: 6px solid #000000;
}
h3 {
border-left: 6px double #000000;
}
テーブルに枠線を引く
テーブルには枠線が無いとテーブルっぽくないので、引いてみました。（私が知っている）普通のやり方では table タグの border 属性に 1 を指定する、つまり <table border="1"> のように書くかと思うのですが、でんでんマークダウンではタグに属性を指定できないので、セレクタで table やら th や td などに border を指定して凌ぎました。
table {
border-collapse: collapse;
border: solid 2px black;
}
table th{
border: solid 1px black;
}
table td {
border: solid 1px black;
}
段落毎に全角スペースを自動で入れる
日本語の文章は段落毎に、先頭に全角スペースを入れますが、これを原稿ファイルに手打ちで入れるのはしんどいです。CSS で対処できないかと思って、調べてみたら、できました。
/* 段落ごとに自動でスペースを付与 */
p {
text-indent: 1em;
}
太字があまり強調されてないのでもっと強調する
太字がいまいち視覚的強調性に乏しかったので、下線も引いてみることにしました。
/* 太字単体だと強調が乏しいので下線も付ける */
strong {
text-decoration: underline;
}
メタデータ
メタデータとは本のタイトルや著者名などの情報のことです。これはでんでんコンバーターの画面上で指定しますが、いちいち指定するのは面倒くさいので、専用ファイル ddconv.yml に指定しておいて、これをアップロードします。
詳しくは公式の Config - でんでんコンバーター を参照していただくとして、ここでは私が使った ddconv.yml を取り上げておきます。
あまり大きな設定ファイルではありません。タイトルや著者名や出版日といった最低限の情報と、あとはページ送りとその他出力オプションを少し指定する程度です。
メタデータ利用時のタイトルフィールドについて
ddconv.yml をアップロードする場合でも、変換前にはタイトルフィールドに何か文字列を入れなければなりません。が、ここはどうせ使われないので適当に「あ」とか入れておけば良いです。律儀にタイトルを指定する必要はありません。
Markdown エディタ
ここは完全な好みでしょうが、私は秀丸エディタで書いています。
軽快な動作とアウトライン機能は欠かせません。アウトラインについては テキストエディタにアウトラインを導入して快適なテキスト編集を手に入れる にまとめてます。
その他の選択肢
最初に一言でまとめておきます。
- マシンパワーフル活用していいから利便性が欲しい → IDE
- テキストエディタ上でサクサク軽快に書きたい → テキストエディタ
- IDEほど重いのはキツイが、プレビュー等は極力楽したい → 専用エディタ
IDE
VSCode こと Visual Studio Code や GitHub 謹製の Atom など、ソフトウェア開発で用いる IDE は、Markdown 用のプラグインも豊富なので、Markdown 執筆環境として使うこともできます。
IDE らしくリアルタイムにプレビューしたり、文法エラーをチェックしたり、とリッチな機能が使えるので、これらに使い慣れている＆マシンがハイスペックな方は、これらを使えば良いと思います。
専用エディタ
IDE ほどリッチで重たくはなく、かといってテキストエディタほど軽いわけでもなく、その中間に位置する存在です。テキストエディタみたいな軽さとシンプルでありながら、Markdown の各種操作編集に特化しているのが特徴でしょうか。
最近よく見かけるのは Typora でしょうか。いわゆる WYSIWYG(Word みたいに変換後の見た目を編集ウィンドウ内に表示する) タイプのようです。
テキストエディタ
私が使っているのは秀丸エディタですが、他にも Vim など汎用的なテキストエディタで Markdown を書くという手もあります。IDE や専用エディタよりも軽くて、かつ自分の使い慣れたエディタ上で編集できるのが一番のメリットです。
ただし、カスタマイズは基本的に自分で行うことになります。といってもメジャーなエディタならプラグインやハイライト設定ファイルなどが配布されていると思います。詳しい方なら自分でつくることも可能でしょう。
epub ファイルの閲覧
epub ファイルの閲覧は Kindle Previewer が無難です。ファイルサイズ 260MB で、動作も中々に重たいですが、ウェブ上のプレビューアよりは断然早いですし、なんだかんだ KDP 謹製です。
以下は epub ファイルを読み込ませてみた例です。
表紙
最大の難所です。読んでもらえる電子書籍には見栄えの良い表紙が必要です。商業本レベルのクオリティが求められるらしく、業者にお願いするのも普通なんだそう。
今回はとりあえずの個人趣味なので業者には頼みません。また表紙だけで何日もかけるつもりもないです（しそんな画力もありません）。が、それでも自分でつくってみたいものです。作ってみました。
表紙ファイルの推奨仕様や取扱いについて
表紙ファイルの仕様についてまとめておきます。
まず、でんでんコンバーターの仕様として従う必要のある事項について。
- ファイル名は
cover.jpg - 本文からはリンクしない
- 参考: Tutorial - でんでんコンバーター
続いて KDP の推奨仕様 について。
- jpg が良い
- サイズ比は x : y = 1 : 1.6 つまり x, y = 1000, 1600
- 理想は x, y = 1600, 2560
- 最低でも x, y = 625, 1000
- 圧縮せずに高画質で
- (背景が白い場合は)表紙境界用に 3-4 pixel の細い薄灰色線
美術が苦手な私の戦略（結論）
画像編集スキルも美術センスも皆無なので、上手いこと特徴を列挙したデザインに頼ろうと考え、最終的に タグクラウド にありつきました。
- (1) WordClouds.com でタグクラウド画像を作りました
- Size は Custom で 1600x2560 に
- Shape は Shapes の吹き出しのやつ
- wordlist はこちら
- (2) 1 のタグクラウド画像をペイントで開いて、タイトルや著者名を埋めました
完成イメージは後述。
美術が苦手な私の戦略（思考過程）
参考までに晒しておきます。
幸いにも本書は「ファイル名を指定して実行」本なので、「ファイル名を指定して実行」ダイアログだけ貼り付けた、シンプルな表紙にすれば良さそうだ。シンプルな表紙でもカッコイイのとかあるしね。
↓ つくってみた
ダメだこれ。ダイアログのサイズが小さすぎて、1600x2560 にまで伸ばすとダイアログが荒くなりすぎて汚い。
↓ どうしよう。万策尽きた……あ、待てよ、何だっけ、あれ。
なんかたくさんの単語を表示サイズに差を持たせて表示させてるやつ。なんとかクラウド……そう、タグクラウド。そうだ、「ファイル名を指定して実行」に関連しそうなキーワードをタグクラウドで並べれば、それっぽくなるんじゃね？無料で作れるサービス、海外ならありそう。
↓ 探した
あった。
そもそもこれ、商用でも使えるよね？…… FAQ によると OK みたい。引用しておくと、
Are there any restrictions on using my word clouds?
The word cloud images you create are yours to use any way you see fit. Feel free however to give credit to Wordclouds.com and spread the word! You are even allowed to use the generated word clouds commercially.
よし、それじゃ作ってみようか。
↓ 主に wordlist の調整に苦戦して、完成までたぶん半日かかりました
何とか完成。あとは完成画像を保存して、ペイントで開いて、タイトルや著者名を入れました。あと「ファイル名を指定して実行」もつけておきました。完成イメージは以下のとおり。
「ファイル名を指定して実行」ダイアログから、吹き出しで関連キーワードがモワモワと思い浮かんでいるような見た目です。自分では頑張ったつもりなのですが、いかがでしょうか 
執筆スタイル
原稿はファイル一つ
原稿を単一ファイルにするか、複数ファイルにするかという話です。
正解はありませんが、中規模以上(文字数10万文字以上など)の大きな書籍や、あるいは複数人で分担したい場合は複数ファイルが便利でしょう。また一般的に、一ファイルだと行ったり来たりが面倒くさいので、複数ファイルにしてタブで切り替えるのが楽です。
ですが今回、私は単一ファイルにしました。理由は以下のとおりです。
- 文字数が少ない(結局 5 万文字いきますが当初は 1-2 万文字の予定でした)から
- 10万文字程度のファイルでも単一ファイルで編集するのが日常的だから
- 秀丸エディタのアウトライン機能のおかげです
- 二度目ですが テキストエディタにアウトラインを導入して快適なテキスト編集を手に入れる
- でんでんコンバーターにアップロードする時が楽(ファイル一つ選択すればいい) だから
- まあ画像が何十枚とあるので結局何十個選択するハメになるのですが
章立ては「部」「章」「節」「項」
章立てと見出し記法との対応付けも地味に悩みますが、以下のようにしました。
- 部 → 大見出し
- 章 → 大見出し
- 節 → 中見出し
- 項 → 小見出し
部は章を束ねる単位です。項は節の具体例を列挙する際に必要になったのでつくりました。
部と章は見出しレベルだけでは区別しづらいので、部の方は「====」で囲うことで視覚的に強調させました。
以下に例として本書の目次（部と章のみ列挙したもの）を挙げておきます。
はじめに
====【第一部】 基本編 ====
第１章 「ファイル名を指定して実行」とは何か
第２章 「ファイル名を指定して実行」を呼び出す四つの方法
第３章 「ファイル名を指定して実行」の画面説明と基本操作
第４章 「ファイル名を指定して実行」を使うと何が嬉しいのか(中上級者向け)
第５章 「ファイル名を指定して実行」が見つからない、実行できない時に試すこと
====【第二部】 コマンド編 ====
第６章 初心者向け：よく使うファイル名を覚えよう
第７章 中級者向け：よく使うファイル名を覚えよう
第８章 中級者向け：よく使うフォルダ名を覚えよう
第９章 中級者向け：好きな名前で好きなファイルを開けるようにしよう
第１０章 上級者向け：コマンドラインを実行しよう
====【第三部】 仕組み編 ====
第１１章 ファイル名 "だけ" を指定して実行するための条件とは
第１２章 「ファイル名を指定して実行」の履歴をマスターする
おわりに
作業はシングルタスクで進める
ページ数にして高々 130 ページの個人趣味本でも、執筆開始から出版まで 10 日かかってます。それも休日は丸々費やしているレベルで、です。工夫して進めないと、時間はどんどんなくなっていきます。
細かいテクニックは色々あるでしょうが、一番重要だと思ったのは シングルタスクで進める ことです。
執筆が絡む作業は大まかに以下に大別できますが、
- 執筆
- ふと気づいた修正や、思いついた加筆
- 変換
これらを思いつくままにやっていては集中できません。たとえば、第四章を執筆しているのに、ふと「はじめに」が目に入って、文言を修正したくなったからそっちを対応して、さらにふと見た目が気になったから epub に変換してプレビューしてみて……というふうに衝動のままに行動していると、いつまでたっても進みません。
なので、執筆中は執筆に専念します。 ふと気づいたことや、思いついたことは、ささっと別ファイルにでもメモしておいて、あとで対応するようにします。また、変換後の見栄えチェックについても、執筆の後で、まとめて時間を取って行います。この時も、やはり「加筆したい」と思った時にすぐ加筆するのではなく、まずは別ファイルにメモしておいて、先にチェックを済ませます。
「一つの作業のみに集中する」「他の作業を思いついても、とりあえずメモしておいて、あとでやる」この二点を心がけただけで、だいぶ作業スピードが上がりました。
その他細かい作業について
目次の生成
目次は KDP に出版する際の紹介文にも含めたいので、なるべく楽して作りたいものです。
私は自作の TOC 出力ツール intoc を使って、コマンド一発で出力できるようにしています。
以下のようなバッチファイル build_toc.bat をつくっており、build_toc.bat を実行するだけで、目次の並んだテキストファイル _toc.md が生成されます。
build_toc.bat
@echo off
setlocal
set curdir=%~dp0
set outfilepath=%curdir%_toc.md
set inputfilename=run.md
set parse_nest_level=1
python ..\intoc\intoc.py -i %curdir%%inputfilename% --parse-depth %parse_nest_level% > %outfilepath% --use-plain-enum
start "" %outfilepath%
※このバッチファイルは私の環境でしか動きません。あくまでバッチファイルで自動化するイメージをお伝えするものです。
キャプチャ(スクリーンショット) について
本書の性質上、手順の説明などにどうしてもキャプチャが必要になります。
私は以下を使いました。
- WinShot
- Windows 標準の Snipping Tool
WinShot はフリーのキャプチャツールで、PrintScreen キーを押すだけで指定ディレクトリに JPG で保存、といったことができます。が、古いソフトなので Windows 10(というより64bit)だと動作は怪しいです。上記リンクにて数点ほど対処法をまとめてます。
Snipping Tool は、「ファイル名を指定して実行」から snippingtool と入力して呼び出せます。範囲選択でキャプチャできるスグレモノです。
著者名の用意
私の HN 名は sta とか stakiran なのですが、既存の書籍の著者名を調べてみると日本語名が多かったので、私も倣うことにして、急きょ準備しました。
注意事項の記載
本書は一応手順を踏襲させる技術書なので「何かあっても責任は負いませんよ」的な事項はあった方が良いでしょう。また、一般的に Windows といった商標を使う件の対策も必要です。
既存の技術書を参考にして、以下のようにしました。
- 本書の内容に基づく運用結果について、筆者は一切の責任を負いかねますので、ご了承ください。
- 本書に記載されている会社名および製品名は、各社の商標または登録商標です。なお、本書中では ™、®、© マーク等は表示していません。
- 本書の一部または全部を無断で複写、複製、転載することを禁じます。
簡易プレビュー
Kindle Previewer でプレビューするのは手間がかかるので、もう少しライトにプレビューしたいものです。IDE や専用エディタをお使いなら、その場でプレビューできますが、テキストエディタで書いているとそうもいきません。
幸いにも Markdown なら GitHub にアップロードするだけでプレビューできます。ビルドさえも必要ありません。
FAQ
変換を自動化したいんですが可能ですか？
Ans: でんでんコンバーターを使う以上はできないと思います。
自動化するなら Pandoc など専用ツールを使うことになるでしょう。
参考: 電子書籍をPandocで作るとき気をつけること | $m0t0k1x2["code"].content
GitHub でソーシャルに執筆できますか？
Ans: やろうと思えば可能だと思います。
詳しく解説されたスライドもあります。
参考: Githubで書く電子書籍
KDP ネタ(アカウントや書籍情報や価格などの登録など)について知りたいのですが？
Ans: 技術ネタ無関係なので、本記事では取り上げません。
下記ブログでは少し取り上げてます。
おわりに
でんでんコンバーターのおかげで手軽に Markdown to EPUB 変換ができますし、EPUB は Kindle Previewer で簡単に閲覧できます。
電子書籍というと難しいイメージがあったのですが、意外とお手軽につくれるということがわかりました。ガチの商業本レベルのクオリティは難しいかもしれませんが。
というわけで以上、Markdown + でんでんコンバーターによる電子書籍執筆ネタでした。参考になれば幸いです。