[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: Fred Ma <fma@xxxxxxxxxxxxxxx>
Subject: Re: Importing images by reference rather than by embedding...
From: TechComm Dood <techcommdood@xxxxxxxxx>
Date: Sun, 8 Aug 2004 23:47:43 -0400
Delivered-to: jeremyg-freeframers:org-ffarchiv@freeframers.org
In-reply-to: <4116EAA6.3229329B@doe.carleton.ca>
References: <4116EAA6.3229329B@doe.carleton.ca>
Sender: owner-framers@xxxxxxxxx
> 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. **