旧稿はコンパイルできる。改訂稿もコンパイルできる。ところが latexdiff が作ったファイルだけが、表、数式、独自コマンド、あるいは長いプリアンブルの途中で止まる。
多くの場合、改訂そのものが壊れたわけではありません。赤入れ版は、自動挿入されたコマンドと独自の失敗要因を持つ、第三の LaTeX プログラムです。比較元の二つと同じように、意識してビルドします。
Table of Contents
単独でビルドできる二つの版を固定する
異なる時点から main.tex だけを拾うのではなく、完全なスナップショットを二つ用意します。
revision-package/
├── old/
│ ├── main.tex
│ ├── sections/
│ ├── figures/
│ └── references.bib
└── new/
├── main.tex
├── sections/
├── figures/
└── references.bibエンジンとビルドコマンドを記録し、それぞれを独立にコンパイルします。
cd old
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
cd ../new
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex片方でも失敗するなら、そこで止めます。入力がすでに壊れている状態では、原因が原稿、環境、差分マークのどれにあるのか判別できません。
実際のツールチェーンも残します。
pdflatex --version
latexmk -v
latexdiff --version「Overleaf では動く」は重要な手掛かりですが、バージョン番号ではありません。パッケージの順序や間接的に読み込まれたパッケージだけでも挙動は変わります。
複数ファイルの原稿は展開してから比べる
単一ファイルなら通常のコマンドで十分です。
latexdiff old/main.tex new/main.tex > new/redline.tex実際の論文には input、include、subfile、図、文献があります。latexdiff の公式マニュアルにある --flatten は、本文から読み込まれるファイルを再帰的に展開します。
latexdiff --flatten old/main.tex new/main.tex > new/redline.tex
cd new
latexmk -pdf -interaction=nonstopmode -halt-on-error redline.tex赤入れ版が受け入れられるまでは、old/ と new/ の木をそのまま保存します。展開後のファイルは比較しやすい一方、元の構造を表しません。正本ではなく、再生成できる成果物として扱います。
Git 管理の原稿なら latexdiff-vc で特定のリビジョン同士を比較できます。その場合も、二つのリビジョンと PDF を生成した正確なコマンドを保存します。
生成とコンパイルを分ける
Overleaf の latexdiff ガイドには、latexmkrc と ShellEscape を使う方法があります。小さな例には便利ですが、複雑な投稿では redline.tex を明示的に生成し、その後で別にコンパイルするほうが追いやすくなります。
こうすると、二つの問いを別々に確認できます。
latexdiffは妥当な TeX を生成したか。- 生成された TeX は改訂稿と同じ環境でコンパイルできるか。
また、入力の一方が変わったために通常の原稿ビルドが別の赤入れ版を黙って作り直すことも防げます。
Overleaf 内で生成する必要があるなら、公式の latexmkrc または shellesc の設定を小さく保ち、どのファイルがメイン文書か確認します。編集者への提出に使った新旧スナップショットもダウンロードしておきます。Overleaf の履歴機能なら指定版を取得でき、「先週のファイル」よりはるかに監査しやすくなります。
最後の五十件ではなく、最初の本当のエラーを読む
差分マークは連鎖エラーを起こしがちです。役に立つのは、通常 redline.tex のコンパイル開始後に出る最初のエラーです。
次の四点を確認します。
- 失敗したコマンドは旧稿、新稿、赤入れ版のどれにあるか。
- 数式、移動引数、表のセル、キャプション、引用のどこにあるか。
DIFaddまたはDIFdelがコマンド境界をまたいでいないか。- 新稿が成功したのと同じ環境で、その生成ファイルが失敗するか。
最初から改訂稿のパッケージを削らないでください。赤入れ版が通っても、編集者が確認すべき論文自体を変えてしまいます。
独自コマンドが単にテキストを包むものなら、latexdiff に扱い方を教えます。マニュアルには --append-safecmd や --exclude-textcmd などのコマンドリストがあります。設定はファイルかビルドスクリプトに保存し、修正を再現可能にします。未知のマクロをすべて安全扱いにはしません。カウンタを変える、ファイルに書く、壊れやすい引数を取るコマンドは個別に見る必要があります。
数式や表では、失敗箇所を一つずつ小さくします。設定を変えるたびに赤入れ版を再生成してコンパイルし、そのページを二つのクリーン PDF と比べます。負号、行、キャプション、引用の変更を隠したまま通る赤入れ版は未完成です。
編集者向け PDF と日常の変更履歴を分ける
Overleaf の変更履歴は共同編集に向いています。投稿用の赤入れ版が答えるのは別の問いです。二つの確定した原稿状態の間で、何が変わったのか。
そのため、三つの成果物を保存します。
- 基準版 PDF
- クリーンな改訂版 PDF
- 対応するソースから生成した赤入れ PDF
ソースのハッシュ、エンジン、コマンド、日付、未解決の警告を短いマニフェストにします。回答書に「第3節を改訂」と書くなら、場所は現在のクリーン PDF で確認します。赤入れ版は変更を見るためのもので、ページや節位置の唯一の根拠ではありません。
小さな監査で、長い修復を避ける
公開されている PaperAgentDemo でこの確認を行いました。現在の main.tex は latexmk で二ページの A4 PDF に再現可能にビルドでき、最終パスでは数式、アルゴリズム、表の参照も解決します。しかし、リポジトリには別の原稿基準版がなく、確認したツールチェーンにも latexdiff がありません。したがって、クリーンビルドの例ではあっても、まだ赤入れ工程の証拠ではありません。
この境界は大切です。投稿可能な改訂パッケージを約束する前に、三つのビルドを実証し、基準版を残し、手作業の例外をすべてスクリプトか監査ノートに記録します。
公開した合成赤入れサンプルには、旧ソース、改訂ソース、三つの PDF、生成した redline.tex、最終パスのログ、ハッシュマニフェストが揃っています。あえて一ページにしてあり、三つのビルドは再現できますが、複雑な顧客原稿の実績を示すものではありません。
私は、安定した原稿ファイル、名前付き基準版、生成した赤入れ、PDF で確認した回答位置、未解決事項を一つにつなぐ計画先行の論文改訂ワークフローを公開しています。この仕組みを使わなくても、この五つの境界を守るだけで難しい latexdiff 修復はかなり整理できます。
範囲を絞った一本の論文を一緒に確認してほしい場合は、USD 250 の原稿ビルド＆赤入れ sprintも用意しています。無料の fit check で尋ねるのはソース構成、投稿先テンプレート、締切だけです。作業範囲と取り扱い方法に合意するまでは、原稿を送る必要はありません。