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
[EMAIL PROTECTED]
_______________________________________________
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.
