*** From the Archives ***
This article is from January 22, 2009, and is no longer current.
INX missing link bug in IDCS4
Yesterday, I was working on a client project and ran into a really weird InDesign CS4 problem.
I’ve been using IDCS4, but my client still uses IDCS3. The client sent me an IDCS3 file without the links and asked me to make changes to the design. I didn’t need the links because I was just going to move things around on the page and make the layout look nicer. The CS3 file opened in CS4 with no problems, other than the missing links. The names of the missing links were displayed in the Links panel with the missing link icon next to them, which is normal behavior. The file also displayed low-res previews of the missing images in the layout for reference, as it should.
When I finished cleaning up the page, I saved the revised layout as an INX CS3 file and sent it back to my client. When they opened the INX file in IDCS3, the missing links appeared as grayed-out frames in the layout (no previews) and the Links panel did not display their names correctly. Instead, every one of the missing links was listed as “fo” in the Links panel, which left no way for my client to reference the missing links and relink them.
This appeared to be a bug of some sort, and a pretty bad one. I used to export files containing missing links from IDCS3 to INX CS2 all the time and never ever had this problem. After testing this strange behavior myself and getting the same results, I decided to ask David and Anne-Marie if they had by any chance experienced the same problem. Anne-Marie did some tests and came up with the same issue.
Essentially, in order to export as INX in IDCS4 without a missing link problem, you have to have all the supports linked at all times. It appears as though the new features in the CS4 Links panel are not translating well through INX CS3. This means that your clients will always have to provide the links, which is a major hassle for them to have to collect and upload to a server for every small layout change that needs to be made. The only other option is to use IDCS3 for all client projects that were created in CS3 and stop using IDCS4. Considering that the majority of my design clients are still using IDCS3, this renders CS4 pretty much useless.
We’ve contacted Michael Ninness, senior product manager for InDesign at Adobe, and he has notified the development team about the problem. They’ve confirmed that it is indeed a bug, and are “officially investigating it.” Hopefully, the development team will find a fix for this problem and it will be repaired with the next update.
 |
