On 5/18/07, Martin Swift <martin(a)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