[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Importing images by reference rather than by embedding...



> I prefer importing images by copying.  LaTeX is a fine document
> preparation software, and I encountered some of the same problems
> I had in LaTeX when using FM with import-by-reference.  That is,
> I delete a picture, think that I can delete the file, but find
> that it is referenced somewhere else.

Well, not to sound arrogant, but that's just poor documentation management.

> I personally don't find the bigger file size that much of a big
> issue, since it's somewhat made up for by the fact that I don't
> keep the images around.  These images are generally created by
> other data-munging tools.  If an FM file gets too large, I merely
> start a new file in the book.

Perhaps that works in an unstructured environment, but not in a structured one.

> For my purposes, it is not an advantage to have the document
> constantly updated because it has a live link to an external image.
> When I document something, it is to capture information.  That means
> taking a snapshot of the state of information at a certain time.  I
> want to be confident that when I look back at information captured on
> Aug. 8 2004, it *really* represents the information at that point in
> time.  

What does this have to do with importing images by reference?

> I had the same problem with hot links in WordPerfect.  Having
> your document constantly and automatically change according the
> anything that can happen outside the document does not give a
> comfortable feeling about the stability of the information.  

It's as stable as you make it. If you work in a wild, unorganized
fashion, then expect instability in your documentation architecture.

> It is
> enough of a logistical challenge to keep track of information outside
> the document that I prefer more certainty within the document.  

I don't understand the logistical challenges you speak of.

> An
> analogous example from software/hardware development is to take
> regular snapshots of the state of design work so that if something
> changes and causes problems, you can go back reliably.  For FM, this
> is especially important if the captured images represents data plots.

Why are you taking snapshots of data plots during the development cycle?

> I keep the 10 most recent snapshots.  If
> something goes wrong, I can drop back to the last snapshot and
> retrieve any damaged files, then bring them back up-to-date.  

Hmmm... I'd love a system that would do that for 300+ books worth of
binary files. Maybe that's why we're looking at a content management
system...

> Never a
> pleasant task, but it hasn't been necessary so far.  Having such a
> history of the state of projects has been helpful in other ways, when
> I made big, questionable changes.  I can go back and compare.

Change should always be questioned beforehand, not after the fact. But
that's just me and my philosophy.

** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **