InDesign CS5 hangs when opening large file

Are you running maintenance revsion 7.0.4?

What operating system?

Have you tried turning off Live Preflight?

Running the latest version.

Respectfully, this does not answer the question.

Many people make this statement and happen to be wrong

What is the precise 3-dotted version number reported by holding down Command and selecting About InDesign?

Moving the file out of the collected folder suggests the problem relates to opening a link. Not too surprising...

Depending on the version information I may have additional advice.

hi !

jfreestern

Try this, delete the Mark II folder

location of Mark II folder :

Mac OS: [Startup Disk]/Library/Applications Support/Adobe/SING/Mark II

Windows 7/Vista: C:\ProgramData\Adobe\SING\Mark II

Windows XP: C:\Documents and Settings\All Users\Application Data\Adobe\SING\Mark II

thanks

Thanks for clarifying (7.0.4.553)

With that in mind, when you experience a hang, there are two diagnostics you can gather that can help us determine why InDesign is hung,

both long files from Activity Monitor. So hang InDesign and start Activity Monitor.

1) Select InDesign, choose Sample Process, and save the file. Upload it to http://pastebin.com/ and post a link here.

2) Choose View > Send Signal: Abort (SIGABRT). This will force InDesign to crash, and generate a crash report. Upload the crash report to http://pastebin.com/ and post a link here.

Ashutosh's suggestion hypothesizes the problem is SING, Smart Independent Glyphlets. See http://helpx.adobe.com/indesign/kb/hang-freeze-open-create-file.html. It certainly could be, and his suggestion will do no harm otherwise.

With the above diagnostics we could certainly tell if the problem was SING, but there's not enough information to know at this point.

jfreestern

Mark II folder :

In some cases, this is caused by corrupt data related to the Smart INdependent Glyphlets (SING) component, which handles use of single glyph font files used to represent custom glyph needs to extend standard font glyph sets. This is primarily used in Chinese, Japanese, and Korean (CJK) documents.

jfreestern wrote:

 

Did try one thing that kind of works -- moved the ID file out of the collected folder and that seems to work.

This suggests to me that the problem may be realted to a linked file, but you should run John's suggested diagnostics to verify.

Do you have any Font management software installed?

jfreestern

Have you tried to remove the Mark II folder .

try it now, It will work.

Here are the links (if I did this correctly):

 

The Sample Process Link: http://pastebin.com/CWuQHNkw

The InDesign Crash Report: http://pastebin.com/TtjhSe7G

Jeff, yes, those are correct.

The first indicates that InDesign is stuck in font manipulation code, and the second is somewhat more precise about where:

Thread 0 Crashed:: Main Thread  Dispatch queue: com.apple.main-thread

0   AdobeCoolType                      0x009060cc CTCleanup + 338232

1   AdobeCoolType                      0x009046d2 CTCleanup + 331582

2   AdobeCoolType                      0x008ab7cd 0x855000 + 354253

3   com.adobe.InDesign.Font Manager     0x14c4d7ea 0x14c42000 + 47082

4   com.adobe.InDesign.Font Manager     0x14c4dfc0 0x14c42000 + 49088

5   com.adobe.InDesign.Font Manager     0x14cd53cf GetPlugIn + 440303

6   com.adobe.InDesign.Font Manager     0x14c873a7 GetPlugIn + 120775

7   com.adobe.InDesign.Font Manager     0x14c90dfe GetPlugIn + 160286

8   com.adobe.InDesign.Font Manager     0x14c752d8 GetPlugIn + 46840

9   com.adobe.InDesign.Font Manager     0x14c76e28 GetPlugIn + 53832

10  com.adobe.InDesign.Font Manager     0x14c7708c GetPlugIn + 54444

11  com.adobe.InDesign.Font Manager     0x14c76c83 GetPlugIn + 53411

12  com.adobe.InDesign.Font Manager     0x14c77249 GetPlugIn + 54889

13  com.adobe.InDesign.Font Manager     0x14c9bdc4 GetPlugIn + 205284

14  com.adobe.InDesign.AppFramework     0x0e1323cf GetPlugIn + 54943

Unfortunately, this signature is not consistent with either SING problems or problems with third-party font management tools, both of which have easy fixes.

The best we can say is probably "sounds like a corrupt font or group of conflicting fonts."

So, start by removing all non-system fonts and seeing if ID will open your document.

Assuming that works:

Then, divide the set of removed fonts in half and put half of the back -- see if it works.

If so, add another half set back, etc., etc. until you pinpoint the bad font.

Thanks John. Any idea why it will open if I move the file outside of the folder?

Oh, gosh, I got that detail mixed up with someone else's question and lost track of it.

If you move it out of the folder, it may have difficulty finding linked content.

If that linked content depends on a font, then it can trigger the problem.

