On 5/18/07, Martin Swift martin@swift.is wrote:
You cannot sensically render a page break in the browser, but a printed book will require page breaks. This means
that
the formatting and styles for the print version of the book needs to be different from the in-browser version, even if only though the addition
of
page breaks and the like.
I agree with you fully. The solution, I argue, lies with CSS. The markup can contain elements that are interpreted differently depending on which stylesheet is used. Elements can trigger page breaks when rendered with the print stylesheet but do nothing otherwise.
The problem is, while support does exist for page breaks and the like it will be excruciatingly difficult to both implement it and also ensure editors understand it. If someone creates even a simple sidebar template it will need to have a print style assigned to ensure it floats correctly on the print page.
The other problem is how to preview it. Even if an appropriate Greasemonkey script were supplied (in which case you could just toggle the monkey and hit show preview to see the edit with the other stylesheet) not every contributor uses or wants to use Firefox, and there's no easy way to turn user stylesheets on and off.
One possibility would be designing the book pages in a "print-like" format, and then transcluding them into web-friendly equivalents for casual screen reading. You may remember how Amazon Online Reader used to have Adobe Acrobat-like page divisions until they changed page movement to left/right arrows. That's the sort of thing I'm thinking of. Live wiki text, but styled to the hilt to automatically take on the limitations and appearance of the American "Letter" paper (although it would also work with A4 since the margins would be more than enough to cover the difference and printers can handle such discrepancies without user intervention). A wide-margin web viewing equivalent would of course still be available. Unfortunately this would require CSS2 at the very least, and possibly some minor JavaScript.
The advantages of such an implementation would be far-reaching, however. Editors would see the pages exactly as print version readers would, and the print stylesheet could override any colors or fonts unsuitable for printing. Thanks to <includeonly> and <noinclude>, any discrepancies between the print and web versions of the page could be dealt with, and automatically correct both pages. As long as the reader's browser was CSS2-capable they could click print and see an identical copy of the "print preview" they were already looking at.
As for those with older browsers (which, without CSS2, would print the page completely wrong), since there are websites able to convert HTML to PDF on the fly it would be a simple matter for additional toolbox links to send the current chapter or the whole book to a suitable conversion site, thus giving the reader an up-to-the-minute and fully accurate PDF copy. This would eliminate people painstakingly laying out each edition and then uploading the PDF, as all tweaks could be done on the live copy, since CSS2 can handle most of what's necessary. Even nitpicking such as breaking a word onto the next line with a hyphen can be included and then marked for exclusion from the web copy.
As for how the user would go between the web and print views, it's really quite simple. There would be a "print" function somewhere on each page. Clicking this would then take them to the print view page (which, again, is live wiki text). If they were then satisfied they would click a confirmation button and a simple JavaScript function would bring up the browser's print window, or they could click a back link to return to the web view. For those with browsers incapable of rendering CSS2 it would be quite possible to piggyback MediaWiki's existing user agent check to instead link to an HTML to PDF service, thus ensuring they still get to see what the genuine printed page will look like before actually printing it. None of this will be easy to implement but the point is that it is possible, and it would be wonderful as the end user is concerned. It's a rare occasion when a website is print-ready to this extent.
Unfortunately, my knowledge of CSS2 is far too limited to help implement such a solution. If anyone's interested I could cobble together an example; it wouldn't be good enough to actually use on books any time soon, but it would look about right and hopefully include most of the functionality I've talked about.
Garrett