Free Script Identifies Word Stacks
At the 2015 Print and Electronic Publishing Conference (PePcon) last week, the InDesign developer and scripting community that was attending the concurrent Creative Developers Summit offered to write a “people’s choice” script based on ideas from attendees before and during the conference. I submitted the idea for a script to identify multiple lines that end in the same word, since I’ve heard frequent requests for this capability from the InDesign community.
Within 24 hours of making the suggestion, Kris Coppieters of Rorohiko Workflow Resources not only produced the first working draft of the script, but had exceeded my request with additional capabilities. He has since put the finishing touches on the script, and you can download the free “SmokeWordStacks” script here.
When you run the script, a dialog box appears that lets you control what type of “stacks” to search for.
The SmokeWordStacks script gives you control over what types of “stacks” to search for
When you click OK, the script creates a Character Style named “Text Stack” and applies this character style to any word stacks that it finds. The Character Style has a thick red underline, so it is easy to spot the word stacks.
The thick red underline makes it easy to visually spot the word stacks
Or, better yet, do a find/change to locate each occurrence of text formatted with the Character Style. Tip: Search backward from the end of the document, since fixing a word stack may cause reflow.
Choose Edit > Find/Change to easily locate all text with the Character Style “Text Stack” applied.
You will need to fix the word stacks manually, but this script sure is a huge help in locating them!
The behavior of the script is extremely configurable by tweaking settings in the well-documented “SmokeWordStacks.ini” file that accompanies the script.
Kris is a brilliant scripter and an all-around really nice guy. Consider Rorohiko for your next InDesign scripting, automation, or custom development project. The Rorohiko web site is also a treasure-trove of very useful commercial scripts and plug-ins for InDesign.
 |
