it's _one_ thing for me to call some of you "stupid idiots"... but i must admit, it's much nicer when you come and post and _prove_ that yes, indeed, you really are "stupid idiots". what's curious, though, or perhaps downright fascinating, is how stupid idiots can argue with _other_ stupid idiots... at any rate, it's all been very amusing... :+) and i do wish you wouldn't stop, not quite yet, ok? ;+) *** but... for the lurkers... if you need solid food to lay down a base for your popcorn as you view the proceedings, here are some pdf's for you... actual product -- not just opinions flung at you, like dung. all of these were churned out from our "master" z.m.l. file for the mabie book; none of 'em required special handling.
but first, of course, the backdrop... *** remember the old days, when we had delineation between the paper-page-focused pdf vs. screen-reflowable html? yeah, well, maybe not so much, these days. first, designers have increasing shut down "reflowability". web-page-width is increasingly defined in terms of "ems", which means that increasing font-size increases the width. it's also the case that "command-plus" to "increase size" in a web-browser has increasingly come to mean "zoom" the entire page, rather than simply increasing font-size... each of these developments causes the same bad effect: the characters get bigger, but the number of 'em in a line stays the same, because the line itself got longer as well. sometimes to the point where it's longer than the screen, so we again see cases of the dreaded horizontal scrollbar, a horror we thought we'd eliminated about a decade ago. another impacting factor is the new popularity of machines -- like the ipad, and the kindle, and the nook, and so on -- without resizable windows, or windows at all! you get one screensize! that's it! and for iphone and ipad, even when you rotate the screen, the window's _dimensions_ stay the same. (oh, and there is no "increase the fontsize" command on the iphone or the ipad; you are stuck with the designer's specs.) apple is even migrating the "one-app-using-the-full-screen" mentality back to the desktop, with their new version of lion. so the "reflow" aspect of html is steadily being downplayed... *** the other side of the pdf=fixed vs. html=reflowable contrast -- namely that pdf is "a frozen format" -- is one my apps are steadily challenging, with an "on-the-fly" pdf-creation power. if i don't have to just take whatever pdf somebody else created, but can rather generate it to my personal custom specifications regarding pagesize, font, fontsize, leading, and everything else, then pdf as a format has just lost lots of its former deficiencies. don't get me wrong... i've been an enemy of pdf for _so_long_ that i'll never consider it to be an ally, let alone a good friend. but people who've grown up without my prejudiced experiences, who are facing the field of e-books for the very first time, might well come to greatly prefer their _self-customized_ pdf output over the formless blob they get from most e-book viewer-apps. heck, haakon wium lie, one of the godfathers of c.s.s., just did a big press event where he advocated a new method whereby a web-page too big for one screen would be "split" into pages, so users could "swipe" to go forward or back through the pages.
http://news.cnet.com/8301-30685_3-20118 457-264/opera-proposal-brings-a-book-look-to-the-web/
he said:
"Doing pages on a screen I think will be very important, especially for tablets."
but, of course, such "pagination" was one of the things that was scorned by the early advocates of html, arguing against the pdf. and if you need the official stamp of the corporate publishers too, "fixed layout" mode is the flavor of the month in the .epub world... along these same lines, there are the book-designers who -- as misguided as they might be -- still keep demanding that _they_ be given the ability to _veto_ any design changes made by users. some of them even want to prohibit us from changing fontsize! but all of them are adamant that pages be displayed as designed. and in addition, all high-profile e-magazines have tended to be simple graphic-file image-flipper apps. (yeah, severely bloated.) that's a darn good way to ensure users can't change your display. of course, there are rather nasty side-effects that come along too. at least you can do a text-search on a pdf! not on a set of images! of course, moving back to pdf, the "classics" app -- the very first e-book app to catch on in the app store, even getting the honor of having their icon shown in an apple commercial, as well as the accompanying bump in sales -- stores its books internally as pdf. and finally, coup de grace, the ibooks app doesn't scroll, does it? heck no, it paginates the book, and you swipe to turn the pages, whereupon you get both a page-curl and a page-turn animation. rip! rap! batman! where did that skeuomorphic crap come from? all i can say is, if you thought the pdf/html delineation was clear, you were wrong, and you're becoming more wrong by the minute. *** fortunately for me, i don't have to go back into that cesspool of "pdf vs. html", because i support both, and let my _users_ decide which one they want, or both (if that's what they choose instead). both pdf and html are just "output formats", far as i'm concerned, and both of them can be generated with one simple button-click. and furthermore, both of 'em are destined for e-book extinction. no one will bother with "generating an output format" which they read in a viewer-program (acrobat or a web-browser) that gives an inferior experience, when they can view the .zml "master file" directly, with a superior app, and without any button-click hassle. not in the long run. not once they've learned the full set of facts. but in the meantime, we'll generate html output, and pdf output. so here are a few pdf files showing the types of output possible, pdfs which demonstrate their direct relationship to html output. *** the "secret" of generating a pdf that seems more like "a website" than a paper-based product is to forget using a fixed pagesize, and instead size each page of the pdf whatever it "needs" to be, depending on the content which you have placed onto that page. here's the first example:
this pdf consists of _one_page_, which contains the entire book. in this sense, it's equivalent to its single-page web-page cousin:
to make the comparison most striking, narrow the html window in your web-browser until it becomes the same width of the pdf. *** here's the second example:
in this file, each _chapter_ is put onto a separate page in the pdf -- so it's akin to our folder with each chapter on a separate web-page.
indeed, each chapter-header in this pdf is an actual _link_ to the web-page in that folder with the respective chapter, so we have an example of the _synergy_ that can be created between the pdf (which can be offline) and the online version. to the extent that "social networking around books" becomes something important -- it's being inflated by hype right now, but it _could_ become big -- this synergy could be quite vital. the best way to view this pdf, to see the intended effect, is the "single page continuous" mode, so each page falls underneath the previous page, creating a display similar to the pdf above... *** and here's a third example:
in this pdf, each _paragraph_ from the book is on a separate page. and the facing page is completely blank. hey, what's up with that? your first reaction might be that this is stupid, that it's "wasteful", in the sense that many of the paragraphs don't use up a full page. (and that description even ignores that every other page is blank!) but of course that's silly, since these are all just _electrons_, son. furthermore, there are some good use-cases where such a pdf can be quite useful, such as when an editor goes over your book. the blank facing page opposite each paragraph is a place where that editor types in the notes and suggestions for that paragraph. go ahead and try it out... just click in the field, and start typing... then, when you quit, you will be asked if you want to save the file. *** so there you go. three examples of different pdf output files, each geared to a specific use-case, with direct correspondence to an equivalent design rendered in html. indeed, if you view those pdf online, using a web-browser (like chrome or safari, but not firefox, which has a lousy pdf viewing capability), then your experience is _amazingly_ similar to the html equivalent. -bowerbird