I did actually think about making that connection overtly, and then realized that I was going to wind up writing something a lot longer than a post. (Also there's only one person in the thread who's really going to like my solution!)
There are some jobs that I do by hand, stepping through the document page by page. There are other jobs that I automate to the point of "I run a single script, and then it's done." In the middle, there's a lot of room for error. For example, if I don't check the style interitance before I start stepping through the file page by page, then it's disturbingly possible for a change I make to an infrequently-used style on page 200 might cause changes to styles I'd fixed on pages 1 through 199. So it's possible for top-down changes made from style management scripts to actually increase the total format time, over what would have been faster to brute-force with a million clicks. And I can't think of any way to operationalize the process of figuring out which strategy will be less time-consuming.
Much depends on the idiosyncracy of the initial designer, and I have actually found (diverging from your experience) that it's often faster to script a clean-up solution to mop up after someone who used no styles at all, than it is to clean up after someone who used styles inexpertly, or someone who doesn't really get style management using an INDT made by a Style Wizard. There are too many variables for me to make a blanket claim like "only methodical and rigorous methods yield easily to scripted solutions." In fact, if you get preptext and PerfectPrepText up and running, you'll find that completely unformatted Word files that only use Normal parastyle and local formatting become some of your fastest projects. That's what I found, back in the bad old days when people still sent me Word files to format.
As you note, EPUB export from InDesign requires even more careful adherence to good styling than a normal print doc. So in my own personal shoes, I've found that automating a few steps saves me a lot of clicks. I mean, I don't do much EPUB work, but I get it done really fast, because a) I can automate some of the script-based style management, and let's be frank here b) I've read a bunch of your own posts on the matter. But the knowledge I've acquired regarding good EPUB export strategy wouldn't be of much use if I hadn't spent the last years trying to bootstrap myself into writing real code, instead of just duck-taping other people's code and hoping.
But! If you can't write JS, there's no real point in chasing those automation solutions. There isn't going to be a good style management script for the OP, because all such solutions require significant in-house dev expertise to adjust such tools to fit. That's when it's time to look at low-code solutions, for people who are good at thinking logically & programmatically, but who don't know ES3-era JS in the form of Extendscript. For such people, using some kind of low-code or no-code automation tool that has a built-in user community with its own developer to help you build multi-pass solutions where your book cleanup requires many separate steps.
The best candidate I've seen thus far, price-perfomance-wise, is actually Robert's ID-Tasker. You get the no-code/low-code automation, you get the robust user community, you get the private developer to rescue you from situations where you've cornered yourself & don't know enough VB to code your way out of it, and you get it for a price that is much lower than the all-encompassing ID-Server-based solutions that occupy the same market segment.
If you wanted to do more of the heavy lifting yourself, David Blatner's Power Styles does the same kind of auto-style-generation trick as the PerfectPrepText I mentioned earlier, with a predictably large amount of post-script cleanup, and also with the caveat that there will be some kinds of styling where blindly using the script will actually create more work.
30
Replies
AdChoices