Andrew Whitworth wrote: <*snip*> This is a general comment about "automated" PDF files that are created with something like the toolserver. While I am not necessarily against somebody spending the effort trying to make an automated process directly from the MediaWiki database of Wikibooks, I would have to consider any such effort created in this manner to be nothing more than a rough draft, and a considerable amount of additional effort would have to be done in order to create something that is book-like. More explicit and to the point, anything that is automated from a bunch of web pages is simply going to be ugly. Now I admit this is subjective, but web pages simply aren't books, as hard as you try. Wikibooks via a simple web interface is an important first step, and it does get us to gather the raw content which can be transformed into a book, but it is only about half-way to the goal of publishing a textbook even when you have some beautiful web pages and the written content is letter-perfect. So far, there isn't anything on Wikibooks resembling what professional editors do in commercial publishing circles. About the best example I've seen anywhere on a large-scale volunteer project is what the Distributed Proofreaders do with the Gutenberg Project draft texts, where there is a completely separate team of volunteers who review the formatting of the document after the actual grammar of the text has been been considered in the final form. I'd also challenge that a book, a really good book, is in many ways a work of art unto itself. Particularly a good textbook. If we want to make textbooks that really revolutionize the publishing industry, and have them used in actual classrooms, we need to treat them as art forms and not something which massive shortcuts have been taken. Is it possible to also include the unique book-only markup tags within the Wiki as well? Yes, and I'll admit that. But it isn't going to be easy to get going either. I expect that a development team working very closely with Wikibooks participants to generate a very good combination of markup tags for book publishing that would generate quality PDF files will take years if not a full decade to perfect. On this I am staking my experience and knowledge of software development cycles I've gained over several decades of writing computer software, and years of being involved with Wikibooks. By far and away the current best "free" method of generating a PDF file is to import the text into Open Office, formatting the content to be much more book-like, and exporting the PDF file. Acrobat Pro certainly does better (Adobe wrote the spec, so they understand it better), but as you said, not everybody on Wikibooks can afford that software. -- Robert Horning

adam hyde wrote: As I said, doing something like this is an excellent first draft if you are trying to design a book. But if you think this is going to be something acceptable in a classroom compared to commercially published textbooks, I think the results are going to be absolutely horrid from an aesthetic viewpoint. It simply can't be automated without either an incredible amount of additional effort and significiant advances in artificial intelligence, or involving some grey matter from volunteers to make it look nice. Perhaps some other software applications can be used, and if you like them, have fun! I'm not suggesting that Open Office is the only one to use, but it is something that many individuals may already have or be using, is available under multiple operating systems, has a very simple installation path, and is also open source. That is a tough combination to try and beat. BTW, thanks for suggesting Scribus. I'll have to download it and try it out. --Robert Horning

mike.lifeguard wrote: I make this distinction about the rough drafts mainly because whenever I see a suggestion to automate PDF files, there is a presumption that somehow you can take an edit you just put in 30 seconds ago and somehow have it show up "magically" in a textbook that can be printed by simply pressing a "print book" button somewhere. Or to completely ignore the problems of trying to format HTML into something that can be rendered into a PDF version of the book. As far as quality control is concerned, I'd love to see something akin to a "published page" tab and "revised" or "draft" page that could be edited, with some sort of admin-type tool that could be used to select a specific version of the page edits to be noted as the "published page" that could be used by casual readers to the wiki. The decision for what page would actually be selected is something to be decided by the participants of that page. I don't believe this would take too much additional programming in terms of adding the extension to MediaWiki, and it would only require the creation of one additional and smallish table to keep track of: what the current "published version" of the page is at the moment. It might even help with caching issues as the published version would be the one to cache, not necessarily the one with the latest edit. Just a thought here, and something on my personal wish list of future Wiki tools I'd love to see. -- Robert Horning

Absolutely! This is the '''only''' reason I bothered to make a PDF of [[First Aid]] - because I was going to be teaching a class, and I wanted to see how the book fared. In the end the class was cancelled, but the point remains. I don't think people should be overly concerned with "book authors who are trying to be overly creative with their formatting, and are not conscious of the fact that things don't render the same on different display media" though. If formatting doesn't render well, then that book will just have bad PDFs. (For that reason we may want to say "this page is hopeless with respect to the automatic PDFs, so don't give it the PDF tab" on a per-page basis. Not sure how that might work though.) This is actually something I hadn't thought of before. I don't know how server-intensive the PDF tool is (and that should be checked by someone who the answers will make sense for) but if it'd work, a PDF tab at the top could be awesome. For pages that have a cached PDF version (ie from the toolserver), that would get served. For pages that don't, one could perhaps get automatically made and cached (ie just link to the toolserver). Then we need to have some rule for when the PDFs expire. This would become much easier once FlaggedRevs is in place - whenever a page is reviewed, then a PDF is automatically generated and cached (and has the same lifespan as that top reviewed revision. Once the page gets reviewed again, the PDF is replaced. Being that I'm not a programmer, this may or may not work exactly as described. -Mike -----Original Message----- From: textbook-l-bounces(a)lists.wikimedia.org [mailto:textbook-l-bounces@lists.wikimedia.org] On Behalf Of Andrew Whitworth Sent: November 25, 2007 11:06 AM To: Wikimedia textbook discussion Subject: Re: [Textbook-l] The PDF generator on the toolserver hasimplications for quality control on a per-chapter basis I think that a lot of the problems involved in this process stem from book authors who are trying to be overly creative with their formatting, and are not conscious of the fact that things don't render the same on different display media. I think there are plenty of ways to make books that will render just as well on screen, in print, or in a PDF file. I love this idea! Tabs at the top of the page for "Printable Version", "PDF version", "Stable Version" (especially once the FlaggedRevs extension is activated) would be much better then the myriad of templates we try to use for the purpose now. I believe that there are many user-interface changes and enhancements that Wikibooks needs, so many that perhaps we would do well to build our own skin from the ground up. I perhaps would like to put this off until after we have a new logo, but some things like adding new tabs could be done immediately. And if no particular version needs to be stabilized, we likely don't need to have one at all. I really envision only stabilizing a particular version for the use of particular classes, and allowing things to be dynamic otherwise. --Andrew Whitworth _______________________________________________ Textbook-l mailing list Textbook-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/textbook-l

just fyi, you may want to look at FLOSS Manuals (http://www.flossmanuals.net) we have exactly this structure so maybe browse around it and see if this is the kind of idea that you like. there are published pages: http://www.flossmanuals.net/read and the 'backend' where manuals are written: http://www.flossmanuals.net/write the 'published' pages are static, and the backend holds pages that can be dynamically edited. the PDFs that are linked from the 'published' pages are also static adam -- Adam Hyde FLOSS Manuals http://www.flossmanuals.net