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

[Fred Ma <fma@xxxxxxxxxxxxxxx>]

TechComm Dood wrote:
> 
> > 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.

TechCom Dood, you can call it whatever you like.  Rarely have I ever
seen a comment add as little value as yours above.

> > 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.

What on earth are you talking about?

> > 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?

May I suggest reading the whole post before starting to reply.

> > 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.

Some of us spend time on matters besides documentation, "TechComm
Dood".  There is only so much time for documentation, and we do what
we can.  Some systems lend themselves to stable work while others do
not.  A system where *many* of a document's parts are contained
outside the document works, but that doesn't mean it is the most
appropriate for all situations.

> > 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.

I hope it is clearer from the above, as well as below.

> > 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?

Because that is required.  One cannot expect to develop a system
without sanity checking characterizations along the way.  The system
will not magically work simply by building the pieces and assembling
them.

> > 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...

Probably a system like that wouldn't work for a 300+ book document.
But I fail to see your point.  It was not presented as a system that
would work for all situations.  Anecdotes were solicited and that is
mine.  The bottom line is that there was a need, and that filled it
and met the constraints in time.  The fact that there might be other
methods that could be found with more time is completely irrelevant
because there is only so much time for us to explore these things.  If
your last rather vague comment was about version control, I agree in
principle.  That needs some investigation on my part.

> > 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.

It's a smug generalization that is so vague as to be without value.
Perhaps some specific examples are in order (of course, they will
probably be ones that are completely agreeable).  Of course the ideal
situation is to have the time to lay everything out and have systems
and idioms in place so that things work like clockwork.  Not all
situations are like that.  Not all techies are given the time to
become intimately familiar with all aspects of their documentation
system.  And we don't control all aspects of our environment,
especially so as to work in a completely deterministic environment.

Fred

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