Heloo all. First post to the mailing list(!)
I found the post about the toolserver PDF generator in the archives. Instead
of leaving a lengthy post on-wiki, I wanted to formulate something a bit
more formal. Matt touched on this, but I don't think anything came of it at
The PDF generator is a tool by Magnus, which automatically generates PDFs -
that much is self evident. But for Wikibooks, I think it has much more
potential in the realm of quality control than that (seemingly-)simple
function. Since it creates PDFs (mostly) on a per-page(=module) basis, it
can be used to keep a stable version up-to-date very easily. If you've
noticed, I uploaded a PDF version of my pet project [[First Aid]], which is
massive, and will be difficult to keep up-to-date. Although the method I
used (PDFLaTeX) allows me much more flexibility in terms of output and
customization, manual creation isn't very useful to maintain a stable but
Enter stage right the PDF generator. As (modules|chapters|books) get to a
point where they're in a state which is ready to be preserved in PDF, just
trundle off, enter the appropriate URL, and out pops wiki.pdf. It's not
perfect; there will be errors: it messes up diacritical marks (as mentioned
below), and it can't handle some/most/all? templates (take a look at
njury&project=wikibooks) though, surprisingly, it handles images quite well
(but not their captions):
All that said, the output ''is'' readable, and it's quick and easy to do.
The keyword for the quality control aspect is ''quick''. This is something
that's not hard to do, so just about any user can decide that content is
ready to have a stable version. But it's just as easy to create a new stable
version if there are changes you want to have reflected in the PDF.
I'd like to see this tool improved, of course, but I think it's at a state
where we can advertise it to users who want to create a (semi-)permanent PDF
version, and also for more-frequently-replaced stable versions.
The question becomes, then, "Do we want stable versions of one kind or
another?" Further, if we do, then are PDF versions the way we want to do it.
In my view, at least, stable versions are a must (and for Wikibooks,
essential if only for the ability to print them easily) and until such time
as a stable version feature is integrated with the MediaWiki software, this
scheme is a surprisingly-close-to-ideal method to achieve that goal.
PS: Sorry for the length, both of the post and of the title. I just finished
a paper, and we use verbose titles in neuroscience especially; I don't have
an excuse for the length of the post ;)
==Previous related posts==
> From: Magnus Manske <magnusmanske at googlemail.com>
> Date: 13 Oct 2007 09:16
> Subject: [Wikipedia-l] PDF generation on the toolserver
> To: wikipedia-l at lists.wikimedia.org
> On a note by [[User:Korrigan]], I have adapted (rather, rewritten) the
> PDF Export extension for the toolserver. You can now get a single or
> multiple Wiki(m|p)edia pages as a PDF, by entering/linking to an URL.
> As the extension, I am using HTMLDOC, so the output is as good (or as
> bad) as that package. Don't blame me.
> I shall demonstrate using our new meme overlord, [[Horse-ripping]],
> and the related article [[Zoosadism]] from en.wikipedia:
> Additional parameters (add them to the URL):
> &language=XX (XX being the language code; en is default)
> &project=wikibooks (default:wikipedia)
> &nogfdl (3 pages of GFDL are appended by default; add this parameter
> to prevent that)
> I haven't figured out how to make HTMLDOC generate a TOC. Maybe tomorrow.
Not so good with the UTF-8, as demonstrated with
Well, it found the article, but the title page was a bit mungled.
Wikimedia Foundation, Inc.
E-Mail: cbass at wikimedia.org
we've set up a blog to accompany our annual fundraiser. The headlines
from the blog will be featured in the sitenotice:
I'd like to invite you to submit posts to the blog. These posts can be
provocative, and should give compelling reasons to support the
Wikimedia Foundation. You can draft posts here:
Posts will be selected by a number of people: Cary Bass (our Volunteer
Coordinator), Sandy Ordonez (our Communications Manager), Sue Gardner
(Special Advisor to the Board), and myself. We'll probably try to have
a new post every 2-3 days at least.
Once again, the point of these posts is first and foremost to invite
the general public to donate. :-) Please submit stories in this
If you are willing to act as a moderator for comments to vet out spam
& trolling, please contact Cary Bass at <cbass AT wikimedia DOT org>.
For now, this is an experiment and as such, only in English. We will
set up blogs in other languages if this one has a measurable impact on
Thanks for any and all help!
Member of the Board
Brian McNeil wrote:
> I agree completely, there would be a lot of work putting templates in the
> right places. For Wikinews every article written before the changeover had
> to have a template added.
> Assuming Wikibooks were to say they wanted to change license you'd have a
> big project on your hands because people wouldn't want their GFDL stuff to
> become frozen in time and cease being edited. If they accepted the reasons
> for the license change you'd be rewriting your books to put them under the
> new license.
> Wikibooks could make a switch, but it would be a real challenge. I can
> imagine having some pages started before the cut off having warning
> templates that contributions are GFDL but there's a
> start-from-scratch-and-rewrite version under CC-BY-2.5 [[here]]. Tricky
> judgement call on when you switch the main article with the sub-page and
> move to a template that says "This book is CC-BY-2.5, an older version under
> the GFDL license is available [[here]]." This may sound overly complex, but
> in line with Wiki philosophy I hate seeing useful information destroyed.
> Of course, I am unaware of any drive within Wikibooks to change the license.
> I guess what I and several other people on the list are saying it is they
> are the only obvious case that could pull the same move as Wikinews. And
> yes, it would be a disruptive, difficult and messy period for the project.
> Brian McNeil
> -----Original Message-----
> From: foundation-l-bounces(a)lists.wikimedia.org
> [mailto:email@example.com] On Behalf Of Andrew Gray
> Sent: 21 November 2007 13:34
> To: Wikimedia Foundation Mailing List
> Subject: Re: [Foundation-l] Citizendium License (Was: [EWW]
> On 21/11/2007, Brian McNeil <brian.mcneil(a)wikinewsie.org> wrote:
>> Were you, for example, to want to go that way with Wikibooks you'd need to
>> say, okay cut-off is <date-A>, and every book started before that gets a
>> template added saying it was started before <date-A>, thus remains under
>> I can't see any way to do that on Wikipedia where virtually every article
>> treated as a work in progress.
> Quite - even were you to try saying "all articles created after Date X
> are License A, all articles created before are License B", you'd
> immediately run into trouble with people wanting to merge or transfer
> material across.
> It really depends on how granular the projects are - how much each
> page or group of pages stands on their own. It seems like this ought
> to be workable for Wikibooks, to deem that this book is CC-BY and that
> one GFDL...
> ...*but* even if it is theoretically practical, it's going to be a
> hellishly big headache to administrate!
> Licenses are really something that needs to be established on a
> project-wide level, I fear.
Let me push the thing a step further Brian
Imagine that there is already a book somewhere, under a regular
copyright. And the copyright holder is willing to have this book
published on Wikibooks, because he thinks it is a cool idea, because he
wants the book to be under a free license, because he wants to be the
book to be regularly updated and so on.
Does the current situation mean that this person has to mandatorily
relicense the book under GFDL, a license we notoriously know as
problematic, whilst other licenses may be more suitable now ?
Does he have the possibility to relicense it under a dual gfdl/CC-by-sa
licence ? What are the implications in Wikibooks today ?
Does Wikibooks have a wishlist in terms of technical developments that
might be useful for the project ?
I am currently hacking down a quick grant request with another
organization, and, if I do it well, we'll be concerned. So, if there are
specific development which might be super useful, please say so, I
might get it added somewhere.
I want to raise an important (and very frequently-asked) question: How
do Wikiversity and Wikibooks relate to eachother (and within this: do
they overlap unnecessarily, and how might they be aligned most
productively)? I'm asking this as an *international* question (ie as
it relates to present and future projects), although perhaps, in
asking this, we could ask: in what ways might different language
communities deal differently with these definitions and distinctions?
(And yes, I also realise this is several questions, and that there are
a few more to come. :-))
The context of this is that there are some Wikibooks communities that
seem to want to hold off on creating a new Wikiversity, as well as
there being some people who want to clarify the distinction between
the projects before setting up new ones. On the former, in some cases
(or at least, in the Dutch, from what I gather), this has had the
practical outcome that these communities have extended the scope of
the Wikibooks project from what other Wikibooks projects are doing -
in hosting lesson plans and pedagogic guidance for using these
textbooks in class. (This latter seems to be more suited to
Wikiversity in my mind at least - is this also the same for you,
and/or is it a problem?) But the larger question is: can different
languages define differently what Wikiversity and Wikibooks do, or can
a Wikiversity be effectively subsumed in Wikibooks (or even the other
way around)? Put another way: what does Wikiversity do (or intend to
do) that Wikibooks can never do, as presently defined?
So, the 'international' dimension here comes down to whether it is
possible - or useful - to define how Wikiversity and Wikibooks would
relate _in_all_languages. If it is possible and/or useful, then it
might be timely to actively construct such a map of how the two
projects relate (eg how much overlap is ok, what the scope of each is,
and how they can share resources etc), and set out a framework for how
different languages can be set up, defined and organised around
I'd really welcome any comments on anything here that sparks your
imagination, or that speaks to your experience.