Sourcefabric, the free-media-software project behind the Airtime radio
broadcasting application (covered here last week), has also launched a new book authoring effort dubbed Booktype. At its heart, Booktype is a collaborative, web-based rich document editor, but it is designed to streamline the process of creating and publishing complete books — using the same text, regardless of whether the end result is exported for print, ebook readers, or the web. In addition to its editing and formatting capabilities, the software integrates tools to manage teams and communities around a book project, which may make it a better fit for documentation jobs and user communities than a generic content management system (CMS).
Booktype is the product of a collaboration itself. The code is an
evolution of the Booki editing platform used to great success by FLOSS Manuals. Although FLOSS Manuals had been using Booki for its own documentation projects and book sprints for several years, the code had never been packaged and distributed as a general-purpose tool. The partnership with Sourcefabric was announced on February 14 by FLOSS Manuals founder Adam Hyde, and the new version of the code was unveiled at the O'Reilly Tools of Change For Publishing conference the same day.
The code is licensed under the AGPL version 3, and is written primarily
in Django using PostgreSQL for storage. The source is hosted at
Sourcefabric's Github repository, where the installation
instructions list several other library dependencies. The most notable
are Espri and Objavi, the content-import and rendering engines
for Booki. At the moment, neither is packaged for distribution, although
there is an empty-at-present Objavi repository, and
the code is accessible from the Booki repository. Instead
of using installed versions of those components, the Booktype code links directly to FLOSS Manuals' hosted versions. However, the project does make both freely available for outside use, but until they are released as stand-alone packages, the hard-coded links will have to suffice.
The initial Booktype release is numbered 1.5, to reflect the code's Booki-era history. Sourcefabric's Adam Thomas said that the principle changes include an overhaul to the user interface, full localization, and the addition of non-ASCII character support in auxiliary functions (such as the Django slug creator). It is now possible to upload exported PDFs directly to a Lulu.com publishing-on-demand account, and to create EPUB and MOBI output tailored for Apple's iPad and Amazon's Kindle.
Anatomy of a book publishing job
The application is web-based, geared towards drag-and-drop simplicity in
the editor, although there are a handful of command-line
tools for administering a Booktype server. Editing a text is similar
to using Google Docs, PiratePad, or any other contemporary collaborative
editor. The main editing window uses TinyMCE, the same WYSIWYG rich text
editor widget found in WordPress, Joomla, Plone, and many other open source
CMSes. Simultaneous editing by multiple users is supported, as is revision
control and roll-back of earlier changes. The site advertises full Unicode
support as well as support for bi-directional text.
What makes Booktype a "book publishing" system rather than a web editor
is its support for long, multi-part documents, its output options, and its
focus on a collaborative workflow. Every user must have an account on the Booktype server, and the creator of a new book is automatically its owner. The owner can keep the title private, or open it up to the public — either the world at large, or a specific group of users — and can optionally assign user roles to distinguish between authors, editors, and proofreaders. Editing a book requires creating one or more chapters, and each chapter is essentially treated as a separate document in the application.
The "book view" allows an editor to rearrange the chapters using drag-and-drop. Users can also break the book into named "sections" and move the chapters freely between them. Booktype keeps track of the order of the material, and when exporting the final product, automatically numbers the sections and chapters, adds page numbers if print output is created, and generates a table of contents. The changes to the book's structure are noted in the interface's History tab (which, like MediaWiki's, allows you to compare different revisions side-by-side).
Whenever a book is ready for publication, its owner can freeze a revision of the text, which gets tagged with a software-style Major.minor release number. Version numbers are strictly-increasing, however; there is no "undo." The project describes this feature as being useful for textbooks and other projects that need to produce updates where it is always clear which revision is the most recent. When the text is finalized, publishing is a matter of choosing the output format — the same text is used to generate print, web, and ebook output.
The publishing feature currently offers five formats: print-ready PDF,
ebook (with iPad, Kindle, and generic EPUB options), screen-resolution PDF,
LibreOffice ODT, and the aforementioned Lulu.com upload. Internally, book
text is stored as HTML and styled with CSS. The export function uses
built-in CSS templates to convert the HTML to the other output
formats. At the moment, there is not much documentation of the templates
used or their options. The "Publish" tab walks you through several set-up
screens where you can alter settings like font style, size, margins, and
gutters, but without a preview. As the Booktype manual notes,
you can enter custom CSS on the final screen under "Advanced Options," although this is not particularly user-friendly.
According to Hyde, the exporter supports all of WebKit's CSS features,
which mean only partial support for advanced
text formatting and font
features. However, he added, "what is most interesting is that
typography libraries and we have been experimenting with the integration of
kerningjs. It's experimental but looks promising."
The "social dimension" of Booktype is its other distinguishing feature.
It has been designed from the ground up to allow users to create their own
book projects at will, and to contribute to each others' texts. That plays
out in the ease with which one can start a new book, and with Booktype's
ability to import chapters from public-domain works (such as the Internet
Archive) and Creative Commons-licensed ebooks. The application also allows
you to create groups in addition to isolated user accounts, and to assign editing rights to a group. User and group profile pages are minimal at the moment, but the feature is clearly intended to support large-scale group efforts akin to FLOSS Manuals' own contributor community.
In addition to the broader social networking designs, there are nice collaboration features built in to the application itself. During the writing and editing process, all changes are logged and are visible to other logged-in users on the same project in a sidebar next to the main editor pane, above a list of other users currently working on the same book. The automatically-logged changes include simple "User Nate has created new chapter 'Introduction'" and "User Nate has saved chapter 'Chapter 2'" messages, but collaborators can leave longer text notes for one another, or send chat messages through the sidebar if both are logged in at the same time.
Book owners and editors can flag chapters as "content needed," "review needed," or any other tag. This stops a little short of permitting a book owner to assign tasks to participants, but Booktype seems designed to fit ad-hoc groups of willing participants, rather than paid employees at a publishing house. FLOSS Manuals has certainly gotten significant mileage out of the volunteer-driven, casual workflow of Booki, which is an endorsement of the idea.
There are a few features discussed in the press release and project page that do not appear to be active in the live Booktype demo, such as publishing directly to Amazon.com or Apple iBooks, or output to static (i.e., non-Booktype) HTML. Coupled with the still-unpackaged status of the Espri and Objavi components, it is possible that the initial release of Booktype was not quite as ready as the project would have liked when the Tools of Change For Publishing event arrived.
Nevertheless, what is there is an easy-to-use collaboration platform suitable for writing-intensive tasks like documentation. FLOSS Manuals' output is of high quality for a number of reasons — including the skills and time contributed by its volunteers — but over the years the project's software has developed into something other communities ought to examine as well. Personally, I would much rather see software documentation written in Booktype than in MediaWiki, with its idiosyncratic syntax and the pages of empty outlines that inevitably result. The workflow tools in Booktype allow an editor to orchestrate a large volume of text with minimal effort, and the application takes care of the formatting automatically. Both features free writers to produce better writing.
Thomas and Hyde both said that work is already underway for the next revision of the code, which should include support for audio, video, and interactive elements. Until then, Booktype is ready to craft PDF, ebook, and print-on-demand output, which gives the rest of us plenty to read.
Comments (none posted)
I'm starting to think about my annual PyCon keynote. I don't want
it to be just a feel-good motivational speech (I'm no good at
those), nor a dry "state of the Python union" talk (I'm bored with
those), but I'd like to hear what Python users care about.
-- Guido van Rossum
From my biased point of
view, in just over one year, colord has gone from concept to being
included on nearly all distros by default. It's pulled in as multiple
things like GTK and CUPS as a dependency. It's my firm belief that
color management should be usable by real people without having to
install or configure anything.
I'm offering to help hackers in the KDE community build simple GUI
code on top of colord. You guys get a color management system that
works, and I get more users using my stuff. It's a win-win situation.
-- Richard Hughes
Comments (10 posted)
Version 2.4.1 of the Apache HTTP server - the first release in the 2.4
series - is now available. There are plenty of new
, including runtime-loadable processing modules, better
asynchronous I/O support, more logging configuration options, a new
general-purpose expression parser, a dozen or so new modules, and more.
Full Story (comments: none)
of the VLC media player, dubbed "Twoflower," is out. "With faster
decoding on multi-core,
GPU, and mobile hardware and the ability to open more formats, notably
professional, HD and 10bits codecs, 2.0 is a major upgrade for VLC.
Twoflower has a new rendering pipeline for video, with higher quality
subtitles, and new video filters to enhance your videos. It supports many
new devices and BluRay Discs (experimental).
Comments (48 posted)
For those who are interested in the details of what needs to be done to get
to the 1.0 release of the Wayland display server: Kristian Høgsberg has put
together a detailed plan. "I expect we'll take a few months to
finish the protocol work and then we'll start the 0.9x releases. From this
point on, the protocol should not change in backwards incompatible ways.
The protocol supports versioning and discovery of new interfaces, so we can
extend the protocol as we need, both as we move towards 1.0 and after 1.0.
Ideally we can incorporate the protocol changes pretty fast and then sit on
them for a while.
Full Story (comments: none)
On the Busybox list, Bradley Kuhn (of the Software Freedom Conservancy)
reports that he had a discussion with Tim
Bird at the Embedded Linux Conference and was able to address most of Tim's
concerns with regard to how GPL enforcement around Busybox is done.
"From my point of view, my discussion with Tim settles settles the
matter. Tim got some incorrect information about BusyBox enforcement
efforts, and that's what led him to feel he needed to support a BusyBox
replacement initially. Tim seems to be in completely reasonable [sic] about the
whole thing now that he's talked directly with me about the actual GPL
enforcement efforts by Conservancy for BusyBox.
" (Those who are
just tuning in to this story can find some background in this article
Full Story (comments: 36)
Newsletters and articles
Comments (none posted)
Jim Gettys looks
how to figure out which hop is the current culprit for
bufferbloat. "In this particular case, with only a bit more investigation, we can guess most of the problems are in the train<->ISP hop, because my machine reports high bandwidth on its WiFi interface (130Mbps 802.11n), with the uplink speeds a small fraction of that, so the bottleneck to the public internet is usually in that link, rather than the WiFi hop (remember, it’s just *before* the lowest bandwidth hop that the buffers fill in either direction). In your home (or elsewhere on this train), you’d have to worry about the WiFi hop as well unless you are plugged directly into the router. But further investigation shows additional problems.
Comments (15 posted)
Over at the Make magazine blogs, Phillip Torrone looks
at some of the unspoken, but largely heeded, rules of open source hardware. The rules have parallels in the open source software world that are interesting to consider, as well. "If you’re calling it open source hardware, release the files: schematic, source, BOM, and code. All under an open license. Don’t hide it. Don’t say you need to sign an NDA and attempt to obfuscate. Don’t be difficult. If you’re trying to be tricky, just don’t do open source hardware. A new thing I’ve seen, and I don’t think meets the spirit of openness: don’t use open source hardware or software as a “prize” if your Kickstarter gets funded. It doesn’t work like that. Open source hardware isn’t a marketing term — it means something specific. We’re doing open source hardware because we want to, not because we want to trick people.
" (Thanks to Paul Wise.)
Comments (none posted)
On his blog, KWin hacker Martin Gräßlin describes the costs of supporting older graphics hardware
. In particular, he looks at some of the maintenance and testing burdens for continuing to support OpenGL 1.x hardware. "This means if I talk of legacy hardware it means hardware which is at least six years old. Supporting such hardware comes with some costs. E.g. on Intel you have the problem that you cannot buy the GPUs, that is you have to get a six year old system just to test. With ATI I faced the problem that even if I wanted to test an old R200 I cannot install it in my system because my system does not come with an AGP socket anymore – the same holds true for old NVIDIA systems.
Comments (82 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>