here's that alice pdf i mentioned on friday. it's at:
http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf
it doesn't represent a finished version, not quite yet, but i posted it because it demonstrates some issues. first of all, you should notice that it has no pimples, as i have exercised control over widows and orphans. in general, the pagebreaks are fairly good throughout. there are a couple i will improve -- can you find them? the biggest issue is that the typography is very dense. even with internet-style blocked paragraphs which have a full blank line between paragraphs, it's still too dense. one reason for the density is because i set the leading at 35 lines per page, and that's more than most books. (most p-books run anywhere from 27-31 lines per page.) the biggest reason for the dense typography -- and the rationale behind the small leading -- is because the lines are of very long length. the file has a line-length that is rather typical of the e-texts found in project gutenberg. (the longest line in the original alice30.txt is 77 characters; 33 lines are 66 characters long or longer. that's too long.) this long line-length is also why the margins are so small. with the font i used -- georgia, a font that was designed to look good on-screen _and_ in-print -- it was necessary to make the margins that small to get all the lines to fit. this was the case even with the type at a measly 9-point. (and 9-point is too small for printout, let alone the screen.) the point: project gutenberg line-lengths are far too long. furthermore, they're being calculated in the wrong manner. when you break lines according to simple character-count, the underlying assumption is the use of a monospaced font. and that's a bad assumption regarding people reading books, because nobody should read a book using a monospaced font; that's just inviting eye-strain and fatigue to ruin the experience. with as loudly as people complain about the unpleasantness of on-screen reading, we must do everything we can to nudge 'em into an experience that lessens the irritation as much as possible. instead of breaking lines according to character-count, we should break them according to _string-width_ in a _proportional_font_. although different fonts can vary greatly in terms of their width, the bulk of reading comprehension studies indicate that a length around 50 characters is optimal, so that's what we should aim at. (to equate the figures, 50 12-point characters is about 300 pixels.) as most of you know now, my viewer-program uses a 2-up display, the familiar facing-pages spread that most end-users associate with "a real book". what they usually say is, "it looks like a real book." (which brings up some questions about the nature of "reality". but let us just say that we know what they mean, and leave it at that...) i don't know if it's just a coincidence, or if there is a deep underlying reason that explains why, but it just so happens that a line-length of some 50 characters, with nice margins on both sides, makes a "page" that fits nicely in the 2-page-spread in the interface of my viewer-app. you can demonstrate this to yourself. open up your wordprocessor and load some text, choosing a fontsize that's comfortable for you; make the window-width convenient for reading for an extended time. unless i miss my bet, or you're lucky enough to have a cinema-screen, your window-width will be about one-half the width of your monitor... another indication of this general rule is the template for most blogs. look at a lot of them and you'll see that the left-quarter of the screen is typically used as a sidebar, and so is the right-quarter, which leaves the middle-half as the primary text-area containing the blog's content. (most templates don't resize this "main text" arena when the person makes the fontsize bigger than the standard-size, which is what they should do, for reading comprehension. that's true of non-blog sites too.) so -- in creating my z.m.l. versions of the project gutenberg e-texts -- i use a shorter line-length, and i have found that that works very well... i doubt the "powers that be" at project gutenberg will listen to me, but my suggestion is that you should use the shorter line-length too... of course, my viewer-app lets people remarginate the text at any time, so hard-wrapped lines at a longer length are not any type of _obstacle_, and it doesn't matter to me if project gutenberg's policy changes or not. i'm just suggesting it because it's an idea that has worked well for me... back to the alice .pdf, though, what you'll see is when lines are wrapped by their character-count, there are bad variations in their "true" length when they are converted into a proportional font. and that's unfortunate. in additional to the remargination that my viewer-program lets the user do, it will also adjust the "default" linebreaks that are computed in the new size, which will quite often create loose lines. in general, although i'm using a rather simple routine to do these adjustments -- because it has to be fast enough to work on-the-fly for real-time display -- i'm getting paragraphs that have very few loose lines. i'm quite happy with it. one reason i'm showing you this output with their original hard-wrapped lines is so that when i later show you output with the "default" soft-wrapped lines, you can compare them. and then when i show you output with my "adjusted" linebreaks, you'll be able to compare those results to the other two instances. (it's not that i expect anyone here to actually care that much, or even at all; but if there _does_ happen to be someone who does, i'll satisfy their curiosity. and i have typography friends elsewhere who find all of this _very_ interesting.) now for the other issues. for the most part, i think the design is straightforward. i'm sure some people will have opinions on things like the chapter-headings, and i would be happy to hear 'em, whether positive or negative. i'm especially open to constructive criticism, and would love to have graphic-design people chip in... the issue on which i would most like feedback is how to handle the illustrations. as you'll see (if you choose to look at the .pdf), what i did is that when a picture is called by the text, i have thrown a page-advance, and displayed that picture in whatever space happens to be remaining on that page, re-sizing the picture (down, since all of these images were the size of a full page). in many cases, that was perfectly fine, in that the picture was displayed at a large-enough size that its detail can be grasped sufficiently, even without using acrobat's zoom... in a few cases, though, the picture really isn't large enough to be appreciated. in one case -- ironically appropriate, the one about alice being "cramped" -- the remaining space was so small, the image is little more than a thumbnail. this "use-the-remaining-space" modus operandi is the one my viewer-app uses, and -- in the case of on-screen viewing -- it is entirely appropriate and reasonable. there, it doesn't matter if the picture is thumbnail-sized, because the reader can simply click on it and a larger version of it will be displayed for their examination. so, the question is, would this be an acceptable solution for a .pdf version too? i can turn each picture into a clickable link that will jump to a full-size graphic. is that what i should do? the down-side to that approach is that (i believe that) including each illustration twice -- once on the page where it is called, and then again on a page (at the end of the book) in a full-size version and all by itself -- will bloat the .pdf. in the case of "alice", for instance, there are 42 illustrations. including each of these on a page of their own at the end of the book would turn this 125-page .pdf into a 167-page .pdf. people wouldn't _have_ to print all 167 pages, if they didn't want to, they could just print up through page 125, so maybe that's not a big deal. but i'm wondering what y'all would recommend. another option would be to print each illustration at full-width where the text calls it, floating it to the next page if it won't fit in the space remaining on the current page. that might turn this into a 145-page .pdf (i'm just guessing, i haven't tried it out), which would have an impact when it came to a person printing out the entire book, but it wouldn't bloat the .pdf so badly because each graphic is only included once. i had a bunch of other ideas about how to deal with this little problem, but now i've forgotten what they were. which is ok, i guess, because this is long enough already. -bowerbird