Linguist Coder

Missing Footnotes, Empty Table Cells, and Stale Index Pages After IDML Translation

2026-09-23T08:55:51.000Z

A translated InDesign document comes back with a footnote number but no text, an empty table cell, or an index page that is blank or still in the source language.

There are four questions to ask, in this order:

Was the content extracted into the bilingual file in the first place?
If it was extracted, was the corresponding target left empty?
Is the content still present but hidden by overset?
For an index specifically: was the index page regenerated after the translated IDML was opened in InDesign?

These checks apply at different stages of the round trip.

First check whether the content was extracted

A common guess is that the CAT tool skipped the footnote or the table cell during extraction, treating it as something other than translatable text. I tested this with a synthetic IDML fixture containing a footnote, a table, and a nested table. Extracted with Okapi Tikal 2.1.48.0 using its IDML filter (okf_idml), each table cell appeared as its own translation unit. The footnote reference in the body text appeared as a placeholder code, and the footnote's own text appeared as a separate translation unit, not attached to the sentence that carries the reference.

That is the behavior I observed with Okapi Tikal 2.1.48.0 and its IDML filter on this synthetic fixture. It is not necessarily what every CAT tool does. Other CAT tools may expose IDML filter settings for footnotes or index content specifically; I did not test those tools, so check the filter configuration used for a project rather than assuming it matches the Okapi result described here.

In this Okapi test, an empty target merged without a warning

I then tested the failure case: I ran three separate merges with an empty target, one for a footnote, one for a table cell, and one for an ordinary paragraph in an independent story, as if a translator had skipped the segment or a reviewer had cleared it by mistake.

The merge completed in all three cases, with no error and no warning. But the result was not a footnote with blank text or a cell with an empty paragraph. In the fixture used for this test, the text was nested inside ParagraphStyleRange, CharacterStyleRange, and Content elements. The tested footnote contained the following structure:

<Footnote>
  <ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/$ID/NormalParagraphStyle">
    <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]">
      <Content>Footnote text goes here.</Content>
    </CharacterStyleRange>
  </ParagraphStyleRange>
</Footnote>

After merging with an empty target, the footnote container still existed, but the elements that held its paragraph, character run, and text were gone:

<Footnote/>

<Footnote/> is an empty XML element. It does not contain an empty string inside the original paragraph structure. It contains no paragraph structure at all. In this Okapi test, the same structural removal happened in the selected table cell and in the independent story: the <Cell> element came back self-closed, with its row and column position intact but no paragraph inside it, and the <Story> element for the ordinary paragraph came back with no ParagraphStyleRange at all.

I also tried removing a unit from the file entirely, rather than leaving its target empty. In this Okapi test, deleting the unit caused the merge to stop with a Text Unit id mismatch during merger error, and no output file was produced. Leaving the unit in place with an empty target did not stop the merge.

Check whether the index page was regenerated

Index extraction and index-page generation are separate checks. The first is an extraction check: inspect the bilingual file to determine whether the index content reached the translator. The second concerns the generated index page.

If the index topics have been translated but the index page is still stale, check whether the index has been regenerated in InDesign. I did not test index regeneration for this article, so treat this as a diagnostic check rather than a confirmed cause. If the index looks unchanged after import, regeneration is the first thing to try.

Do not confuse this with overset text

A related but different symptom: the content was translated, it is in the file, and it still looks missing on the page. One possibility is overset text, which InDesign marks with a red overset indicator. I've covered diagnosing and fixing overset text separately. If the frame shows the indicator, check the layout before treating the content as lost.

What to check before you sign off

After extraction: open the bilingual file and confirm that the expected footnote text and table-cell text appear as source units. If they do not, check the IDML filter settings used for the extraction.
Before merge: look for units with a non-empty source and an empty target. Do not rely on the merge to reject them; in the Okapi test described here, the merge completed without a warning.
After the merged IDML is back in InDesign: if content is missing from the page, check the frame for the overset indicator before concluding it was lost.
For an index: first confirm that the index content appears in the bilingual file. Then confirm whether the index page was regenerated after import.

These checks help distinguish content omitted during extraction, returned with an empty target, hidden by overset, or left on a stale index page. They do not verify the accuracy of the translation itself.

How to Check a Translated InDesign File in a Language You Cannot Read

2026-09-19T23:14:42.973Z

A translated InDesign file comes back from the vendor. You are responsible for it, and you cannot read it. Most of the advice I found on this question ends the same way: have a native speaker review it. That is right for one part of the job. It leaves out the part you can do yourself.

Whether the translation is correct needs someone who reads the language. Without reading it, you can still compare the document's structure, check strings that were agreed in advance, and identify items that need review. These checks do not establish that every passage was translated.

