Mar 10 2009
XMPIe “Missing Plug-In” Issue
A client sends their InDesign CS3 files to a printer, who makes any correx, then returns the corrected file to my client. When the client reopens the file, they receive an error message indicating that they are missing plug-in “XMPBackEnd5.pln.InDesignPlugin.” Usually, this is just a courtesy announcement; plug-ins for InDesign are supposed to be written so that their absence doesn’t mess things up for a recipient who doesn’t have the plug-in.
But in this case, it’s not so innocuous: the file opens, but my client cannot package it after they have worked on the file. The only solution is to run it through InDesign Interchange and open the INX file; this removes all desire for the missing plug-in. Then, the file behaves normally, and can be packaged successfully. Nice that there’s a workaround, but this is no way to live.
LATER NOTE: the XMPie uDirect plug-in seems to leave this residue only if personalization data is added to the file. If a clean file is simply opened, worked on and saved, there’s no problem down the line. The issues arise when personalization data is added, and then the file is passed on to someone who doesn’t have the uDirect plug-in. So it’s not universally dangerous.
I received this response from XMPie support: “Thank you for pointing us into this problem. I have sent this request to our Product Manager and I hope that this problem will be handled in future versions of XMPie.”
If you don’t know what XMPie is, it’s a powerful and nimble variable-data solution for InDesign. I’ve seen it in action, and it is very cool. But beware of this glitch until it’s fixed.
Claudia,
It is indeed true that this error shows that the file has been worked on using the XMPie plug-in for InDesign at some point. XMPie embedded a large amount of information directly inside the INDD file to allow for some complex personalisation.
If you need to continue to work on the file – you could always download the free uDirect plug-in from http://www.xmpie.com which will allow you to both work on the native file, and to add some personalisation of your own to designs.
It’s never a problem – always an opportunity
David,
Thank you so much for the information! Does the uDirect plug-in allow the end-user to then package their file?
My customer’s job doesn’t contain any variable data; it’s just a straightforward print job, but this is good to know. They don’t always deal with the same printer, either, so they need clean files that don’t give surprises down the line, as you might expect.
Thank you for taking the time to comment.
Interesting as the XMPie plug-in should only embedded tags into the INDD file if it is used to personalise the document.
At least if you don’t have the plug-in and it complains; then you can download it for free and carry on working on the document.
It’s true that downloading and installing the trial version of uDirect does allow the user to package the file (I just did an experiment). But then everyone who touches the document has to have that plug-in installed to package the file after they’ve made corrections. Then they have to remember to disable the uDirect plug-in when they work on other documents, lest they leave other recipients in the same situation.
As I said, I think XMPie’s products are very cool, and they do amazing things with variable data and personalization. But plug-ins are not supposed to leave this sort of residue in a document. I’m sure that now that XMPie is aware of this issue that they’ll fix it in a forthcoming version.
Agreed – There’s a new version in Beta. Let me check with R&D.
David,
I did another experiment: this time, on a fresh file (not the customer’s problem file) I created in InDesign CS3 with the uDirect plug-in active. And, sure enough, I can open *that* file without uDirect, and there’s no error message, and no problem saving and packaging it. So, just *having* uDirect active didn’t affect the file’s behavior.
So this implies that the printer *did* perform some personalization. Perhaps knowing this will help you find where the problem is. I do love a good mystery, don’t you?
You beat me to that test; which was on my list-of-things-to-do-today! Thanks.
In essence if a customer uses the uDirect pug-in to relate a document to a data-source or counter, then XMPie starts embedded information within the document; thus needing the plug-in in the future.
However a small test that I did do this morning was to create a new document; which used the uDirect plug-in. I then disabled the plug-in and re-opened the document. Sure enough InDesign complained that the plug-in was not present; but did give me the option to continue on with out it. I made some amendments to the document before saving over the original and opening it back up with the plug-in and all seemed well.
This was done using CS3 and uDirect 4.5.2.
And I thought I left pasteboard behind me.
Also, dumping out to interchange and bringing back added a text inset to a bunch of my text blocks. Definitely very annoying. So be sure to double check the file.
Stephen,
Does your experience match mine: i.e., this happens only if personalization data has been added?
From my exchanges with the gentleman from XMPie (later portions of which I took offline just for simplicity), I’m given to believe they’re working on a fix. And yes, it is a bit of a flashback to the PasteboardXT. I have to say that Markzware has more than made up for that gaffe with their fabulous products, though! I suspect XMPie will do the same.
That’s also why I mentioned that AFAIK, Adobe stipulates that a plug-in not cripple any functionality for users who don’t have the plug-in.
I feel certain this will get fixed. I’ll keep everyone posted.
There should have been no personalization with this file. I have contacted the printer and suggest that they too put in a call to xmpie to put a rush on this. We deal with multiple printers, agencies, and designers so I do not want to subject them to this. I just spent 4 hours combing thru a document after discovering the text inset problem.
Stephen,
Are you using CS3 or CS4? If you’re using CS4, I’d be interested to see if exporting to InDesign Markup (IDML) would provide a more faithful round-trip. (IDML isn’t available in CS3.)
What does the printer say about their handling of the file? Can they guarantee that they didn’t put any personalization in the file? I’m curious because my customer’s file (which inspired this saga) shouldn’t have had any variable data in it, either. And my own few experiments led me to believe that simply opening, modifying, and resaving didn’t introduce the packaging problem.
This has turned into much more excitement than I’d anticipated… let me know what you hear from the printer.
Interesting to see others with the same problems as I have.
My former colleague had xmpie installed on his computer, and even though he rarely used it, all files are now “infected” with the plugin.
I cannot open up a single file without indesign complaining about the missing plugin. The most annoying part is that I no longer can package my files.
I could install xmpie on my computer too. But then will everyone else down the line have the same problem as I. Does anyone know how to repair the files?
Br,
Anna
Anna,
If you export to InDesign Interchange, then open the Interchange (*.inx) file, that should remove the XMPie “poison.” I should caution you that one other commenter has said that doing this changed the text inset on some text frames. I haven’t seen this happen, but it’s worth mentioning.
And if you’re in CS4 and you experience that text inset issue, maybe try exporting to InDesign Markup (idml), and open that back up.
Please keep me posted
Claudia,
You are correct in saying that users of CS4 should export to IDML – doing this will ensure that there layout is safe from modification. Comparatively, INX was an internal Adobe format that was designed to make documents backward compatible with previous versions of InDesign – hence, not all layout options being supported in the format… INX was never intended to be full proof.
Im sure their used to be an option in CS1 or CS2 to “remove missing plugin data” – oddly, that now appears to be missing from CS3 + CS4.
Timothy.
Timothy,
Thank you for your comment. My understanding is that IDML will be the “transporter” format going forward, used both for backsaving and for repurposing InDesign content for other uses. I’ll be interested to hear whether IDML solves the text frame inset issue; if it does, I’ll recommend that to other users who are going through this.
Of course, this isn’t available to users of CS3…
I’m still on CS3 and would be remaining, but a new project is forcing us to upgrade. I also noticed that some boxes that were “unassigned” were converted to text boxes.
CS 4 should be here soon. If I have time I’ll try the IDML export.
I never noticed the “remove missing plugin” feature, but I would say that xmpie is at fault here.
The option to remove missing plug-in gunk was last seen in CS(1) as far as I can determine from a couple of quick experiments with older versions of InDesign. Apparently it’s time to bring that back!
Folks, I’ve been chatting with the R&D team on this issue. For all the details check out my blog, http://david.baldaro.me.uk/2009/03/xmpie-and-the-missing-plug-in-issue/
We have had the same issue. The easiest way to strip that content (assuming you aren’t going to make edits and resubmit the file for additional variable content using XMPie) is to export it as an INX file. When you open the file back up in inDesign it will no longer contain the XMPie tagging, and won’t prompt for the missing plugin.
Hey, I’ve been having the same problem. I was using XMPie and Darwin (trials) on my CS3 install, and when I moved to CS4 without those plugins it’s given me a lot of grief. Since it seemed like exporting to .INX was the best solution I wrote a Javascript that automates most of the process.
http://www.mediafire.com/download.php?zo3uqymwzwz
If anyone would like to help me test and improve it I would love it, it’s working well for me on OS 10.5 but I’d love to know if it works on PC as well
In short it -
1) Asks you to re-save the file (I recommend saving a copy since it will overwrite it during this process)
2) Exports to INX
3) Closes the document
4) Opens the INX version
5) Saves the INX version as an INDD file, overwriting the original with a new, plugin free file
Code is provided as is, so please be careful with it! I highly recommend using it on backups only!
The easiest way to install it is to go to Window/Automation/Scripts, right click on the User folder and Reveal in Finder. Then copy the file into the Scripts Panel folder, and you should see it
-Tim Porath
skooges@gmail.com