Ted, this was great sleuthing!
But if I’m sharing files with a client, I just stay in the version they’re using. Much fewer hassles that way. I have to keep ID CS2 installed because one of my largest clients uses it and we trade files all the time.
If the majority of your clients are using CS3, why not just use CS3 for their projects, and use CS4 for your own stuff until they catch up?
I agree with Anne-Marie. That’s sound advice. In fact, I have every version of ID installed on my machine from version 2 up, just in case I might need it for a client who hasn’t upgraded.
However, sometimes I forget when a client is using IDCS3 or earlier. I’ll rework a file in CS4 and finish up before I realize that, OOPS!, I probably should have used CS3. It’s in these instance that I rely on INX to save me.
I wouldn’t rely on INX for every job, but I would like to see it function better. This missing link bug is one that should definitely be fixed.
This idea of keeping previous versions of InDesign raises an issue I’ll soon face.
On my current computer (an iMac), I installed the full version of CS2 when it came out.
When CS3 came out, I bought the upgrade which allows me to have CS3, and retain CS2. That has come in really handy.
But I’m going to buy a new computer soon, and along with it, CS4.
Here’s the question…
If I want to buy an upgrade to CS4 for a new computer, I’d need to install my full CS2 on the new computer first, then the CS3 upgrade, then the CS4 upgrade, right? (That’s assuming I want all three on the new computer.)
Personally, I’d love to just install the CS4 upgrade on my new computer and keep CS2 and CS3 on the old computer. But that new computer would have no trace of the previous versions I own on other computers, and, I’m assuming, not allow me to upgrade.
Can anyone clarify how this works when you’re upgrading over multiple versions, but switching computers somewhere in the process?
The way I understand it, you don’t have to have the previous versions installed on your computer, as long as you retain the SERIAL NUMBER of the earliest version. I believe the installer will just prompt you for that original serial number. I can’t verify that from my experience, however.
I agree with Ann-Marie, stay in the version that the client is working in. It can be a hassle, but I know that as late as 2008 the company I was working for was still getting requests to make edits on books that were built in Quark 4.11. It is great to get the new versions and play with them, but there are some segments of the industry that are VERY slow to upgrade and even when they do they may have a need to work on those legacy files without the extra expense of upgrading and doing a QA.
Ted,
Great catch!
re: “sometimes I forget when a client is using IDCS3 or earlier”, it sounds like it’s time to install Rorohiko’s InDesign Proxy or my little Adobe InDesign Multiversion Opener app. That way double-clicking the file will always launch the correct version of InDesign instead of accidentally upconverting the document to whatever you have running.
EDIT: And Jerome is right. Some segments of the industry are *extremely* slow to convert. We may finally be allowed to start doing files in CS3 this quarter… W00t!
Thanks, Steve.
I figured I’d call customer service and double-check. They confirmed what you said.
(And I’m still amazed that at such a large company, I was able to talk to a human within 60 seconds.)
I ran across this issue when I was preparing my INX demos for the InDesign Conference. I found a solution, but it’s involves some XML geekery.
What happens is in the LinkInfo property of each link element, the first instance of the file path is changed from a relative to absolute. For some reason, CS3 freaks out when it sees those paths and shouts “fo” which I assume is short for “forgive me, o’ master, I have failed.”
I was able to make the problem go away by opening the bad INX in a text editor and deleting the path up to the filename.
In the bad file it looks something like this:
Lnkl=…Users/rankinm/Desktop/goober.psd…
It should be just …goober.psd…
When the new Untitled file opens up, it behaves as expected.
If you’re doing a Find/Replace on the INX, you have to be careful to just replace the first instance of the path in each c_lnk element. There’s two other instances that need to stay put.
If this is hard to picture, make an INX with art present, then move the art so it’s missing and make a second INX. Then open the two files in BBEdit or the like and highlight the differences.
It’s not a one-click solution, but until the bug is fixed, at least it’s something.
Ooooh Mike you smarty pants you! Very cool fix.
I’ve hesitated to suggest it, but might as well … another fix would be to have the CS3-using client embed all the images before sending it on to the CS4-using designer. Just shift-click all the links in the Links panel and choose Embed from the panel menu.
Doing so increases the size of the ID file (if it has a link to a 3 MB image, the INDD file grows by 3 MB) so if you’ve got a lot of huge high-res images in there, probably not the best solution. But there are many other types of layouts that work well with embedding.
So it’s only one file to send (instead of packaging), and when the CS4 user exports it to INX, the full embedded images are still in there, and so are still in there when the CS3 user opens/converts it back to an INDD file.
And it’s easy enough to unembed them whenever you need to.
Is this an issue when converting from CS3 to CS2? I have CS3 at work and CS2 at home, so I convert to .inx for when I work from home. Hasn’t been a problem for the past couple of months, but just found this morning that I’m unable to open the .inx file in CS2 that I created yesterday and one that I created two days ago on CS3 (although I can still open all .inx files that were created 8 days prior). Have there been updates? I don’t understand how I can’t open the recent files, but can still open files made 8 days ago or older. Any thoughts?
Hi Megan, as far as I know there have been no updates to CS2 or 3 in a long while. Maybe you installed something on your computer that is somehow conflicting with CS2’s ability to open the INX files? See if you can find another CS2 user (patched up to the latest 3.01) to try to open them.
We’ve noticed something similar to what Ted has found, but in CS3. We had a number of CS files that had been convereted up to CS2 that we were modifying extensively. Because we wanted to make sure that we weren’t introducing any legacy errors so would export the CS2 files as INX files and open them in CS3 . If the links were linked when the export was made, no problemo. However, if our links were broken, we got the mocking gray boxes. Sometimes the link name remained the same, and sometimes it would be abbreviated to 6 characters with a number, and if the first 6 characters of all the files were the same . . .
Hi Cinnamon-
The MBGs (mocking gray boxes) would be expected for unembedded art, if the art files were missing when the INX was reconstituted in CS3. But it shouldn’t matter if the art was missing when the INX was made. So long as it’s where ID can find it when you open the INX, the new file should be OK. Could the art have been moved or renamed? or any part of the file path changed? Does it happen if you put the ID file in the same folder as the art?
As for the mangled link names, I’ve seen something like the random 6-character abbreviation, but it was a long time ago (2005) in a galaxy far far away (CS). When I exported an ID file to PDF on a Mac (OS X 10.3), and the resulting file name would be longer than 32 characters, the filename was truncated and the random 6 appeared preceded by a #.
So what should have been
12345678901234567890123456789.pdf
was named
12345678901234567890#xxxxxx.pdf
where the 6 x’s were random numbers/letters to us humans.
You can see the same thing in an INX file where the linked art has a really long file name (even in CS4): LnkI=”x_c_c_12345678901234567890#3D6896.png
However, it reconstitues fine nowadays.
I had a similar (if backward) problem lately with an author who was on the road with a laptop that only had CS4 and a Production Editor who hadn’t upgraded yet. I made the INX conversion during my development review, but I had to follow the advice A-M had given me (thank you!) and have the linked files on hand. Normally I would have just relied on the preview images for this phase of editing, avoiding the need to transfer and store the large image files myself.
I’ve always wanted an easy way to create copies of the preview files for various uses when I don’t want all the high res linked files to have to fly around from person to person. Imagine if you could ask ID to just create a set of low res versions from the previews. A bunch of uses come to mind, including the ability to rename files based on the order they appear in a document. (Useful for books where authors might not follow our image filenaming conventions and I can get them out of hot water before the PE ever sees it.) In this case, you’d not send the low res long, just let person down the line relink to the high res.
(By the way, I do have a workaround for creating real placeholders from previews for linked files I don’t have, it involves making a PDF with the previews, though, and extracting them with Acrobat. I wrote it up on deke.com a while back.)
The problems that arise with compatibility and new versions, and this applies particularly to InDesign, hold back adoption of the new releases in my opinion. Seems like most projects are on the kind of deadlines that don’t allow for luxurious experimentation and troubleshooting. But it would be fun (and educational) to use the latest and greatest on live projects more often without fear of throwing a monkeywrench in a giant deadline-critical project.
Bug squashed.
This bug still exists in the Mac version (currently running 6.03).
The fix is to save the INX file from the Windows version of CS4 (I used 6.02).
We seldom have access to the links, so when this happens (and yes, it does happen sometimes) we can’t fix the customer’s problem.
However, we often have a source document with all link search paths intact.
I have tried exporting both documents to inx, then opening them in Word. Then copying and pasting each link tag from the correct inx file to the broken-links inx file, with a simple Word macro to step through both files and copy/paste. I used the entire link tag, not only the LnkI parameter.
It seems to work… the fixed inx file opens up in InDesign and the now the list of links looks the same as in the source doc. The grey boxes are still there, of course. I have tried it with a dummy document with my own image links also, and yes, the grey boxes do disappear when I supply the image links again.
hello sir
i have a big probliem with IDcs3.
i created my file by using IDcs2 and i install the IDCS4. i opend the file without any proplem and made some updates and closed it. the IDcs4 i have is a trial version i made Inx file by exporting the file to be opend in cs3. the problem that when i open inx file all links is missed, the file open but without any link. what can i do.
thanks