手戻りを減らして完成へ！電子書籍の自作、Mac一台で自作する流れ

Mac一台で電子書籍を自作するときは、EPUBが一度開けた時点ではなく、「販売先へ渡す候補を一つに固定できた時点」を完成とします。候補名、六章の順番、作品情報、表紙・奥付、確認日、残しておく資料を一枚にまとめれば、あとでどの版を入稿したか分からなくなる事態を防げます。

例は横書きの自作エッセイ『港町の六日間』です。本文は六章、表紙1枚、奥付1枚。販売登録の方法ではなく、Mac内で公開候補を確定する直前までを扱います。

先に公開候補の完成条件を書く

ファイルを作りながら完成条件を増やすと、いつまでも終わりません。次のカードを最初に用意します。

この候補名は管理例です。今回の出力で実際に生成されたファイル名を示すものではありません。自分の作品では、作品名、版、確認日を見分けられる命名規則を一つ決めてください。

六章を「入稿候補」にする順番

制作全体を細かく説明するより、候補を固定する最後の一周へ集中します。

1. 六章の元ファイルを01-prologue.mdから06-afterword.mdまで固定し、順番をカードと照合します。
2. 作品名、著者名、言語、横書き、版1.0を入力し、表紙1枚と奥付1枚を指定します。
3. 目次の掲載対象を確認します。表紙や奥付を本文六章と同じ扱いで数えず、目次と読む順番を分けて見ます。
4. EPUBを出力し、ナビゲーション、読む順番、表紙の収録、欠落ファイルの有無を確認します。問題があれば元ファイルか設定へ戻し、候補名を確定しません。
5. 合格したEPUBだけをrelease-candidate/へ複製し、候補名、確認日、確認した項目を記録します。以後の販売先ごとの調整は、この候補の複製から始めます。

候補フォルダへ入れる前のEPUBは作業途中です。候補へ入れた後に本文を一文字でも直したら、旧候補は残したまま版を上げ、もう一度同じ項目を確認します。

版を上げる基準も先に固定します。本文、章順、作品名、著者名、表紙、奥付のどれかを変えたら、v1.0の確認記録を新しいEPUBへ流用せず、v1.1の候補として六章から見直します。確認日だけを書き換えて同じ名前で上書きすると、販売先へ渡した版とMacに残る版を照合できません。旧候補、修正理由、新候補の三つを並べておけば、差し戻し後もどこへ戻るか判断できます。

残すものと渡すものを分ける

自作者が手元に残すのは、EPUBだけではありません。

• 六章の元ファイル
• 作品情報カード
• 元の表紙画像
• 奥付
• 公開候補EPUB
• 候補名と確認日を記したチェック表

販売先へ渡すのは、原則としてその販売先が求めるファイルと情報だけです。元原稿一式を同じフォルダへ混ぜて渡しません。また、販売先で修正を求められた場合は、提出用EPUBを直接直さず、手元の元ファイルへ戻して新しい候補を作ります。

一般的なEPUB 3では、書誌情報、収録資源、読む順番、ナビゲーションが別々の役割を持ちます。EPUB 3.3の構造を意識すると、目次が見えるだけで入稿候補にしてしまう失敗を避けられます。

六章の例で確認できた範囲

Rune Studioの現行Mac版については、縦書き・横書き、章順、目次、表紙、奥付を設定してEPUB 3へ出力できることが公開資料に記載されています。

六章・横書き・本文画像なしの例を出力した確認では、ナビゲーション文書とNCXがあり、画像1点が収録され、欠落は0件でした。ローカルの構造確認も正常でした。この結果は、六章のEPUBパッケージを作って確認できたことを示します。

ただし、『港町の六日間』という作品情報、上記の候補名、確認日カード、release-candidate/への保管、販売先への受け渡しは実行結果ではありません。販売先の審査や登録、すべてのリーダーで同じ表示になることも含みません。これらは自分の候補を確定するときに別途確認してください。

自作の完成は「戻れる候補」があること

Mac一台で電子書籍を自作する流れの終点は、EPUBを一つ作ることではありません。六章、作品情報、表紙、奥付から再び作れる公開候補を一つ選び、版と確認日を記録して残すことです。販売先で差し戻されても元へ戻れる状態なら、手戻りを管理できます。

まず六章の順番と作品情報カードを埋め、候補名を一つ決めてください。Rune Studioで公開候補を作る場合は、現行Mac版について詳しくはこちらで確認できます。