We have experienced the "junk after line ..." message twice in the last week. The InCopy files are corrupt and cause crashes in InCopy and InDesign. Very frustrating. Working in CS5.5.
I can help you fix those files if needed.
Sent from my iPhone, so my message will be brief.
So far we have been unlinking them and making the changes directly to the Indd file because that at least is something we can control. What measures have you taken?
I have been opening the InCopy files in a text editor and fixing them. Sometimes the edits that have been made are not reflected in the layout so we have been reluctant to simply unlink the stories.
I have not found a way to stop it.
Hi. This is the only thread I have been able to find that speaks to this problem—we are having multiple cases of this problem in our ediorial department. We are using 5.5. I don't know enough about the code to fix this in TextEdit. My main concern is not losing all of the editing done to the files. Any ideas?
Fixing our text in TextEdit is akin to starting from scratch. Our solution was to finalize the edits in InDesign. Not elegant, but expedient.
Fixing in TextEdit takes 10 seconds and you don't lose any formatting, edits, etc…
I will be glad to help you. Email me for phone contact information. kevin -dot- cecil -at- lifeway -dot- com.
What is happening is that InCopy is appending an entire second copy of the document after the document close tag (</Document>).
Here is how to fix this issue:
- Copy the corrupted .icml file to your Desktop.
- Open the file in TextEdit.
- Notice the first line of the file is the xml header: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
- Copy this line to the clipboard.
- Choose Find under the Edit menu (Command-F) and paste the header into the Find dialog box.
- You should find two instances of this text–one at the beginning of the file that you just copied and another about mid-way through the file. The second one is the key to fixing this problem. The line above this "second" header should be </Document>
- Insert your cursor after the ">" on this line.
- Scroll to the end of the document (or hit the end key on your keyboard to jump directly to the end).
- Hold the shift key down and click after the final character in the last tag in the document (which should be another instance of </Document>)
- Hit the delete key to delete the selected text.
- Replace the file on the server with the one you just updated.
- Update the story in the layout.
- Your document is fixed.
I search for the header instead of the </Document> tag because it is always at the top of the document (convienient) AND sometimes we get corruption that is a little different. Sometimes the error is "Not Well Formed." The procedure to fix is the same except the second header doesn't start after the </Document> tag, but just randomly in the middle of the file. Then I have to try to figure out where the junk text is and figure out where it ends. Much trickier, but doable. And much better than rebuiling…
This was my first experience with the error message: "Junk After Document Element"
Last night my editor made substantial edits, including copy/pasting in InCopy, to a multi-page Table list with Paragraph and Character styles. This morning when attempting to update the link in InDesign, nothing would happen, and I got the above error message.
Working in CS5 on a MAC workflow through a server. 10.6.8 on both desktops.
Kevin you are a lifesaver. Just as you said, the code duplicated in the .icml file. Thanks for walking me through the fix on the phone.
Thanks, Kevin. This is helpful. I would like to see Adobe address this bug in the application. We were on the phone with tech support for quite a while yesterday discussing the problem. Today we are sending them copies of the corrupted files to examen. I hope this leads to some fixes, but who know.
Thank you for this information. I have forwarded to the InCopy users. They will check it out asap.
Thanks again for your help. I have forwarded to my InCopy users.
Have any of you that have posted on this thread reported your problems directly with Adobe Tech Support? We have opened several case files with them in the past two minths, and they have not followed up. Have any of you had success in getting Adobe to recogize there is a flaw in the software that needs to addressed?
This is Tyler, and I work with Jim. We know how to fix the files when they are damaged, but I am wondering if someone has heard from Adobe as to a solution, fix, etc to prevent this further corruption? We confirmed the icml corruption is also an issue with InDesign and InCopy CS6 version 8 as well.
If anyone hears from Adobe with a solution, let us know.
I have not pursued this with Adobe. I send the requisite "error" reports when the software crashes. Has anyone else?
I have reported this to adobe and sent them sample files. No response.
Advanced Application Specialist
End User Services | Technology Division
LifeWay Christian Resources
Typed with my thumbs, so my message will be brief.
Unfortunately, we have not gotten anywhere with Adobe. We were promised calls back—no one called. In fact, we had someone promise to call within 30 minutes on Friday—no one has yet called back. They said our case was forwarded to a Senior engineer, and they would be in touch—again, no one has ever called us back. We have forwarded them damaged files per their request—still no one has ever responded. Each time we call back to check in, they want to start over the process as if we have never contacted them (putting us through the same rigamarole as before: uninstalling, reinstalling, etc. If this continues, we may ask for our money back or put in an appeal with our credit card company to have the charges reversed. This has been unacceptable and apparently Adobe is unable/unwilling to be held accountable for their software.
We would love to be able to continue our workflow with inDesign and Incopy, so if anyone knows how to get ahold of someone in Adobe who can actually help, or hears of a long-term preventative fix, let us know. Otherwise, we may have to scrap InCopy as defective software and go with something else.
Has anyone by chance encountered a preventative solution to this? If so, please post to the board.
We are still experiencing the problem on a regular basis, and Adobe has not come up with a long-term fix.
For now, we have switched our editors over to making edits in InDesign since InCopy has been so unreliable.
if you are still encountering the issue, keep submitting files and details to Adobe.
We updated our InCopy and InDesign and have not been having problems since. Also, some of our editors and typesetters work offsite. We found that some issues were caused by one or the other shutting down before the file transmission to the server was complete.
To be specific: we applied the updates that were available to Indd and InCopy 5.5. So we are running InDesign and InCopy CS5.5 7.5.3 We have not yet updated to CS6.
All of our users have been on 7.5.3. And are still having the issue.
We are running ID and IC 7.5.3, and it has not resolved the issue. We also tried CS 6, and we were able to cause corruption in the icml files with this version as well (locally and when using files on the server)
Angie, can you tell us a little more by what you mean, "We found that some issues were caused by one or the other shutting down before the file transmission to the server was complete." Can you be little more specific? What did you do as a workaround? This might be helpful to us.
Right now, we have switched all of our editors to making edits in ID instead of InCopy. We have been sending corrupt files to Adobe, but there still has not been any resolution.
An outside typesetter is working on an indesign file, creating the icml and icma files, and uploading them to the server.
Some of our files are large and require a great deal of bandwidth to up- and download.
If he prematurely interrupts the file transfer for some reason (shuts the laptop lid, quits indd, temporarily loses connection with the server) then the transmitted file is truncated and the error occurs.
This has happened twice for different reasons. A hard drive was bad. Another time the connection timed out.
To work around this we have been sending large assignments via file transfer applications rather than directly uploading to the server.
This seems to (knock wood) have helped.
We have ruled out this is the issue for us as both local users (over stable Gigabit Ethernet connections) and remote users (over stable Internet connections) have experienced corruption. Our files are on the smaller side. Also, we have experienced icml corruption when working on the files locally as well (with the server disconnected and removed from the equation), so we think it is an InCopy issue.
You may be right that it is InCopy. We may be experiencing a (happy) lull in corruption.
Wish I had an answer for you Tyler, but I don't, especially if you're having the issue with local files (and thus have ruled out a wonky network or server or permissions).
I'm jumping in to say that I have personally taught and supported hundreds of companies of all sizes using InCopy/InDesign workflow (which equates to probably 1K users) all using the server/folder method and have only run into that sort of document corruption ("not well formed") at two clients, back in CS2 days. I don't remember the cause but the fix was reinstalling the software.
95% (at least?) of all my IC clients these days are well past CS2 of course and I simply don't hear of that anymore. I'm not denying your struggle with it, just jumping in to "defend" InCopy a bit. What you and A.Loko dealt with is VERY unusual, in my experience. (and I'm glad you found the problem A_Loko!) ... That's all.
A few months back -- maybe last year? -- someone posted here about another problem they ran into, where editors save changes but the designers don't see updates, something like that. Equally knotty and frustrating, and a lot of user jumped in w/suggestions, the thread had over 50 replies I think. In the end, the problem turned out to be that when the designers exported multiple stories to InCopy from the layout (and InDesign automatically assigned the stories filenames by pulling the first couple words from each story as usual), in some of the stories, the first word or two had special characters like diacritics, and InDesign included those (stupidly) in the filename. It was no problem on the Mac side, but on the PC server it ignored those characters since they weren't legal, and thus confusion abounded. We didn't figure this out till the user posted screenshots of the Links panel and the Assignments panel.
So I'm wondering ... assuming you are fully updated software wise, and the network is healthy (you don't run into corruption working over the network with "normal" ID files or Word docs etc.), if maybe the issue has to do with fonts (corrupt/old font?) or corruption in the content (old content, Saved As repeatedly over the years?) or something glitchy in the Word docs (symbol/faux character/formulas?) that you're importing into the stories, or a conflicting plug-in etc.?
I appreciate your insight AM. However, there are more than just a customer
or two struggling with this. Before I posted the procedure to "fix" these
files. I was contacted privately several times to help others that have
(still) never posted here. We have had old and new computers with multiple
OS versions, multiple network segments with various network equipment
(Cisco/ Dell), multiple users, multiple dot releases of InDesign/ InCopy
and have had this issue across all of those variables. The corruption
manifests with several different error messages ("not well formed", "junk
after document element", etc…) but the problem with the files is
essentially the same–errors in writing the xml.
It certainly LOOKS like InCopy has an issue and Adobe is unresponsive.
Adobe is now confirming this is indeed a bug. If there are any users that are still experiencing this issue, please email me offline at tyler - a t - wipfandstock - d o t - c o m, and I will give you additional details. I highly recommend contacting Adobe tech support to initiate a tech support case and make sure they escalate it to Tier 2.
In the meantime, we are trying to switch our editors over to using InDesign to make the necessary edits to our typesetters files (yes, it is way overkill as a glorified text editor but it works without corrupting the files!)
Well done, wylertay. Thanks for your vigilance to bring this to Adobe's attention. I will keep track of any problems that arise in the future and report them at once. Knock on wood, we have not had an issue in quite some time.
Received the Not Well Formed error today; on end-of-the-month deadline. I am going to get our help desk to contact Adobe.