完成まで迷わない!EPUB編集ソフト、原稿から出力まで一体のソフト

原稿正本と出力設定からEPUBを生成し、修正を原稿へ戻して再出力するアイキャッチ

EPUB編集ソフトで生成物だけを直した事故の後は、すぐ再出力せず、どの原稿版と設定版から復旧を始めるかを版系譜図へ設計します。この記事で完成するのは復旧済みEPUBではありません。事故前の一本、package-only修正の孤立枝、将来作る正規枝を、source、settings、artifactのIDで説明できる復旧計画です。

Rune Studioについて確認できているのは、Stage 1の文書記載とStage 2のコード実装までです。現行画面も、開始から再出力結果までの操作も確認していません。そのため、本文はファイルを実際に修復・再出力した成功例ではなく、専用環境で後から検証するための版系譜設計に限定します。

事故証拠を動かす前に一覧化する

package-only修正とは、生成済みEPUBの内部だけが変わり、元の原稿や出力設定に同じ変更が残っていない状態です。このまま次の出力を始めると、手修正が消えるか、どの版が正しいか説明できなくなるおそれがあります。

復旧計画の最初の欄には、現在残っている原稿、設定記録、修正前EPUB、修正後EPUBの四点を書きます。取得日時、元の場所、現在の識別名、上書き禁止の扱いも記録します。ここではファイルを移動・上書きせず、何を保全対象にするかを確定するだけです。

説明例では、source-v03、settings-v02、book-build17、book-build17-packagefixという仮IDを使います。これらは系譜図の書き方を示す架空例で、Rune Studioの生成物や操作結果ではありません。

packageだけにある差を孤立枝として描く

次の欄では、修正前後の生成物を将来比較したときに記録する差分項目を決めます。例えば第二章の一文だけがpackage内で変わり、source-v03には旧文が残っているなら、計画図ではその差を原稿系譜につながらない孤立枝として表します。

表には「親=book-build17」「孤立枝=book-build17-packagefix」「差=第二章の対象文」「入力側=未反映」と書く想定です。この時点で差の採否を決めず、承認者と判断根拠の欄を空けておきます。推測で正しい変更と決めないためです。

表紙、navigation、package書誌、spineを全件採点する欄は作りません。完成物全体の静的受入はSTUDIO-122、欠陥種類ごとの責任地図はSTUDIO-233へ譲り、本記事は一件の事故の時間的な親子関係だけを設計します。

最後に説明できる組を復旧点候補にする

復旧点候補は、更新日時が最新のファイルではなく、「この原稿と設定からこの生成物を作った」と既存記録で説明できる最後の組です。例ではsource-v03 + settings-v02 → book-build17を事故前候補として図へ置きます。

対応する生成記録がない原稿や、由来を説明できない設定は復旧点へ決めません。関係が不明なら「不明」と書き、調査項目へ残します。この段階の読後成果は候補線を引くことまでで、正しい親子関係を実操作で証明したことにはなりません。

将来戻す入力と予定IDを設計する

孤立枝の変更を採用する場合に、どの編集可能な入力へ戻すかを計画します。本文差なら原稿候補、出力条件差なら設定候補へ割り当てます。所属を決められない差は「判断待ち」とし、再出力計画へ進めません。

第二章の差を原稿へ戻す仮定なら、予定原稿IDをplanned-source-v04、設定をsettings-v02、予定生成物IDをplanned-book-recovery01とします。

planned-source-v04 + settings-v02 → planned-book-recovery01

planned-は未実行を示す接頭辞です。この記事では原稿へ変更を適用せず、生成物も作りません。book-build17-packagefixは削除対象にせず、「事故証拠・再利用禁止」として計画図の外側へ残します。

Stage 4で確認する受入条件を先に書く

将来の専用ワークスペースで復旧を実行するときの受入条件も計画へ入れます。

  1. 予定した原稿版または設定版だけへ承認差分を反映した
  2. 実行した入力IDと生成物IDを記録した
  3. 新生成物の対象箇所に承認差分が反映された
  4. 生成記録が実際の原稿版と設定版を指している

命令、入力、終了コード、生成物、確認日時、開発版の版をそろえて初めてStage 4の復旧結果にできます。現在はこの実行記録がないため、planned-book-recovery01を成功済み生成物とは扱いません。

EPUB 3標準とRune Studioの実装範囲を分ける

EPUB 3はW3Cが定めるデジタル出版物の配布・交換形式です。これはRune Studio独自の規格ではありません。Rune Studioの資料にEPUB 3出力の記載があること、現行コードにEPUB 3生成に関係する処理があることは、既存規格への製品対応として台帳へ分けています。

一方、ワークスペース、原稿編集、プレビュー、書誌・目次・表紙設定に関係するRune Studioの画面・処理範囲は製品独自です。資料記載はStage 1、現行コードの静的照合はStage 2に限定します。どちらも現行画面、操作成功、package-only差分の自動検出、任意のEPUBの完全復元を証明しません。

作品名・組み方向・ページ順・出力ファイル名・発行日が一覧で並ぶRune StudioのEPUB出力確認画面
EPUB作成の確認画面。原稿の編集と同じ作業場から、作品情報・組み方向・ページ順・出力ファイル名・発行日・表紙の有無を出力前に一覧で確認できます。生成物の構造検査はこの画面とは別に行います。

復旧計画が説明できたところで閉じる

EPUB編集ソフトのpackageだけを直した事故では、まず四つの証拠を一覧化し、package内の差を孤立枝として描きます。最後に説明できる原稿版・設定版・生成物の組を復旧点候補にし、承認差分の戻し先、予定ID、Stage 4の受入条件を一枚へまとめます。

読後にできるのは、次に何をどの順で検証するか説明できる復旧計画です。復旧成功や再出力成功ではありません。実際の原稿変更と新生成物の確認は、別のStage 4操作で証拠を残した後にだけ完了扱いにします。