![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
This Gentleman Prefers Pages
A little-noted but absolutely crucial divide in the ebook world hinges on the question of whether book pages—numbered sequential blocks of text with a fixed format—are necessary, or even useful. I've been mulling this ever since I first loaded a Web page in late 1993 and watched it reflow text as I dragged the lower-right corner of the browser window around. Reflowing text stuck in my craw, in part because I was a magazine editor at that time, and magazine pages have very definite layouts.
I've flip-flopped on the issue many times over the years, but I've recently come back to my original position: The page is essential. Ebooks need page structure so that we have a universal, human-readable notation for identifying a location in a large document. This location must apply identically to all editions of the same work, whether print or electronic. If the equation is on page 201 of a print book, it should be on page 201 of the ebook. This requires that the ebook have a page 201, and in a lot of modern ebook reader software, page numbers are dependent on font size, meaning that they're basically meaningless.
The argument that text needs to be displayable on many different shapes and sizes of displays always seemed like a non-sequitur to me. Laying out a book into pages does not preclude reflowing the text in a window. I know enough about PDF internals to say with some confidence that a properly designed PDF viewer could render a PDF as reflowable text with page boundaries shown by a dotted line. All the information is there in the PDF; it's up to the viewer how the text is presented to the user.
So all the seething arguments about page-oriented versus reflowable file formats is kind of ridiculous. It's not about the file format. It's about the viewer. I see no reason why the industry could not standardize on PDF documents and create special-purpose viewers for devices with small or otherwise nonstandard displays. Certainly, as a publisher I'd prefer to create just one single file format for a published work, supporting both print and electronic editions, and let the viewer software adapt to the limitations of the underlying hardware.
Right now, ebooks are mostly fiction and purely textual nonfiction because our low-power portable displays aren't good enough to render complicated page images well. That's a temporary limitation. I think that within five to eight years we'll see letter-size tablets with full-color, 1200 DPI electrophoretic displays that can render a page image pretty much as well as paper. This will allow ebook editions of comics, kids' books, art books, and figure-intensive technical books without any compromise, and if you want to go crosseyed reading something like that on your cellphone, well, it's up to your software. Page images are the baseline. Subset the format however you prefer, and we'll all get what we want.
I agree - a page break can be embedded where it goes, used as a benchmark - but I disagree also: They're an archaic holdover, like saying that you 'dial' your phone. Remember how 'pages' started. An ebook is not papyrus, nor do the length of flattened reeds need to be taken into account. Is it not more a scroll? 'Books' in the ancient world were what we would call 'chapters' today. That pattern may recur: Your equation isn't on 'page' 201, it's in section 20.
(If search engines become ingrained in the technology, it may not 'be' anywhere; it'll be accessed by an F-command and a menu.)
(Anonymous)
the need for pages, and for books
I agree with the need for preservation of page layout. The argument that it is an archaic holdover is utter nonsense. We have years of accumulated evidence that clearly demonstrates that documents designed only for the electronic "page" rarely if ever approach the quality of the "archaic" books they replaced. Moreover, anyone who would argue that nothing was lost in proofreading is in terminal denial.
The difficulty of designing -- as opposed to letting happen -- a hyperlinked document is huge. How can one check the logical flow of a document that has, depending on your perspective, either no logical flow, or too many? It is impractical, at least, and perhaps impossible, to vet the flow of a document in this form.
The Agile Software fad argues that specifications are no longer practical or necessary. Tell that to my friend, chiefe systems engineer on the C-130 program, and he'll know you for a fool.
The direction that documentation is taking is comparable: no specifications appear to have been laid down for its content, flow, or completeness, and the result is obvious.
Now, in fiction, we might argue that pages are superfluous, and we needn't worry about hyperlinking breaking the sequence, as a murder mystery is nothing without flow, so such links would be forbidden. But in all things technical, we are witnessing the decline and fall of a technological civilization, at least on the software side.
The logical extension of all this is that we'll begin to see failures in the software written by these same folks who disparage specifications. Well, I've already seen it. One highly respected version control system I recently tried installing crashed my system, leaving the boot pathologically damaged.
Like it or not, we humans do think linearly in most things. We may multi-task fairly well, but look closely: when we do, each of those tasks is generally following a well-defined sequence.
E-books -- and e-publishing -- are still in the clever toy stage, in my view. Not yet ready to be taken seriously as eventual replacements for printed media, much less as current contenders.
I would argue that the documents that are most successful in e-media today are those that have been simply converted from conventional media, and therefore, were subject to old-media planning, development, and review.
Bill Meyer
I recommend _Understanding Comics_ by Scott McCloud for a different point of view framing the page concept.
pages
We really don't yet know how all this is going to settle down, or what the generally accepted forms will be. Something like pages and page numbers seems necessary, but since user interface is the most primitive part of a computer system, I have no idea where to go with it to Get It Right.
Page numbers are only 500 years old. They're one of the results (with title pages, tables of contents, indexes, and alphabetic order) of the printing press. (By the way, if you haven't read Elizabeth Eisenstein's The Printing Press As an Agent of Change, get it now. $30-50 for the one-volume paperback is a good buy.) Of course, the printing press also resulted in copyright and intellectual property, science, Protestantism, and nationalism.
You have to be able to find your place, you have to be able to point to a place, you have to be able to string chunks. But what's a "page number" on the web? I don't even know how the "book paradigm" vs. the "web paradigm" will shake out.