MHTML does the packing thing fairly well for HTML based documents, and support is fairly common. Depending on the system, even something as simple as a ZIP file can be used as a package the browser can access.
Personally I don't like HTML as a documentation format, but in some cases it's the least worst option. Usually I prefer PDF.
Sounds like you need something more like a traditional librarian, to write what used to be a card index for each of the documents.
I havent tried it for documents, but it occurs to me you could use the Windows Properties of a file to store related information, like the way they do it for music files or photos.
The Windows Search function will ( mostly ) find that info when you use it.
-- Regards, Adrian Jansen adrianjansen at internode dot on dot net Note reply address is invalid, convert address above to machine form.
I've drunk the RDBMS Kool-Aid so see DB's as a solution to lots of problems (regardless of how well it actually *fits*! :> )
I've been working on a schema to let me track what "needs" to be tracked without having to tolerate the restrictions of a particular OS, file system, etc. E.g., what if you have two revisions of a document bearing the same title? Do you append "Revision XXX" to each? How do you record the names of the authors (and their affiliations) in a manner that is searchable -- even if the document is not? How do you encode special characters in document titles: "A New I/O Paradigm: What it Means for You!"
What do you do with documents that are *collections* of other documents? E.g., "A Set of Papers on High-Speed Potato Peeling, F.Fry, Editor" Can you reference the individual papers within? Or, do you have to rely on some ad hoc mechanism to expose the contents?
It's easier to just use the filesystem -- WHICHEVER filesystem! -- as a means of storing "bulk content" and use another mechanism to apply meaning to specific content (metadata). That way, what I choose to *add* can be handled outside of the scope of the file formats, filename limitations, etc.
(E.g., many web pages have insanely long "names". Save them on a Windows system and you bump up against the 260 character pathname limit really quick -- especially if you are starting from someplace far below "\")
With HTML, you're always worrying about browser compatibility, plugin versions, etc. There will always be things that you CAN do in a browser environment that you *can't* in a document format like a PDF. But, taken to extreme, why not build a VM for each "document" and just archive VM's?
With such, not only can your atlas contain 2D (and 3D!) maps, but it can also contain photos of wildlife in each locale, sound recordings of their mating calls, phonebooks of their inhabitants (with LIVE updates!), *up-to-date* exchange rates for their currencies, heck, even an automatic renaming and resurveying capability to reflect ongoing political changes, conflicts, etc.! :>
And, you'll spend all your time updating plugins/modules so you could access this information -- when all you really want to know is if it was landlocked or not in 1783!
"Large municipal libraries" will have archivces of newpapers on microfiche, and/or digital media also audio and video recordings.
-- umop apisdn
The point was, *paper* has been a successful medium for many hundreds of years -- because our hands and *eyes* ARE "a good fit for all purposes".
The (relatively) *recent* problem is trying to consume materials that were intended for this form of presentation (paper & ink) on devices that don't lend themselves to it, directly. E.g., small screen sizes, pan&scan issues, limited resolution, etc. Hence my comment re: trying to read a (print) book with a telescope or microscope...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.