OK, update today. After discussion with Adobe Support, it appears that this is a "known issue" and that the workaround is to move the INDD and ICML files to a non-shared drive before opening them in InDesign. We will incorporate this practice and see if it solves the problems we have been having.
I thought InCopy was designed to work with InDesign in a collaborative/network environment, so this workaround doesn't make sense to me.
Are there are other users of InCopy and InDesign that store and work on their files on a shared network drive? If so, I am interested in hearing about your workflow and if you are having file update problems.
Just updating. Workaround does not work. We get the same issue with files on the hard drive or on a network drive. Surely someone has InDesign CS5.5 and InCopy CS5.5 working together without this issue? Windows 7?
Still experiencing this issue, though my great IT person has narrowed down the problem and will work with "Support" to try to get a better fix. From my IT department:
"We have made a little more sense of the madness. It looks like the third InDesign 5.5 update, version 7.5.3 , is the cause of our woes. When I run our broken InDesign/InCopy file on a machine that only has the version 7.5.2 update there seems to be no issues updating the file in InDesign. Take that same file and try to open it on any machine that has the version 7.5.3 patch installed and it crashes mid-update. I’m trying to get in touch with adobe tech support again to let them know about the discovery and hopefully pinpoint what in the patch is causing the crash. The InCopy software can be completely updated with no problems arising. The problem is strictly related to the InDesign 5.5 version 7.5.3 patch. I think the problem can be fixed so long as we keep the machine in a pre 7.5.3 patch state, but this is only a temporary solution because there are Information Assurance issues not keeping the software up to date and eventually we will be forced to update our software. When we do, documents will start breaking again so it’s vital we find a more permanent solution. Perhaps Adobe can find a fix for this issues or include a fix in a later patch."
Bizarre. Have not heard of anyone having that problem yet. Thanks for the report!
So you're saying that InCopy 7.5.3 and InDesign 7.5.2 are the solution for you? (instead of 7.5.3/7.5.3?)
It's an interim solution. We are downgrading now. I had a file with issues updating in both IC and ID 7.5.3, switched to ID 7.5.2 and IC 7.5.3 and it updated fine.
I say interim solution because I can only convince my IT guys that I have to keep out of date software for so long. When IT makes me upgrade, I am certain the problem will return. Hoping for a fix in the software itself.
I have no idea why we would have an issue and others would not.
I just upgraded to InDesign 8 (CS6) and I am experiencing some instability with certain InCopy documents. My colleagues are still using InCopy CS5. When placing some, and updating already placed InCopy documents InDesign will shutdown due to a "serious error".
For the record, these InCopy files do not exist on networked storage. Technically, I am using Dropbox to share files with colleagues but those files are hosted locally of course and the issue doesn't have anything to do with currently syncing files, etc.
If no one has any thoughts I suppose I will upgrade InCopy to CS6 and throw another new variable into the mix to see what happens.
Upgrading InCopy would be the first thing to try. You can download a 30 day trial.
Doing so now. Of course my colleagues won't be happy when I tell them they have to buy an upgrade. I'm all for upgrades but in this case I don't think that InCopy CS6 is a requirement for InDesign CS6, correct?
No change. Opened InCopy CS5 document in InCopy CS6, saved as a new document. Chose Relink in InDesign document. Same crash-inducing, serious error. (The InCopy document, by the way, is simply text with a few paragraph styles — I won't get into InCopy documents with graphic anchors, etc.)
Creating a new InCopy CS6 document, copying content from existing InCopy CS5 document and pasting content into new document also produces same crash as does attempting to place this (or previous iterations) in a new InDesign CS6 document.
But, placing InCopy CS5 or InCopyCS6 document in a new InDesign CS5 document (running both versions concurrently) is successful.
Are you using Suitcase Fusion 3 by any chance? If so, disable the auto activation plugin.
No, I use FontCase by Bohemian Coding. Currently I have its auto-activation feature disabled. Which, by the way, I have found to be very unintrusive as a Mac font management application.
I am having the same problem with the InDesign/InCopy workflow crashes. I work in a windows network environment.
I have just suggested to my IT person to re-install my InDesign software (I currently have InDesign CS5.5, v7.5) and do the update suggested in the InDesign forums (7.5.3 available since May 2, 2012 in the Adobe site.
Has anyone experienced the results of this update as to solving the problem or not?
Does the version combination suggested by Anne Marie resolves the problem?
Any assistance will be appreciated :-)
AM, this is Rocio... yes THAT Rocio... experiencing this very frustrating problem with the ID/IC workflow that used to work so well until a few weeks ago.
So, here I am now asking if the combination you suggest is the 'winning combination'... did you got to know the answer to your question? If so, I would like to know how that worked. :-)
Our trouble started when we installed ID 7.5.3. When we went back to ID 7.5.2, the problem went away. We are running IC 7.5.3 and ID 7.5.2 with minimal issues.
One thing that comes up occasionally is that IC will crash when updating links (the opposite as it was before). If that happens, we update the links in ID 7.5.2, clear the Caches folder on the IC computer, and re-open. Works like a charm.
Thanks to Anne Marie for sorting through our posts and summarizing the working combination. I think it would have been lost in the weeds if she hadn't done that.
Good luck, I hope it works as well for you as it has for us. (And that Adobe has more fuel to fix their recent ID patch.) We have an open tech support regarding this issue, since my IT people get grumpy if we run out of date software.
JA Flint, thanks for the information! :-)
You have saved me lots of running around in circles! I am passing this information to my IT people and we will be looking to have the version combination you are suggesting and see how it goes. At the same time, I will keep an eye on the other ID/IC workflows in our department to check how are they working with their own software versions. Now, I am curious to know which versions are they working with.
Later on, I will report on the results from implementing from your advice to assist other possible users looking for a solution to this issue. Also, as you mentioned, hopefully Adobe will fix this issue so that we can move forward with new software versions. At this time, if IC 7.5.3 and ID 7.5.2 work well and the issue is fixed, we will probably not be installing newer software until the issue is fixed at the software level with no need of work-arounds.
Thanks again! :-)
I just wanted to add in my 2 cents here. I've been experiencing this problem since the aforementioned update to InDesign CS5.5 and it has carried through to InDesign CS6. It has rendered InCopy almost useless and from what I can gather I'm not alone, not only from the comments in this thread but from the thread at via the link below along with other forums around the place...
Adobe needs to really get to the bottom of this issue. InCopy was a really useful cross-collaborative tool, it both sped up our internal workflow and minimised editing errors caused by manual insertion of markups on the design end. Now it's joke.
We are also having major problems with our InDesign/InCopy layout and assignment workflows in Win 7, have contacted IT support and still no help going forward.
The recent upgrade to both InDesign and InCopy CS6 (both have the latest patches installed) has not helped, our workflow uses both shared network and dropbox, neither seem stable.
We have posted similar Proectiveshutdown logs, see below
Adobe InDesign Protective Shutdown Log
Unhandled error condition
Session started up at 10:39 AM on Monday, February 04, 2013
Version: 8.0.1 - Build: 406
Error Code 0x20705: "The content is locked and cannot be modified."
Called to process command 0x7313
Command Processor Stack (from top to bottom):
8. Command Sequence "Re-import File"
7. Command 0x7314 "Re-import File"
6. Command Sequence "Update"
5. Command Sequence ""
4. Command 0x8c59 "Update Link"
3. Command 0x18e38 "Relink Story"
2. Command Sequence "Relink Story"
1. Command Sequence "Update Story"
The problem always seems to be the same after a simple editorial change to the .icml files.
Adobe need to sit up and pay attention to the problems we have been experiencing.
When I saw the updates to both InCopy and InDesign included apparent fixes for issues related to the importing of .icml files crashing InDesign (the fix was for a supposed issue with Pantones?) I too was hoping that my days dealing with this issue were over.
On the initial setup of my last project where InCopy was needed to cross collaborate with our editorial team everything seemed to be working fine. However much like previous experiences something occurs and suddenly when trying to update .icml files CS6 shuts down due to the 'Serious Error'.
This issue has been been ongoing now for far too long.
I still experience issues with this as well, and I think I was one of the original posters. I thought I would take a second to "bump" my experience and crude fix in the forum.
For me it seems to be a problem with InDesign gathering hyperlink destinations. InDesign will include these URLs, appending them to InCopy files that are getting edited and checked-in in InDesign. From there something happens where a URL can start duplicating, many hundreds of times during subsequent check-out/check-ins.
I sometime examine the InDesign document's destination options deleting the unnecessary ones.
More importantly, I now use Apple OS X Smart Folders in the Finder to monitor production folders for .icml files over 500KB (for my purposes — magazine articles — basic InCopy files that are just text in nature are typically well below 300KB).
If I see an InCopy file is behaving badly (bloating in size unexpectedly) I will open it in a simple text editor and remove the excessive Hyperlink Destination XML elements and save those changes to the XML. This generally fixed the problem.
I hope this makes sense, and might be of use. I realize the previous poster's comments might be more about chiding Adobe for not fixing the issue than looking for someone to chime in with their observations.
I am not sure they are exactly the same problem. We have been able to take "broken" files from ID5.5 and bring them into ID6 (as a test case). The files were not "broken" in ID6. I suppose it could be that ID6 fixes those files, but if an ID6 file gets "broken" you are back to the same problem...it's all very strange.
Regardless, we will continue to use ID 7.5.2 and IC7.5.3 until this all gets sorted out, or I am forced to upgrade. (But I am doubtful that there will be a fix, given how old this problem is).
1 person found this helpful
I believe I may have some insight to share on this problem.
I produce a magazine in InDesign CS6, and the editors use Incopy over a shared dropbox account.
As we start creating articles, I usually export them to Incopy one by one, just the text frames that I expect them to edit. However, at some point in production, it becomes necessary to unlink all of the Incopy stories, delete those links, and then create clean links - usually because another designer wants to be able to copy text boxes and move all the pages around and having everying linked in Incopy makes that more cumbersome.
When it's time to remake the Incopy links, I have several times tried using "Export all stories" to create them all at once. DON'T DO THIS. I believe this is one of the main causes of the problem because there are various pieces of text that you don't want linked via Incopy - such as master page footers, section markers, anchored text elements, text labels on a digram that are in small round text boxes, and so on. I think these are the things that cause the crashing when you try to update an Incopy link - even if the one you're updating has none of these features.
So, instead, after a clean sweep of all linked text, I now re-export the Incopy links manually. I go one spread at a time, and highlight all of the relevant text frames at once, and export to Incopy. That way I know I'm only exporting the frames that have the main text in them that will be edited, and not the "decorative" text or locked items.
This may be prohibitevely time-consuming in some projects, but until Adobe is able to fix the application, I believe it's one way to solve the problem. Seems to help on my magazine.
I am and continue to have the same exact problem with ID 7.5.2. Not sure what version our IC is. D
We have recently switched to IC/ID 6 and everything seems to be stable. One thing I noticed from the InCopy side though (IC 5.5 and 6 both), is that sometimes when I check in stories and prepare to exit the program, I would click on "File" and notice that "Save All Content" is still able to be selected. I started checking if it was available to be clicked (not greyed out) every time before I closed the program, and most of my crashes went away. (If it was available, I clicked "Save All Content".)
It seems odd that you would have to "Save All Content" after checking everything in, though. Checking in is supposed to save the content. This would happen even if I only checked out one story. Sometimes it's available, sometimes not. If it's available, I click it. Couldn't hurt.
I realize we have reached the realm of computer voodoo and superstition at this point, but it seems to work. I also make three circles around the file icon with my mouse before opening them, just in case. Just kidding. Good luck though.
We also have this problem with Incopy CS6 and Indesign CS6
Downgrading to Indesign CS5.5 fix the issue for us. Here is a thread in the Incopy forums about it.
Sad to see Adobe is ignoring the issue and not releasing a fix
I've been dealing with this issue a lot recently. I work on a 2011 iMac running 10.7.5 (Lion). I'm using InDesign CS6 and my associate is using InCopy CS6. I've done all the "fixes" listed above. And at different times they have seemed to fix the problem. Most recently though, none of the previous fixes (unlinking, exporting as IDML, recreating links, etc) were working. Until I discovered there were locked items within the copy that was exported in the ICML files (namely an anchor icon at the end of the articles). Once I went through and unlocked all of them, I updated the ICML files (did not have to recreate them) and updated the links on my associate's computer. Tadah! No more crashing. We tested it by editing a linked ICML and sending it back and forth a few times. No more crashing! ~It makes sense to me that a locked item within the ICML file would cause this annoying crashing. Hopefully, the 7+ hours we spent trying to solve this issue will be of help to you!
Check Character styles and remove the one that says hyperlinks and has a little disk icon next to it - re output the assignment and whola it should have no crash issues - we have tested on 5 problem files and they all worked, looks like an imported style from word docs i think.
Let me know if it works - it has caused us much grief - and no one at adobe could help!
I had the same issue and spent hour figuring out the issue. I realized that it only happened with text that was imported from word files. Some word files have a little text anchor, or some kind of hyperlink that is invisible. If you turn on hidden characters then you will see what looks like a colon, two dots instead of a space which normally shows as one spot. Check out http://indesignsecrets.com/downloads/guide_specialchars-2012.pdf and look for "Text Anchor" to see what it looks like.
If this anchor is in the text than it will cause indesign to crash when updating the file from incopy. The trick is to either ensure that the anchor never comes into indesign by importing word files with no styling whatsoever, or to search for the anchors (in the story editor it might be easier) and delete them before making incopy links. If they were already made into links just delete them in incopy. After importing word text, before styling, the story editor will show this anchor with a weird anchor symbol so it is easy to spot.
After styling this symbol seems to disappear and all that is left is the to vertical dots in the hidden character view, this can be hard to spot. Once I figured out this issue, I never had a crash again and now can avoid it altogether.
I hope Adobe corrects this bug but till then, just delete the anchors and enjoy crash free file!
I have this EXACT SAME ISSUE popping up in our workflow using Word and InDesign/InCopy CC. And it ooks to have been a problem in CS5.5 and CS6 too.
What, if anything, is being done to resolve it? Or is there a workaround that doesn't involve creating files over and over with frames deleted and repackaged to see which frame is causing the failures
This is posted on at least 2 other threads, see below for one.
Hi to all, I found the solution doing what RachelAdler suggested. You need to erase those invisible text anchors to have a crash free file.
Finding the anchors can be pretty hard but you can use this script to help you with that task.
Hope this solution works for all you too!
Here's the thing though...
When you're using an anchored object in a text box, you get that invisible character. It's not something you can just delete. These are not unused text anchors.
If you delete them, then you have to place the object independently. If you do that and anyone makes any further corrections to the page, you run the risk of the object not flowing along with the text that it used to be anchored to.
Now we're not using that other invisible character, the hypertext link that looks like a colon, so we can just deleter it. But I imagine that someone else out there may need them, or they wouldn't exist, so the problem would remain for those users.
So the real solution, if Adobe wanted to fix it, would be for InDesign and InCopy to be able to handle those characters as files are packaged to go back and forth between the applications. The bottom line is that that workflow is what they are advertising, so it shouldn't result in corrupted files when you do it.
We have used anchored objects that flow with the text with success. I don't know if this depends on the kind of object you are using, but we discovered that the ones that create the conflict are the orphaned text anchors.
I know that the real solution for this bug belongs to Adobe, but until that happens is good to know that you can do something to avoid the crash.
Just for the record... some of our bad files are definitely crashing due to non-orphaned anchored objects.
Currently, Adobe is telling us we may have issues between people working in different versions of the applications. Apparently, Adobe CC and Adobe CC 2014 don't play well together. Further testing will determine if they're on to anything there.
After making sure that our customer and vendors have updated to InDesign CC 2014, build 10.1.0.71, our problems with anchored objects remain.
Unfortunately Adobe support doesn't keep cases like mine open while waiting for new files to go through our workflow, so I'll have to go back and open up another case. I guess that's so they can say they resolve their support issues in a timely manner when they look at their statistics.
Apparently, not using anchored objects in the InDesign/InCopy workflow is our best solution. Hopefully, they'll add this to their list of fixes for some future update.