In my expereince, .idml is pretty reliable, so I have to ask, what happened to the headers in the .indd that they were not on the child masters?
Did you find a Hyperlink character or paragraph style that was imported from Word? you might want to delete that, too.
Thanks for your reply. In the original indd file, I had deleted the headers on the child masters because they were to be applied to pages that didn't need headers. I have to wonder if their appearance on the masters in the post-idml file is related to them containing text variables.
I did not find any hyperlink characters imported from the Word file, and any Word styles brought in were deleted and replaced with indd styles--this is standard procedure in my workflow.
What you are describing is very abnormal. Variables should not be a factor --deleted frames should stay deleted, and if there are no hyperlinks and you deleted the hyperlink styles that should have done it. Are you sure there are no footnote or endnote markers, perhaps, that lead nowhere from the word file?
Did this file begin life in CS5.5? You might also want to try installing the 7.5.3 patch and see if it helps (re-export after installing the patch).
I installed the 7.5.3 patch, and the "unresolved" error still appeared when I exported the original indd to PDF. But when I exported to idml, and reopened in indd, the problem with the zombie heads diappeared--they stayed deleted on the child masters. One problem solved.
However, when exporting this new indd to PDF, still got the "unresolved" error. There are no footnotes or endnotes in this publication. The file did begin its life as CS4 and as the predecessor in this series of publications (no footnotes or endnotes in that one either). After the last one was published, we saved the file as the new one in CS5.5, deleted all the pages and kept the masters and styles. If this is a bad practice, I'd like to know that. Should I start a new Indd file from scratch in 5.5 and then import the masters and styles from the current one? If not, any other ideas on how to get rid of this message? We are sending this to the printer next week via PDF. if we can't get rid of the message, and the PDF looks okay, will we be all right?
1 person found this helpful
First, the unresolved cross references shouldn't have any effect on printing, as far as I know, and if there are not any actual refernces they shouldn't be a problem for the text itself (like a wrong reference).
I don't know that this is the source of the difficulty, but being a legacy file converted in CS5.5 makes me suspicious. There are other reports of strange problems that crop up late in editing or at export with CS3 and CS4 files that are opened directly in CS5 and 5.5 and edited. It seems that exporting legacy files to .inx or .idml (and I think .inx is more reliable) from the oprignal, and opeing that for conversion, generally avoids these problems. Exporting to .idml immediately after opening a legacy file can help, but seems to be less reliable doing the export
I've never experienced this sort of difficulty with one of my own files, but there were enough reports from other users here on the forum that I now do the export as a matter of course when updating, and I never overwrite the original version.
This is very good information. Thank you, Peter.
After a lengthy process of elimination I finally narrowed down the location of the text causing the error, though I still don't know exactly what was causing it. I copied the text from the offending chapter back into Word, saved it as plain text to strip out any Word garbage, then pasted back into indd and re-formatted. No more error upon export to PDF. Don't know what it was, but it's gone. Seems like odd behavior that the export function would find some obscure error, but the hyperlinks panel and preflight (set up to find unresolved references) would not.
Sounds v3ry similar in some respects to a problem one of our other regulars was having several months ago. In that case we also managed to narrow down the problem to text on one page, and we cured it in a similar fashion, in that case by exporting the offending text to tagged text and re-importing, then pasting it into position. Good job.