5 to 8 minutes to spell check 50 pages is terrible

[mazdaspeed]

I have turned off every spell check feature except mispelled words and it still takes 5 to 8 minutes of the CSWOD to check 50 pages. This is on a Mac Studio that blows through every other ID process like butter.

Yes, I've complained before when this was a 1,200 page document, but now that document is a book of documents around 50 pages each. I'd be satified and would shut up under 2 conditions: Either tell us why this should take so long, or fix it so it doesn't.

[Mike Witherell]

Tell us a bit more about your InDesign version? Your operating system and version?

Does this happen to all documents, or the one?

Have you experimented with exporting to IDML and reopening that to a fresh InDesign document?

Are you using paragraph styles to control the text?

Are you using any GREP conditional formatting to style your text?

[mazdaspeed]

This is v.19.5.1 on MacOS 15.3.1. This affects every document in this book, which was once a single document but is now 60+, from about 1 to 100 pages.

I opened a 250 page document that shares the same user dictionary but is not part of the book, and that spell check finished in less than a minute, so yes, this is underlying document specific. To test further, I deleted the story out of the 250 page document, then pasted the text and styles into what was the longer document, ran the spell check and it took 6 minutes. It takes a full minute to reach the second mispelled word on page 4. I also changed the font so I could share it here, which did not affect the time required. 

indd. file is attached to this message. I tried to share the user dictionary added.txt but it gets stripped when I try to post it, so I changed the extension to .csv. There are way too many unique words to test the file without the user dictionary words.

Sorry for the bad attitude I started with. InDesign was crashing in Find/Change for much of this week. It's been frustrating.

[Robert at ID-Tasker]

@mazdaspeed

Can you re-upload 2nd file? 

[James Gifford—NitroPress]

What exactly is taking so long? The search for each hit? Or does it take this long just to find no hits? As Mike asks, do you have any dynamic styles active?

[mazdaspeed]

When you say dynamic, what do you mean? In the two documents I refer to in the reply to Mike, they both use the same GREP styles. The 250 page document works just fine. I don't know how to look further under the hood, but I did attach one of the problem documents to my reply.

[James Gifford—NitroPress]

"Dynamic" means any of the on-the-fly format options, such as GREP, Line, Drop Caps etc. All of these can slow down InDesign operations if they're too broadly applied, there are too many of them or there are other document/system resource problems. Very generally speaking "this document does things very slowly" often devolves to something like a GREP style that applies to multiple items per page, or worse, to some majority of body text or the like. It takes time for ID to parse and process such things.

If this is just one doc, then the doc may be corrupted. Have you done a Save-As recently to a new name, to purge undo and image data that piles up? Have you done save as IDML, open, save as new INDD cycle to purge and rebuild other faults? Both can help with glitchy docs.

You only sort of answered the first part: I read it that each "step" in spell checking takes an extremely long time. That, to me, points to one of the above problems.

[mazdaspeed]

If this is just one doc, then the doc may be corrupted. Have you done a Save-As recently to a new name, to purge undo and image data that piles up? Have you done save as IDML, open, save as new INDD cycle to purge and rebuild other faults? Both can help with glitchy docs.

By @James Gifford—NitroPress

Yes to all of the above. In fact, prefs were reset, then v.19.5.1 was rolled back to on Wednesday, due to issues with Find/Change crashing (which I managed to repeat the workflow consistently, and had to do with moving between Text and GREP tabs). 

[mazdaspeed]

Initally it was no mispelling, so I added 3 or 4 mispellings. While the first one hist almost immediately, the second one, on page 4, takes a full minute. Pretty. much the same for the remining hits.

[mazdaspeed]

Fundamentally, both documents (one that is fine, the other not) use the same styling. There is GREP for no-break and for ligatures. The one that works better than the other actually has more GREP to deal with. I just removed all the GREP styles from the offending documant and now it works as expected. This still does not explain why my 250 page document finishes in less than a minute with same GREP styles in use.

But I have this objection. There is no reason (that I can imagine) for ID to have to process any GREP style or any style at all in order to spell check text. The text for spell checking should be exclusive from markup, making it a very fast matter of processing. If I am incoorect in this assumption,  then I'm satisfied to be corrected.

[James Gifford—NitroPress]

Ah, yes, GREP styles that process all content — always potential trouble.

As for not GREPping during spell-check... I think that's a half-formed concept. Either you don't use GREP to modify the content, or you do... and if you do, you want things like spell checking to be on the 'final' form and not some interim state. Maybe for your needs it makes no difference, but I can see many cases where you would not get the same results from each approach.

