I’ve been working on streamlining and automating some tasks related to our weekly work to layout the print edition of the newspaper using Adobe InDesign.
(This is all “make human work more efficient and less tedious” stuff, not “replace humans and lay out the paper with AI” stuff, so move along if you’re only interested in the latter.)
I’ve been surprised at the lack of tools and solutions for small newspaper publications working with these kinds of issues. If you’re a larger corporate publisher there are lots of enterprise-level tools and plugins that you can pay good money for, but that’s not accessible to us. Generally, it feels like Adobe discourages much in the way of tinkering or customizing their tools, and the documentation that is available is pretty tough to work with.
All of the progress we’ve made has been from digging through obscure Adobe user forum threads and hiring a contract developer experienced with Adobe products and the newspaper world to help us get these tools built. So as always, I’m sharing what we’re doing in hopes that it helps others.
Avoiding page editing conflicts
If you have multiple people editing Adobe InDesign files for a newspaper issue, right now it has to happen by having one person open a file at a time. (Adobe says future versions will allow collaborative editing.)
Before I came to the newspaper, this was handled by calling out in the newsroom what page you had open, and/or sending an email to a group of people who might possibly also be editing pages at that time. This approach gave me a nervous eye twitch.
In some server/shared folder environments, Adobe InDesign has lock files that prevent two people from opening the same file at the same time, but this mechanism has not worked in the cloud syncing environments we’ve used, neither Adobe’s own Creative Cloud offering we used previously nor our Nextcloud-based system in use now.
So, we’re using our own InDesign script to generate lockfiles that do work in our environment. I’ve written about that previously:
Now, when someone opens a page, no one else can open it until the original opener is finished.
Generating PDF files of print issues
When we’re done laying out the paper, we generate PDF versions of the individual pages to send to the printer, and we generate a consolidated PDF of the entire issue for archiving and for use in our online e-edition subscription offering.
Generating a single PDF for a single page was previously a multi-click process. Open the file, select the export profile, choose the target filename, export. Generating the combined issue involved a few more clicks to stitch the individual PDF files together and adjust the file size. And if we needed to repeat the process after finding a typo or other issue on pages when doing a final review, the whole thing had to be repeated. This phase of our final production day could represent anywhere from 20 minutes to an hour.
Now, we have an InDesign script that handles this for us with one click. The source code is available on GitHub here. When we’re ready to generate the PDFs, we select the source directory, let the script run for a minute, and the PDFs are there. If we need to re-run it, same thing. Now that 20-60 minute period is just a minute or two. Added up over every weekly production cycle where 3-5 people are waiting for that step to be complete, it’s a nice time savings and it removes some opportunities for human error.
Pulling content from our story database in to InDesign
Right now when we are ready to put a story on the page in InDesign, our layout editor goes to our story database tool, reviews all of the stories ready for placement on that page, and then begins copying and pasting them into article boxes that are manually created on the page. Headlines, subheads bylines are similarly copy/pasted. Photos are also manually brought in to InDesign from either the story database or our shared issue photo directory. Sometimes styles and formatting are lost in the process.
Now, we’re working on a tool that will once again use Adobe InDesign scripting abilities to pull story content and images for a given page from our story database via an API call. This will theoretically allow our layout editor to bring all of the content for a page in to InDesign in one click, with many of the elements placed in boxes that use the appropriate style for what the content is.
I don’t know how much time this will save, but given the long days the layout editing process requires — currently taking place largely over the weekend — even if it’s just a half hour or an hour every week, I’ll consider it a win.
Images appearing in the print edition of the paper require toning (usually in Photoshop) so that they’ll look right when actually printed on the page. This is usually a manual step of adjusting brightness, color tone and other levels. Repeated across every image on every page in the paper, it’s a fair number of clicks every week.
We’re working on droplets for Photoshop that will allow us to drop images into them and then perform B&W or CMYK toning automatically, saving the processed files to a specified destination folder. There will still be an element of human review and refinement in this process as some photos require more intervention than others, but I expect it to save a fair number of clicks and time each week.
That’s what we’ve been working on lately in the realm of layout automation and efficiency. I’ll try to keep sharing tools and scripts as we polish them up, and if you have your own to share, please do!