TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Image management in docs continues to be a complex issue that is
rarely handled as successfully as we might wish.
This is particularly true with successive releases of any given doc,
which may involve some but not all images changing from prior
versions. How do you keep up with what is the latest version of any
given image as the versioning of the docs continue to increase?
For example, I had a gig doing docs for a telephone switch. These
things typically have long lifespans, with many revisions during that
time. One revision cycle may have only a few changes--but the entire
doc may be several thousand pages long. In the case of the switch I
was documenting, there were two versions of docs, too--one for the
civilian market, the other for the military. Here, too, some images
were common while others were not.
We didn't have a fully satisfactory solution at that time. I suspect
that today, if I were responsible for documentation, I would seriously
contemplate a change control strategy with one complete set of images
kept current, with labels in that directory identifying the image by
some standard naming scheme. Any doc could point to this "current"
directory, and when updating the doc versions all the links would
still work but they would point to the most recent versions of the
images.
A suitable version control system could easily enable recreation of
any particular version of hte docs, too, should a need arise.
Another possibility that may be worthwhile is to use symbolic links to
actual file locations in some standard directory for Frame to point
to. This may give a fairly simple way to maintain a single reference
that would leave your template images directory clean, while also
having the same structure you want to use for doc-specific images
elsewhere. The technique for creating a symbolic link in Windows
varies with the Windows version, as I understand it, but you can find
references for your version easily with a search for "symbolic links
Windows."
David
On Fri, May 14, 2010 at 09:00, <techwr-l-request -at- lists -dot- techwr-l -dot- com> wrote:
> From: "Monique Semp" <monique -dot- semp -at- earthlink -dot- net>
> To: "techwr-l" <techwr-l -at- lists -dot- techwr-l -dot- com>
> Date: Thu, 13 May 2010 15:05:42 -0700
> Subject: FrameMaker paths to imported images...
> Hello, Techwr-l-ers,
>
> I am wondering if anyone can explain the ins-and-outs of how Frame manages paths to imported images? Or rather, is there a way to control it? (I've figured out what it does, and know what to be on the lookout for, so I'm not having any actual production issues. But it's been a bit cumbersome, and I'd like to know if there's anything to do about it.)
>
> I have looked at the FrameMaker help files (version 7.2, but I don't think the version matters here; it's been consistent for at least the several versions I've worked with), but they don't seem to answer my questions.
>
> <Sorry this is a long description, but I don't know how else to explain it enough to get to the point of my question. So most of you can just click delete now :-) >
>
> So here's the scenario: I've got my templates in a Template directory, which contains an images directory with the common images (logos, alert icons, etc.) In my Frame templates, I import the images by reference, and point it to the Template\images directory. No problem.
>
> But when I work on Doc_A, in a directory at the same level as the Template directory, and with a parallel images directory structure that contains both the common images and doc-specific images, Frame keeps wanting to find all the images in the original Template directory.
>
> And if I reset them to the Doc_A\images directory, but then import master pages from the template in the Template directory (because I've changed the page layouts), Frame of course again wants to find the images in the Templates directory. That's pretty logical, and I don't really have any issues with that.
>
> But... of course I have more than one doc: Doc_B, Doc_C, etc. And here's where I'm surprised at what Frame does: if I open Doc_A, reset the images to the Doc_A\images folder, and then open Doc_B, Frame automatically wants to use the Doc_A folder for Doc_B's images!
>
> I've been working around this by closing Doc_A, renaming (temporarily) the Doc_A directory to Doc_A_sav, and then opening Doc_B. Because there's no longer a Doc_A dir, Frame will say that it can't find the images, and I can tell it to use the ones in the Doc_B\images folder.
>
> So, why does Frame remember the most recently used path for images, is there a way to tell it not to do that, and (most desirable), is there a way to make it look for relative paths (I always want it to use an images subdirectory under where the .fm files are)?
>
> TIA,
> -Monique
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
- Use this space to communicate with TECHWR-L readers -
- Contact admin -at- techwr-l -dot- com for more information -
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