I am not a real big fan of GREP for intensive text processing as you're using it. This glitch, whatever the root cause in that document, is an example of why.

(ETA: I'd use the occasional canned GREP F/R instead of a live process.)

[Robert at ID-Tasker]

@James Gifford—NitroPress

But GREP Styles can't change contents? Only formatting. 

[James Gifford—NitroPress]

True enough, but I am leery of anything that could compromise a final result, just to twiddle ligatures or old style figures or whatever on a dynamic basis. Choose one. IMHO.

[Robert at ID-Tasker]

@James Gifford—NitroPress

I understand. But spell-check - internally - should be performed on a "raw" text contents - after stripping all XMLElements, Index markers, etc. 

Ligatures shouldn't affect that - they're just "visuals"? 

[James Gifford—NitroPress]

Who's to say it isn't? That is, it doesn't sound like the GREP is affecting the actual spell checking process... but switching the changes on and off would/could affect the whole document flow and layout, including pushing text into overset and breaking words that are not meant to be broken, and so forth.

Applying text-wide GREP slows things down a ton. That's a known. In some documents, it might cause exactly what the OP is describing, for whatever processing/technical reasons. If the text twiddling is essential, it's something that has to be accepted as part of the workflow... assuming a document purge/refresh doesn't solve it as with so many other runtime issues.

But any notion of taking part of layout out of the document to speed another process is... not well thought through. Again, IMHO.

[Robert at ID-Tasker]

@James Gifford—NitroPress

I still disagree 😉

What you see - is just a representation of the "raw" text with applied formatting. 

It's like when companies translate IDML files - software that is used to do translation - "doesn't care" how text is / will be displayed - all formatting - XML tagging - is stripped and only text contents remains. 

The same should be with spell-check. 

If it doesn't work that way - then it's bad coding. 

[James Gifford—NitroPress]

Oh, I make no claim that my position is the only or correct one. And maybe I tend towards the conservative approach (in this, nowhere else, make no mistake) and try to avoid stacking processes that all too often break — as we see every single day here with this 20-year-old app engine — but I do sigh a bit at those who insist that some very complex combination of features and processes should give them no problems, just because it's how they've chosen to set up their projects or workflows, and damn Adobe to the depths of tech hell for not dropping all else and making it so.

And now we have the whole layer of users who are wailiing because AI doesn't do all this hoop-te-do from a single text prompt, without fault or fail or making them actually think for thirty-four seconds.

(Now where did I put that letterpress?)

[mazdaspeed]

This is correct, and I said as much in another place in this discussion. Spell check should take place against the text, exclusive from any form of markup. All markup, whether a style or line space, or whatever, lives inside delimiters within the markup language (whether that's html, idml, xml, htxml, etc.). Spell check as a process should care less what is inside those delimiters, and act solely upon the plain text. Any other method is asking for trouble. And that's the question I posed: is ID looking beyond plain text? If so, why? There should be zero concern with styles (markup), period. 

[mazdaspeed]

I don't want to drag this through the mud. I appreciate you guys helping me process this. I will likely rebuild it all from scratch since this is a document(s) that gets maintained and updated forever. 

[Mike Witherell]

Hi Mazdaspeed,

Can you also supply the specialized dictionary file that this Biblical text depends on? Without it, I cannot evaluate whether the spell checker is slow. Could you zip it up and upload it?

Update: I looked inside Preferences > Dictionary and can see that your example file is NOT connected to any specialty term dictionary. That alone is going to slow things down a lot. Your text is filled with Hebrew place names and people names.

So far, I find many of the paragraph styles to be overly complicated. The character styles that are meant to provide small-capitals aren't actually doing so.

I note some pitfalls:

There are 39 paragraph styles not being used along with 12 character styles not being used. If you can, unload the extra styles. Another big slow-down potentially is having many styles based on other styles. I suggest you make most of your styles based on No Paragraph Style. 

[Robert at ID-Tasker]

@Mike Witherell

But making styles to be based one on the other - tree structure - is a correct way to do things?

[Mike Witherell]

It can be, if your skill level is very high. But in this case the complexity of the typesetting argues for a conservative approach; an approach of simplicity. As I look at this document, it looks like it has many circular connections. To untangle it, I would recommend basing each style on No Paragraph Style.

[Robert at ID-Tasker]

Looks like I need to get to my laptop and run you know what 😄

[Robert at ID-Tasker]

WOW! Those expressions are really long.

And that's just a HALF of the GREP expression...

And pretty much EVERY style has this GREP Style inside...

[mazdaspeed]

Yes. And spell check runs fine on the original of that file.