Rokohiko might want expand this clever script to catch a host of other layout visual gotchas, including a single short word or part of a word on the last line of a paragraph. Alas, I suspect there is no way to look for ‘rivers’ of white space winding down a page, but it might be possible to tag lines that that wrap so poorly, there’s excessive space between words. That’s particularly true when hyphenation has to be off.
I suspect a make-it-look-good script that caught the most common gotchas would be commercially viable.
We should all thank Adobe for adding backward search. Their developers don’t have unlimited resources. When I lived in Seattle and met with their design team, I made as strong a case as I could for backward search, including for the reason here—that changes to a nearly done document need to be done back to front. I don’t know if my suggestion was the one they took, but it’s certainly a useful enhancement.
Another useful script would be one that offered multiple change options. For instance, some raw text has a mere hyphen when the finished version needs hyphens, N-dashes, M-dashes and even no hyphen at all (when it is an artifact of scanned text with hyphenation. One search-for with multiple change options would save a lot of time. And in the case of hyphens, it’d save a lot of time if the hyphen script could be told to ignore web address, which tend to be full of hyphens that should never be changed.
When Kris showed an early version of this script at PePcon, there was almost a gasp in the audience. Or maybe it was just me gasping that loudly. I don’t know why, but I had made an assumption that this would not be possible, or if it was, that it would be very slow to process. But it’s very efficient and extremely helpful! Thank you, Kris!
Awesome for book makers ! Thank you.
Kris once again is my hero! This is a FANTASTIC script. Wish I’d had this years ago. Many thanks, Kris!!
This is wonderful! In the textbooks I work with, I can always count on the proofreader marking at least one of these for manipulation. There are lots of parallel constructions in textbooks. But in other books, if I don’t catch it, it’s not the kind of thing that most authors will mark. Now I can rest easy, knowing that I’ve caught ALL of them, even if I have to run the script more than once. Thank you, Kris.
Makes me want to break out a long document just to convince myself it is not magic . . .
Completely brilliant, incredibly useful, and oh, my, what a good time for this to come along when I’m up to my earballs in book text!
Kris is one of the nicest people you ever want to meet, and what he does for the InDesign community is amazing. That so much of it is seemingly off-the-cuff, with a casual “Is this what you were looking for? I made it while I was waiting for the cab to arrive,” blows everyone’s minds. Except his. Lightning Brain, indeed… :-)
Keith, thanks for sharing this. I recently posted an article about a GREP to handle placeholder marker with comments in a bright color that is easily noticed.
By setting the GREP’s character style color to overprint fill, then adding overprint fill to my preflight settings, I can easily identify where this information is missing. See subheading Grep Example #1: Placeholder in https://i.sligh.us/?p=126
I modified the character styles in Kris Coppieters’ INI to include overprint fill so they are now included in my preflight workflow.
That will script will definitely come in handy. Thanks, Kris.
Cool script! I tested it in CS5.5 and it worked there, too.
Thanks again, Kris, for another fantastic freebie!
I don’t follow the logic of working backwards here. Let’s say you’ve got a couple of stacks within a single paragraph. If you work backwards, you’ll fix the last stack in the paragraph. Then you’ll go back and fix the first. But by fixing the first stack, the rest of the paragraph could reflow, and perhaps (a) it would no longer have been necessary to fix the second stack in the first place; or (b) the reflow has a created a new stack later on in the paragraph which you will never get to if you’re working strictly backwards!
Similar problems can occur even if the two stacks are in separate paragraphs.
Ariel: Keith was talking about working backward from the end of the document, not each paragraph. It’s just an old typesetters’ trick. If you’re making changes throughout a document, start at the end because as you make changes it will reflow from that point onward.
I’m aware of the idea of working backwards: use it all the time myself.
However, thinking about it carefully, I don’t see how it’s relevant here. If we’re concerned with reflow, that will happen even if you’ve worked backwards, and therefore any fixes that may have been made further on in the document (and earlier in time) could be rendered redundant. Also, because of the reflow, new stacks may have been introduced later on in the document, beyond the point where one is currently fixing the stacks!
I’ve never found working backward to be practical. Because anything you do could still affect what comes after, but not what comes before.
I understand the idea of it, but it never really seems to be practical.
No matter how “automatic” the fix is, you still need to look at all the line and page breaks anyway when doing this kind of work. So, working from the front back still makes the most sense to me in real-world usage. That way you can adjust anything you need to as you go along, with confidence that nothing you do will cause further changes to text higher up the chain.
Matt: One example where working backwards definitely helps, is when I’ve got a long list of corrections to make to a document. If the corrections are listed according to page numbers and line numbers (https://www.id-extras.com/products/line-numbers ;-) ), then if I work forwards, very soon that list of page numbers and line numbers will be out of sync and plain wrong. But if I work backwards, the remaining page numbers and line numbers remain accurate.
Working backward is relevant if you are making large text changes, because it makes it harder to identify where the next textual change went to when examining galleys in relation to the new positioning caused by adding or removing paragraphs. The larger the text flow and textual changes the more text moves around. Working backward means the changes only affect text with which you have already dealt.
In this instance I think Matt is right. Starting from the front makes the most sense. Any changes you make might, or might not, remove a word stack further down in the text.
A very nice script indeed. Thanks Kris for writing this. It is something that was much needed by almost every designer but never raised off. Anyway thanks for sharing it. It is definitely going to save a lot of time.
I just thought of something while testing the script in InDesign CS6. All the options were working fine. What I noticed it that the script creates a character style and apply it to the problem areas. Would it be possible for making something non-printing instead of the character style to avoid printing the underlines by mistake. It is easy to delete the character style but what if someone forgets to do so?
Masood,
I was thinking the same thing. Maybe instead of applying a character style, it can insert an InDesign comment. Something like “Stacked Word “INSERTWORD”. Then you could go through and make the changes if necessary.
Understanding the situation that this script was created in, I think it is fantastic. If Kris were to consider creating a “Pro” version, im sure we could think of many things to add.
This script will save hours over the life cycle of creating long documents. Brilliant! Thank you.
Our team was blown away when I showed them the results of this script. All the time we have spent poring over proofs searching out stacks!
Has anyone tried editing the script as the developer describes in the Read Me file? I would love to customize it, but I get error messages in InDesign when I try. Does one edit the .ini file and save it as .jsx, to start with?
Alicia,
I haven’t worked on this script myself but I believe that you just make any changes you want to the .ini file and keep it named the same way, so the script can find it and reference your parameters from it.
So, no, you do not save it as a .jsx file. The .ini file is not the script; it is just a list of settings for the script to use.
Does that make sense?
Thank you, Matt! That worked like a charm–exactly what I needed to know. I appreciate the help very much.
This sounds like the greatest script for me. I’ve always found this to be one of the most laborious parts of my job when going through a doc looking for stacks.
However i haven’t had much luck with it because when I install it and run it I don’t get the dialogue box options. Just a “ok” and “cancel” option.
I’m on ID CC 11.0.1.105.
Has anyone else experienced this? Any ideas would be greatly appreciated.
Hi Benjamin,
I had exactly the same problem with running the script for the first time ;) I suppose you’ve already figured it out, but I think it might be worth to share the information here: you just have to have the associated .ini file in the same folder as the file of the script itself. It is written in the ReadMe.txt also :)
Good one !!!!!