A relative path of ./filename is ok, but a relative path of ../../product/version/filename is not. These are on the same drive. So I guess if I pass some information in about the actual book I might be able to work this out but the two paths are going to be very similar:
./filename will look like c:\edocswork\wlp\admin\admin.fm While ../../ales/docs30/userguide/file1.fm is going to look like: C:\edocswork\ales\docs30\usergudie\file1.fm So I would need to know that I was working on wlp and admin to detect that this was a ./ path. Also depending upon if I was to process this document at the root level or down a couple of directories I'm not sure what ../../ is going to translate to if I'm at the C:\. Anyway, I could probably do this, I was just surprised at the result I was finding for a pathname. It wasn't going to be a direct string compare of ../../ to make my fix, so I put it aside in FrameScript. My other substitution for DOCROOT will probably be easier than this relative path because of the way Frame/FrameScript is presenting the information to me, I was just less sure of the places this could occur. My other error may force me to go back in and reevaluate this option, but for now its working for the task its supposed to do. Thanks for the ideas though. ..dan *************** Dan Vint Engineer Sr. BEA Systems Home: 510-522-4703 (generally working from home) Office: 408-570-8554 IM Yahoo: dvint1_99 dvint at bea.com > -----Original Message----- > From: Rick Quatro [mailto:frameexpert at truevine.net] > Sent: Wednesday, November 07, 2007 10:02 AM > To: Dan Vint; framers at lists.frameusers.com > Subject: Re: Possible Frame6+SGML Issue only MIF to Native > and OLE graphics > > Hi Dan, > > FrameScript (and the FDK) always report the absolute paths to > imported > graphics, text insets, and external cross-references. You > have to compare > the path of the current document to that of the imported graphic to > determine if it is a relative or absolute path. The rule is > fairly simple, > though; if the document and graphic are on different drives, > then the path > is absolute, otherwise the path is relative. Again, > FrameScript and the FDK > will always show the entire absolute path. > > There are times when it is useful to see a relative path. I have a > FrameScript function that takes a source path and a target > path and builds a > relative path from the source to the target. > > Rick Quatro > Carmen Publishing > 585-659-8267 > www.frameexpert.com > > > > > My first attempt was to try and replace the process that > was here under > > dzBatcher so that is what I have ended up with so far and this issue > > might be enough to try a different direction. Ultimately I > hate these > > sorts of problems that I can't find an explanation for. Why did > > dzBatcher work with no problem on these files, but my new > FrameScript > > environment is catching the issue. Not knowing what > dzBatcher was doing > > under the covers it might have been somehow ignoring this > problem and we > > just never detected the problem - oh well. > > > > I was trying your recommendation for a different set of replacements > > that occur in HyperText links. Actually the process I was > trying this > > approach on was for some books that didn't follow the guidelines for > > linking and uses the string replace process that is causing troubles > > I've reported here. So this one set of books creates > hypertext links in > > a non-standard BEA way and linked directly to books in outside > > directories. Normally we have the writer insert > > DOCROOT/product/version/filename and my string replace would insert > > something for DOCROOT that was appropriate for the HTML or > the PDF we > > generate. These books instead of using DOCROOT, used a > relative path, so > > something like ../../product/version/filename. So I was trying to > > replace the ../../ with the same info I would replace > DOCROOT with. When > > I looked at these with FrameScript, the path that showed up > was expanded > > based upon the file system (machine and file directory) the file was > > being processed on. So instead of seeing a relative path, I > was getting > > a resolved path based upon where the file was in its > current location. > > So instead of seeing ../../ I was getting something like > > c:/edocswork/ales/userguide/docs30/file1. > > > > The problem with this is I wanted to just search and > replace for paths > > with ../../ in them. Instead I had full paths. Where this > had a problem > > was that links to files in the current book had full paths > that say the > > book was for wlp would look like > c:\edocswork\wlp\admingguide\file1 so > > there was no easy way to tell when this full path was a > relative path or > > not. But when I go to the MIF, it is very easy to find the relative > > paths because they aren't expanded in the MIF output. > > > > I haven't researched DOCROOT substitutions at this point, > mainly because > > I'm not 100% sure where it might be used in the book. So a > file level > > search and replace in MIF gets all instances. I don't think without > > processing every type of object in a loop if there is a way > to do this > > in FrameScript. But I haven't spent a lot of time researching this > > approach yet. I had enough surprises with the one where I > knew that this > > would only appear in markers, I ended up with a couple of different > > markers I had to look at. > > > > ..dan > > > > *************** > > Dan Vint > > Engineer Sr. > > BEA Systems > > > > Home: 510-522-4703 (generally working from home) > > Office: 408-570-8554 > > IM Yahoo: dvint1_99 > > > > dvint at bea.com > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.