“Today’s guest blogger is Paul Starr, a Japanese translator who turned to InDesign scripts when he started editing Japanese comics. This is the first in a series of articles about people who to code primarily to automate Adobe’s products, without a Computer Science degree.”
— Erin Finnegan, Community Engineer, Adobe
I’m an editor at Kodansha USA. My team’s job is to oversee the publication of hundreds of volumes of manga — Japanese comics — every year for the English-language market. This involves the translation, lettering, and editing of thousands of comic pages every month. The combination of our high book volume, the variability of the art assets we work with, and the specific quirks of the manga form made it a tempting target for automation.
There was a catch
I…couldn’t, strictly speaking, write code. My programming background is weak, at best. I took a year of computer science in high school, where I learned Pascal, which might give you a sense of when I went to high school. Every five years or so since then, I’d get tempted to write some small script or program, and give up a few hours into the work after becoming too impatient with my lack of knowledge and skill when trying to accomplish something that seemed like it ought to be simple.
The Adobe Developers blog posts covering CEP basics were enormously helpful: Steve Kwak’s How To Create Your First Adobe Panel, Davide Barranca’s CEP Panels and JSON Objects, and Erin Finnegan’s Debugging your Adobe Panel. Additionally, Tom Scharstein’s enthusiasm for the front-end panel code in general, and Vue.js in particular, convinced me to push out of my comfort zone in ways that were very rewarding.
I have used Gregor Fellenz’s transformation of Adobe’s official Indesign ExtendScript API documentation more or less constantly while working on InDesign scripts, and the archives of the official InDesign Scripting Forums have been enormously instructive when I’ve been looking for practical examples of how the API is put to use.
Toggling Binding Direction
The most immediately notable quirk of our books is that nearly all of them read backwards — that is to say, right-to-left. (Editor’s note: Until the early 2000’s, many Japanese comics were “flopped” to read in the American right-to-left direction, until some enterprising comic publishers discovered it was cheaper to let fans read the comics as-is, left-to-right.) Sometimes we receive files with a right-to-left binding direction, but more commonly the books are simply paginated backwards, with page numbers placed manually.
InDesign handles right-to-left binding direction just fine, but the US version doesn’t expose that particular function by default. Nevertheless, it’s still present in the document’s preferences. I wrote a script to toggle the current document’s binding direction between left-to-right and right-to-left, and it’s even a one-liner if you use the ternary operator
? : like so:
Matching Art Frames to Bleed Size
The raw art assets we work with often don’t have consistent pixel dimensions, so after being placed on the pages, they need to be nudged into the correct position. As far as I know, there’s no way to entirely get around doing this manually, but a script to automate the re-placement of the frame containing the art is very useful.
Such a script needs, ideally, to work on books with arbitrary trim sizes, and to align the frame to the page’s bleed — which in our books is 9 points (i.e., ⅛")on every outside edge. I found it convenient to use points as a measurement unit, so the script begins with:
app.scriptPreferences.measurementUnit = MeasurementUnits.POINTS;
The key logic involves setting the art box dimensions to match the dimensions of the page it’s on, plus 9 points in every direction except the gutter. Here’s an example:
I quickly discovered that I would need extra logic to account for both right-to-left and left-to-right binding directions — but since I’d already written the binding reversal script, I knew how to check for binding direction:
There was a maddening bug that happened seemingly at random. In certain documents, on right-side pages only, the command would fail to place the frame currently. It took days of debugging to discover that the math the script uses to work out the bounds of the box is dependent on the page’s ruler origin being per-spread, rather than per-page. If the document happened to have its ruler origin set to the page, the script became unreliable. Once I figured this out, it was straightforward to add a line at the beginning of the script to set the ruler correctly:
app.activeDocument.viewPreferences.rulerOrigin = RulerOrigin.SPREAD_ORIGIN
This script assumes that art is always on the bottom layer of the document, and that the bottom layer only contains page art. For some books, this might be a dangerous assumption to make, but for our books it hasn’t proven problematic.
Overall, this turned out to be a more subtle problem than I’d expected, however, some days I run this script hundreds of times, so it was well worth the time I spent puzzling over it.
Quick Export of Current Page for Proof Corrections
Our workflow involves receiving a bound proof from the printer, and if we need to make further corrections, the corrections need to be returned as individual single page PDFs. Additionally, no matter the binding direction of the InDesign documents that generated them, our print-ready right-to-left-reading PDFs need be ordered last-page-first. This makes it laborious and error-prone to work out which InDesign document page corresponds to which sequence page in the bound proof; the sequence number (again) depends on whether the document has been set up right-to-left or left-to-right.
I wanted to be able to quickly export a PDF of whatever page I was currently working on, with the correct printer sequence number in the filename, irrespective of binding direction. Here’s the script I came up with:
Mapping this script to a keyboard shortcut has saved me hours of time and aggravation.
Creating Translation Note Thumbnails
We often include translation notes in the back of our titles to explain cultural references or linguistic nuances, and readers consistently appreciate this extra material. It’s very handy to be able to refer to a thumbnailed detail of each page being discussed in the endnotes, but assembling this manually is laborious.
To speed up the process, I wrote a script for the letterer or editor to run after selecting all the art and text frames that will appear in the thumbnail. The script then copies the selection, groups it, and cuts it to the clipboard. Then it creates a new frame, pastes the grouped objects into the frame, and cuts that frame back to the clipboard. From there, it’s ready to be pasted into the translation notes. For good measure, I added logic that creates or applies an appropriate object style to the container frame.
These relatively simple scripts have put a respectable dent in the most egregiously repetitive aspects of my manga editorial workflow — I’ve saved dozens of hours, certainly — but there’s much more that could be done. I’m currently working on a CEP panel to put a friendlier interface on these tools, and in the longer term, I’m also interested in changes to the translation part of the workflow that could speed up layout and lettering even more.
I’m still working on convincing the comics editors of the world that regular expressions are really, really worth learning about.
I care deeply about this stuff, and I love to talk about it. My contact information is available on my adequate website.
Are you an InDesign scripter with no formal Computer Science background? Let us know in the comments.