Some Files Slow to React to Input

[KenWK]

We get files created by someone else, usually they are 300-400 pages all done in one InDesign file. Many times these files are very slow to react to user input. Planting the cursor or double clicking a word to select it can take 3-4 seconds for anything to happen. Once that's been done you can select text with no delay, but as soon as a change is made the to the file, the next time something is selected it again takes 3-4 seconds to respond.

I've Googled a bunch and tried clearing preferences and saving as IDML but to no avail. Recently we received one such file that was actually more than double the number of pages than usual at 926 pages, and again all in one InDesign file.

THAT humongous file does NOT have the slowness problem! I captured and compared all the preference settings from that file with another file that has the slowness problem but there wasn't anything different that seemed like it would affect things, just stuff like superscript size and unit differences.

Any ideas on what causes those maddeningly slow reactions?

[James Gifford—NitroPress · Accepted solution]

Check for any GREP or nested styles, probably in body or other frequently used styles. If, say, body text or frequently used list styles have a GREP style, any change to the document forces a re-check of all such content, which in large documents can take a noticeable amount of time.

[KenWK]

Nailed it, James!! I would not have thought to check that, must take a ton of processing though when it's the main text like that. The larger file without the slowness problem does NOT have any of that GREP insanity.

Apparently in Adobe Caslon Pro they don't like the hang of the lowercase f or the uppercase J and are applying a style with 125% character width after and before respectively. Oy!

Thanks a bunch for respoinding.

[James Gifford—NitroPress]

Boy, there's fussy and then there's... something needing therapy. 🙂

Glad to have nailed it in one.

[Robert at ID-Tasker]

@James Gifford—NitroPress

But when I was saying that GREP Styles might slow down InDesign - everyone was saying that GREP Styles do not affect performance?

[James Gifford—NitroPress]

Not when used judiciously. A filter like this has to process every single character in the style, more or less, multiplied by a metric backload of text. That will certainly cause slowdowns.

[KenWK]

OK, just got another one of these #@*&!ing files! XD

I considered just running those grep search and replaces and removing them from the style, but that'll make quite a mess for the next person that has to work on the files.

Changing the view to fast view doesn't seem to help. Any ideas for mitigaging the affects of this?

Thanks again

[James Gifford—NitroPress]

A faster system, maybe, but I am not sure where the bottleneck is. ID is still a single-core app, but it's possible more RAM (up from 16GB) might improve the repeated processing speed.

You could also disable the GREP style, since it's not changing anything critical  — maybe substitute some null Character Style during editing, then restore it before final save. I guess that depends on how many instances of the style are in use. If all use the same Character Style, just swap (by name) that one for a null, do-nothing style during editing.

[Robert at ID-Tasker]

You could also disable the GREP style, since it's not changing anything critical  — maybe substitute some null Character Style during editing, then restore it before final save.

By @James Gifford—NitroPress

Or remove them completely - then "overwrite" with original version of the ParaStyle.

[James Gifford—NitroPress]

Depends on where the pinch point is. If only one or two Para styles do this, duplicating them, then changing the originals and eventually swapping back the duplicates would be most efficient. If, though, as I suspect, multiple Para styles have this fix, the Char style that implements it for all might be easier to swap out/in.

[Robert at ID-Tasker]

[...] If, though, as I suspect, multiple Para styles have this fix, [...]

By @James Gifford—NitroPress

Yes, if done manually 😉 but even a free script can do it quickly:

app.activeDocument.paragraphStyles.everyItem().nestedGrepStyles.everyItem().remove();

[Robert at ID-Tasker]

@KenWK 

Can you share your file? On priv of course.

[KenWK]

We're making changes to the files for reprinting the book, as such we can't have text randomly re-running, so simply removing the GREP from those styles isn't really an option.

I've been working on a Windows 10 Virtual Machine and tried doubling the memory fore that virtual, which didn't help at all.

Don't think I mentioned that they have just one story for all 400 pages in the book. One thing I noticed getting toward the end of making inserting the changes was that the delay got a bit less. So whatever InD is "looking at," it seems to be looking from the point in the document at which I'm working to the end of the story.

I then wrote a few lines of a script to be able to select a frame and split the story, then did that at the start of all the chapters. It didn't completely eliminaate the problem but it cut the stall times to about 1/2 or even a 1/3 of the time for the stalls, making it at least bearable to work on.

I'm very curious to see what someone else experiences trying to use this file, but I'm very reluctant to send my client's contrent anywhere, especially here on the thread. Is there a way to share it privately?

[Robert at ID-Tasker]

@KenWK

You can click my nickname and send me link to your file privately.