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 [EMAIL PROTECTED] > -----Original Message----- > From: Rick Quatro [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 4:36 AM > To: Dan Vint; framers@lists.frameusers.com > Subject: Re: Possible Frame6+SGML Issue only MIF to Native > and OLE graphics > > Hi Dan, > > One thing to consider: it may be better to do your string > replacements in > FrameMaker without going to MIF and back. Since you are using > FrameScript, > you may be able to do these replacements in the binary file > (depending on > what exactly you are doing). > > Rick Quatro > Carmen Publishing > 585-659-8267 > www.frameexpert.com > > > >I have a process in which I run both Frame 6 and 7 documents > through an > > automated build. One step in this effort is to save all the > files to MIF > > and do some string replacements on the file, then save that > result back > > to Native form so I can print the documents. Note that is > this case no > > substitutions were made, so it is just a round tripping of the files > > from MIF to Native > > > > As these files are saved back to Native (via FrameScript) > I'm getting > > the following error/warning from Frame: > > <<SnagIt.jpg>> > > This has occurred on 4 different books, not sure if they > have been all > > Frame 6 or not, but this last one is 6. One of the books we couldn't > > track the problem down and had to rebuild it. The other 3 > seem to all be > > related to embedded OLE graphics. Is there some known > problem with OLE > > embedded graphics or an issue with saving from MIF back to Native? > > > > ..dan > > > > *************** > > Dan Vint > > Engineer Sr. > > BEA Systems > > > > Home: 510-522-4703 (generally working from home) > > Office: 408-570-8554 > > IM Yahoo: dvint1_99 > > [EMAIL PROTECTED] > > 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. _______________________________________________ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
