スクリプトで組版を直すと、エラーを出さずに壊れる

スクリプトで原稿や修正を誌面に流し込むのは、DTP では昔からある方法です。自社でも、校正の修正指示をまとめて打ち込むスクリプトを使っています。最終の確認は必ず人が行い、書き出した PDF は原稿と機械で突き合わせています。

この記事は、そのスクリプトを書くときに踏みやすい、エラーを出さない失敗の記録です。スクリプトは「正常に終わった」と言い、データは黙って壊れています。InDesign と Illustrator の ExtendScript（jsx）で踏んだものを書いておきます。

1. 別の書類を、黙って書き換える

スクリプトの入門記事の多くは、作業する書類を app.documents[0]（最前面の書類）で取っています。これが一番危ない書き方です。

処理を何本かのスクリプトに分けて順に実行していると、その間に人が別のファイルを開いただけで、最前面の書類が入れ替わります。2本目以降のスクリプトは、何の警告もなく、関係のない別の書類を相手に動きます。

スクリプトを書いている途中で、対象とは別の書類を走査して、まったく違う件数を報告してきたことがありました。そのまま書き換えの処理まで進めば、対象外の書類を書き換えてしまいます。

直し方：書類は名前で選び、毎回確かめる。

var doc = null;
for (var i = 0; i < app.documents.length; i++) {
  if (app.documents[i].name == "target.indd") { doc = app.documents[i]; break; }
}
if (!doc) throw new Error("対象の書類が開いていない");

件数が前回と食い違ったら、まず「同じ書類を見ているか」を疑うのが早道です。

2. 置換が途中で止まり、旧語の尾が残る

書式を保ったまま文言を差し替えるため、最初は「新しい文字列を先頭の1文字に上書きし、余った旧い文字を後ろから1字ずつ消す」という書き方をしていました。

ところが、表のセルなどで文字があふれていると、消している途中で、あふれて見えなくなった文字に手が届かなくなり、処理が止まります。結果として、旧い語の後半だけが新しい語の後ろに残ります。

残った文字は、人の打ち間違いと見分けがつきません。スクリプトの不具合だと気づくには、同じ形の崩れが複数か所に出ていることに目を留める必要があります。

直し方：InDesign では、1文字ずつの書き換えをやめ、検索置換（changeText()）で一度に置き換える。途中の状態が生まれません。

app.findTextPreferences = NothingEnum.NOTHING;
app.changeTextPreferences = NothingEnum.NOTHING;
app.findTextPreferences.findWhat = oldText;
app.changeTextPreferences.changeTo = newText;
cell.texts[0].changeText();

そのうえで、書いたあとに読み戻して確かめます。ここにもう一つ落とし穴があります。あふれているセルの contents は、見えている分しか返しません。21文字入れたのに18文字と返ってきます。文字数は characters.length で数えます。

3. 段落を書き換えると、書式と改行が飛ぶ

Illustrator で paragraphs[i].contents = "…" と段落ごと代入すると、文字の属性が初期化されます。色や級数が消えるうえ、改行まで食われて、複数の段落が1行につながりました。テキストの幅が 285pt から 1,027pt に伸びていました。

直し方：段落ごとの代入はしない。書き換えは文字単位で行い、行頭の記号（●など）が本文と別の級数なら、記号は残して2文字目から差し替える。書いたあとは、文字数と属性を読み戻して確かめる。

4. 結合セルを解除すると、文字が消える

InDesign の表で、結合したセルを cell.unmerge() で解除すると、中の文字が壊れることがあります。見出しの「出展者名」が、解除後に「出」だけになりました。エラーは出ません。

直し方：結合セルは解除せず、中身を退避してから作り直す。

表を作り直すときは、もう一つ注意があります。行を総入れ替えすると、前の版でセルに個別に付けていた塗りが残り、交互の塗り分けの中に、関係のない色の行が紛れ込みます。組み直したら、全部の行に塗りを明示的に指定し直します。

5. 座標の単位が、思っていたものと違う

InDesign の geometricBounds は、その書類の定規の単位で値を返します。ミリの書類で返ってきた値をポイントだと思い込み、枠の大きさから写真の解像度を逆算したら、配置した写真が 123ppi になっていました。

直し方：スクリプトの最初で単位を明示する。

app.scriptPreferences.measurementUnit = MeasurementUnits.POINTS;

6. 日本語が文字化けした状態で流し込まれる

Mac で AppleScript（osascript）から jsx を実行するとき、do javascript (read POSIX file "…") のようにファイルの中身を読んで渡すと、AppleScript が先に UTF-8 を別の文字コードとして読みます。文字化けした日本語が、そのままデータに入ります。

直し方：do javascript (POSIX file "…") としてファイルそのものを渡す。念のため、jsx の中の日本語は \uXXXX の形で書いておくと確実です。

共通すること

どれも、スクリプトは正常に終わったと報告します。だから「エラーが出なかった」は、何の保証にもなりません。

自社で落ち着いたやり方は次の3つです。

• 対象を名前で確かめる。書類も、書き換える文字列も。
• 書いたら読み戻す。文字数・属性・消えてはいけない行が残っているか。増えたかどうかだけでは、行が1本消えたことに気づけません。
• 最後に、書き出した PDF を別の道具で原稿と突き合わせる。スクリプトの中の検証は、スクリプトと同じ思い込みを共有しているからです。

手作業の打ち間違いは、人がゆっくり見れば見つかります。スクリプトの間違いは、同じ形で何十か所にも出て、しかも見た目は打ち間違いと区別がつきません。速くなった分だけ、検証の仕組みを自分で持っておく必要があります。

InDesign・Illustrator 2026（Mac）で確認した内容です。例に出した文言は、実際の案件のものから変えています。

技術コラムの一覧へ