You do not need InDesign for most of this. An IDML file (InDesign's interchange format, a ZIP of XML files) can be inspected in a text editor, and the returned PDF can be searched. The overset check below uses InDesign's Preflight panel or an InDesign script. If you do not have InDesign, ask the vendor to run the check and report the results.

First, confirm the container survived

Before looking at any text, compare the document's structure: the stories (a story is one continuous flow of text, possibly running through several linked frames), the row and column counts of each table, the number of footnotes and anchored figures per story, and the set of paragraph styles in use. None of this requires reading. The checklist, including how to read the counts out of the IDML file without InDesign, is in Comparing InDesign Files After Translation: What to Check. Resolve missing stories or tables before linguistic review.

Compare agreed strings and values

Check part numbers, model names, quantities with units, URLs, email addresses, phone numbers, product names, and trademarks against the agreed conventions and exceptions. Some of these change form by locale, and some names are translated or transliterated by policy.

In many locales the decimal separator is a comma and the thousands separator is a period or a space, so 3.5 mm becomes 3,5 mm and 1,000 becomes 1.000. Dates change order. Ask the vendor for the list of names that were translated or transliterated on purpose, and record it with the conventions. Without this step, formatting differences may be mistaken for discrepancies.

For a short document, search the returned PDF or the target's story XML for each item by hand. For a manual with hundreds of part numbers, extract them from the story XML of both IDML archives with a script and compare the two lists. After accounting for the agreed conventions, record unmatched values for review. A value present in both files is not evidence that the sentence around it is right.

Search the target for your own language

You cannot read the target, but you can recognize the source. Pick sentences and distinctive phrases from the source that were meant to be translated, and search for them in the target. A hit is a candidate to look at in context. No hits do not establish that nothing was left untranslated; a sentence that was half translated will not match a search for the whole sentence.

Some source-language text is supposed to be there: product names, code samples, trademarks, text the vendor was told not to translate. Keep that list next to the exceptions list from the previous step, so that a hit can be classified quickly.

If you have the returned PDF, start by searching it. It does not include overset text (see the next section). The story XML inside the IDML archive also contains story text that is absent from the PDF. One caution when searching the XML directly: the text of a paragraph is split into separate elements wherever the formatting changes, so a sentence with a bold word in the middle will not match as one string. Try shorter phrases when formatting splits a sentence. Record searches you cannot complete as unchecked.

Look for text you cannot see

Translated text is often longer than the source. When it no longer fits its frame, InDesign keeps it but does not display it, and it is not included in an exported PDF. InDesign's Preflight panel reports overset text, and a short script can list which pages have it: Your First InDesign Script: Which Pages Have Overset Text?. Check this in the target before the reviewer opens it, because a reviewer reading the PDF cannot see what the PDF does not contain.

Also check text on hidden layers, master pages, and the pasteboard. That text is in the IDML archive whether or not it shows on the page. In the Okapi filter I use, separate settings control extraction of text on hidden layers, master spreads, and hidden pasteboard items. Ask the vendor whether those locations were included in the translation. If the source has text there that matters, search the target's story files for the source-language text, as in the previous section. I wrote about finding those objects in Scaling Multilingual DTP by Detecting Objects Outside the Layout.

If you have reference strings, use them

Two kinds of target-language text can be checked without reading, because someone else already approved them.

If you have approved target-language wording for a required notice or statement, search for it in the required location. I described automating this for PDFs in Scaling Multilingual DTP by Automating Mandatory Text Checks in PDFs Before Delivery.

If the vendor was given a glossary of source terms and their required target terms, you can search the target for each target term. Use exact matching for terms that are required to appear unchanged. For languages that inflect, an exact search may fail to find a correctly inflected form; treat a missing match as a question for the reviewer, not as an error.

For both kinds, a match elsewhere does not confirm the required occurrence. If you cannot locate the required occurrence in the target, record it as unchecked.

What none of this tells you

A paragraph can have every number in place, no source text left in it, and the approved terms, and still say something the source does not. That is the reviewer's job, and nothing above replaces it.

Machine translation back into your language gives you a rough reading of the target. It cannot tell you the translation is correct, because you would be judging a translation of a translation. Before using an online service, check whether you are permitted to upload the document.

When you hand the file to the reviewer, hand over the record of which checks were completed and which questions remain.

What to ask the vendor for

Ask the vendor to confirm the number conventions and the exceptions: strings intentionally left untranslated and names intentionally translated or transliterated. If you do not have InDesign, request the overset check results. Send any search results you cannot classify to the vendor for clarification.

The order

Container: stories, tables, footnotes, anchored objects, styles.
Agreed strings and values: part numbers, quantities, URLs, and names, using the agreed conventions and exceptions.
Source-language text left in the target.
Text that does not show: overset, hidden layers, master pages, pasteboard.
Reference strings: required wording, glossary terms, checked at the location where they are required.
Linguistic review by someone who reads the target language.

Steps 1 to 5 can be run without reading the target language, using agreed conventions and approved references. Some of what they find still needs the vendor or the reviewer to resolve.

I am developing a tool that does step 1 for two IDML files and reports, for each item, whether it compared it or could not. The current trial and the testing request are in a separate post.

Why IDML Formatting Can Produce Translation Tags, and What to Check in InDesign

2026-09-18T22:18:59.981Z

A document goes out for translation as IDML and the translator writes back: the file is full of tags. Some segments have a tag pair around a single letter. Others have a dozen tags in one sentence. The translator asks whether they can be deleted. The layout side asks why they are there at all.

This post is about the second question, and about what to check in InDesign before the next export.

Where the tags in an IDML come from

IDML is a ZIP archive. Inside it, the Stories/ folder holds one XML file per story, and each paragraph is a ParagraphStyleRange element. Inside the paragraph, the text is split into CharacterStyleRange elements. A range is a run of text in which every character attribute is the same. Where an attribute changes, InDesign closes the range and opens a new one.

A paragraph set entirely in its paragraph style, with no breaks or inline objects in it, is one range. Put one word in bold and it becomes three ranges: the text before the word, the word, the text after it.

Character formatting changes therefore create range boundaries in the IDML before any translation tool has touched the file. The example below shows how the Okapi IDML filter renders two of them as paired inline codes; it does not establish how Trados or memoQ will display the same IDML.

Which formatting changes create a range boundary

Any character attribute that differs from the text around it starts a new range. In the story XML these show up as attributes on the CharacterStyleRange element or in its Properties child. Attributes to inspect include AppliedCharacterStyle, FontStyle, PointSize, AppliedFont, Position, KerningValue, Tracking, BaselineShift, HorizontalScale, Leading and AppliedLanguage.

The attribute name does not tell you why it is there. A Tracking value may be a fix for one line of English that ran a word too long, or the consistent treatment of a product name. A local PointSize may be a deliberate emphasis or a squeeze to fit a caption. An AppliedLanguage difference may not be visible in the layout at all, and it can be an unintended difference or an intentional setting, since the language controls hyphenation and the spelling dictionary.

Formatting is also not the only source of tags. In the Okapi output for the test file below, a footnote marker and an anchored rectangle each appeared as a placeholder code (ph). These codes represent document structure that needs to be preserved.

Why a tag appears in the middle of a word

Manual kerning can produce this pattern. Kerning is applied between two characters, so InDesign usually stores it as a range that contains a single character with a KerningValue attribute. (A kerning value applied across a longer run of text produces a longer range; the single-character form is the common one.) That range differs from the text on both sides.

To see what that looks like in a bilingual file, I took a one-paragraph IDML exported from InDesign and added two settings directly to the XML: a kerning value on the letter p in "copper", and a local bold on "winter". Extracted with the Okapi IDML filter, the segment reads:

Independent frame BRAVO describes a co<bpt id="1">&lt;content-1></bpt>p<ept id="1">&lt;/content-1></ept>per telescope aimed at <bpt id="2">&lt;content-2></bpt>winter<ept id="2">&lt;/content-2></ept> stars.

(bpt and ept are XLIFF's begin and end markers for a paired inline code; the content-1 inside them is the filter's name for the range.)

The first pair records a kerning setting between two letters of one word. The second pair records a bold setting on a word that, in this example, is meant to stay bold in the translation. The bpt and ept markers alone do not explain why either setting was applied.

Which source formatting to keep or clear before export

Decide what the formatting is for before clearing it. Preserve formatting intended to follow the content: a word that is bold because it is a warning, a product name in a character style, a superscript that is part of a unit. Clear an adjustment only when you have identified it as a fix for the source-language layout: kerning between two letters of an English word, tracking that pulled the last word of a line back up, a local leading change on three lines that were too tall. Where you cannot tell, leave it alone.

How to find and clear the overrides in InDesign

Work on a copy of the InDesign document.

The IDML you are about to send is one way to inspect the source formatting. Copy it, rename the copy to .zip, extract it, and search the Stories/ folder with find-in-files for KerningValue=, Tracking=, BaselineShift=, HorizontalScale= and AppliedLanguage=. These attributes are written only where the text departs from its styles, so each hit is a local override. The searches identify ranges to inspect; they do not tell you what each override is for, and they are not a complete check of all character- and paragraph-level overrides. A uniform override across a whole paragraph does not, by itself, create an internal range boundary.

In InDesign, the tool for clearing local formatting is the Clear Overrides in Selection button on the Paragraph Styles panel. It removes every override in the selection, character-level and paragraph-level, and returns the text to what its styles define. That includes overrides you meant to keep, which is why the order matters.

Define a character style for each kind of formatting you intend to keep. A Bold character style that leaves point size unspecified does not set the text size; after overrides are cleared, the size follows the paragraph style unless the character style defines it. If your emphasis also changes the point size, that change has to be in a style as well, which may mean one style per size. Paragraph-level formatting you need to keep belongs in paragraph styles in the same way.
Convert the local formatting to those styles with Find/Change. If you are preserving different point sizes, process each size separately with the matching character style; the following example applies where one Bold character style is sufficient. On the Text tab, leave Find what and Change to empty, set Search to Document, set Find Format to Font Style: Bold, and set Change Format to apply the Bold character style. Use Find Next on the first few matches to confirm they are the emphasis you expect before you use Change All. Repeat for italic. Other formatting you want to keep needs its own search criteria and its own style.
Review the AppliedLanguage hits from the XML search. A local language override is cleared along with the other overrides. Where a language difference is intentional, preserve it together with the other attributes required for that text.
Clear all overrides in a story only after you have confirmed that every remaining override in it can be removed. If any are unresolved, leave that story unchanged. Once that condition is met, place the cursor in the story, select all of its text, and click Clear Overrides in Selection. The character styles you applied in step 2 are not overrides, so they stay; the remaining kerning, tracking and baseline shifts go. Check footnotes, table cells and text inside anchored frames separately before treating the cleanup as complete.
Export the IDML again and repeat the XML searches. Look at what is still there and decide whether each remaining hit is one you chose to keep.

This changes the layout of the copy. Lines that were held together by tracking will break differently.

What cannot be removed

Footnote references, anchored objects, index markers, cross-references and inline tables all appear as tags, and they have to. They are structure, and the target document needs them in the corresponding places. Character styles that mark meaning also stay.

If you are the translator

If you receive the IDML for translation, do not delete tags simply because they interrupt a word. Ask the document owner to review the source formatting. The cleanup described here takes place in InDesign, before a new IDML is exported.

Comparing InDesign Files After Translation: What to Check

2026-09-15T21:26:12.878Z

A document goes out for translation as an InDesign file and comes back as an InDesign file. In between it went through a translation workflow: exported to IDML (InDesign's interchange format, a ZIP of XML files), split into segments, translated, reassembled. The question that follows is simple to ask and harder to answer than it looks: is everything still there?

In the forum threads I reviewed, two answers recur. Export both versions to PDF and use Acrobat's comparison. Or switch on Track Changes before the edits happen. Each does what it says. Neither, on its own, answers the structural question, and the reason tells you what the check has to look at instead.

What "compare" means after translation

When you compare two versions of a same-language document, you are looking for edits: a sentence changed here, a paragraph deleted there. The text is mostly identical, and the differences are the signal.

After translation, text differences are expected. What you actually want to know is whether the structure the translation was poured back into still matches the one you sent out. Concretely, six things:

Are all the stories still there, and does each still contain text? (A story is a continuous flow of text; it can run through several linked text frames.)
Do the tables still have the same number of rows and columns?
Does each story still have the same number of footnotes?
Does each story still have the same number of anchored objects — figures, callouts, inline frames?
Are the paragraph styles that were in use in the source still in use in the target, and vice versa?
Is any of the text not different — a paragraph, a footnote, a table cell that still reads in the source language?

None of these is about how well the translation reads. They are about whether the container survived the round trip, which is a separate check from linguistic review.

What a PDF comparison shows

Acrobat's Compare Files compares the rendered appearance and the extracted text of two PDFs. Run it on a source PDF and a translated PDF and the report will be dominated by the text differences you already expect, and layout changes from text expansion add to them. The six questions above are not what the report is organized around, and a missing footnote is one difference among many.

There is also a quieter limit. Overset text is not included in the exported PDF. A PDF comparison therefore does not inspect that text.

What Track Changes shows

InDesign's Track Changes records edits made inside InDesign after it is switched on. It answers "what did the editor change in this file". It does not record what happened to the text while it was outside InDesign, and switching it on after the file comes back records only what you do next.

What the CAT tool shows

A third route that experienced operators use: load both files into the CAT tool and let the translation memory find segments that are identical between source and target. This is useful for question 6, untranslated text, and it works at the segment level.

What appears in the extracted bilingual data depends on the filter settings. Footnotes, for example, can be excluded. In the XLIFF (a bilingual data format used in translation workflows) generated by the Okapi round trip I tested, I found Story, Cell and Footnote tokens, but no occurrences of TextFrame, Table, Row, ParagraphStyle or Self=. That observation applies to that output; it does not establish what every CAT tool or every XLIFF file can represent.

Before you start: which two files

Identify the source version you sent out and the returned version you want to check. Record whether the returned IDML was subsequently opened in InDesign and exported to IDML again — for example, after layout fixes.

This matters because of what happened to object identity in my tests. InDesign assigns every object an internal ID. In the three documents I tested through Okapi, those IDs survived the translation round trip; when the returned IDML was then opened in InDesign and exported to IDML again, the IDs I had recorded were no longer present. In the same tests, labels I had added to the objects myself before export survived both stages.

Whatever the state of your files, the rule for the check is the same: for each item, record whether you could establish which object in the target corresponds to which object in the source. If you could not, mark that item as could not be compared.

A checklist you can run by hand

Record the outcome for each object or check performed, not one result for the whole document. Three outcomes: matched for a value you checked and found equal; differed for a difference you established; could not be compared when you could not establish the correspondence or complete the check. Keep the third separate from a clean result.

The practical way to do this without a tool is to read the IDML directly. An IDML file is a ZIP archive: copy it, rename the copy to .zip, and extract it. Inside, the Stories/ folder holds one XML file per story, named after the story's internal ID (for example Story_u195.xml). The checks below involve reading these XML files in a text editor with find-in-files. They cover values you can inspect directly; where the correspondence between objects or the counting unit is unclear, record could not be compared. The search strings match the formatting of the IDML pair I inspected; check the element formatting in your own files before relying on search counts.

Stories. Compare the list of file names in Stories/ between the two archives. In the Okapi pair I inspected before any re-export, all eight story file names matched, and I used them to pair the stories in that test; do not assume the same for another workflow. After a re-export, the story IDs I had recorded were no longer present in my three tests, so the file names had changed as well. If you cannot establish the correspondence, record the stories as could not be compared. Record a file name present on only one side as a difference in the file list; it does not by itself establish that a story was lost. For each story you can pair, inspect the text inside its <Content> elements. If the source contains text and the target contains none, record a difference. The presence of a <Content> element alone is not a check that the story contains text; in my sample, an emptied story still had the elements, with nothing inside them.
Tables. In each paired story, find each <Table element. Its attributes HeaderRowCount, BodyRowCount, FooterRowCount and ColumnCount give the counts. Compare them only after establishing which table in the target is the counterpart; do not use the order of appearance alone as proof, since one missing table shifts everything after it. Record tables present on one side only separately, and tables you cannot pair as could not be compared.
Footnotes. In each paired story, count the <Footnote elements and compare.
Anchored objects. In each paired story, count the <AnchoredObjectSetting elements and compare. Each anchored or inline object carries one of these elements; in my sample, a story with one anchored frame in the source and two in the target showed one and two of them. I have not tested a file with an anchored group, so if your file contains one and the count is unclear, record this check as could not be compared.
Paragraph styles. Across all story files in each archive, collect the distinct values of AppliedParagraphStyle="…". These are the styles actually applied, as opposed to the styles merely defined in the document. Note any value present on one side only.
Untranslated text. This is a spot check, not a comparison, and the three outcomes above do not apply to it. Choose a few source-language strings you have confirmed were meant to be translated, and search for them in the target's story files. Record the strings searched and any candidates found; a hit is a candidate to check in context, and no hits do not establish that the file contains no untranslated text. Where I automate this check, I apply a word-count threshold; text below that threshold is outside the check, including any untranslated text it may contain, and the method does not work for languages without word spaces.

These checks cover counts, style use and a spot check for untranslated text. They do not establish that every footnote or anchored object is still attached at the same place in the text; that requires a finer comparison than counts. If you need that, treat items 3 and 4 as a first pass, not a conclusion.

I am developing a tool for comparing the structure of two IDML files. Its report distinguishes items it compared from items it could not compare. The current trial and the testing request are in a separate post.

After translation, text differences alone do not tell you whether the document's structure survived. The review also needs to cover stories, tables, footnotes, anchors, styles, and possible untranslated text.

Seeking Testers: Comparing IDML Files Before and After Translation

2026-09-15T04:02:20.523Z

I'm developing a tool that compares two IDML files: the InDesign document you sent out for translation, and the one that came back. It runs on Windows, the current build is unsigned, and the trial is free. I plan to offer a paid version later. What I need now is feedback from people who can run it locally on a real translation job. I'm a technical writer based in Japan, with 17 years in multilingual document production; this blog is where I write about that work.

Why I'm building this

This tool grew out of a question from my translation work: when a document comes back, what changed structurally, and is anything missing? I have not found that question answered by the tools I use, so I started building one.

What the tool checks

It compares the source IDML and the returned IDML for:

missing stories, text frames and tables where a match can be established; emptied story or table-cell text; changes in footnote and anchored-object counts per story
changes in paragraph counts, table row and column counts, applied paragraph styles, and the sequence of character styles within a paragraph
paragraphs, footnotes and table cells whose text is still identical to the source, subject to a word-count threshold (short unchanged text and untranslated text mixed into an otherwise translated paragraph are not reported, and the check is ineffective for text without word spaces, such as Japanese or Chinese)

The comparison runs without launching InDesign, reads the two IDML files without modifying them, and sends nothing over the network. It does not assess translation quality, layout geometry, images or links. Every report lists what was checked and what was not compared, even when it found nothing.

Testing so far has used synthetic documents, not real translation jobs. That is the gap I am trying to close. I'm asking for feedback, not copies of your files or reports.

Getting the trial

The trial and Quick Start are on GitHub Releases: linguist-coder/localisation-qa. You can download and try it without contacting me first. Because the build is unsigned, Windows may show an Open File security warning or a SmartScreen warning; the Quick Start covers both. The trial runs all checks and counts every finding; it shows one finding per rule with its page, object and content, and lists the rest by rule only. Re-running the same pair does not reveal more details. The included sample pair has planted defects and always produces a full report, so you can try it before using your own files.

The trial build does not expire, and there is no deadline for feedback. Running the included sample takes a few minutes, most of it reading the report; a real document pair depends on its size.

So you can decide whether this is worth your time: the paid version is planned as a one-time purchase, about $99, sold under the same name as this blog (Linguist Coder). It runs on your machine and does not send files anywhere. If any of that rules it out for your workplace, I would still like to hear why; that is useful feedback on its own.

Two limits to know before you try it

IDML only. It does not read INDD. You need the source and returned versions as IDML, exported from InDesign if necessary.
Matching depends on identifiers. The tool uses labels added by the included script, or InDesign's internal IDs when labels are absent. In a tested workflow using Okapi, internal IDs survived the translation round trip; they were reassigned when the IDML was then opened in InDesign and re-exported. An existing pair without labels may therefore have objects that cannot be matched; these are reported as "could not be compared", not as clean. For future jobs, run the included script in InDesign before exporting the source IDML you send out; matching then uses those labels if the returned file retains them.

How to send feedback

If you try it, a brief note on these four questions is all I need:

Did you use files from a real translation job, or only the sample?
Did ZIP extraction, launch and analysis all complete? If not, where did it stop?
How do you currently check returned files?
Did it show anything your current check had missed? "No" or "couldn't tell" is useful too; please mention any false alarms.

Email your feedback to hi@linguist-coder.com, or reply to the announcement post on X (@linguist_coder). Please leave out client names and document text when describing your results; replies on X are public. I won't publish feedback sent by email without your permission.

Where an InDesign Script Should Stop

2026-09-11T03:30:49.015Z

A translated document comes back and the layout is full of overset text. Not one frame: dozens, spread across chapters, plus a handful of table cells where the German ran two lines longer than the English.

A script can tighten the tracking, drop a point of type, grow the frame, raise a fixed row height. The interesting question was never whether it can do that. It is how far it should go, what it should refuse to do at all, and what it should say when it stops short.

The examples below come from Overset Fixer Pro, a script I sell for InDesign. Version 2.0 forced four of those decisions into the open, and the last one was a lesson in how quietly this kind of thing goes wrong.

A Row It Could Grow, and Doesn't

InDesign gives a table row one of two height behaviors. At Least means the row grows on its own to fit whatever is in it. Exactly means the row is pinned at a height someone chose, and text that does not fit becomes overset.

If a cell in an Exactly row is overset, growing the row is a reasonable fix. The row is pinned; raise its fixed height a little and the text may fit.

If a cell in an At Least row is overset, growing the row is not a fix at all. That row is already trying to grow. Its height is not what is holding the text back — something else is, usually the frame the table sits in. Writing a height to that row would not solve the problem, and it would do damage on the way past: the height the script writes imposes a minimum the script chose, and the script has no verified way to reconstruct the row's previous state afterward. That is reason enough not to write it.

So the script never writes to those rows. Not as a default, not as an option, not when you clear the option that lets fixed rows grow. That option governs Exactly rows only.

The asymmetry is the whole argument. On one side, one row gets fixed. On the other, the document's existing behavior is replaced by a minimum the script invented, silently, in a document that may have hundreds of rows. The test is not whether the script can do the thing. It is whether the user can get back what the script replaced. When the answer is "by hand, and only if they notice," the feature does not ship.

One Lever at a Time

The text side has three levers: tracking, font size, horizontal scale. Leading is not a fourth; it follows font size at a ratio you set. Each lever has a floor you set, and the floor is a typographic decision before it is anything else — I made that case for the single-lever version in Part 2 of the beginner series, which ends by noting that a script with several levers also needs a rule for the order they are tried in. This is that rule.

The obvious implementation runs them together. Nudge everything down a step, check whether the overset cleared, nudge again. It terminates, and it can be wrong in a way that is easy to miss: text that tighter tracking alone would have fixed comes back a half point smaller and slightly narrower as well. Nothing looks broken. The page is just quietly further from the design than it needed to be, and no single setting explains why.

2.0 runs them as a cascade instead. Tracking goes first and goes all the way to its floor. Only then does font size start moving, with leading following it. Horizontal scale is last, and is reached only if the other two fell short. The loop stops the moment the overset clears. Tracking and horizontal scale are off by default, so a default run moves only the type size and its linked leading; the cascade is the order among whatever you switch on.

Two things come out of that. The result respects the order: when an earlier lever clears the overset, no later lever is touched. And the result is legible: when tracking is enabled and clears the overset at the first stage, you can look at the frame, see that only the tracking moved, and know the type size was never touched.

The order is a judgment, not a fact. I put tracking first because I judge a few units of it to be the least objectionable change of the three, and horizontal scale last because I treat visibly distorted letterforms as the costliest. Someone setting a different kind of work could argue for a different order. What matters is that there is an order, that it is written down, and that it is the same on every run.

Saying What Happened When It Stops Short

Sometimes the levers reach their floors and the text still does not fit. Now the script has to do something, and there are two defensible answers.

Text adjustment mode writes the original values back and counts the frame as unresolved. Part 2 is about why "putting it back" is a claim to test rather than assume. Here it is verified at the level of values: the script snapshots each style run before it moves anything, and a mixed-formatting test confirmed that each run received its original values again, so a story that disagreed with itself comes back disagreeing in the same places. Whether the text's relationship to its styles comes back with the values, I have not tested. Either way the frame is left for a person.

Frame expansion mode does the opposite. A frame or row that was enlarged without resolving is left at its new size rather than silently discarded. That is not a claim that the page is finished: expansion moves only the bottom edge and does not move nearby items out of the way, so the result still needs to be inspected. The choice is simply to keep the enlargement for that inspection, and to report that it remains.

Both answers are defensible. What is not defensible is leaving the user to guess which one happened. The run report names it, and the notice after a frame expansion run says plainly that enlarged frames have been left at their new size, that one Ctrl+Z undoes the entire run, and to do that before making any other edit. Nobody discovers it three pages later. Skips are reported the same way, with the reason attached instead of folded into a single count of failures — a row skipped because it grows on its own is a different fact from a frame the script tried and could not fix.

A limit whose effect you cannot see is not a limit. It is a hope.

The Limit That Was Not Real

Which brings me to the decision that should have been checked before the first version shipped.

Frame expansion has two numbers: how much to add per step, and the maximum a frame may grow in total. They are the safety rail for the entire feature. Set 2mm and 15mm, and a frame should grow in 2mm steps and stop at 15mm.

In a document whose rulers are set to millimeters, it did not. It grew in steps of 5.669mm and would carry on to roughly 42.5mm. Every number was off by the same factor — 2.835, the number of points in a millimeter.

The cause is one step of reasoning that was never verified. geometricBounds reports a frame's position in whatever unit the document's rulers use. The script was converting the user's millimeters into points before adding them. Two values, two unit systems, one addition, no error message.

Nothing announced it. The frames grew, the overset cleared, the script reported success. The clue that led me to it was excess space below the last line in frames the script had expanded, which is exactly the kind of thing you put down to the document. It surfaced when that impression finally got measured: one frame, before and after, read off the Transform panel — 13.529mm to 24.868mm. Two steps of a setting that said 2mm had added 11.339mm.

The fix is unremarkable. The run now forces measurements into points for its duration and restores the previous setting afterward. What is worth keeping is the shape of the failure. Refusing a row and reporting a skip need no number. But the floors in the cascade are numbers, and so are these two limits, and a number in an interface is only a promise about what the code does. The guard had been written, documented, and shipped, and it was not enforcing the value anyone typed.

So the fourth decision is not finished when the limit is designed. It is finished when the boundary has been measured in a real document, in the units the user actually has, rather than trusted because it was written down.

The Pattern Underneath

This is the distinction I keep coming back to in low judgment work: some parts of a production job are mechanical and repetitive, and some parts need a decision only a person can make. Automation earns its place on the first kind, and gets dangerous when it quietly annexes the second.

Where to stop is not one question but four:

What will it refuse to touch, even when it could, because it cannot put the previous state back?
When several levers are available, in what order are they tried, and where does each one stop?
What state is left behind when it stops short, and how is that reported?
Have the limits you configured been measured where they actually run?

The script that comes out of this does less than it could. That is the point. The work it declines to do is the work you would not want it doing unsupervised, and what a tool leaves alone is one of the things I check before handing one to a production team.

Overset Fixer Pro 2.0 is on aescripts + aeplugins, with a free trial.

Your Second InDesign Script: Condensing Text Until It Fits

2026-09-10T05:23:38.333Z

Part 1 reported which pages contained overset text without changing the document. This post changes it: the script below lowers the horizontal scale of the selected frame's entire story, one percentage point at a time, until the overset clears or it reaches a limit you choose.

Two things are worth knowing before you read another line:

It changes the whole story, not the frame. If the story runs through three linked frames, all three get restyled. The reason is structural and I come back to it below.
It expects a frame that reports overset — in practice, an unthreaded frame, or the last frame in a chain. A frame in the middle of a thread passes its surplus along and does not report anything.

This edit needs an explicit limit, and a defined outcome for the case where the text still does not fit.

So the interesting question is not how to condense text. It is how far you are willing to go, what the script should do when that is not far enough, and what "putting it back" actually means.

One number, one typographic decision

Horizontal scale is a percentage. At 100 the type is drawn as designed. Below that, every character gets narrower while its height stays the same.

That is the appeal and the problem in the same sentence. It always makes text occupy less width. It never asks whether the result still looks like the typeface you chose.

In my work I go by the following rough rules of thumb, not measured thresholds, and the exact numbers depend on the typeface, the size, the measure, and how forgiving the job is. A couple of percent goes unremarked in body copy. Ten percent is visible to someone who sets type for a living. By a quarter, the letterforms no longer carry the proportions the designer drew. A display line at 24pt gives you away sooner than a caption at 7pt.

None of that is InDesign's business to enforce. It is yours, and the script should say where you drew the line.

The overset text is not in the frame

Here is the part that trips people up.

You have a frame. You want to condense the text in that frame. So you reach for the frame's text:

frame.characters
frame.lines

Both of these reach the text the frame actually holds — the composed, visible text. But overset text is, by definition, the text the frame does not hold. It belongs to the story and it is waiting outside. Scale only what the frame contains and you are working on the wrong characters; some of the surplus may flow in as the visible text narrows, but you are shrinking the part that already fit in order to rescue the part that did not.

So you go one level up, to the story:

frame.parentStory

And that has a consequence worth stating plainly: if that story flows through three linked frames, you just restyled all three. This is not a bug you can fix by choosing a narrower scope. The story owns the characters; the frame only decides how a portion of them is displayed. A script that condenses overset text is always a story-level operation wearing a frame-level interface, and the honest thing to do is say so rather than let the selection imply otherwise.

The loop needs a second exit

The naive version writes itself:

var frame = app.selection[0];

while (frame.overflows) {
    frame.parentStory.texts[0].horizontalScale -= 1;
}

Do not run that.

The only stop condition written into this loop is that the frame no longer reports overset. It names no minimum acceptable scale, and no outcome for text that still does not fit. Its one exit depends entirely on the document changing its mind, and horizontal scale cannot go down forever.

This is a general lesson worth taking out of InDesign with you: a loop whose exit depends on the world responding needs a second exit that does not. The complete script adds both — a floor, and a defined outcome when the floor is reached.

The floor is not a safety hack

var MIN_SCALE = 90;

It is tempting to read that as loop protection, and it does serve that purpose. But it is really the typographic decision from earlier, written down.

A lower floor permits more horizontal compression, and buys the appearance of a higher success rate by widening what you are willing to ship. Reaching the floor without clearing the overset is not a malfunction: it means this lever failed within the limit you chose, and the frame needs a different kind of fix.

Ninety is not a standard. It is a starting point for the kind of work I do, and it is the first number you should change for yours.

That is the value of putting it on the first line as a named constant. The most visible judgment call in the script sits where you can argue about it.

What "putting it back" can and cannot mean

This is the part I would have skipped a few years ago, and it matters more than the loop.

When the script gives up and writes the original value back:

story.texts[0].horizontalScale = original;

the number you see in the Character panel returns to where it was. The question is what else came back with it.

Does the text then go back to following its paragraph style, or does the assignment leave a local override sitting on top of the style? That is not a question to reason about from first principles. I tested it.

I ran these tests in InDesign 21.5.1.73, on one machine, in one session; I have not checked other versions or platforms. The test is not to look at the page, which shows nothing either way. It is to change the paragraph style's horizontal scale afterwards and see whether that change reaches the text.

Starting from a story that inherited 100% from its style: condense it to 97% and leave it there, and a later change to the style does not reach the text — an override is sitting on it. Write the 100% back, which is what the failure branch does, and the change reaches the text again. Write 90% onto text that already inherits 90%, and nothing is created at all.

A successful fit still needs your approval. The test shows why checking whether the text fits is not enough: keeping 97% also changed how the text responded to later style edits. These results do not establish how every combination of styles and existing overrides behaves.

What the restore genuinely cannot do is put back differences. It writes one value across the whole story, so if the story had disagreed with itself before the run, that disagreement is gone. This is the same problem as the mixed-scale check below, seen from the other end, and it is why the script refuses to start on a story whose runs disagree: the only restore it has is a single number.

The script also groups its edits into a single undo step.

app.doScript(condenseToFit, ScriptLanguage.JAVASCRIPT, undefined,
             UndoModes.ENTIRE_SCRIPT, "Condense to fit");

UndoModes.ENTIRE_SCRIPT groups the operation into one undo step. That matters most after a run that worked: in the same test, undoing a successful run let later changes to the paragraph style reach the text again.

It is worth being precise about what that covers. The restore branch handles one outcome: text that still overflows at the floor. It is not an exception handler. Locked objects or layers can interrupt the run, and the restore line never runs if the failure happens before it. Automatic rollback after an exception is undocumented and unverified here. The recovery instructions in this post describe a run that completed, not a tested recovery procedure for an interrupted one.

The script

Use the setup steps in Part 1 to save the code below as condense-to-fit.jsx. For the first run, work on a copy of a document. With the Selection tool, select one overset text frame — an unthreaded frame, or the last frame in a thread — then run the script from the Scripts panel.

// Condenses the selected frame's story horizontally until the overset clears.
(function () {
    var MIN_SCALE = 90;   // percent - the most distortion you are willing to ship
    var STEP = 1;

    function condenseToFit() {
        var sel = app.selection;
        if (sel.length !== 1 || !(sel[0] instanceof TextFrame)) {
            alert("Select exactly one text frame with the Selection tool.");
            return;
        }

        var frame = sel[0];
        if (!frame.overflows) {
            alert("That frame is not overset.");
            return;
        }

        // The overset text sits outside the frame, so the story is the only handle.
        var story = frame.parentStory;

        // Asking the story for its horizontal scale does not tell you whether the
        // story agrees with itself: a mixed story hands back its first run's value.
        // So compare the runs instead of trusting the effective value.
        var runs = story.textStyleRanges;
        var original = runs[0].horizontalScale;
        for (var i = 1; i < runs.length; i++) {
            if (runs[i].horizontalScale !== original) {
                alert("This story already mixes horizontal scales. Not handled.");
                return;
            }
        }
        if (original < MIN_SCALE) {
            alert("This story is already below " + MIN_SCALE + "%. Not handled.");
            return;
        }

        var scale = original;
        while (frame.overflows && scale > MIN_SCALE) {
            scale = Math.max(scale - STEP, MIN_SCALE);   // never step past the floor
            story.texts[0].horizontalScale = scale;
        }

        if (!frame.overflows) {
            alert("Fitted at " + scale + "%.");
        } else if (scale === original) {
            alert("Already at the " + MIN_SCALE + "% floor. Nothing was changed.");
        } else {
            story.texts[0].horizontalScale = original;
            alert("Could not fit at " + MIN_SCALE + "% or above.\n"
                + "The scale is back at " + original + "%, but the document is still marked as modified.\n"
                + "Use Undo once to undo this run.");
        }
    }

    if (app.documents.length === 0) {
        alert("Open a document first.");
        return;
    }

    app.doScript(condenseToFit, ScriptLanguage.JAVASCRIPT, undefined,
                 UndoModes.ENTIRE_SCRIPT, "Condense to fit");
})();

"Fitted at X%" is not the end of the job. It means the selected frame no longer reports overset. Before you keep the result, look at every frame in that story — all of them were restyled — and decide whether you accept the horizontal-scale change. In the style-inherited case tested above, keeping the fitted value also meant keeping a local override. To reject the run, press Ctrl+Z once.

Three more small things are doing real work.

Clamping the step. The starting scale is not necessarily a whole number — a story sitting at 90.5% is perfectly ordinary. Subtract one and you are at 89.5%, below the floor you just spent a section defending, and if the text happens to fit there the script reports success. Math.max(scale - STEP, MIN_SCALE) prevents a step from going below the floor. If the text fits sooner, the loop stops there. A floor you can step over is not a floor.

Restoring only what was written. If the story starts at exactly the floor, the loop makes no assignment at all. So the restore is guarded: that branch skips it and reports that nothing was changed — which is the point. A run that changed nothing should not ask you to go and check anything.

Comparing the runs before writing. If part of the story is already condensed and part is not, the script has no business scaling the whole thing from a single starting number. My first version treated a numeric result as evidence of a uniform scale: it asked the story for its horizontal scale and refused if the answer was not a number.

The mixed-run tests showed that check does not detect the differences. In a story with three runs at 100, 95 and 100, story.texts[0].horizontalScale returned the number 100. Flip the order so the runs read 95, 100, 100 and it returned 95. In these tests the property returned the first run's value rather than any marker for mixed values, so the check never fired and the run went on to flatten a difference it had not noticed.

The check has to compare the runs itself — this is the excerpt from condenseToFit above:

var runs = story.textStyleRanges;
var original = runs[0].horizontalScale;
for (var i = 1; i < runs.length; i++) {
    if (runs[i].horizontalScale !== original) {
        alert("This story already mixes horizontal scales. Not handled.");
        return;
    }
}

The guard compares horizontal-scale values, not the number of runs. In the six-run test, the text differed in weight, size and color, but every run started at 100% horizontal scale. The script accepted it and fitted the text at 95%.

Note also what the check does not buy you. It confirms the runs agree on a value. It says nothing about whether that value came from a style or an override, which is the distinction from the section above. Uniform on screen is not the same as uniform underneath.

Where this stops working

Run it on real pages and you will meet the edges quickly.

Condensing does not always help. What it buys is width, so it works by changing where lines break. When the overset is governed by vertical constraints rather than by line length, narrowing the characters may buy very little. The script reports that it could not clear the overset within your limit, but not which kind of problem you had — and "it did not work" and "it cannot work" look identical from the outside.
A version with several adjustment methods needs more than the methods. Tracking, leading, point size and the size of the frame itself all buy space, and each buys a different amount at a different cost. Applying several of them on each pass can change more than necessary: the text may fit after one adjustment, before the others are applied. So such a version needs a limit for each method and a rule for the order they are tried in. This script implements one method, which is why it can get away with one number.
One percentage point at a time is coarse. A frame that would have cleared at 99.4% gets taken to 99%. Fine here; not fine if you are trying to prove you used the minimum distortion necessary.
This is advice about horizontal Latin text. The 90% starting point reflects my work with it. A composite font can cover several scripts under one setting, so do not assume that a limit acceptable for one of them is acceptable for the rest. Choose and review a limit for the text in the job in front of you rather than carrying this one across a language boundary.
Locked objects and locked layers can cause an exception. This script does not check their lock state before writing. A production version checks first, which is the difference between recovering from a problem and not having one.
One frame at a time. Part 1 hands you a list of pages. If there are forty overset frames on them, this script asks you to click forty times.
A document-wide version has to rescan and repeat. Fixing one frame can change what fits elsewhere: expanding a frame can make its text overlap nearby content, and condensing a story recomposes every frame that story runs through. Once a lever changes geometry, the fix stops being local, so a version that works on a whole document needs to rescan and repeat until nothing changes — with a limit on the number of passes, so that it stops instead of thrashing.

What the two scripts are for

Part 1 defined what to inspect and what its report meant. Part 2 defines what to change, how far to change it, and what happens when the text still does not fit.

The floor is only one part of that decision. Before running the script, accept its story-wide scope. After a fit, review the result and decide whether to keep the horizontal-scale change. If the text still does not fit, the script writes the starting scale back — in the case tested above the text followed later style changes again, though the document stays marked as modified — and one Undo reverses the whole run.

Those choices belong to the person running the script. The code only makes them explicit.

What neither script covers is the case that actually eats the day — a hundred frames across a dozen documents in five languages, where several methods have to be tried in a defined order, the results recorded, and anything unfixable handed back to a human with its page number attached. I discuss broader multilingual production workflows in this earlier post.

I also sell Overset Fixer Pro, a paid script for document-wide fitting with multiple adjustment methods and reports of what was fitted, left overset, or skipped.

InDesign Will Not Warn You About External Links

2026-08-22T00:10:57.340Z

A document opens cleanly. No red flags in the Links panel, no warnings on export. It gets zipped, copied to a shared drive, or handed off as it stands. On the other machine, images are missing — not one or two, but a screenful.

Nothing broke in transit. The links were already pointing at places that were never going to travel with the file. They had been for weeks. The handoff was just the first moment anything depended on it.

Two Kinds of Bad Link, and InDesign Only Names One

InDesign is precise about link state. It will tell you a link is missing — the file is not where the document expects it. It will tell you a link is out of date — the file changed since it was placed. Both get a badge in the Links panel, and both are picked up by the default preflight profile.

There is a third situation it does not treat as a problem: the link resolves perfectly, and its source file lives somewhere that only exists on your machine. A different folder. A different drive. Someone's Desktop.

This is not a third link status, and InDesign is not wrong to omit it. The link genuinely is fine. Missing and out-of-date are observations about the file as it is right now. An external source is a different kind of fact — a dependency on a location that may or may not exist on the other side of a handoff. That is a property of the workflow, not of the link, which is why no badge covers it.

What "External" Means Here

Worth pinning down, because everything below depends on it.

LinkSafe uses one deliberately strict rule: the canonical home for a linked file is the Links folder beside the INDD. Anything outside that folder is reported as external — including files elsewhere inside the same project folder, which would travel with the document perfectly well.

That is a workflow policy, not an InDesign category. If your shop keeps assets in Photos/ and Logos/ next to the document and always moves the whole tree, those links are fine in practice and LinkSafe will still list them. The strictness is the point: one canonical place means one test, with nothing to configure per project and nothing to get wrong.

The Panel Shows You a Name, Not a Relationship

It would be wrong to say the path is hidden. Open the Links panel menu, choose Panel Options, and you can switch on Folder 0, Folder 1, Folder 2 — the enclosing folder and its parents — as columns. Select a link and Link Info shows the full path.

So the information is there. What is not there is the comparison.

Folder 0 tells you a link sits in a folder called Images. It does not tell you which Images — the one beside this document, or the one on the shared drive, or the one in last year's job folder. Two links showing an identical folder name can point at completely different places. The panel gives you a label; what decides the outcome is a relationship between two paths, and there is no column for a relationship.

That leaves reading full paths row by row. It is fine at six links and stops scaling quickly, because a clean result is only provable by exhaustion: there is no shortcut to establishing that none of the remaining rows point somewhere else.

Meanwhile the state accumulates through ordinary work — duplicating last year's layout, reusing a logo from a shared folder, placing an image straight out of a client's download folder, opening a document built on a machine with different drive letters. Each one leaves a link pointing somewhere a handoff will not carry.

Package Fixes the Handoff, Not the Working Document

The obvious objection is that InDesign already covers this. File > Package copies linked graphics into a Links folder and, with Update Graphic Links in Package enabled, repoints the links at those copies. That is true, and for a handoff it is the right tool — done properly it prevents exactly the failure this post opens with.

The distinction is narrower than "Package is not enough," and it is worth stating exactly: Package makes a portable copy. It does not change the dependency structure of the document you keep working in. The links that get repointed belong to the copy inside the package folder. Your working file still points wherever it pointed before.

If production continues from the packaged copy, that is a complete answer and there is nothing left to do. If production continues from the original — the common case, since the original is what sits in the job folder and carries the edit history — then the underlying condition is untouched, and every future handoff depends on remembering to package correctly again.

Consolidating in place is the other operation. It changes the working document so that its eligible links resolve from the canonical Links folder beside the INDD. Packaging is still the right way to hand off afterward; by then the links are already consolidated.

This Is a Low Judgment Check

Once the canonical location is fixed by policy, deciding whether a given link satisfies it takes no judgment at all. At the scripting level it reduces to a deterministic path-containment test — after both paths are normalized, which is the part that is less trivial than it sounds: separators, trailing separators, and whether the volume is case-sensitive, which LinkSafe probes at run time rather than inferring from the operating system's name.

Objective detection, predictable action: that is the combination I have written about before as low judgment work, and it is the category that is safe to automate first. There is a second reason to hand it over, which only shows up later. Done by hand, the result exists in someone's head and there is nothing to point at afterward. Done by tool, the result is a file — and a file can be attached to a handoff, filed with the job, or read six months later when someone asks what happened.

Consolidation Is Four Operations, Not One

"Collect the links" sounds like one action — copy the files. It is four, and skipping any of them is where consolidation scripts usually go wrong.

Copy every eligible external file into the Links folder beside the document. Eligible carries weight: an embedded graphic has no external source to copy, because it is already stored inside the document; a missing file cannot be copied at all; a file already in the folder does not need to be. Three different reasons, and each should be recorded rather than silently skipped.
Relink the document to the copies. This is the step that changes the document, and the only one that does.
Verify each relink after making it. Not assume — read the link back and check both its status and its resolved path against the copy you intended. A relink that reports success and does not land is worse than no relink at all, because now the document looks consolidated.
Log the run. What moved, what did not, and why.

Name conflicts deserve their own note. Two different images called logo.eps from two different folders will collide in one flat folder. Blind overwrite is the unsafe answer: it leaves a file that still opens, still shows an image, and shows the wrong one. Several responses are defensible — preserve the source hierarchy, abort on collision, ask. LinkSafe renames the incoming copy (logo.eps, logo_2.eps) and never overwrites what is already there.

The Script

LinkSafe is an InDesign script that does the above. It has one mode that changes the document and three that only read it:

Collect & Relink — copy, relink, verify, log. The run is wrapped as a single InDesign undo transaction, so one Ctrl/Cmd+Z reverts every relink together.
External Links Report — a CSV of every link whose source sits outside the Links folder beside the document, with its path and a reason code.
Missing Links Report — a CSV of everything that is gone, keeping the recorded path so you know what to restore.
All Links Inventory — one row per link with its status: local, external, embedded, missing.

The three report modes do not touch the document. That separation is deliberate: on a file you did not build, you want to look before you change anything.

Worth knowing before leaning on it:

Undo covers the relinking, not the copying. The relinks revert in one step because the run is wrapped as one transaction. The copied files stay on disk — a filesystem operation is not something Undo can reach — and nothing already in the folder is overwritten. Delete the unused copies manually once you are satisfied with the document.
It does not collect fonts. Package does. Consolidating links is not a replacement for packaging; it removes one class of failure from it.
It does not reconstruct missing sources. If a recorded path no longer resolves, LinkSafe can list it but not rebuild it. Recovering the file from a backup, an earlier package, or the machine it came from is outside what a script can do.
It works on links, whatever they point at. Everything in the Links panel is in scope — graphics, placed INDD files, linked text — because the rule is about where a source file lives, not what kind of file it is. What it does not do is recurse: a placed INDD is copied and relinked as a file, but the links inside that document remain that document's own problem. Fonts and color settings are not links at all, and are separate concerns with separate failure modes.

Full walkthrough here: https://youtu.be/Ccm4zA4w6dw

LinkSafe is on aescripts, with a free trial: https://aescripts.com/linksafe/

Your First InDesign Script: Which Pages Have Overset Text?

2026-07-29T00:18:19.631Z

Most InDesign scripting tutorials open with a finished script. This one opens a step earlier: with the smallest useful thing a script can do, and with the decision of what to leave out of it.

The goal is one dialog that tells you which pages of the open document contain overset text. To be precise about what that means, since precision is most of the point here: it checks the text frames that belong directly to each page, and nothing else. It is not a complete document-wide audit. It will not mark anything, it will not fix anything, and it will not write a log file. Those are not missing features. They are the boundary I drew before writing the first line.

If you already write ExtendScript, you may want the production-shaped version I published earlier instead. This post is for the reader who has not yet run a script in InDesign at all.

The one property that does the work

Overset text is text that has nowhere to go. A story contains more than its available frames can display, and the surplus sits outside the layout, invisible. In a single frame it appears once the story exceeds what the frame can hold; in a threaded chain of frames it appears after the last frame in the chain. InDesign shows you this as a red plus sign in the frame's out port.

InDesign already knows. You do not have to measure anything, compare anything, or compose anything. You only have to ask:

textFrame.overflows

It returns true or false.

Reading the property is the easy part. The work in this post is deciding which objects to ask, and how to report what comes back — which turns out to be where all the interesting decisions live.

Running a script at all

If you have never run one, here is the whole setup.

Open the Scripts panel: Window > Utilities > Scripts.
Right-click the User folder and choose Reveal in Explorer (Windows) or Reveal in Finder (macOS).
Save a plain text file into that folder with a .jsx extension.
Back in the Scripts panel, double-click the file to run it.

Two things to know before you type anything.

ExtendScript is an old dialect of JavaScript. Roughly ES3. There is no let, no const, no arrow functions, and no Array.prototype.forEach. You write var and you write for loops. Code copied from a modern JavaScript tutorial will often fail here for reasons that have nothing to do with InDesign.

Save it as plain text, and watch two separate things.

The first is your quotes. Many editors, and every word processor, replace straight quotes (" and ') with typographic ones as you type. Those are different characters, and JavaScript will not accept them as string delimiters. If you paste code from a web page and get a syntax error on a line that looks perfectly correct, this is usually why.

The second is the file's encoding. Save as UTF-8, and confirm your editor is actually writing UTF-8 rather than quietly using something else. Older ExtendScript environments can behave inconsistently when a script contains non-ASCII characters, sometimes reporting a syntax error on a line that has nothing wrong with it. Keeping comments in ASCII avoids that particular source of trouble. If you want Japanese or accented text in your dialogs, that is fine — just be deliberate about how the file gets saved.

Step 1: ask one frame

Select a text frame on the page, then run this:

(function () {
    alert(app.selection[0].overflows);
})();

You get a dialog saying true or false. That is the entire mechanism.

The wrapper is worth explaining. (function () { ... })(); defines a function and calls it immediately. Anything you declare with var at the top level of a script goes onto the global object, which is shared by everything running in the same ExtendScript engine — and whether those leftovers outlive your script depends on which engine InDesign used to run it. The wrapper means you never have to know. Your variables stay yours, and the script becomes a self-contained unit you can drop into a larger one later without renaming anything.

This version breaks if nothing is selected, or if you selected a rectangle instead of a text frame. That is fine. It exists to prove the property works, and then it goes away.

Step 2: ask every page

The obvious next move is two loops: every page, and every text frame on that page.

var doc = app.activeDocument;

for (var i = 0; i < doc.pages.length; i++) {
    var frames = doc.pages[i].textFrames;

    for (var j = 0; j < frames.length; j++) {
        if (frames[j].overflows) {
            alert("Overset on page " + doc.pages[i].name);
        }
    }
}

This works, and it is unusable. A document with thirty overset frames gives you thirty dialogs, each one waiting for a click. The script is correct and the experience is wrong, which is a distinction worth learning early.

The fix is to separate finding from reporting. Collect everything first, then say it once.

Note also doc.pages[i].name rather than i + 1. If the document uses sections — front matter in roman numerals, a chapter that restarts at 1 — then i + 1 gives you a number that appears nowhere in the page box, and you will go looking for page 7 and not find it. page.name is the label you actually see in the Pages panel.

The tradeoff is that page names are not guaranteed to be unique. In a document where every chapter restarts at 1, a result of 1, 1, 3 is entirely possible and tells you less than you want. For most documents this never comes up; when it does, you have outgrown this script.

The script

// Reports which pages contain an overset text frame.
(function () {
    if (app.documents.length === 0) {
        alert("Open a document first.");
        return;
    }

    var doc = app.activeDocument;
    var hits = [];

    for (var i = 0; i < doc.pages.length; i++) {
        var page = doc.pages[i];
        var frames = page.textFrames;

        for (var j = 0; j < frames.length; j++) {
            if (frames[j].overflows) {
                hits.push(page.name);   // page.name respects section numbering
                break;                  // one report per page is enough
            }
        }
    }

    if (hits.length === 0) {
        alert("No overset text frames found.");
    } else {
        alert("Overset text on page(s): " + hits.join(", "));
    }
})();

Two lines are worth pointing at.

The break stops scanning a page as soon as one overset frame turns up. You already know the answer for that page, and the question is which pages to look at, not how many frames are involved. It also means each page object is added to the list at most once, without any deduplication logic.

The guard at the top costs three lines and removes an entire class of confusing failure. app.activeDocument throws when nothing is open, and the resulting error dialog says nothing useful to someone who has run four scripts in their life.

What I left out, on purpose

It reports pages, not frames. The question this script answers is "where do I need to look." A page number answers that. A frame identifier would need coordinates or labels to mean anything, and then I would be building a different tool.

It shows a dialog, not a log file. A file needs a path, a format, a write permission, and a story about what happens to it next week. A dialog needs none of those. Every one of them is a decision I did not have to make. The ceiling is real, though: a document with sixty overset pages produces a dialog you cannot comfortably read or copy out of. That is the point at which writing to a file, or building a scrollable window, stops being optional.

It does not fix anything. This is the limit I would defend hardest. Detection and correction fail differently, and at different prices. A detection that fires when it should not costs you a look. A detection that stays quiet when it should not — the failure mode every exclusion in the next section produces — leaves overset text sitting in the file. A correction that goes wrong changes the layout itself. Keeping detection and correction in separate scripts is what lets you weigh those three risks one at a time instead of all at once.

Small scope is not a stage you pass through on the way to a real script. It is the thing that lets a short script be finished.

Where the script stops seeing

Being honest about the edges is part of the design, so here is what this one does not catch.

Frames inside a group. page.textFrames returns the frames the page owns directly. A frame nested in a group is owned by the group.
Anchored frames. A text frame anchored into another story lives in that story, not on the page, for the same reason.
Frames on the pasteboard. They belong to the spread rather than to any page, so the page loop never reaches them.
Frames on parent pages that have not been overridden. Parent pages — still called master spreads in the scripting DOM — are a separate collection.
Overset inside a table cell. The cell hides the surplus text without the containing frame reporting overflows at all. Cells carry their own overflows property, so a fuller version has to walk tables separately.
Threads. In a chain of linked frames, normally only the last one returns true. You learn the page where the text ran out, not the page where the pressure started.

These are deliberate exclusions, not oversights — but they turn into defects the moment the script gets described as a complete overset audit, which is why I put the scope in the first paragraph rather than here. A script that answers one question cleanly and a tool that covers a workflow are different objects, and most of the frustration in scripting comes from expecting one to behave like the other.

If you want the version that walks the whole document, parent pages included, and marks what it finds directly on the page, that is the earlier post.

Finding overset is the easy half. In Part 2, I take the most obvious way to fix it — condensing the type horizontally until the text fits — write that script with the same discipline about limits, and then look at exactly where the approach stops working.

When InDesign Fails to Export: Start by Finding the Broken Page

2026-07-14T23:06:19.585Z

InDesign export failures can be difficult to diagnose. A document may open normally, but fail when you try to export it as a PDF. The file may hang partway through, crash the application, or produce an incomplete PDF with no clear error message.

When this happens, the first problem is often not fixing the file. The first problem is finding where the failure starts.

A note on scope. This article is about one specific situation: a PDF (or print) export that fails in a way you can reproduce with a specific page range. That scope matters, because the core technique below — testing page ranges — only works for outputs that accept a page range. IDML export and ordinary "Save As" failures do not; there is no "export only pages 1–150 to IDML." Those require a different isolation method based on duplicating the document and removing pages or content, which I touch on at the end but do not cover in depth here.

A damaged InDesign document can fail for many reasons: a corrupted object, a broken placed file, a font issue, a complex table, an anchored object, a parent-page item, threaded text, transparency settings, or internal document corruption. Trying to repair everything at once is rarely efficient. A better first step is to narrow the search area.

Why diagnosis should come before repair

When an export fails, it is tempting to start deleting objects, replacing links, changing fonts, or exporting to IDML immediately. Sometimes that works. But it also changes the document before you understand the problem, which can make troubleshooting harder. You may spend time on pages unrelated to the failure, or apply a repair that appears to work temporarily without addressing the cause.

Before repairing the file, it is usually better to answer two smaller questions in order:

Is this actually a page-local content problem at all?
If so, which page should I inspect first?

The first question is the one most people skip — so let's start there.

First, rule out the environment

Before you bisect a 300-page document, confirm that the failure is caused by the document's content and not by something around it. A PDF export can fail for reasons that have nothing to do with any page:

the output folder's permissions, or a network / cloud-sync destination
low disk space
corrupt InDesign preferences
a third-party plugin
one specific PDF preset
memory pressure on large jobs
a problem with the InDesign install itself

If one of these is the real cause, page bisection may never converge — or worse, converge on a misleading suspect range. So run a short gate first:

Reproduce on a copy. Duplicate the .indd and confirm the failure still happens. Work on the copy from here on.
Export to a plain local folder. If it now succeeds, the problem was the destination, not the document.
Test the preset in isolation. Create a new one-page document and export it with the same preset. If that fails too, suspect the preset or the environment, not your file.
Try a known-good preset. If your file exports fine under a different preset, you've narrowed it to preset-specific handling (fonts, transparency, color conversion, compression).
Classify the failure. Is it a clean error dialog, a hang, a crash, or a silently incomplete PDF? These are different problems, and you'll treat them differently below.
Test the same range twice. If the same export sometimes passes and sometimes fails, the failure is non-deterministic — and, as you'll see, bisection cannot be trusted in that case.

Only once the failure survives this gate — reproducible, document-specific, deterministic — is page-range bisection the right tool.

Common causes, once it is the document

When the cause is inside the file, it is often hidden. The page can look normal, and the error message rarely names the responsible object. Candidates include:

corrupted page items
missing or damaged linked images
damaged placed PDF, AI, or EPS files
font problems
complex tables
anchored objects
parent-page (formerly "master page") items
threaded-text problems
transparency or effect settings
internal document history or file corruption

One item deserves a caveat: overset text is frequently blamed, but it usually causes missing output rather than a halted export. Keep "the export failed" and "the output is incomplete" as separate problems; they don't always have the same cause.

Why a script can't do this whole job unattended

If you write InDesign automation, your instinct here is probably to script it: loop through the pages, export each one, catch the error on the bad page, write a report. It's worth being precise about what a script can and cannot do, because the honest answer is both, depending on how the export fails.

InDesign export failures don't share one failure mode:

A catchable scripting exception. exportFile() throws, control returns to your script, try/catch works, and you can log the result. A script handles this case fine.
An asynchronous failure. asynchronousExportFile() returns a background task and reports problems later, decoupled from the calling try/catch. The error may surface well after the line that started it.
A hang. The InDesign process is still alive but unresponsive. Your script is stuck inside the same process and never returns.
A hard crash. The native InDesign process terminates rather than raising a catchable exception, taking your script down with it before it can log anything.

For diagnosis, it helps to take the asynchronous path off the table — and how you do that differs for manual tests versus scripts. For manual File > Export tests, you can disable desktop background PDF export: quit InDesign, place an empty file named DisableAsyncExports.txt in the application folder (on macOS, inside the app's Contents/MacOS/; on Windows, the InDesign program folder, which usually needs administrator rights), then relaunch. PDF export will then run in the foreground and block the InDesign UI until it finishes. In a script, there's no file to place — the choice is explicit: exportFile() for a synchronous call, asynchronousExportFile() for a background task.

Either way, a foreground/synchronous export ties any catchable error directly to the export attempt, instead of it being reported later by a background-task alert — easier to observe, time, and trap. (A hang or hard crash can still prevent control from returning; running in the foreground only helps with the errors that are catchable in the first place.)

The hang and the hard crash are the two that break the "just script it" plan. When the host process hangs or dies, an in-process script cannot record a post-export result or continue to the next page. In a hang, the script never regains control; in a crash, the process and the script terminate outright. Either way, nothing gets logged after the fact.

But notice the limit precisely, because it is narrower than "scripting is useless here." A script can still write the range it is about to test and persist that line to disk before starting the export. What it cannot do is complete an unattended full sweep in a single process: after a crash it needs to be relaunched and resumed. So the honest framing is not "manual instead of script." It's: an in-process script can preserve state, but it cannot recover and continue on its own. The dependable, low-effort method for that recovery loop is your own hands.

The manual method: page-range bisection

The most dependable approach is to divide the document into smaller page ranges and test them by hand. Because you are the one clicking Export, a crash costs you a relaunch — not your entire record.

A precondition first. Bisection is reliable only when two things hold: the failure is reproducible, and there is at least one local, independent trigger — a page or contiguous range that still fails when it is tested inside one of the two halves on its own. ("Local" here means it can be reproduced within a sub-range by itself, not merely that it's "visible on the same page.") There can be more than one such trigger, which is why removing one may not make every other range pass. As long as at least one local trigger holds, the search is efficient:

Export the whole document (you did this in the gate above).
If it fails, export only the first half.
If the first half succeeds, a trigger is in the second half — split that.
If the first half fails, split it.
Repeat until the failing range is a single page or spread.

Page-range bisection: follow the failing half down, splitting each time, until one suspect page is left.

Each test roughly halves the search area, so a 300-page document usually collapses to one suspect page in about nine splits (plus the initial full-document test).

That locality assumption is exactly what breaks in the hard cases, so watch for these — where bisection can point at the wrong range, or at no range at all:

the export fails only when two specific pages are both present (an interaction — a cross-reference or shared resource — so neither half fails on its own)
the failure depends on total load: memory exhaustion that only appears on large ranges, or accumulates across many sequential exports
results vary between runs (a non-deterministic failure)
the tested pages depend on adjacent-page or document-wide state — parent-page items, threaded stories, shared swatches, cross-references
the whole document fails but neither half does — the trigger is not independently page-local; it may be document-level state, a cross-range interaction, or total workload

One case looks like a breakage but isn't: multiple independent bad pages. Bisection still finds one of them just fine — the catch is that fixing that page won't fix the document, because another remains. That's exactly why the last habit below matters.

A few habits keep the manual search reliable:

Record every range and its result in a two-column note. After a crash forces a relaunch, this note is the only thing stopping you from repeating tests.
Fix one preset for the whole session — the one you actually need — and note which it was.
Test spreads, not single pages, for spread-based layouts.
Relaunch cleanly after a crash and reopen the copy fresh before the next test.
After isolating one page, re-test the whole document with that page removed to check for a second bad page.

Record your intent before each risky export

There is one place where a little automation helps, and it does not contradict anything above — because it does its work before the export, not after.

Keep a log, and write the next line and save it to disk immediately before each export attempt. The key word is save: an unsaved editor buffer is not durable against an editor crash, a system crash, or power loss (an InDesign-only crash usually spares an external editor, but don't count on it). Use a log format that distinguishes states rather than just "OK/Failed":

STARTED    range=151-300
COMPLETED  range=151-300  output=exists, pages=150, opens=yes
FAILED     range=151-300  error=<message>
TIMEOUT    range=151-300

If InDesign crashes, the log's last line will be a STARTED with no matching COMPLETED. That tells you which range was being attempted when it stopped — a strong suspect, not a proven cause. Two refinements matter:

A STARTED-only entry means only that no completion was recorded for that attempt. The cause could be a crash, a hang followed by a forced quit, a system interruption, or even a logging failure — so treat it as a candidate, not a verdict.
Beware the success-then-crash case: if the PDF finished but InDesign crashed before writing COMPLETED, the range looks failed but isn't. Check whether the PDF exists, has a plausible size, opens, and has the expected page count — that distinguishes a finished export from an interrupted one, though it still doesn't prove every page rendered correctly.

You can maintain this log by hand or with a tiny helper that only appends-and-flushes a line (that part never touches the failing export, so it's safe either way).

If you want to push it further: an external driver

To actually recover and continue across crashes without you at the keyboard, the automation has to live outside InDesign, so it survives the crash. This is a real option, but it is considerably more work than the manual loop, and worth doing only if you hit these failures often.

On Windows, InDesign exposes a COM automation interface onto substantially the same scripting object model the JavaScript engine uses, with language-specific mappings — so an external Python process (via win32com, Dispatch("InDesign.Application")) can drive it directly. On macOS, the equivalent path is AppleScript / Apple Events. (Note that you can't simply drop a .py file in the Scripts panel; Python isn't a natively supported in-panel language, so it drives InDesign through that external COM/AppleScript layer.)

A production-grade driver needs more than a liveness check, because a hang is not a crash: the process stays alive but never returns, so "is InDesign still running?" won't detect it. At minimum it needs to handle launch-completion detection, modal/recovery dialogs, a per-range timeout, output-file validation (exists, size, page count, opens as a valid PDF), forced termination, relaunch, and a persisted state file so it can resume the sweep.

For genuinely unattended, high-volume automation, the intended tool is InDesign Server, the headless, UI-less product (commonly driven over SOAP). But it is a separate product and license, and it does not guarantee it will reproduce a desktop InDesign failure identically — so it's a scaling path, not a drop-in diagnostic for a single broken desktop file. (Note too that asynchronous export is a desktop-only feature; InDesign Server exports synchronously.)

After isolating the page: go object by object

Once you have a suspect page, keep bisecting — this time at the object level, and always on a duplicate of the original. (Copying suspect objects into a new document can silently regenerate their structure and "heal" the corruption, giving a false pass; deleting or hiding within a duplicate of the original preserves the problem.)

Check the Links panel on that page for missing or modified links.
Hide or delete half the objects on the page, re-test, and narrow down — the same bisection idea, one level lower.
Temporarily swap placed PDF / AI / EPS files for a low-res proxy or a known-good file.
Remove parent-page items from the page and test.
Check bleed, slug, and pasteboard items that print but are easy to overlook.
Inspect tables, anchored objects, and grouped objects.
Re-test with the same preset after each change.

This is still investigative — but now the search area is one page, then a handful of objects, not a whole book.

What the result does and doesn't tell you

Isolating a page is useful, but interpret it carefully.

A failing range is a strong candidate for inspection. A range that passed is not proof the document is healthy. And even a single isolated page is a failure-triggering page, not necessarily the root cause — the actual cause may be a parent page, a shared swatch, document structure, total export load, or an interaction with another page. Call it a suspect page or trigger range, and don't attribute the root cause to the page itself until you've confirmed it at the object level.

There's also a practical cost: for very large documents, many manual exports take time, and each crash means a relaunch. Bisection keeps the number of tests low, but budget for the relaunches.

Why this matters for scalable DTP workflows

In multilingual DTP and production work, file failures are usually handled as one-off emergencies. Someone investigates, tries a few repairs, finds a workaround — and the knowledge disappears when the job ships.

A written diagnostic record changes that, even when the whole process was manual. But to be reusable, the record needs more than "page 3 failed." Capture:

InDesign version and build, and the OS
output format and the exact preset name/settings
output destination (local vs network/sync)
failure classification: error, hang, crash, or incomplete PDF
reproducibility rate (always, or intermittently?)
the suspect range/page and, if found, the object
relevant link and font versions

Do this a few times and patterns emerge — the same placed-file type, the same font, the same parent page. That's the beginning of a repeatable document-health practice, and it doesn't require a single line of working script.

Conclusion

When InDesign fails to export a PDF, the most important first step is not always to fix the file. It's to rule out the environment, then narrow the document until only a suspect page — and then a suspect object — is left.

The instinct to automate that is understandable, and partly right: a script can preserve state before each risky export. What it can't do is recover and continue on its own after the process hangs or dies, which is exactly what the hard failures do. So the dependable core is a manual bisection, backed by a log that records your intent before each export and distinguishes a crash from a genuine failure.

Good troubleshooting doesn't always fix the problem directly. Often the most valuable thing it does is shrink the search until there's only one page left to suspect — and make sure a crash can never erase the fact that you got that far.

The Expensive Part of Multilingual DTP Isn't Only the Translation

2026-07-08T04:05:06.982Z

A finished English layout existed in InDesign — a short quick-start guide, set cleanly, with a type hierarchy and a grid. It needed to exist in Japanese and German as well. The translations were already done. What remained was the part that actually takes the time: getting each language back into the layout.

That last step is easy to underestimate. It sounds like typing, or pasting. In practice it is where multilingual production quietly goes wrong, and the reason is worth stating plainly.

What Is Fixed, and What Varies

A multilingual document has a fixed part and a variable part. The design — the frames, the styles, the master pages — is fixed. The language is the variable. The job is to hold the first constant while changing the second.

Done by hand, that distinction collapses. Each language becomes a fresh layout task: select the text, replace it, then re-check every frame by eye. The design that was supposed to stay constant is now being re-touched three times, five times, once per language — and every touch is a chance to move something that was meant to stay put.

So the useful question is the same one I keep returning to in production work: which part is the source, and which part is derived? Here the layout is the source. Each language is a rendering of it. The text content is the only thing that should change.

Two Failures That Ship When You Reflow by Eye

Translating is the easy part precisely because a translation is just different words. The trouble is that the different words have two other properties the layout cares about.

The first is length. German runs longer than English — often much longer. The same sentence that fit a narrow column in English now overflows its frame. On screen the overflow is a small red +; in a shipped PDF it is simply missing text. Nobody decided to cut the sentence. It fell off the end of a frame that no one re-measured.

The second is script. Japanese set in a Latin font renders as tofu — the empty boxes □□□ that appear when the font has no glyph for the character. The text is correct; the font just cannot draw it.

Both of these are detectable properties of the swap, not matters of judgment. A frame either overflows or it does not. A font either has the glyphs or it does not. Which means they belong to the tool, checked at the moment the text is swapped — not to a human doing a final visual pass and hoping to catch them.

Swap the Content, Keep the Container

The approach that follows from this is a keyed swap. Every translatable frame carries a label — a key — and the translation table is keyed the same way:

key, en, ja, de
title, Quick Start Guide, クイックスタートガイド, Kurzanleitung zur Inbetriebnahme
intro, Thank you for ..., 本製品をお選び..., Vielen Dank, dass Sie ...

The script matches each frame to its key, replaces the text inside it, and re-applies that frame's paragraph style to the swapped text. The master pages and the paragraph-style definitions stay exactly as they were — they were never the variable. Where a language needs a different font — Japanese — the script applies it as a local override on the swapped text, leaving the style definition itself unchanged. This is the same shape as a TMS round-trip — extract, translate, reimport — done directly against the document.

And because the swap is the moment the new text meets the old frame, it is the right moment to check the two failures:

Overset is caught and reported. Every frame where the translated text no longer fits is written to a report, by language and by key. The overflow that a by-eye reflow ships becomes a line you read before you deliver.
A CJK font is applied automatically. For Japanese, the script finds an installed CJK font and applies it as a local override on the swapped text — the paragraph style itself is left as defined. If no CJK font is installed, that is flagged in the report rather than exported as broken output: a missing font is a note to fix, not a file you send.

The design — frames, master pages, and the style definitions — survives; the content is replaced, and for Japanese the font is overridden on that swapped text.

Two Ways to Run It

The same engine reads two ways, and which one you lead with depends on where the content lives.

One CSV in, every language out. Hand it a table (key, en, ja, de, …) and it lays out and saves each language as a finished document, plus the report. One data file in, a set of print-ready PDFs out.
On your own document, in place. Open your branded InDesign file, point the script at a language, and it swaps that layout where it stands — preserving your design. This is the real localization job: here is our brochure, we need it in five languages.

Where This Has Limits

Worth knowing before you lean on it:

Right-to-left is out of scope here. Arabic and Urdu need bidirectional layout handling that this proof does not attempt.
The swap is whole-frame, and it does not preserve inline formatting. Each keyed frame is replaced with plain text from the table, so local emphasis — a bold word, a character style on a single term, or several different paragraph styles inside one frame — does not survive the swap. A frame comes back in one paragraph style, with | adding further paragraphs in that same style. That is what keeps the behavior predictable, and it fits structured, one-field-per-frame content — a label, a spec line, a short guide — better than richly formatted running text. For the latter, an inline-aware swap that replaces phrases inside a run is the right next step.
Input is a CSV for now. Word and xlsx import are a natural next step, not part of this proof.
Terminology is a separate layer. Making the translation fit is this tool's job; making it use the approved terms is a different check. I keep that in a companion, a glossary/terminology checker, run on the copy before reflow.

None of these are blockers. They are the edges of a deliberately small proof, and knowing them up front is part of the point.

The Structural Takeaway

The layout is the source; each language is a rendering of it. Once you treat it that way — swap only the content, keep the container, and let the tool check the fit and the font at swap time — reflowing a document into another language stops being a fresh manual job and becomes a repeatable step. The translation was always the easy part. The value is in everything that has to happen after the words are ready.

How a Print PDF Should Be Built from HTML

2026-07-01T20:37:10.691Z

Recently I had a small but common production problem. A report already existed as a designed HTML page — good typography, a cover, a table of contents — and it needed to become a print-ready PDF. Not a screen capture of the web page, but a proper document: numbered pages, a table of contents whose page references are correct, and no heading left stranded at the bottom of a page.

At first glance this is just "export to PDF." But the more useful question is the same one I keep returning to in production work:

Which layer should own the page numbers and the table of contents?

The Wrong Layers

There are two tempting answers, and both create problems later.

The first is to type the numbers into the table of contents by hand. This works until the content changes. Add a paragraph near the front, and every page reference after it is quietly wrong. The numbers live in the text, but they describe the layout — so they fall out of sync the moment the layout moves.

The second is to use the browser's "Print to PDF." This renders the page faithfully, but it cannot compute that the Methods section begins on page 7, and it cannot restart numbering after the cover. It produces an image of the document, not a paginated document with cross-references.

Neither approach is wrong because of effort. They are wrong because the page numbers and the TOC references are being placed in the wrong layer.

The Source Is the HTML; the PDF Is a Rendering

The useful framing is to treat the HTML as the source and the PDF as one rendering of it. Page numbers and table-of-contents references are not content you author. They are properties of the laid-out pages, and they should be computed at layout time — the same way a screen layout computes where a line wraps.

That is exactly what the CSS Paged Media specification describes, and what Paged.js implements as a browser polyfill — paginating the document in the DOM, which a headless Chrome run then prints to PDF. So instead of editing the document, the print behavior is added as a separate layer on top of it.

The conversion then becomes four predictable steps:

Read the source HTML.
Inline local images as data URIs, so the file stays self-contained.
Overlay the print CSS — page size, margins, page numbers, live TOC.
Render to PDF with Paged.js. Body text stays selectable and fonts are embedded.

The document's own design is never touched. The overlay only adds the print semantics the screen layout had no reason to carry.

Page Numbers Belong to the Page Box

In Paged Media, a page number is not text in the document. It is content of the page box itself, so it sits in the margin and updates automatically:

@page {
  size: A4;
  margin: 18mm;
  @bottom-center { content: counter(page); }
}

/* the cover is its own page, full bleed, with no number */
.cover { page: cover; break-after: page; }
@page cover { margin: 0; @bottom-center { content: none; } }

/* the imprint is the first page that carries a number: restart the count here */
.imprint { counter-reset: page 1; }

Because the folio is a property of the page rather than the text, suppressing it on the cover and restarting the count at the imprint are small, declarative changes — not manual edits to chase on every revision.

A Table of Contents Computed at Layout Time

This is the part that surprises people. Each TOC entry is an ordinary link to an anchor in the document. The page number is filled in after the layout is known, with target-counter:

.toc a[href^="#"]::after {
  content: target-counter(attr(href), page);
}

Move a section, regenerate the PDF, and every number is correct again. The reference describes the layout, and now it is derived from the layout, so the two can no longer drift apart.

Where This Approach Has Limits

A few things are worth knowing before you rely on it:

CSS Grid does not fragment across pages. A grid block jumps whole to the next page and can leave its heading stranded. When a long section needs to flow, multi-column layout (column-count) paginates cleanly where grid does not.
Paged.js cannot resolve var() inside @page rules. Page geometry has to be written with literal values.
Headings set in a web font render correctly but may not be selectable as text. When verifying output, check the body text and a rendered page image rather than the headline.

None of these are blockers. They are just places where the print layer behaves differently from the screen, and knowing them up front saves an afternoon.

A Note on Tools

Prince XML handles this category of work very well, but it is commercial and its free tier watermarks the output. Paged.js is open source and adds no watermark, which is why I reach for it when the goal is a repeatable conversion rather than a single file. The browser's own "Print to PDF" remains fine for a quick one-off — it simply cannot compute references or restart folios.

The Script

I packaged the workflow as a small command-line tool and published it:

https://github.com/linguist-coder/html-to-print-pdf (MIT)

It takes a designed HTML file and produces the PDF, driven by a small config for page size, margins, the cover, where numbering restarts, and which links form the table of contents. The repository includes a self-contained sample report — a cover, an imprint page, a computed TOC, a table, and a figure — so the whole thing runs end to end:

git clone https://github.com/linguist-coder/html-to-print-pdf.git
cd html-to-print-pdf
npm install
npm run example     # -> examples/report/report.pdf

The takeaway is the same structural point I started with. The PDF is a rendering of the document, not the document itself. Once the page numbers and the table of contents are computed at layout time instead of typed by hand, regenerating the file after an edit stops being manual work — which is the whole point of treating the HTML, and not the PDF, as the source.

When Font Replacement Should Happen at the Definition Level in InDesign

2026-06-16T02:05:17.436Z

Replacing Helvetica with Arial inside document composite fonts

InDesign font replacement is not always a text-level task.

Recently, I had a small but practical multilingual DTP problem: a Chinese InDesign document used composite fonts, and Helvetica was assigned inside those composite font definitions. The production requirement was simple:

Replace Helvetica with Arial.

At first glance, this sounds like an ordinary font replacement task. But in InDesign, the important question is not only which font should be replaced.

The more important question is:

Which layer owns the font decision?

InDesign documents can contain font information in several places: direct text formatting, paragraph styles, character styles, and composite font definitions. If the change is made at the wrong layer, the document may look correct temporarily but become harder to maintain later.

This is why I created a small script that replaces Helvetica with Arial only inside document-level composite fonts.

Why I Usually Avoid Direct Font Replacement

In many InDesign production workflows, I do not treat font replacement as a direct text-level operation.

If a font is controlled by a paragraph style or a character style, the safer approach is usually to update the style definition itself. This keeps the document structure clean.

Directly replacing the font in the text may fix the appearance, but it can create local overrides.

That causes two practical problems.

First, if the override is cleared later, the text may return to the old font defined in the style.

Second, when new content is added, the same local override may need to be copied or recreated manually.

In other words, direct font replacement can solve the visible problem while leaving the structural problem unresolved.

For maintainable InDesign files, font changes should usually happen at the style level when the font is controlled by a paragraph style or a character style.

If the font is controlled by a paragraph style, update the paragraph style.

If the font is controlled by a character style, update the character style.

But composite fonts add another layer.

Why Composite Fonts Are Different

Composite fonts are commonly used in CJK typography workflows.

Depending on the InDesign version or language edition, composite font features may not be exposed in the same way through the user interface. In other words, some readers may not see the same composite font controls in their own InDesign environment.

In CJK workflows, a paragraph style may use a composite font. Inside that composite font, different character classes can be assigned different fonts. For example, Chinese characters may use a CJK font, while Latin letters, numbers, and symbols may use a separate Latin font.

That means the visible text may not directly tell the whole story.

The paragraph style may simply point to a composite font. The actual Latin font used inside that composite font may be Helvetica.

In that case, changing the paragraph style to Arial would not be the right interpretation of the problem.

The issue is not that the paragraph style itself should become Arial.

The issue is that Helvetica should no longer be used inside the composite font definition.

So the replacement target is not ordinary text.

It is not a paragraph style.

It is not a character style.

It is the applied font inside the document’s composite font entries.

Two Possible Approaches

There were two reasonable ways to handle this.

Approach	When it makes sense
Create a new composite font	When the old and new composite fonts need to coexist
Modify the existing composite font	When the old font should no longer be used in that composite font

The first approach is to create a new composite font and then update paragraph styles and character styles so that they use the new composite font.

This is a good approach when both composite fonts need to remain available. For example, if some pages or styles should continue using the old composite font while others should use the new one, creating a separate composite font keeps the distinction clear.

The second approach is to modify the existing composite font definition.

This is appropriate when the old font should no longer be used at all in that composite font. In this case, the style references can stay as they are. The definition they point to is updated instead.

For this case, Helvetica was no longer supposed to be used.

So I chose the second approach.

Why I Chose to Modify the Existing Composite Font

The requirement was not to create a new font design system.

It was to remove Helvetica from the existing document-level composite font setup and replace it with Arial.

Creating a new composite font would have worked, but it would also have introduced another definition into the document. Then I would need to update paragraph styles and character styles that referenced the old composite font.

That approach is useful when both definitions must coexist.

But here, the old Helvetica-based composite font was not needed anymore.

So the better choice was to update the existing composite font definition.

This kept the style structure intact. Paragraph styles and character styles could continue pointing to the same composite font. Only the internal font assignment changed.

The important decision was not Helvetica versus Arial.

It was whether the existing composite font definition should be updated or replaced with a new one.

The Script Scope: Document Composite Fonts Only

The script is intentionally narrow.

It does not try to replace every instance of Helvetica in the document.

It only scans composite fonts stored in the active document and changes Helvetica entries inside those document composite font definitions.

At the top of the script, the intended scope is documented clearly:

/*
    Replaces Helvetica with Arial in document composite fonts.

    Scope:
    - Processes only app.activeDocument.compositeFonts.
    - Does not directly modify app.compositeFonts.
    - Does not modify paragraph styles, character styles, normal text, or find/change settings.
*/

(function () {
    main();
}());

function main() {
    var doc;
    var fallbackArialFont;
    var log;
    var compositeFonts;
    var i;
    var cf;
    var shouldSkipIndexZero;
    var summaryMessage;

    if (app.documents.length === 0) {
        alert("No InDesign document is open.");
        return;
    }

    if (!confirm("This script will replace Helvetica used in composite fonts in the current document with Arial. Continue?")) {
        return;
    }

    fallbackArialFont = getArialFontByStyle("Regular");
    if (fallbackArialFont === null) {
        alert("Cannot continue because Arial is not available.");
        return;
    }

    doc = app.activeDocument;
    log = {
        compositeFontsScanned: 0,
        entriesScanned: 0,
        entriesChanged: 0,
        styleMappedEntries: 0,
        fallbackEntries: 0,
        styleSetWarnings: 0,
        errors: 0,
        lines: []
    };

    try {
        compositeFonts = doc.compositeFonts;
    } catch (e) {
        alert("Could not retrieve the document composite fonts.\r" + e);
        return;
    }

    shouldSkipIndexZero = canSkipFirstCompositeFont(compositeFonts);

    for (i = 0; i < compositeFonts.length; i++) {
        if (i === 0 && shouldSkipIndexZero) {
            log.lines.push("Skipped composite font at index 0: " + safeGetCompositeFontName(compositeFonts[0]));
            continue;
        }

        try {
            cf = compositeFonts[i];
            processCompositeFont(cf, fallbackArialFont, log);
        } catch (e2) {
            log.errors++;
            log.lines.push("[Error] Composite font index " + i + ": " + e2);
        }
    }

    summaryMessage = buildSummaryMessage(log);
    alert(summaryMessage);
}

function getArialFontByStyle(styleName) {
    var font;
    var normalizedStyle;
    var candidates;
    var i;

    normalizedStyle = normalizeArialStyleName(styleName);
    candidates = getArialFontNameCandidates(normalizedStyle);

    for (i = 0; i < candidates.length; i++) {
        font = getValidFontByName(candidates[i]);
        if (font !== null) {
            return font;
        }
    }

    return null;
}

function getArialFontNameCandidates(styleName) {
    var candidates;

    candidates = [];

    if (styleName === "Bold Italic") {
        candidates.push("Arial\tBold Italic");
        candidates.push("Arial Bold Italic");
        candidates.push("Arial-BoldItalicMT");
        candidates.push("Arial-BoldItalic");
    } else if (styleName === "Bold") {
        candidates.push("Arial\tBold");
        candidates.push("Arial Bold");
        candidates.push("Arial-BoldMT");
        candidates.push("Arial-Bold");
    } else if (styleName === "Italic") {
        candidates.push("Arial\tItalic");
        candidates.push("Arial Italic");
        candidates.push("Arial-ItalicMT");
        candidates.push("Arial-Italic");
    } else {
        candidates.push("Arial\tRegular");
        candidates.push("Arial");
        candidates.push("ArialMT");
        candidates.push("Arial-Regular");
    }

    return candidates;
}

function getValidFontByName(fontName) {
    var font;

    try {
        font = app.fonts.itemByName(fontName);
        if (font !== null && font.isValid) {
            return font;
        }
    } catch (e) {
    }

    return null;
}

function canSkipFirstCompositeFont(compositeFonts) {
    var firstName;

    if (!compositeFonts || compositeFonts.length < 1) {
        return false;
    }

    try {
        if (!compositeFonts[0].isValid) {
            return true;
        }
    } catch (e) {
        return true;
    }

    firstName = safeGetCompositeFontName(compositeFonts[0]);

    if (firstName === "") {
        return false;
    }

    if (firstName.indexOf("\u306A\u3057") >= 0 ||
        firstName.toLowerCase().indexOf("none") >= 0 ||
        firstName.toLowerCase().indexOf("no composite") >= 0) {
        return true;
    }

    return false;
}

function processCompositeFont(compositeFont, fallbackArialFont, log) {
    var entries;
    var compositeFontName;
    var i;
    var entry;

    compositeFontName = safeGetCompositeFontName(compositeFont);
    log.compositeFontsScanned++;

    try {
        entries = compositeFont.compositeFontEntries;
    } catch (e) {
        log.errors++;
        log.lines.push("[Error] Could not read entries for composite font \"" + compositeFontName + "\": " + e);
        return;
    }

    for (i = 0; i < entries.length; i++) {
        try {
            entry = entries[i];
            processCompositeFontEntry(compositeFontName, entry, fallbackArialFont, log);
        } catch (e2) {
            log.errors++;
            log.lines.push("[Error] Composite font \"" + compositeFontName + "\", entry index " + i + ": " + e2);
        }
    }
}

function processCompositeFontEntry(compositeFontName, entry, fallbackArialFont, log) {
    var entryName;
    var oldFont;
    var oldFontName;
    var rawStyle;
    var inferredStyle;
    var mappedTargetStyle;
    var arialFont;
    var fallbackUsed;
    var styleMapped;
    var newFontName;
    var newStyleName;

    log.entriesScanned++;

    entryName = safeGetEntryName(entry);

    try {
        oldFont = entry.appliedFont;
    } catch (e) {
        log.errors++;
        log.lines.push("[Error] Could not read appliedFont. Composite font: \"" + compositeFontName + "\", entry: \"" + entryName + "\": " + e);
        return;
    }

    oldFontName = getFontDisplayName(oldFont);

    if (!isHelveticaFont(oldFont)) {
        return;
    }

    rawStyle = getRawFontStyleName(oldFont, entry);
    inferredStyle = inferFontStyleName(oldFont, entry);
    mappedTargetStyle = inferredStyle;
    arialFont = getArialFontByStyle(mappedTargetStyle);
    fallbackUsed = false;

    if (arialFont === null) {
        arialFont = fallbackArialFont;
        fallbackUsed = true;
    }

    styleMapped = isMeaningfullyDifferentStyle(rawStyle, mappedTargetStyle);

    try {
        entry.appliedFont = arialFont;
    } catch (e2) {
        log.errors++;
        log.lines.push("[Error] Could not change appliedFont. Composite font: \"" + compositeFontName + "\", entry: \"" + entryName + "\", before: \"" + oldFontName + "\": " + e2);
        return;
    }

    try {
        newStyleName = getFontStyleForEntry(arialFont, mappedTargetStyle);
        if (newStyleName !== "") {
            entry.fontStyle = newStyleName;
        }
    } catch (e3) {
        log.styleSetWarnings++;
        log.lines.push("[Warning] appliedFont was changed, but fontStyle could not be set. Composite font: \"" + compositeFontName + "\", entry: \"" + entryName + "\": " + e3);
    }

    newFontName = getFontDisplayName(arialFont);
    log.entriesChanged++;
    if (styleMapped) {
        log.styleMappedEntries++;
    }
    if (fallbackUsed) {
        log.fallbackEntries++;
    }
    log.lines.push("[Changed] Composite font: \"" + compositeFontName + "\", entry: \"" + entryName + "\", inferred style: \"" + inferredStyle + "\", before: \"" + oldFontName + "\", after: \"" + newFontName + "\"" + (fallbackUsed ? " [Fell back to Arial Regular]" : ""));
    if (styleMapped) {
        log.lines.push("[Style mapped] Original style \"" + rawStyle + "\" was mapped to \"" + mappedTargetStyle + "\".");
    }
}

function isHelveticaFont(fontValue) {
    var family;
    var name;
    var fullName;
    var text;

    if (fontValue === null || fontValue === undefined) {
        return false;
    }

    if (typeof fontValue === "string") {
        return containsHelvetica(fontValue);
    }

    family = safeGetProperty(fontValue, "fontFamily");
    if (family !== "" && containsHelveticaFamily(family)) {
        return true;
    }

    name = safeGetProperty(fontValue, "name");
    if (name !== "" && containsHelvetica(name)) {
        return true;
    }

    fullName = safeGetProperty(fontValue, "fullName");
    if (fullName !== "" && containsHelvetica(fullName)) {
        return true;
    }

    text = "";
    try {
        text = String(fontValue);
    } catch (e) {
        text = "";
    }

    return containsHelvetica(text);
}

function inferFontStyleName(fontValue, entry) {
    var parts;
    var i;
    var normalized;

    parts = [];

    addIfNotEmpty(parts, safeGetProperty(fontValue, "fontStyleName"));
    addIfNotEmpty(parts, safeGetProperty(fontValue, "styleName"));
    addIfNotEmpty(parts, safeGetProperty(entry, "fontStyle"));
    addIfNotEmpty(parts, safeGetProperty(fontValue, "name"));
    addIfNotEmpty(parts, safeGetProperty(fontValue, "fullName"));

    if (typeof fontValue === "string") {
        addIfNotEmpty(parts, fontValue);
    }

    for (i = 0; i < parts.length; i++) {
        normalized = normalizeArialStyleName(parts[i]);
        if (normalized !== "Regular") {
            return normalized;
        }
    }

    return "Regular";
}

function getRawFontStyleName(fontValue, entry) {
    var style;

    style = safeGetProperty(fontValue, "fontStyleName");
    if (style !== "") {
        return style;
    }

    style = safeGetProperty(fontValue, "styleName");
    if (style !== "") {
        return style;
    }

    style = safeGetProperty(entry, "fontStyle");
    if (style !== "") {
        return style;
    }

    return "";
}

function isMeaningfullyDifferentStyle(rawStyle, mappedStyle) {
    var raw;
    var mapped;

    raw = normalizeStyleForComparison(rawStyle);
    mapped = normalizeStyleForComparison(mappedStyle);

    return raw !== "" && mapped !== "" && raw !== mapped;
}

function normalizeStyleForComparison(styleName) {
    var text;

    text = normalizeText(styleName);
    if (text === "") {
        return "";
    }

    text = removeFontFamilyWords(text);
    text = text.replace(/[^a-z0-9]+/g, "");

    // Ignore family-name residue so plain Helvetica Neue is not reported as a style mapping.
    if (text === "neue" || text === "helveticaneue" || text === "helvetica" || text === "arial") {
        return "";
    }

    if (text === "roman" || text === "plain" || text === "normal" || text === "book") {
        return "regular";
    }

    return text;
}

function normalizeArialStyleName(styleName) {
    var text;
    var compactText;
    var isBold;
    var isItalic;

    text = normalizeText(styleName);

    if (text === "") {
        return "Regular";
    }

    text = removeFontFamilyWords(text);
    compactText = text.replace(/[^a-z0-9]/g, "");

    isBold = containsStyleWord(text, "bold") ||
        compactText.indexOf("bold") >= 0 ||
        containsStyleWord(text, "black") ||
        compactText.indexOf("black") >= 0 ||
        containsStyleWord(text, "heavy") ||
        compactText.indexOf("heavy") >= 0 ||
        containsStyleWord(text, "demi") ||
        compactText.indexOf("demi") >= 0 ||
        containsStyleWord(text, "semi bold") ||
        containsStyleWord(text, "semibold") ||
        compactText.indexOf("semibold") >= 0;

    isItalic = containsStyleWord(text, "italic") ||
        compactText.indexOf("italic") >= 0 ||
        containsStyleWord(text, "oblique") ||
        compactText.indexOf("oblique") >= 0 ||
        containsStyleWord(text, "slanted") ||
        compactText.indexOf("slanted") >= 0;

    if (isBold && isItalic) {
        return "Bold Italic";
    }

    if (isBold) {
        return "Bold";
    }

    if (isItalic) {
        return "Italic";
    }

    return "Regular";
}

function removeFontFamilyWords(value) {
    var text;

    text = value;
    text = text.replace(/helvetica neue/g, " ");
    text = text.replace(/helveticaneue/g, " ");
    text = text.replace(/helvetica/g, " ");
    text = text.replace(/arial/g, " ");
    text = text.replace(/\s+/g, " ");
    text = trimString(text);

    return text;
}

function containsStyleWord(value, word) {
    var text;
    var normalizedWord;

    text = " " + value + " ";
    normalizedWord = " " + normalizeText(word) + " ";

    if (text.indexOf(normalizedWord) >= 0) {
        return true;
    }

    if (word === "semibold" && value.indexOf("semi bold") >= 0) {
        return true;
    }

    return false;
}

function getFontStyleForEntry(fontValue, inferredStyle) {
    var style;

    style = safeGetProperty(fontValue, "fontStyleName");
    if (style !== "") {
        return style;
    }

    style = safeGetProperty(fontValue, "styleName");
    if (style !== "") {
        return style;
    }

    return inferredStyle;
}

function addIfNotEmpty(list, value) {
    if (value !== null && value !== undefined && String(value) !== "") {
        list.push(String(value));
    }
}

function containsHelveticaFamily(value) {
    var text;

    text = normalizeText(value);
    if (text === "") {
        return false;
    }

    return text === "helvetica" || text.indexOf("helvetica") === 0;
}

function containsHelvetica(value) {
    var text;

    text = normalizeText(value);
    if (text === "") {
        return false;
    }

    return /(^|[^a-z0-9])helvetica($|[^a-z0-9]|neue)/.test(text);
}

function normalizeText(value) {
    var text;

    if (value === null || value === undefined) {
        return "";
    }

    try {
        text = String(value);
    } catch (e) {
        return "";
    }

    text = text.toLowerCase();
    text = text.replace(/\r/g, " ");
    text = text.replace(/\n/g, " ");
    text = text.replace(/\t/g, " ");
    text = text.replace(/_/g, " ");
    text = text.replace(/\s+/g, " ");
    text = trimString(text);

    return text;
}

function getFontDisplayName(fontValue) {
    var family;
    var style;
    var fullName;
    var name;
    var result;

    if (fontValue === null || fontValue === undefined) {
        return "(None)";
    }

    if (typeof fontValue === "string") {
        return fontValue;
    }

    family = safeGetProperty(fontValue, "fontFamily");
    style = safeGetProperty(fontValue, "fontStyleName");
    fullName = safeGetProperty(fontValue, "fullName");
    name = safeGetProperty(fontValue, "name");

    if (family !== "") {
        result = family;
        if (style !== "") {
            result += "\t" + style;
        }
        return result;
    }

    if (fullName !== "") {
        return fullName;
    }

    if (name !== "") {
        return name;
    }

    try {
        return String(fontValue);
    } catch (e) {
        return "(Unknown font)";
    }
}

function safeGetCompositeFontName(compositeFont) {
    var name;

    name = safeGetProperty(compositeFont, "name");
    if (name !== "") {
        return name;
    }

    return "(Unnamed composite font)";
}

function safeGetEntryName(entry) {
    var name;
    var characterRange;

    name = safeGetProperty(entry, "name");
    if (name !== "") {
        return name;
    }

    characterRange = safeGetProperty(entry, "characterRange");
    if (characterRange !== "") {
        return characterRange;
    }

    return "(Unnamed entry)";
}

function safeGetProperty(obj, propertyName) {
    var value;

    if (obj === null || obj === undefined) {
        return "";
    }

    try {
        value = obj[propertyName];
        if (value === null || value === undefined) {
            return "";
        }
        return String(value);
    } catch (e) {
        return "";
    }
}

function trimString(value) {
    return value.replace(/^\s+/, "").replace(/\s+$/, "");
}

function buildSummaryMessage(log) {
    var message;
    var maxLines;
    var i;

    message = "Finished replacing Helvetica with Arial in composite fonts.\r\r";
    message += "Composite fonts scanned: " + log.compositeFontsScanned + "\r";
    message += "Composite font entries scanned: " + log.entriesScanned + "\r";
    message += "Entries changed: " + log.entriesChanged + "\r";
    message += "Style-mapped entries: " + log.styleMappedEntries + "\r";
    message += "Fallback entries: " + log.fallbackEntries + "\r";
    message += "Style set warnings: " + log.styleSetWarnings + "\r";
    message += "Errors: " + log.errors;

    if (log.lines.length > 0) {
        message += "\r\rLog:";
        maxLines = 20;
        for (i = 0; i < log.lines.length && i < maxLines; i++) {
            message += "\r" + log.lines[i];
        }
        if (log.lines.length > maxLines) {
            message += "\r... " + (log.lines.length - maxLines) + " more log entries.";
        }
    }

    return message;
}

This is the core design principle of the script.

The script is not a general font replacement tool.

It is a targeted cleanup script for a specific composite font problem.

Limitations

This script is intentionally limited.

It does not modify ordinary text formatting.

It does not modify paragraph styles.

It does not modify character styles.

It does not create a new composite font.

It does not directly modify application-level composite fonts.

It does not check fonts embedded in exported PDFs.

It does not manage a full font policy for a project.

For this specific workflow, the goal was not to build a general font management system. The goal was to correct one document-level composite font rule safely and repeatably.

What the Script Does

The script follows a simple process:

Check whether an InDesign document is open.
Ask for confirmation before making changes.
Check whether Arial Regular is available.
Get the composite fonts from the active document.
Scan each composite font entry.
Detect Helvetica or Helvetica Neue.
Infer the font style, such as Regular, Bold, Italic, or Bold Italic.
Replace the Helvetica entry with the matching Arial font when available.
Fall back to Arial Regular if a matching Arial style cannot be found.
Show a summary that separates changed entries, style mappings, fallback replacements, style-setting warnings, and errors.

This is a small script, but the logic reflects a production rule:

Only replace Helvetica when it appears inside document composite font entries.

The summary separates several types of results:

Summary item	Meaning
Composite fonts scanned	Number of document composite fonts checked
Composite font entries scanned	Number of composite font entries checked
Entries changed	Number of entries where Helvetica was replaced
Style-mapped entries	Number of entries where the original style was mapped to a simpler Arial style
Fallback entries	Number of entries where a matching Arial style was not found and Arial Regular was used
Style set warnings	Number of entries where the font was changed but the font style setting could not be applied
Errors	Number of entries or composite fonts that could not be processed

The distinction between style mapping and fallback is important.

For example, Helvetica Neue Medium may be mapped to Arial Regular. In that case, the script records a style mapping so that the change is visible in the log.

Fallback is different. It means the script tried to find a matching Arial style, but could not find one, so it used Arial Regular instead.

This makes the result easier to review after execution.

Key Code Points

The script starts by getting the composite fonts from the active document:

compositeFonts = doc.compositeFonts;

This is the key scope decision.

The script is not scanning all text in the document. It is not searching paragraph styles. It is not searching character styles.

It is targeting document composite font definitions.

Then it reads the entries inside each composite font:

entries = compositeFont.compositeFontEntries;

Each entry may have an applied font. The script reads that font:

oldFont = entry.appliedFont;

Then it checks whether the font is Helvetica:

if (!isHelveticaFont(oldFont)) {

return;

}

This prevents the script from touching unrelated fonts.

If the entry uses Helvetica, the script selects an Arial font and applies it to the composite font entry:

entry.appliedFont = arialFont;

This is the actual replacement.

Again, the target is not the text itself.

The target is the font assigned inside the composite font definition.

That distinction is the main point of the script.

Demo: Updating the Composite Font Definition

For the demo, I created a fictional Chinese InDesign document.

The demo file contains sample Chinese text mixed with Latin letters and numbers. The paragraph style uses a composite font. Inside that composite font, the Latin entry uses Helvetica.

Before running the script, the composite font definition contains Helvetica.

After running the script, the same composite font definition uses Arial.

The paragraph style still points to the same composite font.

The normal text structure remains unchanged.

The script also shows a summary dialog after execution. This makes it possible to confirm not only how many entries were changed, but also whether any style mappings, fallback replacements, style-setting warnings, or errors occurred.

This is the behavior I wanted.

The script does not create a new document structure. It updates the existing composite font definition.

Conclusion

The lesson from this script is not that every font replacement needs automation.

The lesson is that font replacement should happen at the layer that owns the font decision.

If the font is controlled by a paragraph style, update the paragraph style.

If it is controlled by a character style, update the character style.

If it is controlled inside a composite font, update the composite font definition.

In multilingual DTP, this distinction matters.

A script should not simply change as much as possible. A good script should change only the layer it is supposed to change.

For this case, Helvetica did not need to be replaced everywhere.

It needed to be replaced inside document composite font definitions.

That is why a small, targeted script was the right solution.

A Rule-First Approach to AI-Assisted Terminology QA

2026-05-11T21:33:00.000Z

Terminology errors are rarely dramatic.

They usually appear as small inconsistencies: one deprecated term, one preferred phrase that was missed, one verbose expression that should have been simplified, or one word that does not match the approved glossary.

In technical documentation, these small issues matter. They affect consistency, readability, translation quality, and sometimes even product safety.

The problem is that terminology checks are repetitive. They are also easy to miss when reviewing long documents manually.

That makes terminology QA a good candidate for automation.

But there is an important design question:

Should AI be the first checker?

My answer is: usually, no.

For production-oriented QA, terminology checking should start with explicit rules. AI should be used as a second-pass confirmation layer, not as the primary source of detection.

This is the design idea behind a small terminology checker I recently built and published on GitHub. The repository is available here: Terminology Checker.

The Problem with Manual Terminology Checks

A terminology rule often looks simple.

For example:

Use “use” instead of “utilize”
Use “before” instead of “prior to”
Use “because” instead of “due to the fact that”
Avoid inconsistent product names
Avoid deprecated technical terms

In theory, these rules are easy to check.

In practice, they become difficult for several reasons.

First, documents are long. Even if a reviewer knows the correct terminology, checking every occurrence manually is slow and unreliable.

Second, terminology rules are often scattered. Some rules live in a glossary, some in a style guide, some in a client-specific instruction file, and some only exist as reviewer experience.

Third, final deliverables are not always checked in the same environment where translation was performed. A document may pass QA in a CAT tool, but still need to be checked again after layout, PDF generation, or DOCX formatting.

This is especially common in multilingual production workflows.

A CAT tool can check the translation environment.
But the final PDF or DOCX is what the client actually receives.

That gap is where lightweight QA tools can help.

Why AI Should Not Be the First Checker

It is tempting to ask AI a simple question:

“Please check this document for terminology errors.”

For a short document, this may work well enough.

For production QA, however, this approach has several weaknesses.

Lack of repeatability
The same input may not always produce the same output. This makes it difficult to use AI-only checking as a stable QA process.
Unclear rule traceability
It may be hard to tell which glossary entry, style rule, or client instruction caused a finding.
Over-detection and under-detection
AI may over-interpret harmless phrases, while also missing simple rule violations that a deterministic search would catch.
Difficult review history
If the finding is not tied to an explicit rule, it becomes harder to review, compare, or improve the result later.
Unclear cost and scope
Sending entire documents to AI for open-ended checking can be inefficient, especially when many issues can be detected by simple rules.

This matters because QA needs repeatability.

A terminology checker should answer basic questions clearly:

Which rule was checked?
Which term was found?
Where was it found?
What is the suggested replacement?
Was the finding confirmed or rejected?
Can the result be reviewed later?

If AI is used as the first checker, these questions become harder to control.

For this reason, I prefer a rule-first approach.

The rules should find candidates first.
AI can then help confirm whether each candidate is actually a problem in context.

A Two-Pass Approach

The terminology checker uses a simple two-pass structure.

Document
  ↓
Rule-based candidate detection
  ↓
AI-based confirmation
  ↓
CSV report

The first pass is rule-based.

The tool reads a glossary file and searches the document for defined terms or phrases. This step is deterministic. If the same document and the same glossary are used, the same candidates should be detected.

The second pass is AI-assisted.

After the rule-based pass finds candidates, AI can review the surrounding context and help reduce false positives.

This separation is important.

The rule layer provides repeatability.
The AI layer provides context sensitivity.
The report layer keeps the result reviewable.

That combination is more practical than relying on AI alone.

A Simple Example

Suppose a glossary contains this rule:

wrong_term,correct_term,notes
utilize,use,Use plain English where possible

A rule-based checker can easily find every occurrence of “utilize.”

But not every occurrence has the same priority.

For example:

We will utilize this tool to check the document.

In this case, the preferred wording is probably:

We will use this tool to check the document.

The rule-based layer can detect the candidate.
The AI confirmation layer can then check the surrounding sentence and confirm that this is likely a real style issue.

Now consider a different case:

The report discusses asset utilization in manufacturing environments.

A simple search may still detect a related term pattern, depending on the glossary rule. But the surrounding context may show that this is part of a technical expression, not a simple “utilize → use” replacement.

This is where AI can be useful.

Not as a magic checker.
Not as the source of truth.
But as a context filter.

The goal is to reduce the number of items that a human reviewer needs to inspect manually.

What This Terminology Checker Does

The tool is a small web app and command-line utility for terminology QA.

It can check:

PDF files
DOCX files
TXT files

It uses a CSV glossary with entries such as:

wrong_term,correct_term,notes
utilize,use,Use plain English
prior to,before,Simplify the phrase
due to the fact that,because,Avoid verbose expressions

The tool extracts text from the document, checks it against the glossary, and generates a CSV report.

The report can then be reviewed by a human.

This is intentional. The tool does not automatically rewrite the document. It focuses on detection, confirmation, and reporting.

In QA workflows, that distinction matters.

Automatic fixing may be useful in some controlled cases, but terminology QA often requires human judgment. The goal is not to remove the reviewer. The goal is to reduce repetitive checking and make possible issues easier to review.

Web UI and CLI

The tool includes a simple web interface built with Gradio.

The web UI is useful when the goal is quick checking:

Upload a document
Upload a glossary CSV
Run the check
Download the result report

The tool also supports command-line execution.

This is useful if the checker is later integrated into a more structured workflow, such as:

project-level QA folders
repeated checks for the same client
batch processing
automated report generation
local production pipelines

The web UI makes the tool easier to try.
The CLI makes it easier to extend.

Why This Matters in Multilingual Production

Terminology QA is not only a translation issue.

It is also a production issue.

In a multilingual workflow, text may move through several stages:

Source document
  ↓
Translation
  ↓
CAT tool QA
  ↓
Layout / DTP
  ↓
PDF or DOCX output
  ↓
Final review

A terminology issue can appear, disappear, or become harder to detect at different stages.

For example, a term may be correct in the CAT tool but become difficult to verify after layout. A PDF may introduce line breaks or extraction noise. A final DOCX may contain manually edited text that was not checked in the translation environment.

This is why final-document QA matters.

The terminology checker is not meant to replace CAT-tool QA.
It is a final-document QA layer.

It is designed to help check deliverable formats such as PDF, DOCX, and plain text against explicit terminology rules.

That makes it useful as a bridge between translation QA and final production QA.

Rule-Based Detection Is Still Valuable

AI is powerful, but rule-based detection is still extremely useful.

A rule is clear.
A rule is reviewable.
A rule can be versioned.
A rule can be reused across projects.

For example, if a client says that “utilize” should be replaced with “use,” that rule does not need creative interpretation. It should simply be checked.

In such cases, using AI as the first detection layer adds unnecessary uncertainty.

A better design is:

Explicit rule:
“utilize” → “use”

Detection:
Find occurrences of “utilize”

AI confirmation:
Check whether this occurrence is actually a problem in context

Human review:
Accept, reject, or revise

This keeps the workflow understandable.

It also makes the QA result easier to explain to another reviewer, translator, client, or production manager.

AI as a Smart Filter

AI becomes more useful when its role is limited.

Instead of asking AI to invent the checklist, the tool gives AI a narrower task:

This term was found by a rule.
Based on the surrounding context, does it look like a real terminology issue?

This is a better use of AI in QA.

The AI is not replacing the glossary.
It is not replacing the reviewer.
It is not deciding the entire QA policy.

It is only helping with context confirmation.

In other words, AI works best here as a smart filter.

The rule-based layer finds possible issues.
The AI layer helps prioritize them.
The human reviewer makes the final decision.

This role separation makes the workflow easier to trust.

Current Limitations

This is still a small MVP.

There are several limitations.

First, PDF text extraction is not always perfect. If the PDF contains complex layouts, unusual encoding, scanned pages, or broken text order, the extracted text may not reflect the visible page accurately.

Second, AI confirmation requires an external API. This means confidential documents should not be checked with AI confirmation unless the workflow allows it.

For sensitive documents, the rule-based mode is safer because it can be used without sending document text to an external AI service.

Third, the tool does not automatically apply corrections. This is by design. At this stage, the output is a report, not a rewritten document.

Fourth, glossary management is still simple. The current CSV format is easy to understand, but larger workflows may need Excel support, rule categories, severity levels, client profiles, and version control.

These limitations are useful because they clarify the next design step.

Future Direction

The interesting part of this tool is not the web UI itself.

The important part is the structure:

Rules
  ↓
Detection
  ↓
Context confirmation
  ↓
Reviewable report

This structure can become a reusable QA module.

Possible future improvements include:

Excel glossary support
batch checking for multiple files
project-specific rule profiles
severity levels
false-positive feedback
highlighted PDF output
DOCX comments
QA history logs
local AI model support
integration with other multilingual DTP checks

The long-term goal is not just to build another checker.

The goal is to make terminology QA more structured, repeatable, and easier to connect with other parts of multilingual production.

A terminology checker can become one module in a larger local QA workflow.

For example:

Terminology check
  +
PDF text check
  +
layout issue detection
  +
overset / missing link checks
  +
QA logs
  =
local multilingual production QA layer

That is the direction I am interested in.

Not just one-off automation, but reusable workflow components.

Conclusion

Terminology QA should not depend only on human memory.
It should also not depend entirely on AI judgment.

A more practical approach is to start with explicit rules, detect candidates consistently, then use AI only where context matters.

That is the idea behind this terminology checker.

Rules provide structure.
AI provides context support.
Reports keep the process reviewable.

For multilingual technical documentation, this balance is important.

The goal is not to automate judgment away.
The goal is to make judgment easier to apply consistently.

GitHub:
https://github.com/linguist-coder/terminology-checker

Why TOC Is Hard to Automate in InDesign

2026-04-17T21:36:00.000Z

InDesign can generate and update a table of contents.

But once you try to build automation around it, things get much less straightforward.

The problem is not TOC generation itself. The problem is reliable identification.

From the scripting side, a TOC often looks like an ordinary text frame. It sits on a page like any other block of text, and at first glance it seems like something you should be able to detect, inspect, and process like normal content.

In practice, that assumption breaks down quickly.

What makes TOC difficult to automate is not that it is impossible to create. InDesign exposes TOC creation through its scripting model. The real issue is that the document model does not give you a practical, explicit frame-level way to say, “This text frame is a TOC.” The UI clearly knows how to update it. The scripting side does not give you the same kind of certainty.

That gap matters more than it may seem.

A TOC looks like normal text, but it does not behave like normal text

Visually, a TOC is just text.

But functionally, it is closer to a generated structure than to hand-authored text. The fact that InDesign can update it already tells us that something more than visible text is involved. There is some internal relationship between the TOC and the document’s heading structure, TOC style, and regeneration logic.

The problem for automation is simple: whatever InDesign uses internally, it is not exposed in a way that makes frame-level detection reliable from the scripting side.

This is where many automation attempts go wrong. What looks simple in the UI is not always simple in the DOM.

There is no simple “is this TOC?” property

This is the practical limitation.

You can create a TOC. You can define TOC styles. But when you scan document stories or text frames, there is no clean, obvious, automation-safe property that tells you, “Yes, this is the TOC frame.”

That means any script that tries to detect TOC by inspection is already operating on weak ground.

You can guess. You can infer. You can build heuristics. But you cannot depend on a robust and explicit TOC flag in the way many automation workflows would ideally require. Even in the UXP era, this remains fundamentally a document-model problem, not just a scripting-engine problem. Adobe clearly supports UXP scripting and provides migration guidance from older platforms, but that does not automatically mean every internal document structure is fully exposed for reliable detection.

And in production, weak detection logic quickly turns into unstable automation.

Why this matters in real production

This is not just a technical inconvenience.

In multilingual DTP workflows, TOC is often one of the most fragile parts of a document. After translation, headings get longer, line breaks change, page flow shifts, and the TOC often needs to be updated. That is already a sensitive moment in the layout process.

Now add automation to that situation.

If your script cannot safely identify which frame is the actual TOC, then every downstream action becomes risky. You may update the wrong content. You may miss the TOC entirely. You may trigger layout changes in a place you did not intend to touch.

And once a TOC expands or reflows, the effect is rarely isolated. In multilingual documents, one TOC change can push text onto the next page, create overset, shift anchored objects, or break carefully balanced page structures.

In other words, TOC is not just a generated list. In production, it is a layout-sensitive object.

That is why the real question is not “Can InDesign update a TOC?”
The real question is “Can this be handled safely inside an automated workflow?”

Why detection-based automation is fragile

A common instinct is to solve this with smarter detection.

For example, a script might assume that a TOC frame:

uses a specific paragraph style
appears near the beginning of the document
contains a predictable title such as “Contents”
sits on a dedicated page
includes page numbers in a recognizable pattern

Sometimes this works.

The problem is that it often works only by chance.

And “it works by chance” is one of the most dangerous states in production automation. It creates false confidence. A script appears successful in one template, one language, or one document family, then quietly fails when a different template, language, or editorial variation is introduced.

This is especially risky in multilingual workflows, where layout conventions, naming, language length, and TOC formatting can vary across editions.

If identification is ambiguous, automation becomes a reliability problem.

That is the real turning point: some problems should not be solved by increasingly clever detection logic. They should be solved by document design.

A better approach: design for identification

The safer approach is not to guess what the TOC is.

The safer approach is to make the TOC identifiable by design.

That means embedding reliable structure into the document so automation does not depend on interpretation. Instead of asking a script to infer whether a frame is a TOC, make that information explicit in the file structure.

Depending on your workflow, that can mean using:

a dedicated paragraph style
a dedicated object style
a dedicated layer
fixed placement rules
a script label attached to the relevant page item

This last option is especially practical. In InDesign’s object model, page items support labels and key-value style metadata methods such as insertLabel() and extractLabel(), which makes them useful as lightweight automation identifiers. In real workflows, that is often far more reliable than guessing from layout or text content.

The safest automation is often not smarter detection, but better document structure.

Once you adopt that mindset, the whole problem changes. You are no longer trying to reverse-engineer the file. You are designing the file so automation can work safely from the beginning.

In some cases, regeneration is safer than update

There is another practical shift that follows from this.

If detection is weak, regeneration may be safer than update.

Instead of trying to find an existing TOC frame and update it in place, you may get a more stable workflow by treating TOC as a controlled output:

identify the target area through explicit document structure
remove the old TOC under known conditions
regenerate the TOC from the correct TOC style
place it back into a known layout context

This has an important advantage beyond stability.

Regeneration does not just rebuild content. It also lets you reapply the correct TOC style every time. That matters in real production, because hand-adjusted formatting often accumulates over time. If someone manually tweaks the TOC, an “update” workflow may preserve unwanted leftovers. A regeneration workflow gives you a cleaner reset to the intended structure.

Of course, this only works well when the surrounding rules are controlled. If placement, style usage, and layout boundaries are undefined, regeneration can be just as risky. But in a template-driven workflow, regeneration is often the more predictable strategy.

Not because it is more sophisticated.

Because it is more controllable.

What this means for automation design

This is not really a TOC-only lesson.

It is a broader InDesign automation lesson.

Some parts of a document are easy to automate because the DOM exposes them clearly. Some are hard not because they are conceptually complex, but because the information you need is not exposed in a reliable way.

When that happens, there are two possible responses.

One is to keep adding more detection logic, more exceptions, and more edge-case handling.

The other is to redesign the workflow so identification becomes explicit.

The second path is usually better.

If your automation depends on fragile guessing, the real fix is often not better code. It is better structure. Better naming. Better labels. Better layout rules. Better production discipline.

That is the real shift from detection to design.

And once you make that shift, your scripts usually become simpler, safer, and easier to maintain.

Conclusion

TOC is one of those classic InDesign cases where the UI makes something look simpler than it is.

Yes, InDesign can update a TOC.

But from the scripting side, reliably identifying a TOC as a specific frame or story is much harder than many people expect. That is why TOC automation often becomes brittle when it is built on inference.

The practical solution is not to write increasingly clever code that tries to guess what the file means.

The practical solution is to make the file readable to automation in the first place.

When the DOM is a black box, document structure has to become your map.
Stop guessing in code. Start designing for automation.

Scaling Multilingual DTP by Detecting Objects Outside the Layout (Low Judgment Workflows)

2026-04-10T22:48:00.000Z

Where this fits in the series

This article completes the automation prioritization framework.

In this series, we looked at three key dimensions:

What should you automate first
High frequency tasks
High instability workflows

And now, the final piece:

Low Judgment workflows

This is where automation becomes both safe and scalable.

The problem: invisible objects that still exist

In multilingual DTP, not all problems are visible.

Objects outside the layout area are a typical example.

They don’t appear in the final output
They don’t trigger obvious warnings
But they still exist in the document structure

And because of that, they quietly introduce risk.

Why this is a Low Judgment problem

Low Judgment tasks are the safest place to start automation.

This type of issue has three characteristics:

detection is objective
action is predictable
decision complexity is low

For objects outside the layout:

“Is it outside?” → Yes / No
“Should it exist?” → Almost always No

This is exactly what defines a Low Judgment workflow.

Why “invisible” does not mean “harmless”

Hidden objects are not harmless — they introduce ambiguity into the document.

Because these objects are not visible in the layout, they are often ignored.

However, in real workflows, they can cause problems across multiple layers:

CAT tools (e.g., Trados) may count them as translation content
→ increasing workload and cost unexpectedly
Packaging workflows may exclude them
→ causing missing link errors when files are handed off
Scripts and automation may pick them up as valid objects
→ introducing noise and reducing reliability
Handover between operators becomes less predictable
→ it is no longer clear which objects are intentional and which are not

Even though each issue is small,
they all come from the same root problem:

→ the document contains objects that should not exist

Why manual handling fails

Even if the decision is simple,
manual handling is not.

you don’t know where to look
you don’t know how many exist
you don’t notice them consistently

So the result is:

→ ignored problems accumulate

This is typical of Low Judgment work:

easy to decide
but easy to overlook

A minimal approach: detect → count → confirm

Low Judgment does not mean “fully automatic.”

The correct first step is:

detect
quantify
confirm

This keeps control while removing friction.

Sample script (InDesign JSX)

Want the ready-to-use version?

Skip the copy-paste and download the script directly from Gumroad.

Download on Gumroad (Free) →

#target indesign

(function () {
    function isTopLevelPasteboardItem(item) {
        if (!item || !item.isValid) {
            return false;
        }

        if (item.parentPage !== null) {
            return false;
        }

        try {
            var parent = item.parent;

            // Avoid double-counting children inside groups or other containers.
            if (parent && parent.hasOwnProperty("parentPage")) {
                return false;
            }
        } catch (e) {}

        return true;
    }

    if (app.documents.length === 0) {
        alert("No documents are open.");
        return;
    }

    var doc = app.activeDocument;
    var pasteboardItems = [];

    var items = doc.allPageItems;

    for (var i = 0; i < items.length; i++) {
        try {
            if (isTopLevelPasteboardItem(items[i])) {
                pasteboardItems.push(items[i]);
            }
        } catch (e) {}
    }

    var count = pasteboardItems.length;

    if (count === 0) {
        alert("No pasteboard objects were found.");
        return;
    }

    var confirmDelete = confirm(
        "Found " + count + " pasteboard object(s).\n\nDelete them?"
    );

    if (!confirmDelete) return;

    var deletedCount = 0;
    var failedCount = 0;

    for (var j = pasteboardItems.length - 1; j >= 0; j--) {
        try {
            if (pasteboardItems[j].isValid) {
                pasteboardItems[j].remove();
                deletedCount++;
            }
        } catch (e) {
            failedCount++;
        }
    }

    if (failedCount > 0) {
        alert(
            "Deleted " + deletedCount + " object(s).\n" +
            "Failed to delete " + failedCount + " object(s)."
        );
        return;
    }

    alert("Deleted " + deletedCount + " object(s).");
})();

Why this works

Low Judgment workflows benefit from controlled automation.

This script does not try to be smart.

It simply:

detects
counts
asks

This aligns with a key principle:

reveal first
automate later

From Low Judgment to system design

This is not just a cleanup script.

It represents a reusable pattern:

invisible → visible
unknown → measurable
implicit → explicit

This same structure applies to:

overset text
missing links
style inconsistencies

Why this matters for scaling

Low Judgment workflows are where automation scales cleanly.

Because:

decisions are consistent
edge cases are limited
behavior is predictable

This makes them ideal for:

standardization
reuse
system integration

Final takeaway

Start automation where judgment is low.

Not because it is easy,
but because it is stable.

High frequency → impact
High instability → necessity
Low Judgment → safety

And when all three align,
you get automation that actually scales.

High Instability in Multilingual DTP

2026-03-28T22:25:00.000Z

Introduction

In multilingual DTP, some problems are not difficult — but they are dangerous.

Imagine this:

You have just finished updating a document in 20 languages.
All corrections are complete. All verification checks are done.
The project is ready for delivery.

Then a request comes in:

“This one line is no longer needed. Please remove it.”

For the client, this is a small change.

For you, it is not.

If the layout relies on reflow, a single line change can break the entire layout
Every page in the document may need to be reviewed
And this must be repeated across all languages

This is not an edge case.

It is a structural property of document production.

What Is “Instability” in Multilingual DTP?

Small changes can produce disproportionate layout shifts.

Instability in multilingual DTP means that:

a small input change
produces a large and often unpredictable output change

A single line can trigger:

text reflow
frame resizing
page shifts
cascading layout changes

And this effect becomes stronger in multilingual production, where:

text expansion varies by language
line breaks behave differently
layout density changes across versions

Why Does This Happen?

Layouts are not static — they are interconnected systems.

InDesign layouts are not isolated elements.

They are connected through:

text flow
frame relationships
page composition

A small change in one place can propagate through the system.

In multilingual workflows, this instability is amplified:

different languages expand differently
text breaks at different points
layout balance shifts unpredictably

This is why even minor edits can require large-scale rechecking.

How Do You Deal With It?

Instability cannot be eliminated — only managed.

There is no single solution.

Instead, there are several strategies, each with trade-offs.

1. Make the Layout Static

The most straightforward approach is to remove flexibility.

prevent automatic frame expansion

ensure each text frame is self-contained*
* You can split text frames using the sample script (Scripts panel > Application > Samples > Split Story) provided with InDesign.

This limits the impact of changes:

a line change stays within one frame
layout shifts are localized

However:

flexibility is reduced
larger edits become harder to handle
layout adjustments can become time-consuming

This approach is robust, but not efficient for everyday production.

It is also not always possible — for example, when working with files exported from a CCMS.

2. Introduce Flow Boundaries

Another approach is to limit how far changes can propagate.

This can be done by:

splitting documents at logical sections
inserting controlled page breaks (Type > Insert Break Character)
leaving buffer space in layouts

This helps contain instability:

the affected area becomes smaller
rechecking scope is reduced

However:

too many splits increase management overhead
page breaks only reduce impact — they do not eliminate it
larger edits can still break layout beyond the boundary

This is a mitigation strategy, not a solution.

3. Design for Controlled Behavior

A more structural approach is to design layouts that behave more predictably.

This is done using paragraph style settings such as:

Keep Options (Paragraph Styles panel > Keep Opetions > Keep Opetions > Keep with Previous, Keep Lines Together)
Start Paragraph (e.g., On Next Page)

For example:

forcing major headings to start on a new page
keeping headings and their lead text together

These settings reduce undesirable layout behavior.

However:

setup requires time and experience
optimal settings vary depending on layout design
there is no universal best configuration

Despite this, it is often the most balanced approach:

flexible enough for real workflows
stable enough to reduce cascading issues

If you want to reduce the impact of layout instability, one practical approach is to design your paragraph styles carefully and reapply them consistently across languages.

I’ve written about this approach here:
[Scaling Multilingual DTP by Automating Style Reloads Before Translation]

What These Strategies Have in Common

None of these eliminate instability.

They only change how you manage it.

Static layouts reduce flexibility
Flow boundaries limit propagation
Design-based approaches shape behavior

But the underlying instability remains.

Conclusion

Instability is not a bug — it is a property of the system.

In multilingual DTP:

layouts are interconnected
languages behave differently
small changes can cascade

This means instability cannot be avoided.

It must be anticipated and managed.

In the previous article, we discussed High Frequency — tasks that repeat.

In this article, we looked at High Instability — tasks where small changes produce large effects.

In the next article, we will explore the third factor:

Low Judgment — where automation becomes possible.

High Frequency Tasks Worth Automating in Multilingual DTP

2026-03-17T00:44:00.000Z

Introduction

In multilingual DTP, the difficulty of a task is often less important than how often it appears.

Layout adjustments, date updates, missing links, small formatting fixes — none of these tasks are particularly complex. But when they repeat across languages and revisions, they quickly become a significant source of manual work.

This is why the first automation target is rarely the most technically impressive task.
It is usually the task that happens the most often.

In the previous article, I introduced a simple framework for identifying good automation candidates.

In this article, we will look at the first of those criteria: High Frequency.

Recap: The Automation Framework

This framework helps identify which tasks are actually worth automating.

In the previous article, I introduced three criteria that make a task a strong automation candidate:

High Frequency – the task occurs repeatedly
High Instability – the conditions change each time
Low Judgment – the handling rules are predictable

The strongest automation opportunities appear where these forces overlap.

In this article, we focus on the first one: High Frequency.

What “High Frequency” Really Means

High-frequency friction scales across languages and production cycles.

High Frequency does not simply mean that a task happens often.

In multilingual production, repetition multiplies across several dimensions:

number of languages
number of documents
number of revisions

For example:

1 issue
× 10 languages
× 3 revisions
= 30 manual fixes

A small issue in a single layout can quickly become dozens of repeated corrections across a project.

This multiplication effect is why High Frequency tasks are often the best starting point for automation.

A Real Example: Missing Links

A small asset problem can propagate across every translated layout.

Many multilingual workflows begin with an English source layout — the base document from which translated layouts are produced.

Translated versions are then created from that structure:

English source layout
↓
Translated layouts
(JA / DE / FR / IT / ES ...)

This structure works well — until the asset structure changes.

For example, the English asset folder may be:

renamed
moved to a different directory
reorganized during a project update

When that happens, translated documents can suddenly lose their links.

Why This Becomes a High-Frequency Problem

One missing link can multiply across every language version.

In multilingual production, the same layout may exist in many language versions.

A single missing asset can therefore propagate across multiple documents.

1 broken asset
↓
10 translated layouts
↓
10 missing links

What looks like a minor issue in one file quickly becomes repeated friction across the entire production set.

This is exactly the kind of situation where automation becomes valuable.

The Limitation of Preflight Detection

Preflight detects missing links, but it does not remove the manual tracing step.

InDesign’s Preflight feature can detect missing links reliably.

However, it does not immediately provide the information operators often need most:
the expected file path of the missing asset.

To resolve the issue, the operator typically has to:

open the Links panel
inspect the link information
identify the original file location
attempt to relink manually

This extra tracing step becomes repetitive when the same issue appears across multiple layouts.

The Packaging Alternative

Packaging avoids missing links but introduces asset maintenance overhead.

Another common workaround is to package the document.

Packaging gathers all linked assets into a single folder together with the document.

This can prevent missing link problems, but it also introduces new complications:

assets are duplicated
shared resources become harder to update
folder structures grow more complex

In multilingual projects, this becomes particularly problematic when shared assets change.

If a common asset — such as a logo or illustration — is updated, every packaged language folder may need to be updated manually.

In other words, the problem shifts from link detection to asset maintenance.

A Minimal Script: Missing Link Reporter

This removes the repeated step of manually tracing where a file should be.

The goal here is not to automatically repair links.

Instead, the goal is to remove one repeated manual step:
identifying where the missing file was expected to be located.

A small helper script can scan the document and generate a simple report of missing links.

Script Example

Want the ready-to-use version?

Skip the copy-paste and download the script directly from Gumroad.

Download on Gumroad (Free) →

#target indesign

if (app.documents.length === 0) {
    alert("Open a document first.");
    exit();
}

var doc = app.activeDocument;
var links = doc.links;
var report = "";
var missingCount = 0;

// Header
report += "Missing Links Report\r";
report += "Document: " + (doc.name || "Untitled") + "\r";
report += "Generated: " + new Date().toString() + "\r";
report += "----------------------------------------\r\r";

// Scan links
for (var i = 0; i < links.length; i++) {
    var link = links[i];

    if (link.status === LinkStatus.LINK_MISSING) {
        missingCount++;
        report += "Link name: " + (link.name || "(no name)") + "\r";
        report += "Expected path:\r";
        report += (link.filePath != null ? link.filePath : "(unknown)") + "\r";
        report += "----------------------------------------\r\r";
    }
}

if (missingCount === 0) {
    alert("No missing links found.");
    exit();
}

// Save report: use document folder only if document has been saved
var reportFile;
var docPath = doc.filePath;

if (docPath && docPath !== "") {
    var docFolder = new Folder(docPath);
    reportFile = new File(docFolder.fsName + "/Missing_Links_Report.txt");
} else {
    reportFile = File.saveDialog("Save Missing Links Report As", "Missing_Links_Report.txt");
    if (reportFile === null) {
        alert("Save cancelled.");
        exit();
    }
}

reportFile.encoding = "UTF-8";

if (reportFile.open("w")) {
    reportFile.write(report);
    reportFile.close();
    alert("Report created:\r" + reportFile.fsName);
    reportFile.execute();
} else {
    alert("Failed to create the report file.");
}

This script focuses on only two pieces of information:

link name
expected file path

This is usually enough to quickly identify the missing asset using the Links panel.

After generating the report, the script automatically opens the text file using the system’s default application (for example, Notepad on Windows).

Example Output

A simple report might look like this:

Missing Links Report
Document: example.indd
Generated: YYYY-MM-DD

Link name: image_023.tif
Expected path:
C:\project\images\image_023.tif

Link name: diagram_A3.ai
Expected path:
D:\assets\illustrations\diagram_A3.ai

With this information available immediately, operators no longer need to manually trace the original file location through the Links panel.

Why Minimal Automation Works

Small scripts often remove the largest repeated friction.

The interesting thing about this example is that the script itself is extremely simple.

It does not:

repair links automatically
search folders
perform batch relinking
modify document structure

Yet it still removes a repeated manual step that occurs frequently in multilingual production.

Automation does not need to be complex to be useful.
It only needs to remove friction that appears repeatedly.

Conclusion

Automation becomes valuable when small friction repeats across projects.

In multilingual workflows, many tasks are not difficult.
They are simply repeated.

A small issue can multiply across:

languages
documents
revisions

When this happens, even small improvements can produce significant time savings.

This is why High Frequency tasks are often the best place to start automation.

High Frequency is often the easiest signal to recognize — but it is only one part of the automation decision.

In the next article, we will explore the second criterion from the framework:
High Instability, and why layout behavior after translation often becomes unpredictable.

What Should You Automate First in Multilingual DTP?

2026-02-28T22:45:00.000Z

Introduction

Automation is everywhere.

You can automate layout adjustments, file packaging, PDF export, translation import, style cleanup—the list is long.

But if you automate the wrong thing first, your workflow doesn’t scale.
It just becomes more complicated.

So here’s the real question:

If you could automate only one thing in multilingual DTP this year, what would it be?

This is not a technical question.
It’s a prioritization problem.

Common Mistakes When Choosing What to Automate

Before defining criteria, it helps to look at what not to do.

1) Starting with something impressive

I once tried to automate text importing across documents.

The idea was clean: writers prepare text files, and a script finds placeholders in InDesign and replaces them automatically.

Technically, it worked.

Practically, it didn’t move the needle.

Copy-paste was often faster. And the real friction didn’t come from importing text—it came afterwards: overset text, layout breaks, exceptions in tables, grouped objects, and all the messy edge cases.

It was a wide-scope automation, but not a high-leverage one.

2) Automating a one-time emergency

At one point, I wrote a script that reduced every paragraph style’s point size by 1pt to solve a layout issue.

It saved the day.

Once.

But that wasn’t a scalable improvement. It was a workaround.

One-off automation often optimizes a single fire—not the system.

3) Prioritizing what is “possible”

I also built a date-change script with a UI that let users choose multiple update modes.

It looked flexible.

Later, I removed the UI.

Why?

Because in actual usage, the requirement was almost always fixed:

If the date contains “xx”, update to today’s date.
Otherwise, set the day to “xx” while updating month/year.

The extra flexibility added friction. I built it because I could—not because it improved the workflow.

“Can be done” is not the same as “worth doing.”

Three Criteria for Your First Automation

If you want automation that actually scales multilingual DTP, use these three filters:

1) High Frequency

It must happen often.

If you only encounter the task twice a year, it’s rarely your first candidate.

2) High Instability

The task behaves differently each time.

In multilingual production, instability is common:

text expansion after translation
language-specific line breaks
tables breaking differently per language
layout shifts across versions

Instability does not mean the rule is complex.
It means the condition changes.

The condition may be unpredictable—but the rule to fix it should be simple.

3) Low Judgment

The task does not require complex human interpretation.

If the decision can be expressed as rules, conditions, or predictable logic, it’s a strong automation candidate.

If it requires contextual understanding, regulatory interpretation, or content nuance, it’s not your first target.

Look for tasks where at least two of these forces strongly overlap.
The strongest candidates usually satisfy all three.

Applying the Criteria in Practice

Case 1: Minimal Date Update

(Frequency × Low Judgment)

Date updates happen repeatedly, and the correct behavior is often rule-based.

In my case, most updates followed predictable logic:

If the date contains “xx”, update to today’s date.
Otherwise, set the day to “xx” while updating month/year.

Instead of adding options, I removed them.
I embedded the decision logic directly into the script.

The result:

fewer clicks
fewer decisions
less room for error

This example uses a simple English date format for clarity.
In multilingual environments, it is often better to create separate minimal scripts per language rather than adding complex UI branching logic.

Here’s a minimal example (no UI, no options—just rule-based behavior):

Want the ready-to-use version?

Skip the copy-paste and download the script directly from Gumroad.

Download on Gumroad (Free) →

#target indesign

if (app.selection.length === 0) {
    alert("Please select text containing a date.");
    exit();
}

var sel = app.selection[0];
if (!sel.hasOwnProperty("contents")) {
    alert("Selected object does not contain editable text.");
    exit();
}

var text = sel.contents;

// Match: "xx Xxx 20xx" or "12 Jan 2025" etc.
var regex = /([0-9xX]{2})\s+([A-Za-z]{3})\s+([0-9xX]{4})/;
var match = text.match(regex);

if (!match) {
    alert("No date pattern found (expected: dd MMM yyyy).");
    exit();
}

var oldDay = match[1];
var oldMonth = match[2];
var oldYear = match[3];

var hasX = /x/i.test(oldDay + oldMonth + oldYear);

var now = new Date();
var dayNum = now.getDate();
var day2 = (dayNum < 10) ? ("0" + dayNum) : String(dayNum);

var months = ["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];
var curMonth = months[now.getMonth()];
var curYear = String(now.getFullYear());

var newDate;

if (hasX) {
    // If the date contains "xx" (or any x), update to today's full date.
    newDate = day2 + " " + curMonth + " " + curYear;
} else {
    // Otherwise, set the day to "xx" while updating month/year.
    newDate = "xx " + curMonth + " " + curYear;
}

sel.contents = text.replace(regex, newDate);

alert("Date updated to: " + newDate);

This is not sophisticated automation.
It is targeted friction removal.

This shows the script in action:

Case 2: From a Font-Shrinking Hack to Overset Fixer

(Frequency × Instability × Low Judgment)

Shrinking all paragraph styles was a reaction.

Overset text after translation is a pattern.

The real issue wasn’t “make text smaller.”
It was that translated layouts become unstable.

Different languages expand differently.
Tables overflow unpredictably.
Anchored objects behave inconsistently.
Even small upstream changes can shift pagination.

Overset is both frequent and unstable—making it a strong automation candidate.

Although overset behaves differently each time, the handling logic can still be rule-based:

detect overset
apply controlled adjustments
re-check

The judgment required is procedural, not interpretive.

Instead of a destructive global font reduction, the solution evolved toward a more controlled approach:

detect overset reliably
adjust strategically
preserve design intent where possible

The difference is not technical complexity.

It is alignment with frequency, instability, and low-judgment handling.

I’ve written separately about how this thinking evolved into a more structured overset-handling approach.

Where the Bottleneck Eventually Moves

Once repetitive friction is reduced, the constraint shifts.

Not to file handling.
Not to formatting.

But to judgment.

What should change—and what should not?

Automation can remove mechanical repetition.
It cannot replace structured decision design.

And that is where scaling truly begins.

If you had to choose just one thing to automate this year, choose the one that happens often, behaves unpredictably in input, but can be handled with simple rules.

Start there.

Your First Practical InDesign Automation: Opening and Closing Multiple Files

2026-02-20T22:24:00.000Z

0. Who This Article Is For

This is the second article in the beginner automation series.

It assumes you already know how to run a simple .jsx file in InDesign.
(If not, please read the first article in this series first.)

You do not need advanced JavaScript knowledge.

If you work with InDesign Books and regularly open multiple documents for checking or review, this article is for you.

The goal is simple:

Remove repeated friction.

1. The Problem: Opening 15 Files Manually

Imagine this situation:

One Book file
15 InDesign documents inside
5 language versions

After translation, you need to open every file to check layout, overset, images, or styles.

Opening 15 files once is not a problem.
Opening them 100 times over a project lifecycle is.

The action itself is trivial.
The repetition is not.

2. Why This Doesn’t Scale

Automation is not about complexity.

It is about repetition.

Opening files manually:

Click
Wait
Click
Wait

This pattern seems small, but in multilingual workflows it multiplies quickly.

Scaling means removing actions that do not require judgment.

Opening and closing files require no judgment.
Therefore, they are good candidates for automation.

3. Minimal Script Example

Before using these scripts, make sure:

InDesign is open
A Book file is open

(You already know how to run a .jsx file from the previous beginner article.)

3.1 Open All Documents in the Active Book

#target indesign
// Open all documents in the active Book (.indb)
//
// Beginner version:
// - No GUI (no dialogs)
// - Minimal guards
// - No heavy error handling
// - No OS-specific path logic

(function () {
    if (app.books.length === 0) {
        alert("No Book is currently open.\nOpen a .indb file first, then run this script.");
        return;
    }

    var book = app.activeBook;
    var contents = book.bookContents;

    if (contents.length === 0) {
        alert("The active Book has no documents.");
        return;
    }

    for (var i = 0; i < contents.length; i++) {
        // Opens the INDD referenced by the Book content.
        // If the document is already open, InDesign may show a notice or simply activate it.
        app.open(contents[i].fullName);
    }

    alert("Completed.\nOpened: " + contents.length + " document(s).");
})();

This script:

Assumes one Book is active
Loops through all bookContents
Opens each file

Nothing more.

3.2 Close All Open Documents (and Books)


#target indesign
// Close all open documents (without forcing a save)
// Optional: close all open Books as well
//
// Beginner version:
// - Does NOT force saving (SaveOptions.NO)
// - Skips unsaved documents (new/dirty) to avoid risky loss
// - Loops backward to avoid index shifting while closing

(function () {
    if (app.documents.length === 0 && app.books.length === 0) {
        alert("Nothing to close.\nNo documents or Books are currently open.");
        return;
    }

    // Close documents (backward loop is important)
    var docs = app.documents;
    var closedDocs = 0;
    var skippedDocs = 0;

    for (var i = docs.length - 1; i >= 0; i--) {
        var doc = docs[i];

        // doc.saved is true when the document has no unsaved changes.
        // We only close "clean" documents in this beginner example.
        if (doc.saved) {
            doc.close(SaveOptions.NO);
            closedDocs++;
        } else {
            skippedDocs++;
        }
    }

    // Optional: close Books too (also without forcing a save)
    var closeBooks = confirm("Documents closed: " + closedDocs +
        "\nSkipped (unsaved/dirty): " + skippedDocs +
        "\n\nDo you want to close all open Books as well?");

    var closedBooks = 0;

    if (closeBooks) {
        // Close all open Books (backward loop to be safe)
        for (var b = app.books.length - 1; b >= 0; b--) {
            app.books[b].close(SaveOptions.NO);
            closedBooks++;
        }
        alert("Completed.\nClosed Books: " + closedBooks);
    } else {
        alert("Completed.\nClosed Docs: " + closedDocs + "\nSkipped Docs: " + skippedDocs);
    }
})();

Why loop backward?

When closing items inside a collection, the index changes.

If you close from the front:

You close item 0
What used to be item 1 becomes item 0
The loop skips one

Looping backward avoids this.

4. What This Teaches You

Even this small script introduces core concepts:

app
books
documents
loops
conditions

You do not need complex logic to start automating.

You need to identify repetition.

5. Where This Leads

From here, you can extend the idea:

Open only files matching a condition
Skip certain chapters
Run a check automatically after opening
Combine open → process → close

This is how automation grows.

Not by jumping to complex tools.

But by removing friction, step by step.

Detecting Text Overset in InDesign: A Minimal Script Before Automation

2026-02-02T00:31:00.000Z

Update (2026-02-18):
Fixed a restore issue that could leave a black 1pt stroke in certain environments. Please use the updated script below.

Note:
In some localized versions of InDesign, the internal name of the built-in “None” swatch may differ. If the restore script does not correctly remove the stroke, verify the swatch name in your document and adjust the getNoneSwatch() function accordingly.

Context

In the previous article, I explained why text overset is not just a layout problem, but a scaling problem in multilingual InDesign workflows.

When overset handling depends on manual inspection and ad-hoc fixes, the workflow breaks down quickly as document count and language count increase.

This article is a follow-up.
It intentionally does not attempt to fix overset text.

Instead, it focuses on a more fundamental question:

How do you reliably see where overset exists before deciding what to do?

If you have not read the previous article yet, it provides important context on why overset detection itself must scale, not just the correction step.

Previous article:
https://www.linguist-coder.com/2026/01/scaling-multilingual-dtp-by-eliminating.html

Why Detection Still Matters (Even with Preflight)

InDesign already has a Preflight feature, and it does detect overset text.

The problem is not capability, but usability at scale.

Preflight reports issues as a list
This script visualizes issues directly on the page

Instead of scanning rows in a panel, you flip through pages and immediately see where overset exists.

Think of it as a visual pressure map for text.

Before fixing anything, this answers a more important question:

Are these a few isolated problems, or a structural issue that will not scale manually?

Design Philosophy of This Free Sample

This script is intentionally limited.

What it does

Scans all text frames in the document (including master spreads)
Detects overset text frames
Makes them visually obvious using stroke color and stroke weight
Stores minimal metadata for later cleanup

What it does not do

Automatically fix overset
Change text composition
Adjust fonts, tracking, or layout rules

This is deliberate.

Overset correction requires context and judgment.
Blind automation in this area is more likely to damage layouts than improve them.

This sample exists to support human decision-making, not replace it.

Why Stroke Color + Stroke Weight

Overset frames are marked by:

Changing the stroke color (e.g. a bright warning color such as red)
Increasing the stroke weight to 2pt

The fill is left untouched to avoid interfering with layout or readability.

Increasing stroke weight is intentional.
Without it, visibility is poor in dense layouts.

Important clarification:
This script does not change text content or layout decisions.

It only adds a temporary visual marker to help you identify where overset occurs.

Detection Script: Mark Overset Text Frames

#target indesign

/*
Detect overset text frames and mark them with a warning stroke.
Marker is stored in TextFrame.label as:
  |LC_OVRSET_V1{c=<origStrokeColorToken>;w=<origStrokeWeight>}
Where c=@NONE means "no stroke" (None).

Note:
- Some environments are sensitive to file encoding. If the script does not run, save as "UTF-8 with BOM".
*/

(function () {
    var MARK_KEY = "LC_OVRSET_V1";
    var NONE_TOKEN = "@NONE";
    var WARN_STROKE_WEIGHT = 2; // pt
    var WARN_SWATCH_NAME = "LC_Overset_Warn";

    if (app.documents.length === 0) {
        alert("No documents are currently open.");
        return;
    }

    var doc = app.activeDocument;
    var frames = collectAllTextFrames(doc);

    var scanned = frames.length;
    var oversetFound = 0;
    var marked = 0;
    var alreadyMarked = 0;
    var skippedLocked = 0;
    var skippedErrors = 0;

    for (var i = 0; i < frames.length; i++) {
        var tf = frames[i];
        if (!tf || !tf.isValid) continue;

        try {
            if (!tf.overflows) continue;
            oversetFound++;

            // Avoid label pollution on repeated runs
            if (tf.label && tf.label.indexOf("|" + MARK_KEY + "{") !== -1) {
                alreadyMarked++;
                continue;
            }

            if (isLockedOrOnLockedLayer(tf)) {
                skippedLocked++;
                continue;
            }

            // Capture original stroke
            var origColorToken = getStrokeColorToken(doc, tf, NONE_TOKEN);
            var origWeight = safeNumber(tf.strokeWeight, 0);

            // Apply warning stroke
            tf.strokeColor = getWarningSwatch(doc, WARN_SWATCH_NAME);
            tf.strokeWeight = WARN_STROKE_WEIGHT;

            // Store marker
            tf.label = (tf.label || "") +
                "|" + MARK_KEY + "{c=" + origColorToken + ";w=" + origWeight + "}";

            marked++;

        } catch (e) {
            skippedErrors++;
        }
    }

    alert(buildSummary());

    function buildSummary() {
        var lines = [];
        lines.push("Overset detection completed.");
        lines.push("");
        lines.push("Text frames scanned: " + scanned);
        lines.push("Overset frames found: " + oversetFound);
        lines.push("Marked: " + marked);
        lines.push("Already marked: " + alreadyMarked);

        if (skippedLocked > 0 || skippedErrors > 0) {
            lines.push("");
            lines.push("Warnings:");
            if (skippedLocked > 0) lines.push("- Skipped (locked object or layer): " + skippedLocked);
            if (skippedErrors > 0) lines.push("- Skipped (other errors): " + skippedErrors);
        }
        return lines.join("\n");
    }

    function collectAllTextFrames(doc) {
        var result = [];

        try { collectFromItems(doc.allPageItems, result); } catch (e) {}

        // Include master items
        try {
            for (var m = 0; m < doc.masterSpreads.length; m++) {
                try { collectFromItems(doc.masterSpreads[m].allPageItems, result); } catch (e2) {}
            }
        } catch (e3) {}

        return result;

        function collectFromItems(items, out) {
            var len = 0;
            try { len = items.length; } catch (e) { return; }
            for (var i = 0; i < len; i++) {
                try {
                    var it = items[i];
                    if (it && it.isValid && it.constructor.name === "TextFrame") out.push(it);
                } catch (e2) {}
            }
        }
    }

    function isLockedOrOnLockedLayer(tf) {
        try { if (tf.locked) return true; } catch (e) {}
        try { if (tf.itemLayer && tf.itemLayer.locked) return true; } catch (e2) {}
        return false;
    }

    function getStrokeColorToken(doc, tf, noneToken) {
        try {
            var c = tf.strokeColor;
            if (isNoneLike(doc, c)) return noneToken;
            return (c && c.isValid && c.name) ? c.name : noneToken;
        } catch (e) {
            return noneToken;
        }
    }

    // Robust "None" detection (locale-safe enough for common environments)
    function isNoneLike(doc, colorObj) {
        if (!colorObj) return true;
        try { if (!colorObj.isValid) return true; } catch (e0) { return true; }

        // Name-based (works in your environment: "None")
        try {
            var n = colorObj.name;
            if (n === "None" || n === "[None]") return true;
        } catch (e1) {}

        // Identity-based fallback
        try {
            var noneSw = getNoneSwatch(doc);
            if (noneSw && noneSw.isValid && colorObj === noneSw) return true;
        } catch (e2) {}

        return false;
    }

    function getNoneSwatch(doc) {
        // Your environment uses "None", but keep both for portability.
        try { var s0 = doc.swatches.itemByName("None"); s0.name; return s0; } catch (e0) {}
        try { var s1 = doc.swatches.itemByName("[None]"); s1.name; return s1; } catch (e1) {}

        // Minimal scan fallback
        try {
            for (var i = 0; i < doc.swatches.length; i++) {
                var sw = doc.swatches[i];
                if (!sw || !sw.isValid) continue;
                var nm = "";
                try { nm = sw.name; } catch (e2) {}
                if (nm === "None" || nm === "[None]") return sw;
            }
        } catch (e3) {}

        return null;
    }

    function getWarningSwatch(doc, swatchName) {
        try {
            var s = doc.colors.itemByName(swatchName);
            s.name; // validate
            return s;
        } catch (e) {
            return doc.colors.add({
                name: swatchName,
                model: ColorModel.PROCESS,
                space: ColorSpace.RGB,
                colorValue: [255, 0, 0]
            });
        }
    }

    function safeNumber(n, fallback) {
        var v = parseFloat(n);
        return isNaN(v) ? fallback : v;
    }

})();

Restore Script (Cleanup, Not Undo)

This restore script exists for cleanup, not for perfect rollback.

If your goal is simply to undo the script execution,
InDesign’s built-in “Revert” feature is the safest option.

The restore script is intended for two specific situations:

After you manually fix overset text and want to remove the visual markers
When you forgot to save before running the detection script

It removes only the visualization layer
(stroke color and stroke weight added by the detection script).

It does not attempt to restore all original appearance details
such as stroke style, tint, or other decorative attributes.

Implementation notes

The restore logic is written defensively to handle real-world InDesign documents:

Frames that became invalid (e.g. after ungrouping) are skipped safely
Locked objects and locked layers are not modified
Multiple markers from previous runs are fully removed
Frames that originally had no stroke are explicitly restored to “None”

This keeps the script predictable and avoids leaving warning styles behind.

About Undo support

For simplicity, this sample does not wrap changes in a single Undo step.

If you adapt this logic for production use,
wrapping the script with app.doScript(...) and UndoModes.ENTIRE_SCRIPT
is the standard approach to improve safety.

This sample intentionally avoids that step
to keep the focus on conceptual clarity rather than tool completeness.

Restore Script: Remove Overset Markers

#target indesign

(function () {
    var MARK_KEY = "LC_OVRSET_V1";
    var NONE_TOKEN = "@NONE";

    if (app.documents.length === 0) {
        alert("No documents are currently open.");
        return;
    }

    var doc = app.activeDocument;
    var frames = collectAllTextFrames(doc);

    var scanned = frames.length;
    var restored = 0;
    var notMarked = 0;
    var skippedLocked = 0;
    var skippedErrors = 0;
    var failedSetNone = 0;

    for (var i = 0; i < frames.length; i++) {
        var tf = frames[i];
        if (!tf || !tf.isValid) continue;

        try {
            var parsed = parseLastMark(tf.label, MARK_KEY);
            if (!parsed) { notMarked++; continue; }

            if (isLockedOrOnLockedLayer(tf)) { skippedLocked++; continue; }

            if (parsed.colorToken === NONE_TOKEN) {
                // Force None + 0
                if (!setNoStroke(doc, tf)) {
                    failedSetNone++;
                }
            } else {
                // Restore original color if resolvable
                var restoredColor = resolveColorOrSwatch(doc, parsed.colorToken);
                if (restoredColor) tf.strokeColor = restoredColor;

                if (!isNaN(parsed.weight)) tf.strokeWeight = parsed.weight;
            }

            tf.label = removeAllMarks(tf.label, MARK_KEY);
            restored++;

        } catch (e) {
            skippedErrors++;
        }
    }

    alert(
        "Restore completed.\n\n" +
        "Text frames scanned: " + scanned + "\n" +
        "Restored (marker removed): " + restored + "\n" +
        "Not marked: " + notMarked + "\n" +
        (skippedLocked ? ("Skipped locked: " + skippedLocked + "\n") : "") +
        (failedSetNone ? ("Failed to set None (kept stroke): " + failedSetNone + "\n") : "") +
        (skippedErrors ? ("Errors: " + skippedErrors + "\n") : "")
    );

    function setNoStroke(doc, tf) {
        // Get "None" swatch fresh each time (environment-safe)
        var noneSw = getNoneSwatch(doc);
        if (!noneSw) {
            // If we can't even find None, at least set weight=0
            try { tf.strokeWeight = 0; } catch (e0) {}
            return false;
        }

        // Apply
        try { tf.strokeColor = noneSw; } catch (e1) {}
        try { tf.strokeWeight = 0; } catch (e2) {}

        // Verify (some environments keep old strokeColor)
        try {
            var sc = tf.strokeColor;
            var nm = sc && sc.isValid ? sc.name : "";
            if (nm === "None" || nm === "[None]" || nm === "なし" || nm === "[なし]") return true;
        } catch (e3) {}

        // Retry once
        try { tf.strokeColor = noneSw; } catch (e4) {}
        return true;
    }

    function collectAllTextFrames(doc) {
        var result = [];
        try { collectFromItems(doc.allPageItems, result); } catch (e) {}
        try {
            for (var m = 0; m < doc.masterSpreads.length; m++) {
                try { collectFromItems(doc.masterSpreads[m].allPageItems, result); } catch (e2) {}
            }
        } catch (e3) {}
        return result;

        function collectFromItems(items, out) {
            var len = 0;
            try { len = items.length; } catch (e) { return; }
            for (var i = 0; i < len; i++) {
                try {
                    var it = items[i];
                    if (it && it.isValid && it.constructor.name === "TextFrame") out.push(it);
                } catch (e2) {}
            }
        }
    }

    function isLockedOrOnLockedLayer(tf) {
        try { if (tf.locked) return true; } catch (e) {}
        try { if (tf.itemLayer && tf.itemLayer.locked) return true; } catch (e2) {}
        return false;
    }

    function parseLastMark(label, key) {
        if (!label) return null;

        var needle = "|" + key + "{";
        var pos = label.lastIndexOf(needle);
        if (pos === -1) return null;

        var end = label.indexOf("}", pos);
        if (end === -1) return null;

        var token = label.substring(pos + needle.length, end);
        var parts = token.split(";");

        var colorToken = "";
        var weight = NaN;

        for (var i = 0; i < parts.length; i++) {
            var kv = parts[i].split("=");
            if (kv.length !== 2) continue;
            if (kv[0] === "c") colorToken = kv[1];
            if (kv[0] === "w") weight = parseFloat(kv[1]);
        }

        return { colorToken: colorToken, weight: weight };
    }

    function removeAllMarks(label, key) {
        if (!label) return "";
        var needle = "|" + key + "{";
        var out = label;
        while (true) {
            var start = out.indexOf(needle);
            if (start === -1) break;
            var end = out.indexOf("}", start);
            if (end === -1) break;
            out = out.substring(0, start) + out.substring(end + 1);
        }
        return out;
    }

    function getNoneSwatch(doc) {
        // Your environment shows "None (Swatch)" so try "None" first.
        try { var s0 = doc.swatches.itemByName("None"); s0.name; return s0; } catch (e0) {}
        try { var s1 = doc.swatches.itemByName("[None]"); s1.name; return s1; } catch (e1) {}

        // Scan by name / constructor
        try {
            for (var i = 0; i < doc.swatches.length; i++) {
                var sw = doc.swatches[i];
                if (!sw || !sw.isValid) continue;
                var nm = "";
                var cn = "";
                try { nm = sw.name; } catch (e2) {}
                try { cn = sw.constructor && sw.constructor.name ? sw.constructor.name : ""; } catch (e3) {}
                if (nm === "None" || nm === "[None]" || nm === "なし" || nm === "[なし]" || cn === "NoColor") return sw;
            }
        } catch (e4) {}

        return null;
    }

    function resolveColorOrSwatch(doc, name) {
        if (!name) return null;

        try {
            var c = doc.colors.itemByName(name);
            if (c && c.isValid) return c;
        } catch (e1) {}

        try {
            var s = doc.swatches.itemByName(name);
            if (s && s.isValid) return s;
        } catch (e2) {}

        return null;
    }

})();

Closing Thoughts

Overset itself is not the real problem.

The real problem is mixing detection, judgment, and correction into a single step.

This free sample exists to separate those concerns —
not to fix everything, but to help you decide what deserves fixing at all.

That separation is what allows multilingual DTP workflows to scale.

Scaling Multilingual DTP – Maintenance / Recovery: When and How to Clean Up InDesign Files with IDML

2026-01-29T01:36:00.000Z

0. Why This Article Exists

Recovery as Part of Scaling

The Scaling Multilingual DTP series has covered the parts that are easier to systematize:

pre-export for translation (IDML export from books)
automation before/after translation (style reloads, relinking)
final QA (PDF required-string checks)
“escape hatches” when the layout pressure becomes too high (bulk image scaling)

This final article is different. It is not about adding another layer of automation.
It is about protecting what you have already built.

When you scale a workflow, you eventually hit a different kind of problem:
files that become unstable, inconsistent, or unpredictable—often after years of edits, template reuse, or a major InDesign update.

IDML cleanup is not a magic wand.
Especially in multilingual production, you may see unexpected line breaks or subtle reflow changes after an IDML round trip. That is exactly why this is a strategic decision, not a routine step.

Scaling is not about “never breaking.”
It is about having a reliable way back when things break.

1. IDML Cleanup Is Not a Routine Task

IDML cleanup is best treated as a maintenance / recovery tool.

If it becomes part of your daily workflow, two things happen:

you increase the amount of “extra work” you generate
you pay the verification cost repeatedly

In other words, frequent cleanup can reduce stability rather than improve it.

The correct mental model is:

Routine steps keep production moving
Recovery steps exist to restore stability when something is off

IDML cleanup belongs to the second category.
It is a “last resort” tool—useful, powerful, and not meant for everyday use.

2. When IDML Cleanup Actually Makes Sense

A Go / No-Go Checklist

This is the most important part of the article.

Go (consider IDML cleanup)

Use IDML cleanup when you have a clear reason to believe the file’s internal state is the problem:

After a major InDesign update, especially for high-stakes deliverables
Unexplained unstable behavior (random glitches, unexpected errors, crashes)
Abnormal file bloat (file size grows beyond what the content explains)
Long-lived master templates reused for years across many projects

No-Go (probably unnecessary)

Avoid it when the issue is likely caused by something simpler:

minor, visible layout issues that can be fixed directly
clear editing mistakes
“just in case” cleanup without a concrete trigger

The goal is not to “keep files clean.”
The goal is to recover stability when the cost of instability becomes higher than the cost of an IDML round trip.

3. Save / Save As / IDML

What Is Actually Different

When InDesign feels unstable, people often try:

Save
Save As
IDML round trip

These are not equivalent.

A useful way to think about the difference:

Save: putting a bandage on a wound
Save As: cleaning the room
IDML: rebuilding the house from the ground up

Save and Save As operate inside the existing structure.
IDML forces a rebuild via an interchange format.

That difference is exactly why IDML can work when the other options don’t.
It also explains why IDML comes with risk: rebuilding can change small behaviors, including text flow.

4. What IDML Cleanup Does Not Solve

IDML cleanup is powerful, but it is not a guarantee.

Common limitations and side effects include:

subtle text reflow (line breaks and spacing differences)
loss of plugin-dependent data (features stored by third-party plugins)
edge cases involving conditions or special document states

Because of this, verification is mandatory after an IDML round trip.

For multilingual work, verifying every page manually does not scale.
This is a good place to rely on diff-based review (PDF comparison tools, difference extraction, structured QA checks) to reduce the review burden.

The key point is simple:

IDML cleanup can restore stability, but it can also introduce small differences.
Always verify the result.

5. A Minimal, Reproducible Cleanup Workflow

The biggest risk with “maintenance” operations is inconsistency.
Different people perform slightly different steps, or skip a critical check.

That is why the workflow should be minimal and reproducible:

start from a saved INDD file
export to IDML
reopen the IDML
save a cleaned INDD file
verify (diff/QA) before replacing anything

This is not about convenience.
It is about repeatability, which is the core requirement for scaling maintenance work.

6. The Minimal Script

Reproducibility Over Convenience

This script is not the main point of the article.

Its role is to make the cleanup workflow repeatable and less error-prone.

Design choices (intentional constraints):

it processes all currently open, saved documents
it exports IDML and saves a new cleaned INDD copy
it does not overwrite originals
it keeps the exported IDML files for troubleshooting
it suppresses blocking dialogs during batch processing and restores settings afterward
it avoids UI complexity (only a single confirmation)

The script saves outputs in the same folder as the original document.
That increases the chance that link behavior remains predictable.

Note: dialog suppression improves batch stability, but it does not remove the need for verification. It simply prevents the process from stopping halfway.

Script: IDML Cleanup Helper (non-destructive)

Want the ready-to-use version?

Skip the copy-paste and download the script directly from Gumroad.

Download on Gumroad (Free) →

#target indesign

(function () {
    var docs = app.documents;

    if (docs.length === 0) {
        alert("No documents are currently open.");
        return;
    }

    var proceed = confirm(
        "This will export each saved document to IDML, reopen it, and save a cleaned copy as a new INDD file.\n\n" +
        "Original files will NOT be overwritten.\n" +
        "IDML files will be kept for troubleshooting.\n\n" +
        "Continue?"
    );
    if (!proceed) return;

    var results = [];
    var skipped = [];

    // Suppress blocking dialogs during batch processing
    var oldLevel = app.scriptPreferences.userInteractionLevel;
    app.scriptPreferences.userInteractionLevel = UserInteractionLevels.NEVER_INTERACT;

    try {
        // Close() happens inside the loop -> iterate backwards to avoid index shifts
        for (var i = docs.length - 1; i >= 0; i--) {
            try {
                var doc = docs[i];

                if (!doc.saved) {
                    skipped.push(doc.name + " (not saved)");
                    continue;
                }

                var originalFile = doc.fullName;           // File
                var originalFolder = originalFile.parent;  // Folder
                var baseName = stripInddExtension(originalFile.name);

                // Output paths (same folder to preserve link behavior as much as possible)
                var idmlFile = new File(originalFolder.fsName + "/" + baseName + "__idml_cleanup.idml");

                // If a cleaned file already exists, add timestamp to avoid collision
                var cleanedInddFile = new File(originalFolder.fsName + "/" + baseName + "__idml_cleaned.indd");
                if (cleanedInddFile.exists) {
                    cleanedInddFile = new File(
                        originalFolder.fsName + "/" + baseName + "__idml_cleaned_" + timestamp() + ".indd"
                    );
                }

                // 1) Export IDML
                doc.exportFile(ExportFormat.INDESIGN_MARKUP, idmlFile, false);

                // 2) Close original without saving (non-destructive)
                doc.close(SaveOptions.NO);

                // 3) Open IDML (attempt hidden open if supported)
                var reopened;
                try {
                    reopened = app.open(idmlFile, false);
                } catch (_) {
                    reopened = app.open(idmlFile);
                }

                // 4) Save as new INDD (do not overwrite original)
                reopened.save(cleanedInddFile);

                // 5) Close cleaned doc
                reopened.close(SaveOptions.YES);

                results.push(baseName + " -> " + cleanedInddFile.fsName);

            } catch (e) {
                skipped.push(safeDocNameAtIndex(i, docs) + " (error: " + e.message + ")");
                continue;
            }
        }
    } finally {
        // Always restore interaction level
        app.scriptPreferences.userInteractionLevel = oldLevel;
    }

    // Report
    var msg = [];
    msg.push("Completed.\n");

    if (results.length > 0) {
        msg.push("[Cleaned copies created]");
        for (var r = 0; r < results.length; r++) msg.push("- " + results[r]);
        msg.push("");
    }

    if (skipped.length > 0) {
        msg.push("[Skipped]");
        for (var s = 0; s < skipped.length; s++) msg.push("- " + skipped[s]);
        msg.push("");
    }

    msg.push("Note: Always verify (diff/QA) before replacing originals.");
    alert(msg.join("\n"));

    // ---- helpers ----

    function stripInddExtension(name) {
        return name.replace(/\.indd$/i, "");
    }

    function timestamp() {
        // YYYYMMDD_HHMMSS
        var d = new Date();
        return (
            d.getFullYear() +
            pad2(d.getMonth() + 1) +
            pad2(d.getDate()) + "_" +
            pad2(d.getHours()) +
            pad2(d.getMinutes()) +
            pad2(d.getSeconds())
        );
    }

    function pad2(n) {
        return (n < 10) ? ("0" + n) : ("" + n);
    }

    function safeDocNameAtIndex(idx, collection) {
        try { return collection[idx].name; } catch (_) { return "(unknown document)"; }
    }
})();

7. How This Fits into a Scalable Workflow

Why Recovery Scales

Recovery sounds “non-scalable” at first—because it happens when something is wrong.

But in multilingual publishing, recovery can be the highest-leverage step.

If you produce 20 languages from a single master workflow:

one unstable master can generate 20 unstable outputs
one recovery operation applied upstream can prevent that multiplication

That is the reason IDML cleanup belongs in a scalable workflow:

not as a routine step
but as a controlled, upstream recovery action
applied at the point where it prevents downstream multiplication

This is also why reproducibility matters.
When recovery steps are defined clearly, the work becomes transferable and less dependent on individual intuition.

8. Closing: Scaling Includes Recovery

Scaling is not about “never breaking.”

It is about having a reliable way back when things break.

The first phase of scaling is usually:

creating repeatable processes
automating stable rules
reducing decisions

The second phase is more subtle:

protecting those processes
restoring stability when something becomes unpredictable
maintaining the system you built

That is what maintenance and recovery are for.

In multilingual DTP, scaling includes recovery.

Scaling Multilingual DTP by Creating an Escape Hatch for Layout Adjustment (Shrinking All Placed Images at Once)

2026-01-26T00:45:00.000Z

0. Context: Why Layout Adjustment Stops Scaling After Translation

In multilingual publishing, text expansion after translation is expected.
The real problem is not that layouts need adjustment, but that the adjustment work does not scale.

Line spacing and paragraph tweaks can absorb small increases in text volume.
However, there is always a point where those adjustments are no longer enough.

What remains at the end is usually layout work that must be done by hand — and that is where scaling breaks down.

1. Why Image Adjustment Is the Least Scalable Part

Image adjustment often becomes the last step.

Images are visually prominent
Each image seems to require individual judgment
Decisions feel content-dependent

This makes image-related layout work expensive in terms of attention.

The more carefully each image is adjusted, the less scalable the process becomes.
Perfect layouts do not compound well when document count and language count increase.

2. Escaping Instead of Fixing Everything

Instead of trying to fix everything perfectly, this article proposes a different approach:

Create an intentional escape hatch.

An escape hatch is not about achieving a final layout.
It is about applying a simple, uniform rule to reduce overall layout pressure.

The goal is not perfection, but room to breathe.

3. What This Script Does (And Intentionally Does Not Do)

3.1 What It Does

The script introduced here applies a single rule:

All currently open documents are processed
All placed images are affected
Image frames and their contents are scaled together
A fixed relative reduction of −10% is applied

No decisions are made per image.
Everything is treated uniformly.

3.2 What It Does Not Do

This script intentionally avoids:

Processing only selected images
Letting the user choose a percentage
Handling exceptions or special cases
Providing a UI

These features may be convenient, but they introduce additional decisions.
This example avoids them on purpose.

4. Why the Frame Must Be Scaled Together with the Image

Shrinking only the image content is rarely sufficient.

If the frame size remains unchanged, shrinking the image simply increases surrounding whitespace.
The layout pressure does not change.

What affects layout flow is the area occupied by the frame, not the image inside it.

That is why the script treats the frame and its contents as a single unit and scales them together.

5. The Minimal Script

This approach may feel risky at first.

Shrinking all placed images at once will also affect anchored objects, logos, and icons.
That is intentional.

This script is not meant to produce a final, polished layout.
It is a rough operation designed to reduce overall layout pressure.

In practice, fixing a few broken spots afterward is often much faster
than adjusting every image by hand from the beginning.

In real production workflows, certain images might be excluded —
for example, logos or icons identified by name or layer.

That kind of filtering can make a script more convenient.
However, it also introduces more rules and decisions.

This example intentionally avoids that.
Its purpose is to demonstrate a scalable fallback, not a complete solution.

#target indesign

(function () {
    var docs = app.documents;

    if (docs.length === 0) {
        alert("No documents are currently open.");
        return;
    }

    for (var d = 0; d < docs.length; d++) {
        try {
            scaleAllPlacedGraphicsInDoc(docs[d]);
        } catch (e) {
            continue;
        }
    }

    alert("Completed");

    function scaleAllPlacedGraphicsInDoc(doc) {
        var pages = doc.pages;

        for (var i = 0; i < pages.length; i++) {
            var graphics = pages[i].allGraphics;

            for (var j = 0; j < graphics.length; j++) {
                try {
                    var frame = graphics[j].parent;

                    // Reset relative scaling to 100%
                    frame.redefineScaling();

                    // Apply relative -10% scaling
                    frame.horizontalScale = 90;
                    frame.verticalScale   = 90;

                    // Fix the result as the new 100%
                    frame.redefineScaling();

                } catch (e2) {
                    continue;
                }
            }
        }
    }
})();

The choice of 10% is not critical.

There is no special meaning in that number.
What matters is deciding on a single rule and applying it consistently.

A UI would invite further decisions.
This script avoids that by design.

6. Another Escape Hatch: Preparing Smaller Paragraph Styles

Images are not the only place where escape hatches can be prepared.

Text-related pressure can often be reduced earlier by preparing paragraph styles with smaller font sizes.
Loading these styles in advance creates another controlled fallback.

This approach is discussed in more detail in:

Scaling Multilingual DTP by Automating Style Reloads Before Translation

The underlying idea is the same:
prepare scalable options before manual adjustment becomes necessary.

7. Combining Escape Hatches in Practice

In practice, these escape hatches work best together.

Text volume can be absorbed by switching to prepared paragraph styles
Image-heavy pages can gain space through uniform image scaling

Only after these global adjustments does it make sense to perform individual fine tuning.

This ordering significantly reduces the number of decisions required.

8. Closing: Scaling Is About Reducing Decisions

The main obstacle to scaling is not complexity, but decision count.

Scripts like this are not about convenience.
They are about fixing rules in advance so that fewer decisions are needed later.

Instead of perfecting each page, create room first —
and adjust only where necessary.

That is what allows multilingual DTP workflows to scale.

How to Run JavaScript in Adobe InDesign (Without Learning JavaScript First)

2026-01-24T21:28:00.000Z

0. Who This Article Is For

This article is for InDesign users who don’t want to “learn JavaScript” — they just want to make InDesign do the work.

You may have seen scripts, automation examples, or .jsx files before, but stopped there because many explanations immediately turn into a JavaScript course.
That is not the purpose here.

This article is not for people who want to become JavaScript developers.
It is for people who already work in InDesign and want to automate small, repetitive tasks.

1. What This Article Does (And Does Not Do)

The goal of this article is very simple:

Write a minimal script
Run it in InDesign
Confirm that it actually works

That’s it.

This article does not cover JavaScript syntax in detail.
General programming concepts are also not explained.

Those topics are already well covered elsewhere.
Here, the focus is limited to what is necessary to make InDesign execute a script.

If something runs and produces a visible result, that is already a success.

2. Write the Smallest Possible Script

2.1 Open a Text Editor (or VS Code)

Any plain text editor can be used.

Notepad (Windows)
TextEdit (macOS, plain text mode)
VS Code, if it is already familiar

The specific tool does not matter.
The only requirement is that a plain text file can be saved.

2.2 Type This One Line

Type the following line exactly as it is:


alert("Hello, world");

At this stage, understanding the code is not required.
This line is only used to confirm that InDesign can execute a script.

3. Save the File as a `.jsx`

Save the file with the .jsx extension, for example:


hello.jsx

InDesign recognizes scripts by this extension.
For now, no further explanation is needed.

4. Put the Script into InDesign’s Scripts Folder

InDesign only runs scripts placed in a specific folder.

The easiest way to locate it is:

Open InDesign
From the top menu, choose Window → Utilities → Scripts
The Scripts panel will appear

In the Scripts panel, three folders are usually shown:

Application
Community
User

Select User
From the panel menu, choose Reveal in Explorer / Finder
A folder named Scripts will open
Open the Scripts Panel folder inside it
Save your .jsx file into Scripts Panel

This is the folder where the .jsx file should be saved.

Once placed there, the script should appear in the Scripts panel.

5. Run the Script

Double-click the script in the Scripts panel.

If a dialog displaying “Hello, world” appears, the script has run successfully.

At this point, one important thing has been confirmed:

JavaScript is running inside InDesign.

This step exists only to verify that fact.

6. Change One Line to Control InDesign

6.1 Replace the Code

Open the same .jsx file again and replace its contents with the following line:


app.documents.add();

Save the file.

6.2 Run It Again

Run the script from the Scripts panel once more.

If a new InDesign document opens, the script worked.

This confirms something more important than before:

JavaScript is not just running — it is controlling InDesign.

7. What Is Actually Necessary (And What Is Not)

At this stage, enough has already been covered to start using scripts in practice.

It is now clear:

Where scripts are stored
How they are executed
That scripts can control InDesign

A deep understanding of JavaScript is not required.
Programming theory is also unnecessary at this point.

For many real-world InDesign tasks, this level of knowledge is sufficient.

8. That’s It for Now

This article intentionally stops here.

The goal was not to teach JavaScript, but to remove the barrier between
“I’ve heard of scripts” and “I can actually run one”.

Most articles on this blog are written for people working with InDesign in production environments.
Occasionally, articles like this are added as entry points.

If a script can be executed successfully, the hardest part is already over.

If you want to try a real-world example, the following article includes a sample script.

The script can be run using exactly the same method shown in this article:

Scaling Multilingual DTP by Automating Trados-Ready IDML Export from InDesign Books

Scaling Multilingual DTP by Automating Mandatory Text Checks in PDFs Before Delivery

2026-01-22T00:54:00.000Z

In multilingual documentation workflows, the final deliverable is often a PDF.

Even when layout, links, and styles are correct, a document can still fail for a very simple reason:

a required text string is missing.

Typical examples include:

Safety headings such as Warning
Regulatory sections such as Intended Use
Copyright statements
Document or revision codes

These are easy to overlook—especially when you deliver many PDFs across multiple languages.

Why I built this script in the first place

In my experience, many PDF proofreading or QA tools are good at finding forbidden words (for example, detecting if Draft is still present).

However, tools that can reliably detect when a required text is missing are surprisingly rare.

When such tools do exist:

they are often enterprise-level solutions
and they are usually very expensive

That gap is what motivated me to create a small, purpose-built script that answers a simple question:

“Is this required text actually present in every PDF?”

The automation approach

The basic idea is straightforward:

Extract text from each PDF
Search for a predefined list of required texts
Report which PDFs pass or fail
Save the results as a log file for traceability

This does not replace full QA.
It provides a fast, repeatable safety net before delivery.

Minimal script example (folder-based batch check)

⚠ Important note for readers
This example is written in Python, not JavaScript.

If you mainly work with InDesign scripting, this is intentional:

InDesign scripts are ideal for layout and asset automation
PDF-level QA is often easier and more reliable in Python

To run this script, you need:

Python 3.10 or later
The following modules:
- PyMuPDF (fitz)
- tkinter (usually included with Python)

Module installation example:


pip install pymupdf

Example required texts (sample only)


NEEDLES = [
    "Warning",
    "Intended Use",
    "Copyright",
    "1234-5678A",
]

These strings are intentionally generic and represent typical mandatory elements in technical or regulated documentation.

Python sample script (MIT License)


from __future__ import annotations

from pathlib import Path
import re
import time
import fitz  # PyMuPDF
import tkinter as tk
from tkinter import filedialog

# Sample mandatory strings (English-only example)
NEEDLES = [
    "Warning",
    "Intended Use",
    "Copyright",
    "1234-5678A",
]

LOG_FILENAME = "pdf_mandatory_text_check_results.txt"


def normalize(s: str) -> str:
    """
    Minimal normalization for robust matching:
    - lowercase comparison
    - collapsed whitespace
    """
    s = s.lower()
    s = re.sub(r"\s+", " ", s).strip()
    return s


def select_target_dir() -> Path | None:
    root = tk.Tk()
    root.withdraw()
    root.attributes("-topmost", True)

    folder = filedialog.askdirectory(
        title="Select a folder containing PDFs"
    )
    root.destroy()

    return Path(folder) if folder else None


def pdf_contains_all_text(
    pdf_path: Path,
    needles: list[str],
) -> tuple[bool, list[str], str | None]:
    """
    Returns:
      ok: bool
      missing: list[str]
      error: str | None
    """
    try:
        doc = fitz.open(pdf_path)
        texts: list[str] = []
        for page in doc:
            texts.append(page.get_text("text"))
        all_text = normalize("\n".join(texts))
    except Exception as e:
        return False, needles, f"{type(e).__name__}: {e}"

    missing: list[str] = []
    for needle in needles:
        if normalize(needle) not in all_text:
            missing.append(needle)

    return len(missing) == 0, missing, None


def main() -> int:
    target_dir = select_target_dir()
    if target_dir is None:
        print("Cancelled (no folder selected).")
        time.sleep(5)
        return 0

    pdfs = sorted(target_dir.glob("*.pdf"))
    if not pdfs:
        print("No PDFs found in the selected folder.")
        time.sleep(5)
        return 0

    log_path = target_dir / LOG_FILENAME
    lines: list[str] = []

    lines.append("PDF Mandatory Text Check Results")
    lines.append(f"Folder: {target_dir}")
    lines.append(f"Mandatory strings: {NEEDLES}")
    lines.append("")

    has_ng = False

    print("Results:")
    for pdf in pdfs:
        ok, missing, error = pdf_contains_all_text(pdf, NEEDLES)

        if error:
            has_ng = True
            msg = f"{pdf.name}: ERROR  {error}"
        elif ok:
            msg = f"{pdf.name}: OK"
        else:
            has_ng = True
            msg = f"{pdf.name}: NG  Missing: {missing}"

        print(msg)
        lines.append(msg)

    log_path.write_text(
        "\n".join(lines) + "\n",
        encoding="utf-8"
    )

    print(f"\nLog written to: {log_path}")
    print("\nProcess completed.")
    print("This window will close automatically in 5 seconds...")
    time.sleep(5)

    return 1 if has_ng else 0


if __name__ == "__main__":
    raise SystemExit(main())
Note:
This script is intentionally simplified and provided as a sample.
Because the required texts are defined in English, it cannot be used as-is for full multilingual validation.
In production, the validation logic itself is typically shared, while the rule sets are switched automatically by detecting the target language from the file name or from the PDF content.

What I add in real production workflows

In real projects, this kind of checker is usually extended with:

Language-specific required text sets
CSV reports for PMs and QA teams
Additional PDF checks (file naming, etc)

This article intentionally focuses on the simplest reliable starting point.

If you are interested in scaling multilingual DTP workflows, you may also find these useful:

Scaling Multilingual DTP by Automating Language-Based Image Relinking in InDesign

2026-01-19T01:43:00.000Z

When working on multilingual documents, it’s common for placed images to exist in language-specific variants.

A typical pattern looks like this:

diagram_EN.ai
diagram_DE.ai

Before or after translation, these images must be relinked to the correct language version.
Doing this manually works for a single file — but it quickly breaks down at scale.

Why manual image relinking doesn’t scale

In InDesign, relinking a single image is trivial.
But in real projects:

One document can contain dozens of placed images
A Book can contain many documents
Missing just one image can cause serious QA issues

As the number of files grows, manual relinking becomes both slow and error-prone.

Why not just replace images with the same filenames?

At this point, some readers may ask:

“Why not keep all image filenames identical and simply replace the contents of the Links folder?”

This approach does exist in real production environments. I have encountered multiple cases where companies have organised their data in this way.

However, in practice, it introduces serious risks.

When all language variants share the same filename:

Once an image is replaced, there is no longer any visible indication of which language it belongs to
If a replacement mistake occurs, tracing the error becomes difficult
When a designer or operator needs to make even a small visual correction, it is no longer obvious which language version they are editing

In multilingual production, these situations are common:

A regulatory label needs a minor wording fix
A UI screenshot requires a small update
A diagram needs a slight annotation change

Without explicit language identifiers in filenames, such fixes can easily be applied to the wrong file.

By contrast, language-suffixed filenames such as _EN, _DE, or _JPN make the language immediately visible.
This improves traceability, reduces mistakes, and makes version control far safer.

For this reason, I deliberately prefer language-coded filenames combined with automated relinking, rather than relying on silent file replacement.

Automation works best when the rules are explicit — and filename conventions are among the most reliable rules available.

The automation approach

In many production environments, image naming rules are fixed and predictable.
For example:

_EN → _DE
Same file extension
Same Links folder

When these assumptions hold, relinking can be automated safely with a small script.

The idea is simple:

Detect linked images ending with _EN.ai or _EN.psd
Replace the suffix with _DE
Relink the file only if it exists
Repeat for all open documents when required

Minimal script example (AI + PSD)

The following script demonstrates the core idea.

It is intentionally minimal and designed for educational use.

Targets AI and PSD files
Uses a fixed naming rule (_EN → _DE)
Assumes the same extension and Links folder
Includes only a simple confirmation dialog

License: MIT
Use at your own risk.

#target indesign

(function () {

    if (app.documents.length === 0) {
        alert("No documents are open.");
        return;
    }

    var processAll = true;

    if (app.documents.length > 1) {
        processAll = confirm(
            "Multiple documents are open.\n\nProcess all open documents?"
        );
    }

    var docs = processAll ? app.documents : [app.activeDocument];

    for (var d = 0; d < docs.length; d++) {
        relinkImages(docs[d]);
    }

    alert("Relinking completed.");

    function relinkImages(doc) {

        var pages = doc.pages;

        for (var i = 0; i < pages.length; i++) {
            var graphics = pages[i].allGraphics;

            for (var j = 0; j < graphics.length; j++) {
                try {
                    var link = graphics[j].itemLink;
                    if (!link) continue;

                    var name = link.name;

                    // Target: _EN.ai / _EN.psd
                    if (!name.match(/_EN\.(ai|psd)$/i)) continue;

                    var newName = name.replace(
                        /_EN\.(ai|psd)$/i,
                        "_DE.$1"
                    );

                    var newFile = new File(
                        doc.filePath + "/Links/" + newName
                    );

                    if (!newFile.exists) continue;

                    link.relink(newFile);

                } catch (e) {
                    // Skip problematic links safely
                    continue;
                }
            }
        }
    }

})();

What this looks like in real production workflows

In actual production environments, this logic is typically part of a larger automation pipeline.

Common extensions include:

Language selection via UI
Validation and logging
Support for additional naming rules

Those topics are intentionally left out of this article.

If you are interested in scaling multilingual DTP workflows, you may also find these useful:

Scaling Multilingual DTP by Automating Style Reloads Before Translation

2026-01-16T00:35:00.000Z

Why styles must be reloaded before or after translation

In multilingual publishing, layout problems are not caused by text expansion alone.

When translating from English into Asian languages, fonts and typographic rules are completely different. Even when translating into languages like German, longer words and different kerning requirements can quickly push text out of its original layout.

For this reason, in real production work, paragraph and character styles are usually reloaded either before or after translation.

Language-specific styles allow you to pre-define things like:

Font families
Tracking and kerning
Line spacing
Paragraph spacing

This reduces the amount of layout correction needed after translation.

What does not work is changing fonts, kerning, or spacing manually for every file. That approach simply does not scale.

Why this breaks down in multilingual projects

Even with language-specific styles, serious problems appear when projects grow.

In an InDesign Book, every .indd file must have the correct style set loaded. If a book contains 20 files, that is 20 separate imports.

Worse, mistakes are easy to make and hard to detect.

If you accidentally load Dutch styles instead of German styles, the document may still look “mostly okay” at a glance. The error might only be discovered much later—sometimes after translation or even at delivery.

This is what makes manual style management dangerous at scale:

The work is repetitive
The differences are subtle
The cost of mistakes is high

The automation approach

The solution is to remove choice and memory from the process.

Instead of letting operators manually pick style files, you place language-specific template files in fixed locations. A script then loads the correct styles into every open document, automatically and consistently.

The goal is simple:
every document enters translation with the correct, normalized style set.

A minimal script example

Below is a simplified version of the script I use in production.
You only need to adjust the file path for your own environment.

License: MIT.


function applyStyles(styleFile)
{
    var templateFile = new File(styleFile);
    if (!templateFile.exists) {
        alert("Template file not found: " + styleFile);
        return;
    }

    var tempFilePath = File.decode(styleFile);
    var docs = app.documents;

    if (docs.length === 0) {
        alert("No documents are currently open.");
        return;
    }

    for (var i = 0; i < docs.length; i++) {
        try {
            // Paragraph + Character styles
            docs[i].importStyles(
                ImportFormat.PARAGRAPH_STYLES_FORMAT,
                tempFilePath,
                GlobalClashResolutionStrategy.LOAD_ALL_WITH_OVERWRITE
            );

            // Table + Cell styles
            docs[i].importStyles(
                ImportFormat.TABLE_STYLES_FORMAT,
                tempFilePath,
                GlobalClashResolutionStrategy.LOAD_ALL_WITH_OVERWRITE
            );

            // Object styles
            docs[i].importStyles(
                ImportFormat.OBJECT_STYLES_FORMAT,
                tempFilePath,
                GlobalClashResolutionStrategy.LOAD_ALL_WITH_OVERWRITE
            );

            // Stroke styles
            docs[i].importStyles(
                ImportFormat.STROKE_STYLES_FORMAT,
                tempFilePath,
                GlobalClashResolutionStrategy.LOAD_ALL_WITH_OVERWRITE
            );

            // TOC styles
            docs[i].importStyles(
                ImportFormat.TOC_STYLES_FORMAT,
                tempFilePath,
                GlobalClashResolutionStrategy.LOAD_ALL_WITH_OVERWRITE
            );

        } catch (e) {
            alert("Error importing styles to document " + docs[i].name + ": " + e.message);
        }
    }
}

// Usage
applyStyles("/path/to/your/template.indt");

This script reloads all major style categories—paragraph, character, table, object, stroke, and TOC styles—using a single template file.

The key point is not the code itself, but the idea:
style normalization should be automatic, not manual.

What this looks like in real production

In practice, I run this as part of a larger automation package that also handles things like:

Exporting IDMLs
Updating linked artwork
Reloading master pages
Normalizing document settings before translation

Those pieces belong in separate posts, but the principle is the same:

If a task must be done for every file and every language, it should not be done by hand.

If you haven’t seen it yet, you may also want to read my previous post on automating one of the biggest layout bottlenecks in multilingual workflows:
Scaling Multilingual DTP by Eliminating Manual InDesign Text Overset Fixes

Scaling Multilingual DTP by Automating Trados-Ready IDML Export from InDesign Books

2026-01-11T22:54:00.000Z

Why IDML is required before translation

If you work with Trados, you already know this:
InDesign .indd files cannot be processed directly. They must be converted to .idml first.

For a single document, that’s trivial.

Press Ctrl+E, choose IDML, and you’re done.

The problem starts when you receive an InDesign Book (.indb) instead of a single file.

Why InDesign Books turn this into a bottleneck

A Book file is just a container for multiple .indd files.

If a book contains 20 documents, you now have to repeat the same export process 20 times.

What used to take seconds becomes minutes — and in large multilingual projects, that happens for every language.

This is where a simple file format requirement quietly turns into a production bottleneck.

Why manual export does not scale

Once the number of files increases, a more dangerous problem appears: human error.

One file forgotten
One export skipped
One outdated IDML sent to translation

If you catch it early, you lose time.
If you notice it at delivery, you have a real problem.

This isn’t a matter of being careful.
It’s a structural issue: repetitive manual work breaks at scale.

The automation approach

The fix is straightforward:
Let InDesign do the repetitive work for you.

By using a script, you can export all open .indd files to .idml in one operation — consistently, repeatably, and without missing anything.

A simple example script

Here is a minimal version of the script I use in production.
It exports all open InDesign documents as IDML files into the same folders as the originals.

The full script file is attached to this post.
License: MIT. Use at your own risk.

Want the ready-to-use version?

Skip the copy-paste and download the script directly from Gumroad.

Download on Gumroad (Free) →


function exportIDML()
{
    // Check if any documents are open
    if (app.documents.length == 0){
        alert("No documents to process");
        return;
    }
    
    // Confirmation dialog
    var result = confirm("Export all open documents as IDML files?\n\nIDML files will be saved in the same location as the original documents.");
    
    if (result == false) {
        alert("Process cancelled.");
        return;
    }
    
    var docObj = app.documents;
    var successCount = 0;
    var failCount = 0;
    
    // Process each document
    for(var z=0; z<docObj.length; z++) {
        
        // Skip unsaved documents
        if (docObj[z].saved == false) {
            alert(docObj[z].name + "\n\nThis document has not been saved.\nPlease save the file before processing.");
            failCount++;
            continue;
        }
        
        try {
            // Set object style default to "None"
            docObj[z].pageItemDefaults.appliedTextObjectStyle = docObj[z].objectStyles[0];
            
            // Get file path (save as .idml in the same location as original file)
            var originalPath = docObj[z].fullName.toString();
            var idmlPath = originalPath.replace(/\.indd$/i, ".idml");
            
            // Export as IDML file
            var exportFile = new File(idmlPath);
            docObj[z].exportFile(ExportFormat.indesignMarkup, exportFile, false);
            
            successCount++;
            
        } catch(e) {
            // Display error details
            alert(docObj[z].name + "\n\nExport failed.\n\nError details:\n" + e.message + "\nLine: " + e.line);
            failCount++;
        }
    }
    
    // Display process summary
    var summary = "Process completed.\n\n";
    summary += "Successful: " + successCount + " file(s)\n";
    if (failCount > 0) {
        summary += "Failed: " + failCount + " file(s)";
    }
    alert(summary);
}

// Run script
exportIDML();

This is intentionally simple.
It shows the core idea: remove humans from repetitive format-conversion tasks.

What this looks like in real production

In actual multilingual workflows, IDML export is only one step.

In practice, I run this as part of a larger automation package that also handles things like:

Updating linked artwork
Reloading paragraph and character styles
Reloading master pages
Normalizing document settings before translation

Those pieces belong in separate posts, but the principle is the same:
If a task must be done for every file and every language, it should not be done by hand.

If you haven’t seen it yet, check out our previous post on automating InDesign text overset:
→Scaling Multilingual DTP by Eliminating Manual InDesign Text Overset Fixes

Scaling Multilingual DTP by Eliminating Manual InDesign Text Overset Fixes

2026-01-03T23:35:00.000Z

Update: Overset Fixer Pro is now available on aescripts. Now supports installation via aescripts Manager.

Are you struggling with text overset after translation?

If you work in multilingual publishing, you’ve probably run into this problem more times than you can count.

I’ve spent over a decade working across translation agencies and in-house manufacturing environments, using tools like Trados on a daily basis. One recurring bottleneck has always been post-translation DTP—especially text overset in InDesign.

When you translate from Japanese into English, or from English into languages like German or Russian, text expansion is almost inevitable. Layouts that worked perfectly in the source language suddenly break, and text starts overflowing frames.

Why text overset becomes a real problem in multilingual layouts

For main body text, overset can sometimes be mitigated by threading text frames and letting content flow into the next frame. That works to a point.

Captions are a different story.

Captions usually live in fixed-size frames. They’re often positioned tightly near figures or diagrams, and they don’t have anywhere to flow. Even for main text, many projects require the translated layout to match the original layout exactly, which means manual adjustment is unavoidable.

Individually, these fixes feel trivial. Five minutes here, five minutes there.

But multilingual production changes the math completely.

A task that takes five minutes in one language turns into nearly two hours when you’re dealing with 20 languages. And that’s before reviews, corrections, or last-minute changes.

This is how small, “simple” tasks quietly consume entire days.

Common workarounds — and their limitations

One approach I’ve seen is to avoid translating captions altogether by converting them into numbered references. Instead of translating each caption, you translate a list of numbered descriptions elsewhere.

In theory, this reduces layout issues.

In practice, it introduces new problems:

The document structure has to be changed
Numbering mistakes become a real risk
Many clients reject this approach due to readability concerns

For many projects, altering the document structure simply isn’t an option.

Automating the problem instead of redesigning the document

Rather than changing how documents are written, I chose a different approach: keep the document as-is and automate the cleanup.

I built a script that detects and resolves text overset directly in existing layouts, without requiring manual frame-by-frame adjustments. The goal wasn’t to create a “clever” solution, but a practical one—something that actually fits real production workflows.

If you’re dealing with overset text repeatedly across multiple languages, this kind of automation quickly pays for itself.

I refined Overset Fixer Pro through real-world production challenges to ensure it’s reliable and efficient. If you’re looking to reclaim your time from repetitive manual fixes, this tool is built for you.

To make this approach actually usable in real workflows:

Automate overset fixes instead of handling them manually.

Use the full version of Overset Fixer Pro with a streamlined installation process.
Choose your preferred platform below.

Download on aescripts → Download on Gumroad →

Final note

Text overset isn’t a skill issue. It’s a structural problem that appears whenever language expansion meets fixed layouts.

Once you look at it that way, automation stops being optional and starts becoming the only scalable solution.

When Times New Roman Suddenly Vanished from InDesign

2025-11-22T23:05:00.000Z

Recently at work, I ran into a strange and frustrating issue in Adobe InDesign:

Times New Roman suddenly started appearing as an unsupported font.
This happened completely out of the blue — the same documents had been fine just a few days earlier.

After some trial and error, I came to suspect that this wasn’t an InDesign issue at all, but a Windows-side problem. It seems that a recent Windows Update may have updated the Times New Roman files, and as a result, InDesign was no longer able to recognize the updated version properly.

I even tried writing a script to automate the font replacement, but it didn’t help. Because the font name technically matched, InDesign didn’t treat it as something that could be substituted cleanly.

At this point, the only reliable method is to fix the fonts manually — either by using “Find/Replace Font” in InDesign or by updating the font settings in each paragraph or character style one by one.

A workaround for urgent situations

One workaround did help when I needed a quick fix:

If I had another InDesign project that had been packaged before the issue occurred, the “Document fonts” folder often included older Times New Roman font files.
By copying that folder and placing it in the same directory as the problematic INDD file, InDesign was able to display the fonts correctly again.

It’s not a fundamental solution, and it doesn’t address whatever is happening at the system level, but it’s a surprisingly effective emergency measure when the document needs to open correctly right now.

I hope this note helps anyone facing the same sudden Times New Roman issue.

Close All InDesign Files with One Click: A Script for Busy Designers

2025-06-29T01:00:00.000Z

As a technical writer and InDesign user, I often find myself working with a large number of open InDesign files at the same time.
You might know the feeling—at the end of a busy day, you just want to close everything quickly and call it a day.

Of course, you can always use Ctrl+Q to quit InDesign entirely. But then, when you want to get back to work, you have to launch InDesign all over again, which can be a bit of a hassle, especially if you need to continue working right away.

That’s why I created this simple script. It allows you to close all open InDesign documents with a single click—but it leaves InDesign itself running, so you can stay in your workflow.

When I shared this script with my colleagues, it got some surprisingly positive feedback!
It’s a small, handy tool, so I’ve decided to make it available to everyone for free.

#target indesign

try {

var docs = app.documents;

for (var i = docs.length - 1; i >= 0; i--) {

var doc = docs[i];

if (doc.saved) {

doc.close(SaveOptions.yes);

} else {

// Skip (do not close unsaved documents)

}

} catch (e) {

alert(e);

}

var flag = confirm("Do you want to close all open Books as well?");

if (flag == true) {

while (app.books.length > 0) {

app.activeBook.close(SaveOptions.yes);

}

How it works:

The script closes all open InDesign documents that have already been saved.
If there are any unsaved documents—such as newly created files or files right after format conversion—they will be skipped (left open) to prevent accidental data loss.
Please be aware of this limitation!

After closing the documents, the script will also ask if you want to close any open Books. If you confirm, all open Books will be closed as well.

Tested Environment

This script was tested with the Windows versions of InDesign CC 2023 and 2024.
It should also work with other recent versions of InDesign, although I have not verified every version.
I have not tested it on Mac OS, but it should work there as well.

How to Use

Download the script (see below).
Place the file in your InDesign Scripts folder.
Double-click the script in the Scripts Panel in InDesign to run it.

Download

Download the script here (closeAllDocsAndBooks_saved.jsx)

Final Note

I hope this little tool saves you some time!

Rename Linked Files Easily in InDesign

2025-06-26T23:32:00.000Z

This post is about a paid script for Adobe InDesign.

1. Introduction

Renaming linked images in Adobe InDesign can be tedious — especially when they appear in multiple documents.

To solve that, I’ve created a small script that renames and relinks files with just one prompt.

2. What the Script Does

This script automatically:

- Renames the selected linked image file

- Updates all instances of the image across open documents

- Keeps folder structure and file formats intact

It’s designed to save time and reduce mistakes during layout editing.

3. When It’s Useful

This tool is ideal for:

- Designers cleaning up image names before final delivery

- Working with reused layouts or multi-language versions

- Anyone who edits InDesign documents with linked assets regularly

4. How to Use It

1. Open your InDesign file(s)

2. Select a linked image

3. Run the script

4. Enter a new name → Done!

The script will rename the file and update all links to it.

5. Try it now

🔗 Get it here: https://linguistcoder.gumroad.com/l/fmvyiq

💸 Price: $7

📂 File includes the script and README

Automatically Replacing Helvetica Fonts in Adobe InDesign with a JavaScript Script

2024-03-30T21:44:00.000Z

As of January 2023, Type1 Helvetica fonts are no longer usable in Adobe InDesign...

This has been a headache for the company I work for.

To mitigate this problem, I created a JavaScript script that automates the process of replacing Helvetica fonts with Arial fonts in Adobe InDesign documents.

#target indesign

(function () {

// Helvetica → Arial mapping

var FONT_MAP = {

"Helvetica\tMedium": "Arial\tRegular",

"Helvetica\tBold": "Arial\tBold",

"Helvetica\tBold Oblique": "Arial\tBold Italic"

};

if (app.documents.length === 0) {

alert("No InDesign document is open.");

return;

}

* If multiple documents are open:

* OK = process all open documents

* Cancel = process only the active document

var documentsToProcess = [];

if (app.documents.length > 1) {

var processAll = confirm(

"More than one document is open.\r\r" +

"Click OK to process all open documents.\r" +

"Click Cancel to process only the active document."

);

if (processAll) {

for (var i = 0; i < app.documents.length; i++) {

documentsToProcess.push(app.documents[i]);

}

} else {

documentsToProcess.push(app.activeDocument);

}

} else {

documentsToProcess.push(app.activeDocument);

}

// Make sure that all replacement fonts are available before editing.

var missingReplacementFonts = getMissingReplacementFonts();

if (missingReplacementFonts.length > 0) {

alert(

"The script cannot continue because the following replacement " +

"fonts are not available:\r\r" +

missingReplacementFonts.join("\r") +

"\r\rInstall or activate these fonts and run the script again."

);

return;

}

var proceed = confirm(

"This script will replace selected Helvetica fonts with Arial in:\r\r" +

getDocumentNames(documentsToProcess).join("\r") +

"\r\rThe documents will not be saved automatically.\r" +

"It is recommended that you work on backup copies.\r\r" +

"Continue?"

);

if (!proceed) {

return;

}

app.doScript(

function () {

var result = {

paragraphStylesChanged: 0,

characterStylesChanged: 0,

unsupportedHelveticaStyles: [],

errors: []

};

for (var d = 0; d < documentsToProcess.length; d++) {

processDocument(documentsToProcess[d], result);

}

showReport(result);

ScriptLanguage.JAVASCRIPT,

undefined,

UndoModes.ENTIRE_SCRIPT,

"Replace Helvetica styles with Arial"

);

function processDocument(doc, result) {

* These collections include styles inside style groups.

var paragraphStyles = doc.allParagraphStyles;

var characterStyles = doc.allCharacterStyles;

processStyles(

doc,

paragraphStyles,

"Paragraph style",

"paragraphStylesChanged",

result

);

processStyles(

doc,

characterStyles,

"Character style",

"characterStylesChanged",

result

);

}

function processStyles(doc, styles, styleType, counterName, result) {

for (var i = 0; i < styles.length; i++) {

var style = styles[i];

try {

if (!style.isValid) {

continue;

}

var sourceFontName = getAppliedFontName(style);

// A blank value normally means that the style inherits its font.

if (sourceFontName === "") {

continue;

}

if (FONT_MAP[sourceFontName]) {

var replacementFont =

app.fonts.itemByName(FONT_MAP[sourceFontName]);

style.appliedFont = replacementFont;

result[counterName]++;

} else if (isHelveticaFont(sourceFontName)) {

addUnique(

result.unsupportedHelveticaStyles,

doc.name + " | " +

styleType + ": " +

getStylePath(style) + " | " +

sourceFontName.replace("\t", " — ")

);

}

} catch (error) {

result.errors.push(

doc.name + " | " +

styleType + ": " +

getStylePath(style) + " | " +

error.message

);

}

function getAppliedFontName(style) {

try {

var appliedFont = style.appliedFont;

if (

appliedFont === null ||

appliedFont === undefined ||

appliedFont === NothingEnum.NOTHING

) {

return "";

}

* appliedFont can return either a Font object or a string.

var fontName;

if (typeof appliedFont === "string") {

fontName = appliedFont;

} else if (appliedFont.isValid) {

fontName = appliedFont.name;

} else {

return "";

}

* A Font object's name normally contains:

* family name + tab + style name.

* If only the family name is returned, append fontStyle.

if (fontName.indexOf("\t") === -1) {

var fontStyle = getFontStyleName(style);

if (fontStyle !== "") {

fontName += "\t" + fontStyle;

}

return fontName;

} catch (error) {

return "";

}

function getFontStyleName(style) {

try {

var fontStyle = style.fontStyle;

if (

fontStyle === null ||

fontStyle === undefined ||

fontStyle === NothingEnum.NOTHING

) {

return "";

}

return String(fontStyle);

} catch (error) {

return "";

}

function isHelveticaFont(fontName) {

return (

fontName === "Helvetica" ||

fontName.indexOf("Helvetica\t") === 0

);

}

function getMissingReplacementFonts() {

var missing = [];

for (var sourceFont in FONT_MAP) {

if (!FONT_MAP.hasOwnProperty(sourceFont)) {

continue;

}

var replacementName = FONT_MAP[sourceFont];

var replacementFont = app.fonts.itemByName(replacementName);

if (!replacementFont.isValid) {

addUnique(missing, replacementName.replace("\t", " — "));

}

return missing;

}

function getStylePath(style) {

var names = [style.name];

var parent = style.parent;

while (

parent &&

parent.isValid &&

parent.constructor &&

(

parent.constructor.name === "ParagraphStyleGroup" ||

parent.constructor.name === "CharacterStyleGroup"

)

) {

names.unshift(parent.name);

parent = parent.parent;

}

return names.join(" > ");

}

function getDocumentNames(documents) {

var names = [];

for (var i = 0; i < documents.length; i++) {

names.push(documents[i].name);

}

return names;

}

function addUnique(array, value) {

for (var i = 0; i < array.length; i++) {

if (array[i] === value) {

return;

}

array.push(value);

}

function showReport(result) {

var message =

"Font replacement completed.\r\r" +

"Paragraph styles changed: " +

result.paragraphStylesChanged + "\r" +

"Character styles changed: " +

result.characterStylesChanged;

if (result.unsupportedHelveticaStyles.length > 0) {

message +=

"\r\rHelvetica styles found but not replaced:\r" +

result.unsupportedHelveticaStyles.join("\r");

}

if (result.errors.length > 0) {

message +=

"\r\rErrors:\r" +

result.errors.join("\r");

}

message +=

"\r\rThe documents have not been saved automatically." +

"\rCheck text reflow and overset text before saving.";

alert(message);

}

})();

The script operates by checking if more than one document is open in Adobe InDesign and asking the user if they want to apply font changes to all open documents. Depending on the user’s choice, it then iterates through each document, replacing instances of Helvetica Medium, Helvetica Bold, and Helvetica Bold Oblique with their Arial counterparts.

Linguist Coder

Missing Footnotes, Empty Table Cells, and Stale Index Pages After IDML Translation

First check whether the content was extracted

In this Okapi test, an empty target merged without a warning

Check whether the index page was regenerated

Do not confuse this with overset text

What to check before you sign off

Related

How to Check a Translated InDesign File in a Language You Cannot Read

First, confirm the container survived

Compare agreed strings and values

Search the target for your own language

Look for text you cannot see

If you have reference strings, use them

What none of this tells you

What to ask the vendor for

The order

Related

Why IDML Formatting Can Produce Translation Tags, and What to Check in InDesign

Where the tags in an IDML come from

Which formatting changes create a range boundary

Why a tag appears in the middle of a word

Which source formatting to keep or clear before export

How to find and clear the overrides in InDesign

What cannot be removed

If you are the translator

Related

Comparing InDesign Files After Translation: What to Check

What "compare" means after translation

What a PDF comparison shows

What Track Changes shows

What the CAT tool shows

Before you start: which two files

A checklist you can run by hand

Related

Seeking Testers: Comparing IDML Files Before and After Translation

Why I'm building this

What the tool checks

Getting the trial

Two limits to know before you try it

How to send feedback

Where an InDesign Script Should Stop

A Row It Could Grow, and Doesn't

One Lever at a Time

Saying What Happened When It Stops Short

The Limit That Was Not Real

The Pattern Underneath

Related

Your Second InDesign Script: Condensing Text Until It Fits

One number, one typographic decision

The overset text is not in the frame

The loop needs a second exit

The floor is not a safety hack

What "putting it back" can and cannot mean

The script

Where this stops working

What the two scripts are for

InDesign Will Not Warn You About External Links

Two Kinds of Bad Link, and InDesign Only Names One

What "External" Means Here

The Panel Shows You a Name, Not a Relationship

Package Fixes the Handoff, Not the Working Document

This Is a Low Judgment Check

Consolidation Is Four Operations, Not One

The Script

Related

Your First InDesign Script: Which Pages Have Overset Text?

The one property that does the work

Running a script at all

Step 1: ask one frame

Step 2: ask every page

The script

What I left out, on purpose

Where the script stops seeing

Next

When InDesign Fails to Export: Start by Finding the Broken Page

Why diagnosis should come before repair

First, rule out the environment

Common causes, once it is the document

Why a script can't do this whole job unattended