Quote:
|
Originally Posted by rlauzon
The point is that with PDF, I have to know the screen sizes of all the devices I intend to support before hand.
|
Yes and no.
"Yes," in that the target page size needs to be known prior to generating the PDF, but for an "ebook print-on-demand" service, that's not a problem. One could produce a service right now which dynamically generated books to users' custom size requirements using open source tools like TeX.
"No," in that page-oriented typesetting systems generally provide many useful features for tweaking the typesetting of a work. Although the core engine may generally provide good overall typesetting, generally (well, at least w/ TeX) a certain amount of manual tweaking is required to eliminate the occasional "warts," such as orphans/widows, paragraphs w/ poor greyness, and bad line-/page-breaks around figures, quotations, and poetry. Most of these tweaks will depend exactly upon the final layout, and thus the page size.
Systems based upon infinitely reflowable content definitionally lack many of these features, which in the worst-case can result in very bad typesetting the author has no recourse for repairing. The most often-occuring offender here is lack of hyphenation and the resulting horrible greyness -- especially the "rivers of whitespace" it can cause in fully-justified text. I consider this one a bit of an odd case though, especially for ebook devices. For example, the Sony Reader already needs to pre-calculate linebreaks in the reflowable formats it supports, so why not simply run the Knuth-Liang algorthim used by TeX, calculating the line-/word-breaks for future pages in the background while the user begins reading?
And so the conflict rages ever onward...