for roughly the first decade or so of my research on e-books, i was content with an absence of concern for the printed page. this was just a bit disconcerting, because i'd previously been involved with desktop publishing, and derived great pleasure from the act of laying ink on paper, and doing it beautifully... and especially because i had a smattering of contact with the practices of the past -- such as paste-up boards and hot wax and color-separations -- i _marveled_ because the computer empowered me to do and re-do, simply, accurately, and fast. so, particularly because of the ease and power of the machine, it was hard to leave behind all of my obsession with the page... but eventually i could forget about the trappings of that past, throw 'em all out and start anew. and it was quite refreshing to work from scratch, to have a blank slate, an empty canvas, a reason to have to decide everything from the very beginning. one of the first things to go was the notion of "the page" itself. the mantra was clear -- "electronic-books don't _have_ pages." so all of the fussing that i had done before, on run-heads and drop-folios and fretting over widows and orphans, all of that, margins and gutters and page-counts and such -- _all_ of it -- was just thrown out the window, never to be thought of again... and to be truthful, it _was_ liberating, very much so, for a while. then some cracks began to appear, around the corners at first... for instance, even if you don't have the notion of "pages" per se, sometimes the number of lines in a field of content still can run _one_too_many_ for the current screen, and slop on to the next. so even if you don't _call_ it a widow (or an orphan, or whatever), that's what it _is_. and it is still upsetting to your obsessiveness. and page-count? well sure, it felt good to give up the arbitrary monster that used to say "this book is a few pages too long" or "dummy, there is no way to make money on a 70-page book"... now you could say "i made it exactly as long as it needed to be". but it also meant that sometimes you had to keep on wondering whether a book was "exactly" as long as it "needed" to be, or not, or whether you maybe should flush out that one little vague bit with a few more pages, or just decide that it was "good enough". sometimes having a hard target can save you a lot of fretting... *** but without question, the most troubling thing to discard was the noble page-number, with all of the utility that it provided. it's not that a page-number per se is all that useful. it's _not_. once you're inside a book, you don't look at the page-numbers. if you do stop and ask "how many pages are left in this book?", it's because the story lost the rivet fastened to your attention... and even further, the page-number is more than a gauge of how far you've moved along in the course of the entire book. we can put "page-numbers" in an e-book ("screen-numbers?") very easily, and they serve some useful purpose as milestones, but since we know they are so arbitrary (change the fontsize, and the number of "screens" changes accordingly), we _know_ that they don't have any lasting value in a cross-person sense. and the "location numbers" that the kindle uses are consistent, but they're spongy because they don't delineate a clear portion. we do not easily see where one starts, or the next one kicks in. and _that_ is the main purpose that page-numbers really serve -- the ability for one person to communicate them to another, and have the second person know the place in the book where the first person is talking about. ok, yes, it's a _general_ place, but that's sometimes exactly what we want, and even when not, it's usually _sufficient_. (and we _can_ be even more precise, such as specifying "the top of the page" or "the eleventh line".) more importantly, the page-number successfully encapsulates a _range_, and the range is _known_ and _specific_, because we can tell you the first word on the page, and the last one as well. so that's why the page-number became the canonical "pointer" for print-books, employed by _indexes_ and _references_ and the classroom-teacher who says "now please turn to page 69." there are some books, like "the social science citation index", which is entirely composed of collections of page-numbers... and thus, page-numbers are the print equivalent of the "link". not quite as handy as point-and-click, nope, but just as useful. because inherent with the page-number is the _certainty_ that this information points to one specific part of a book's content. and it is that _certainty_ that is the most important thing here; a page in a book, named via number, is a _known_commodity._ we know the first word, the last, and all the words in-between. and thus has the page come to be a precious commodity to us. it's so well-known that the page itself has become an icon -- words in lines, running across the page, from top to bottom. or -- as an icon -- a series of squiggles from top to bottom. but an e-book is formless; it's "free" to "reflow", like water. what that means, though, in the end, is that it's just a blob, which runs through our fingers, like sand, instead of being a solid tangible _goblet_ which could _hold_ water (or sand). *** having abandoned the page, there were times when i would wish to bring it back. not on a permanent, exclusive, basis. it's clear that we need for our e-books to be able to reflow. but rather as an _option_, something that can be _chosen_. however, i'm stuck with the formless blob of free-flow text. or am i? to answer, and cut directly to the chase, _no_, i'm not stuck. i can formulate the e-book such that it replicates the pages of the print-book, but then can reflow_ out_ of that goblet... and that's precisely what i do, with my paginated .zml files. all the page-boundaries are marked with information giving the filename of the page-scan (at the top of each page) and the page-number (printed or not) of the page (at the bottom). and the line-breaks, of course, are indicated with line-breaks. this information allows us to clone the look of the print-book. but it's also entirely easy to provide the reflow, when needed. remove page-boundary info and mid-paragraph line-breaks, and voila, you've got reflowing text, just like that, easy-peasy. (well, yeah, you gotta mark "soft" hyphens versus "hard" ones, and do something to indicate lines that shouldn't rewrap, but it's entirely do-able, and it's not even all that difficult, really.) this gives us the ability to replicate the print-book if desired -- such as, for instance, to make print-on-demand copies -- but also to reflow the book when that's the best thing to do... *** ok, so this is brain-dead simple to do on straight-text books, but when there is something else on the page, it can become more difficult. the common "something else" is illustrations. the version of "huck" which i worked on did have illustrations, so i've taken a whack at the task of replicating the print pages. the results i got were "good enough", considering that the graphics-files seem to have been collected in a fashion that is not very conducive to what i was trying to accomplish, so i've decided to settle on "good enough" and proceed on, but i am still happy to show you these less-than-perfect results. it's also the case that this attempt works reasonably well on _my_ screen, but _might_ fail _miserably_ on a screen which is not a 23-incher. you can adjust the size of the graphics by adjusting the size of the browser-window, but it won't mean you will end up with something "reasonable", just "different". because this is just a trial, i'm not interested in reworking it so as to ensure the results will be impervious to screen-size. therefore, if it doesn't work for you, i give my apology to you, but not anything more. but if you still wanna see my results, just say so, and i'll post screenshots instead of "live output". (probably what i should've done anyway, so do let me know.) *** there were three ways illustrations were displayed in this book. the first was on chapter-headers. the chapter-header _itself_ was rendered as a graphic and incorporated into an illustration which was laid in to the left of the text that opened the chapter. you can see these chapter-headers beginning with chapter 1:
click the "cplus" button to jump to the next one, and the next... i think these screens were sabotaged by the fact that the scans were not terribly consistent in their vertical placement, which is crucial here to matching up the graphic with the (separate) text. *** the second basic way an illustration was placed on these pages was centered in the measure, displacing text above and below. examples can be seen here:
http://zenmagiclove.com/huckf/wisdom.py?whatpage=21 http://zenmagiclove.com/huckf/wisdom.py?whatpage=25 http://zenmagiclove.com/huckf/wisdom.py?whatpage=43
these pages were, of course, very simple to replicate. (in cases when the picture had been presented mid-paragraph, i moved it so that it was displayed between paragraphs instead.) *** and finally, the third way illustrations were placed was as an "inset" -- placed up against one of the margins, with the text being wrapped to a rectangular edge along the opposite side. you can see this type of placement here:
http://zenmagiclove.com/huckf/wisdom.py?whatpage=18 http://zenmagiclove.com/huckf/wisdom.py?whatpage=19 http://zenmagiclove.com/huckf/wisdom.py?whatpage=24
the tradition is that illustrations are put on the outside margin -- left side on a verso/even page, right side on a recto/odd -- so they are more easily located when a person riffles the book; and i coulda done that, but i just put them all on the right side. the problem was that the graphics seem to have been resized. they weren't consistently sized the same as on my page-scans. perhaps this is because they were from a different edition, or maybe david widger resized them for his convenience, i dunno. but it caused something of a problem in placing them correctly; most of the time they were too small for the "hole" in the text... so i wrote a routine to up-size them, which i think worked well, at least for the particular window-size i was using at that time, although i have no assurance the routine will work on any size. but since there should be no need for any resizing at all, i am not willing to spend any more time changing this one-off code. what i _did_ do, though, is make the inset graphics draggable. so if they happen to bump into some text, or obscure any text, you can just drag the graphic out of the way, where you want it. a more-advanced version of this positioning routine will install some "collision detection" routines in the code, so the graphic will "move itself" if it detects any collision with any of the text. this notion that a graphic will "find some available whitespace" and adjust itself into it appropriately is one i have entertained for a long time now, and i continue to believe it's a great idea. so i'm happy to have taken a first step toward implementing it. i also believe it is important that we create the capability of "replicating" the printed canonical versions of classic books, in modern-day digital equivalents that also have the ability to break out into reflow mode whenever we want 'em to, so i took on the illustration challenge which huck presented me. -bowerbird