Possible Frame6+SGML Issue only MIF to Native and OLE graphics

[Rick Quatro]

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