Sidequest: How Claude Reaches Into InDesign and Moves Your Drop Caps

Cold open

Claude never touches InDesign's screen. It writes a short program in InDesign's own built-in scripting language, asks macOS to pass that program to the running InDesign, and InDesign runs it on your open document as if you had picked it from the Scripts panel.

What happened on the page tonight

You had the literary map centerfold open in InDesign, the file with all the quotes set in odd-shaped text frames. The Lotten byline had a drop cap with a gap next to it. Claude worked out that the gap came from the alignment. You said the font was supposed to be different, so it put the L back into Patrick Hand in Plommon. Then you asked for the same treatment on Verner von Heidenstam, and a two-line orange V showed up in your window. Each time it told you the change was live but not saved, and that one Undo would take it back.

You never saw a mouse move, and nothing was exported and re-imported. So what did happen?

The four hops

Hop 1. Claude writes a small text file in the session's scratch folder. The language is ExtendScript, Adobe's own dialect of JavaScript. It is about as old as the late 1990s: no modern conveniences, but every Adobe desktop app since the early 2000s has carried an engine for it. The Heidenstam script is about 20 lines long.

Hop 2. Claude runs a terminal command called osascript. That is the Mac's command-line door into AppleScript, and through it into Apple Events, the old macOS plumbing that lets one program send another program an instruction. The message amounts to: "Adobe InDesign, please run this file, and the language is javascript." The parmaps builder does it with that exact line.

Hop 3. InDesign receives the message, starts its scripting engine and runs the file inside itself. This is the important part. The script is not clicking menus or simulating keystrokes. It talks to InDesign's object model, which is a family tree of the document. The application holds documents. A document holds text frames. A text frame has a story. The story has paragraphs, and the paragraphs have characters. Every one of those has properties you would normally set in a panel: justification, drop cap characters, drop cap lines, applied font, fill colour.

So the Heidenstam script did roughly what you would do by hand, only by name. It found the open document called litmap for cc, walked through every text frame, and picked the one whose story contains "Verner von Heidenstam". It found the byline paragraph inside it and wrote down the current settings so it could report them. Then it set the drop cap to 1 character over 2 lines and set the alignment to left. Last, it gave the first letter the same font and colour as the second letter, which is how the V ends up in the byline's own Patrick Hand and orange without anyone typing a font name.

Hop 4. The script's last line is a short message, something like "ok, here is what it was before, and overflows is false". InDesign hands that string back through osascript, and it lands in Claude's terminal as the tool result you saw scrolling past. That is how Claude knows the frame did not overflow.

How Claude sees the result

A string saying "ok" is not the same as seeing the page, and Claude does not trust "ok" without looking. The same script tells InDesign to export page 1 as a JPEG at 200 dpi into the scratch folder. Claude crops it and opens the image to check with its own eyes. That was the Read of heid dot png in the excerpt. So the full loop is: write the script, send it, read the reply, look at the picture.

Why one Undo takes it all back

This is the elegant bit. Claude does not run the edit directly. It wraps it in InDesign's own "run this as a script" call with two extra arguments: treat the entire script as a single undo step, and give that step a name. So your Edit menu shows Undo "Heidenstam drop cap" instead of 6 separate little undos for alignment, font, colour and so on. The undo history belongs to InDesign, so Claude needs no backup copy or snapshot of its own.

It also explains "live but not saved". The script edits the document in memory, in the window you are looking at. Saving is still your keystroke. Claude is the colleague who leans over and changes the setting, and you decide whether it stays.

Why your own tweaks did not break it

You said you tweaked the result afterwards and it still held. That makes sense, because Claude did not fake a drop cap. It did not draw a big V in a separate frame and nudge it into place. It switched on InDesign's real drop cap feature with real settings. Once the script finished, InDesign's own text engine owned the result. You were editing a normal paragraph with a normal drop cap, just as if you had set it in the Paragraph panel yourself.

That is the general principle: a script that sets the application's own properties leaves you a file that behaves normally. A script that imitates the look with extra objects leaves you something fragile.

Where this already lives in the estate

The method came over from parmaps today. A note in pargrafik's inbox describes it. Parmaps used it to build the whole litmap document from scratch: Python worked out the Voronoi districts, angles and font sizes and wrote them to a layout file. An ExtendScript then had InDesign build the layers, a text frame shaped like each district, and the ring of quotes on a path. Parmaps borrowed the mechanism from imagelab's peel tool, which has an option to output an InDesign file. So the estate now has 3 uses: imagelab, parmaps, and tonight's live surgery on your open window.

That note also lists the traps, and they show what talking to a 25-year-old scripting engine is like. Telling it to work in millimetres makes it read point sizes in millimetres too. Exporting a preview marks the document as modified. And when something fails, osascript tends to report only "Object is invalid", with no hint of which object. So a careful script catches its own errors and reports the line number itself. Clearly an engine built for patient print people.

The limits

It only works on this Mac, with InDesign running and the fonts installed. It cannot reach the copy of InDesign in the cloud, because there is no such thing. Adobe also has a newer scripting system called UXP, which is slowly replacing ExtendScript. For now the old one is still built in and still does the job, and every Adobe forum answer from the last 20 years is written for it. Claude has read all of them, unfortunately.

If you remember one thing: Claude edits InDesign by handing it a small program in its own scripting language through the Mac's Apple Events. That program changes real document settings, which is why one Undo removes it and why your own edits afterwards behave normally.