You could also try to divide-and-conquer approach on the links associated with the file. This might be trickier because of how InDesign remembers file paths...

Well, we're guessing. but it's a font-related BUG.

Bugs are tricky things. Their behavior can change depending on the precise path that they are approached from.

Perhaps ID treats opening a new document a little differently than crash-recovering a document and the problem fails to manifest...perhaps there is an ordering dependency?

It's definitely a bug. What is triggering it is hard to say. I suspect a corrupt font, but I could be wrong.

Certainly not everything in your story lines up perfectly with that theory...

The moving outside the folder might also point to something with the Document Installed Fonts feature. Try moving it back where it was in the package folder and move the document fonts folder out, or rename it, and see if that works.

Sounds like the problem is one of the packaged fonts.

Well, Peter's explanation makes much more sense than mine about linked fonts in PDF files... it also explains why crash recovery works differently, since presumably crash recovery doesn't look for the Document Fonts file associated with the original document's path (perhaps a bug?).

Although wouldn't they be the same as the ones loading from Suitcase Fusion? -- that is, if InDesign is trying to load the fonts from the packaged font folder when the ID file is in the folder, what fonts is the file using when the file is outside the folder (those already loaded in Fusion)? and if it's the Fusion fonts, they would in theory be the same fonts that ID collected and packaged, yes?

Well, maaaybe. It depends on how you have Suitcase set up and whether the fonts are indeed the same, and where they came from, and so-on and so-forth.

So go ahead and split out half the fonts from Document Fonts and keep narrowing until you find the problem. Even if you have 128 fonts in there that's only 7 divsions in half before you find the font that's the problem (assuming only one is the problem...).

Please let us know what happens!

jfreestern wrote:

 

Although wouldn't they be the same as the ones loading from Suitcase Fusion? -- that is, if InDesign is trying to load the fonts from the packaged font folder when the ID file is in the folder, what fonts is the file using when the file is outside the folder (those already loaded in Fusion)? and if it's the Fusion fonts, they would in theory be the same fonts that ID collected and packaged, yes?

I wouldn't swear to it, but I think Suitcase would be entirely bypassed in this case. I know, for instance, that ID uses the Document Fonts rather than the installed versions if both are present.

Also just for clarification, when a job is packaged from ID and the fonts that are being used are loaded through Suitcase, when ID collects the fonts, isn't it pulling them from Suitcase's database (I have all my fonts in the Suitcase Fusion database)?

Essentially yes, if indeed the job is packaged on the same machine with the same configuration as the machine where it is later opened. That may be the case in your situation, but it is not necessarily generally true.

And for clarity, to be technical, ID is not pulling the fonts from Suitcase's database

ID takes the fonts from the OS. Suitcase provides them to the OS. So there is a level of indirection involved, and that indirection may reflect the opportunity for bugs in the OS and bugs in Suitcase and bugs in InDesign to all interact in new (or old) and exciting (always) ways.

If yes, then they should be one and the same fonts -- that is the ones in the collected fonts folder should be the same as the ones in my suitcase database unless some damage is occuring during collection -- correct? (Also, all the fonts used in the booklet are fonts that I had previously installed in Suitcase (none were sent to me by others)--unless an embedded font in a PDF that I placed into the document could be causing an issue or conflict with my fonts??

So, yes, it sounds like they should be the same fonts. And that certainly begs the question why it would be different if ID loads a font from Document Fonts versus Suitcase loading a font through the OS mechanism. But certainly they are different mechanisms and may have different bugs.

Peter wrote:

I wouldn't swear to it, but I think Suitcase would be entirely bypassed in this case. I know, for instance, that ID uses the Document Fonts rather than the installed versions if both are present.

Well, Suitcase installs a hook that gets triggered when ID loads a document--this is autoactivation. It causes Suitcase to stop and load fonts when the document is opened. At which point it could do anything... Only then, after Suitcase does whatever it does (with auto-activation enabled, only, of course), then ID will do what it does (either loading from the OS or loading from Document Fonts).

Plenty of room for all sorts of problems...

jfreestern wrote at Apr 26, 2012 9:48 AM:

Good explanations and I agree lots of room for problems. Will give things a try a bit later.

Any updates?

Jeff,

I'm really happy to have found this discussion. I've just had the identical problem, using (I think) identical software. I'm not sure I followed every detail of the conversation above, but all the behaviors described matched what was happening with my files. I had gotten as far as determining that renaming the Document Fonts folder (even by just one letter, to, for instance, "ocument Fonts") was enough to make the problem go away, but I had no idea why. Reading the above post led me to remove HelveticaNeue-CondensedBold.dfont from the Document Fonts folder (it was the only .dfont in the folder), and voila! The problem is fixed. Thanks for sharing the problem and solution.

— (another) Jeff