Solved - b1.10.2.1167 – Publisher goes to a slow freeze after working in large doc - requires closing

[nwhit]

I am working on a trade show display (panels) doc in 1.10.1, then in the newest beta .2.1167. As I work on the doc, placing images, moving things, adjusting sizes, setting type, etc., within a few minutes (5-10), the app essentially starts to freeze up and won't proceed or recognize new clicks/input. Doesn't actually freeze/lock up the entire program since I can switch to other apps, and I can eventually close the project after letting it sit for several minutes, although it takes a few minutes (with the beachball) for it to actually close. It appears that it is simply overloaded and can't handle any more input. The doc saves and reopens fine. Changes made just before the slowdown/freeze-up are there (eventually). Just gets to a point where I can't go any further and need to close the doc (waiting until it eventually closes) and reopen in order to proceed.

I had thought it might have been an issue with 1.10.1, so tried the current beta for 1.10.2, but it does pretty much the same thing. 

The doc file size is only 7.4 MB with linked graphics. I have 72 GB RAM, so not short on that, as well as a new iMac. The doc's single spread is 3748mm x 2280mm in 300dpi, cmyk (actual size trade show panel).

I opened it for the first time in Publisher today for revision work from a newly done IDML export from the original ID CS5 file. Never had this issue working on several of the same files in ID CS5 many, many times. (This is the first time working on them since Publisher came out). Files are on a local drive (RAID5 Thunderbolt 3). I think I have the APub performance settings at about a max setting (see attached). Don't have Save with History turned on. Overall, the doc is not highly complex with only about 9 images/pics. Just physically large, but as I said, never once caused any slowdown in ID CS5 for the many, many revisions and working sessions in the past. 

Can upload (with link) a package if needed. Just very difficult to work on this project in Publisher and hard to understand why.  

[nwhit]

UPDATE: Just moved a small linked APhoto graphic element and did a save. The Save froze the app for about 4 minutes. 

I also do have 5 items placed in the doc (linked) that are APhoto files. Could that be the culprit? Do they need to be TIFF/JPEG/PNG etc.?

[MikeTO]

Your file is quite simple so I don't think it's specific to the file. Are you having this problem with other documents?

You might try turning off Metal compute acceleration and then restarting Publisher.

[nwhit]

Thanks. No. Produce a bunch of far more complex docs daily and no issues. With this iMac, never had a problem with Metal. Likely something related to the document since much larger (MB-wise), more complex files have not caused any issues. First time this has happened with APub.

I do seem to recall someone once reporting issues with placed APhoto/ADes files within a Publisher doc. Plus I have a couple of the original PS files linked as well from when this was an ID file. That's my best guess but will wait for someone who knows or has resolved a similar issue. 

[nwhit]

Also just did a Save As and used a new name. Reduced file size slightly. Then moved a small text item and Saved. Took about 3 minutes for it to save. 

[Gabe]

Hi @nwhit,

Can you save that as a package, zip everything up and upload it on this link? https://www.dropbox.com/request/Tifpr6V6XCfQjDzqdL0S

[nwhit]

8 hours ago, Gabe said:

Hi @nwhit,

Can you save that as a package, zip everything up and upload it on this link? https://www.dropbox.com/request/Tifpr6V6XCfQjDzqdL0S

Done. Just uploaded. Thanks.

[nwhit]

Related to this same file, I have done another Save As and am attempting to replace items that are either APhoto or PSD files with jpg, TIFF or PDF versions. However, having tried to replace 3 of them, each time in Resource Manager when I replace one, it shows up listed as Missing in Resource Manager and Preflight. But if I save and close the doc, then reopen, it now shows as OK. And what I see on screen at 100% looks correct. 

Am I doing something wrong or is this perhaps a bug? (Still using the beta.)

 

[nwhit]

Thanks. Interestingly, when I replace the linked APhoto files with TIFFs, they show OK right away. But all of the items that are replaced with a PDF show missing until I Save, Close, then reopen. 

[nwhit]

UPDATE:

Okay, I went through and replaced all graphic items (linked as before) that were eps, psd or APhoto items with pdf or TIFFs. I don't seem to have the freezing up issue anymore. Seems that the bug/problem is related to placing those type of files/objects within a Publisher file. I'm thinking that it shouldn't be that way. In many cases, I would think it would be preferable to place a APhoto file, especially where there are transparencies, drop shadows and other issues that may not do as well as an exported and placed file in another format. 

But at least I can proceed with this revision for this project! That's the good news! That's assuming my PDF/X-4 output file will now work okay once I'm done!! 😉

[Gabe]

I can't seem to replicate it with your packaged file. I wonder if it was just a matter of re-linking everything, rather than replacing them. Can you try and open your project from the afpackage you sent me and see how it works? 

[nwhit]

@Gabe, looks like you found the problem. I've been playing with the packaged version and it doesn't seem to show the problem. Interesting! I'll keep playing with the file today as time allows, but looks okay right now.

That does raise the question. For other files that are IDML imports that might have this same issue, is there a quick way to relink all the linked files? In a few threads I have seen the advice to rename the directory with the resources in it, then re-find and relink the resources. However, our production group has never kept various resources in a single folder. They are distributed all over the place and are filed based on project, product, use, etc. Thus no possible way to simply move or rename a folder. Nor would it be possible to Package, then rename/relink since those assets have to stay where they are.

Thus is the correct way to accomplish this to simply click on the Replace button in Resource Manager and select the same file? 

Thanks. Happy that I can still Place and link to APhoto, etc. files! 

[Gabe]

I'm afraid there is no easy way to re-link all in one go (unless you package it?)

Where were the original files stored? 

[nwhit]

8 hours ago, Gabe said:

I'm afraid there is no easy way to re-link all in one go (unless you package it?)

Where were the original files stored? 

As per my post above, all the resource files are stored in a wide variety of locations (on local drives) based on the related product, project, use, period/date, etc., and cannot under any normal circumstances be moved to a single directory/folder for use in an APub doc. These resources are routinely used for a wide variety of projects, and in many cases, are often revised/updated, so need to be stored in their appropriate locations and only linked, not embedded. The resources are used in or linked to numerous other docs, pubs, etc.

So if I follow what you are saying, I would need to in the Resource Manager click the Replace button, but select the same resource for each graphic item? That alone will resolve the problem?

PITA, but if that's the only option, guess I'll have to remember that for any further IDML imports. Doesn't seem like it should be that way, so hopefully it's something that can be resolved in a future update. When IDML import was first added, I trialed it during the various betas. I opened numerous IDMLs with lots of linked resources but never had this issue, so it appears to be something related to the newer versions. Thanks.

[Gabe]

14 hours ago, nwhit said:

So if I follow what you are saying, I would need to in the Resource Manager click the Replace button, but select the same resource for each graphic item? That alone will resolve the problem?

Hopefully yes. It's quite hard to diagnose this on our end as regardless of how you send the file, the resource link would be broken and will in turn fix whatever is going wrong with it. 

Is this issue something you can replicate with any large IDML import?