Actually let's put this help request on hold for a minute. I have been doing some experiments to try and track down what is happening. I loaded a new project and brought in some older versions of the word docs and did some testing to see if it was the new service pack to Robohelp, and it seems the old versions work correctly.
I am thinking it may have to do with some formatting that was done in the word doc. More specifically to "Hyperlinks" where I asked the author to make the link targets to be "Page Default (same frame)". He mentioned to me after I made the request that he found a "global way" to set it on the entire document so he didnt have to manually edit each link in the word doc individually. I dont know what his method was and he is on a plane at the moment so I wont be able to speak to him about it till later today or tommorow. But I do think this may be the culprit. The link targets show in Word as same frame and in Robohelp as none. But there may be some kind of global variable stuffed away in a css or somewhere in Robohelp that is affecting the image paths also.
I'll post back and look for any added info from you later.
Well pretty sure I figured it out, though didnt waste a bunch of time trying to prove it to myself. I had mistakenly made a trequest to the Word Doc creator to use a target frame of "Same Frame" on his links in the word docs, though the desired result was acheived with a standard (none). Upon importing these docs to RobohelpHTML, the link properties were reported as "none" though when compiling the WebHelp or FlashHelp, Robohelp would put an "hhtp:///" on all image paths that were relative, so as opposed to ../folder name, you would get http:///foldername, with no domain information.
Anyway, it was a fairly small project, so I fixed it by performing a Word "Copy and Paste" from the offending word doc to a new one, which seemd to strip out the target frame info and replace it with the new docs default setting of none, then re-importing my word docs to Robohelp.