[Cephas Atheos]

[Note : My apologies to anyone actually interested in this thread, and particularly to Agama and fratermus : I've had a technically challenging week (I have a number of embedded medical devices to help manage a spinal problem, but one of those failed this week) and so I'm quite literally flat on my back at the moment... and it wasn't just an internal "technical difficulty" : the wifi router chose this week to munch it's own brain, so I've been wifiless until a couple hours ago. I don't know which device failure was worse... So I wasn't being intentionally rude, I swear! Please accept my apologies for the delay, and I hope the drivel below is enough to go on with... - Pete]

Primarily, I use plain text as a fallback, worst-case-scenario archive format. It's been around since microprocessors started using 8-bit data paths, and all my text editing and retrieval tools are Unicode aware, so multiple source languages aren't an issue from that perspective. I've had some "pointed" questions asked of me by various folks with an axe to grind about ASCII, but to be honest, I'm quite happy to use ASCII if the source material's in English.

The reason I also use PDF as an archive option has more to do with the original intent (and the longevity) of the portable document format. I have some material that was encoded with Acrobat 1.0, and that's still perfectly readable in the latest readers on the iPhone, iPad, Macbook pro, and all my other notebooks (HP Omnibooks, HP palmtop, Jornada, and Kindle DX), as well as my main system running Win7 x64.

So it's been - up until now, anyway - a bit of a no-brainer as far as having a "universal" format that preserves both the full document and all the metadata I can poke a stick at!

Since storage isn't an issue, I have no need to compress any material, nor do I have to worry about changing compression algorithms or incompatibilities in that area. While that may sound artificial and contrived, a few weeks ago I had to try and unpack a CP/M .lbr archive containing some technical manuals in WordStar 3.3 format, and I ended up writing my own decompressor since no modern archiving utility on any platform still handles that format! But back in the day, there simply was nothing better than WordStar, and no better archive/library manager than LBR! But things change in the long run, I guess!

So I hope that helps clarify why I selected and use what are (based on recent, unrelated, comments in a couple of documentation forums I try to participate in) fairly universally ignored (or at least, misunderstood) document formats for my long-term archiving.

However, as a rational and sceptical person, I'm always open to suggestions for better document archive formats (by "better", I suppose I mean more powerful/flexible, more widely supported, with stronger pedigrees and broader future possibilities on more platforms). So if anyone has any suggestions, by all means, I'd like to hear your ideas!

Hopefully this is helpful!

[EDIT]
Oh, I forgot to answer your point about reflow and rendering speed...

As far as reflow goes, my primary interest as an extremely fast reader, is quick display of maximum text, as well as fast access and navigation, and I haven't reached the limit of PDF readers yet. The Kindle DX is the touchstone there for me. It's faster when displaying commercial ebooks (MOBI, AWZ, EPUB), but like most ebook readers, it's terribly limited in terms of margin and font options in those modes. So while the HTML format is faster in terms of reflow and rendering, it's a real waste of time for me!

That's another reason I prefer PDF formats for reading on the Kindle - the resolution is good enough that I can publish to PDF using a small enough font size and small enough margins that I don't have to turn the page every 5-10 seconds. Since I normally read at around 800-1,000 wpm, that translates to roughly 30-45 seconds per physical paperback page, depending on font size and layout. Of course, I'm slowing down as I age... I used to read flat out at around 1,800 wpm, but my eyes ain't what they used to be, so I've slowed down since getting reading glasses. But I still read many times faster than most people, so volume (maximum text density) is still critically important to me, more so than raw display update speed.

For me, a typical MOBI or EPUB commercial text, at maximum 'native' resolution, has me pressing the 'next' button about every 18-20 seconds on the DX (minimum font size, minimum margins, maximum text per line). But that flattens the battery in about 4 days! (Boy was I unhappy when I found that out. Amazon technical support informed me that they tested the battery life with a 'typical' page turn time of between 50 seconds and 2 minutes per page at the default text settings. But I was turning the page between about every 5 and 11 seconds at the default settings. So much for "battery life up to a month"! I later tried both a standard Kindle someone lent me, and a Nook I tried in a demo, and I was flipping pages 6-12 seconds apart, which was a total PITA...)

So the DX - which is what I read 95% of my digital text on - has a PDF rendering speed, at the lowest font size and narrowest margins, much faster than I can keep up with. So rendering and reflow aren't the deciding factor for me because the limitations are the size and resolution limitations on the devices (that I can afford, anyway) that have technically faster text reflow and page rendering speeds. In fact, I can read far more, far more quickly, on the DX than I can on anything else in production, including my laptops and my main system, and any speed improvement inherent in the other devices is irrelevant because of the resolution limitations. Plus, the limits most devices -including the Kindle- put on higher text density and font sizes means that I don't care how fast they render and reflow the text, because I'm completely distracted pressing the 'next page' button instead of reading.

But that's just me, and I understand that real people (with lives and friends and stuff) enjoy and appreciate the other devices and the clever and complex (and fast!) rendering and displaying they do. It's just not for me.

Hopefully that addresses the non-technical reasons for the choice of my archive formats...

Sorry for the long boring story.