Given a sufficient device it's actually a fairly decent format. The problem is that that device has to relatively closely correspond to printed paper sizes, within a factor of about 75% - 125%.
What PDF offers is a consistent, space-persistent, formatted output. For reading longer works, it actually does matter to me where a passage appears on a page, or within a work. Spatial memory is important that way.
I read a lot of material, in a lot of different formats: paged text (manpages, console-mode browsers), formatted HTML, ePubs, DJVU, image-scanned books.
If I'm reading on a largish (9-10") tablet, PDF in one-page-up format is actually really good. Fills the screen, is almost always suitably readable. Scans of old books (thank you, Internet Archive and Google) in particular are a delight -- there's something about reading a century-plus-old library copy with markings and (hopefully not too much) marginalia, as well as the original typesetting and images.
The main problem I have with fluid formats ultimately is their fluidity. I realise that that's perverse, and that there are times when it's a real benefit, but again, I can't seem to get away from that spatial memory thing.
If I'm extracting content from works, I prefer source (LaTeX, Markdown, DocBook, etc.). Though that's another story.
The ability to spin out formats on demand would be an ideal. I'm looking into ways of doing that.
> If I'm extracting content from works, I prefer source (LaTeX, Markdown, DocBook, etc.). Though that's another story.
except it's not actually another story. it's just a different part of the same story. and a format (like .pdf) which only handles one part of the story well (such as reading) but falls apart on another part (like text reuse) is not -- ultimately -- a good solution.
but that doesn't mean .pdf is worthless. yes, it's worthless as an archival format, and as a distribution format. (and those two are the ones which people commonly pitch as _strengths_ of .pdf, unfortunately, which is misguided.)
but .pdf is fine as a one-off output-format, spun out in an on-demand fashion by an end-user who wants .pdf for their own personal reasons (which require no justification to us). this is what you mention at the end of your comment, and i, too, am working on that...
As you note: if PDF is what you want, then the option to request it, or whatever other format is your preferred option, would be excellent user-centric behaviour.
The idea of requesting, say, <item>.<extension>, where extension is [html,pdf,epub,djvu,txt,json,tex,md,csv,dir,...] would be interesting.
This presumes that there's a way to represent the content as, say, a directory listing, CSV, or JSON archive.
pdf is my prefered format of storing information, after markdown and source code, of course. It allows me to portably crystallize visual information without resorting to images which completely wipe out textual information.
