Webkit – Adam Hyde

The Old Days

First Book Sprint using Booki, Berlin, 2010

Wow…I was browsing some old archives to update this new version of my site. I found the most incredible stuff in the Internet Archives Wayback Machine including the outline of a description of Booki (2010) many years before it became Booktype. Amazing! I didn’t think I had the product manager in me but it seems once upon a time I was really focused on this kind of acute detail for product management. I had forgotten!

Forgive the long post, it’s just pure indulgent nostalgia for me. In any case, here is one of the emails I found really fascinating, from back in 2010, talking about features for Booki and Objavi (book renderer). This has been taken from the zip of a public list we used for dev at the time:
https://web.archive.org/web/20111029143503/http://lists.flossmanuals.net/pipermail/booki-dev-flossmanuals.net/

I’m so astonished how much of my thinking recorded in this email carries through to the way we are approaching product development for Coko now. The statement:

You might have noticed that I prefer to take the easy road for features, leaving as much open as possible, and then refine according to use. That is because,from experience, I have learned that when designing software it is better to be led by the user rather than force them into an imagined work flow.

Might as well be out of the Collaborative Product Design manifesto.

I’ts kind of incredible. The email documents so much of how we were thinking at the time, including using HTML and CSS to create paginated books using browser engines:

* Objavi utilises Webkit for PDF generation. Later Gecko will be added.

…and later in the product description…

3.2.2 CSS Book Design
Status: High Priority, Implemented
Function: The default PDF rendering engine for Booki is now Webkit and will eventually be Mozilla Firefox hence there is full CSS support for creating book formatted PDF in Booki. This changes the language of design from Indesign to CSS - which means any web native can control the design of the book.

Pretty interesting, if only to me! Anyway, the email is below, it documents some features we built on commission for Source Fabric before they eventually took over the project. Thank you for indulging me 🙂

From adam at flossmanuals.net Wed Jul 28 09:11:21 2010
From: adam at flossmanuals.net (adam hyde)
Date: Wed, 28 Jul 2010 18:11:21 +0200
Subject: [Booki-dev] notes to meeting
Message-ID: <1280333481.1582.143.camel@esetera>

hi Frank,

It was good to meet you and I'm glad Source Fabric is considering working with us and you to develop features they and we need (Aco is also keen for this). 

I have sent this email to the dev list and to you and Micz. It might be good for you both to consider joining the list.
http://lists.flossmanuals.net/listinfo.cgi/booki-dev-flossmanuals.net

Below the content of this email is a very basic requirements doc. It does not outline the notes tab, so I thought I would make some notes here for your (and Micz's) consideration should Source Fabric decide they wish to commission all or part of this development. 

In essence, I think that the notes tab could nest the following:
1. To do list
2. Book notes
3. Style guide

These could be hidden via a dropdown or accordian style interface. Our plan is to keep everything as simple as possible so I would imagine a page with three headings and clicking on each reveals the information behind it.

Some ideas:
1. To do list
The basic form could be a Jquery to do as we looked at today:
http://demo.tutorialzine.com/2010/03/ajax-todo-list-jquery-php-mysql-css/demo.php

If this is the format, it would be good enough as it is. The good news is that this is done using Jquery so I imagine this is a very easy implementation. What you would need to work out, however, is how Aco implements the dynamic updates so that when a to do is altered everyone has that info updated.

If there was room to take this development a step further, I would recommend considering adding the following fields:
* assigned to
* due date
* priority

I am not married to those ideas though as I think we need to insure that the interface does not have too many things going on. So I would actually recommend we start with the basic implementation and move on. When users have tried it then we can consider extending it with these items.

2. Book Notes
Something like etherpad would be good but too complex (see.
http://piratepad.net/ )
I would suggest considering either a) the same interface as we have now in the notes pad except with a very very simple WYSIWYG or b) a threaded comment system. I think the best would again be to do the easiest and simplest - what we have now with a WYSIWYG interface (and no need to press 'save'). Then when users use it we extend according to demand for most-needed features. 

3. Style Guide
This is pretty much the same as (2) except it would be used for storing the Style Guide. A style guide is optional but many people request it in FLOSS Manuals and some go out of their way to create one so I think this would be a very good feature to anticipate based on our user experience so far.

I think all of the 3 above are simple and I think Source Fabric's working process (especially for the forthcoming Sprints) would benefit a lot from them.

You might have noticed that I prefer to take the easy road for features, leaving as much open as possible, and then refine according to use. That is because from experience I have learned that when designing software it is better to be led by the user rather than force them into an imagined workflow.

It has worked well for us so far - everything you now see in Booki is pretty much that way because we have tried similar ideas in FLOSS Manuals and seen their effect. I would prefer to continue to work this way with Booki. 

So...there was one more feature we discussed - Chapter Level notes. I think this would be extremely useful for Source Fabric (but Micz needs to comment on this) but we need to be careful that we get it right because it is not so obvious how this might work. 

I think the notes have to be associated with the chapter page when you edit it - however there is very little space there. One possibility is to build this into the WYSIWYG editor - Xinha - as a 'notes server' or some such. ie. it opens from the WYSIWYG editor but stores the content (chapter notes) in the booki db. The risk here is that people will not know that the notes are there...so we need to consider this. Another possibility is to build this into a 'sliding tab' as Micz suggested. I think that might be ok but it would have to be done carefully as it might look too much like a gimmick.

The other issue with chapter level notes is that I strongly believe that an overview of all chapter notes for a book should be able to be seen somewhere, in one place. Otherwise it would mean checking each chapter which would be a tedious job (books easily have 30+ chapters). So if you consider Chapter notes then you must also consider how to do this. 

So on this I am not so clear what would work well for Chapter level notes and because of this I think it's not such a good feature for our first adventure working together. I would recommend instead the first three to be done all together - however this is up to Micz.

My feeling is that the first 3 are an extremely quick development, first however you need to know how it all fits together so i would suggest emailing this list when you have questions and I am sure Aco will answer your questions...

Also, Aco is currently working on the Booki site update so I expect the GIT repo is not updated but will be within the next days once the booki www is updated....

also you should meet Doug - doug is on this list and he is the Objavi (PDF generator) developer....doug - frank, frank - doug

also, meet John who does the Booki manual and other essential tasks intro intro :)

:)

adam

1 INTRODUCTION

1.1 Description
Booki is designed to help you produce books, either by yourself or collaboratively. A book in this context is a "comprehensive text" which can be output to book-formatted PDF (for book production), epub, odt, screen readable PDF, templated HTML and other formats.

Booki supports the rapid development of content. Booki has tools to support the development of content in 'Book Sprints'. Book Sprints are intensive collaborative events where collaborators in real and remote space focus on writing a book together in 3-5 days. 

While you can use Booki to support very traditional book production processes, the feature set matches the rapid pace of publishing possible in the era of print on demand and electronic readers. Booki can output content immediately to multiple electronic formats. Print ready source (book formatted PDF) can be immediately generated, and then uploaded to your favorite Print on Demand (PoD) service, taken to a local printer, or delivered to a publisher.

1.2 Purpose
Booki embraces social and collaborative networked environments as the new production spaces for comprehensive (book) content. 

1.3 Scope
Booki is available online as a networked service (http://www.booki.cc) for free. This service is a production tool for the creation of free content and not a publishing/hosting service. Content produced within Booki.cc is intended to be published elsewhere, either under another domain, in paper form (ie. books), distributed in electronic formats, or re-used in other content. 

Booki can be installed by anyone wishing to utilise this software under their own domain or within private or local networks. 

2 OVERALL DESCRIPTION

2.1 Product Perspective
Booki takes what was learned from building the FLOSS Manuals tool set and posits these lessons within a more suitable architecture. 

Booki is the name of the collaborative production environment, however there are 2 associated softwares that provide all the services required :
Booki - production environment
Objavi - import and export engine
This document refers to Booki 1.5 and Objavi 2.2

2.2 Booki Functions
* User account creation requiring minimal information
* One click book creation
* Drag and drop Table of Contents creation
* One click editing of chapters
* Chapter level locks
* Live chat on a book and group level
* Live book status reports (editing, saving, chapter creation) delivered
to the chat window
* Drop down chapter status markers
* One click to join a group
* One click to add a book to a group
* One click exporting to epub, screen pdf, book formatted pdf, odt, html with default templates
* Easily accessible advanced styling options for export (CSS controlled)
* User profile control (status, image, bio)
* One click group creation
* Easy importing of book content from Archive.org, Mediawiki, other Booki installations
* Option to upload content to Archive.org

2.3 User Characteristics
2.3.1 Contributor
The majority of users will be contributors to an existing project. They may contribute to one or more project and may produce text and/or images, provide feedback or encouragement, proof, spell check, or edit content. These are the primary users and the tool set should first meet their needs.

2.3.2 Maintainer
These are advanced users that create their own books or have been elevated to maintainer status for a book by group admins. Maintainers have associated administrative tools for the books they maintain which are not available to other users.

2.3.3 Group admin
These are advanced users that wish to establish and administrate their own group. They have maintenance tools for every book in their group plus additional group admin tools.

2.4 Operating Environment
Booki is designed primarily for standards-based Open Source browser comparability but is tested against other browsers. 

2.5 General Constraints
* Booki and Objavi are Python-based.
* Booki is built with the (bare) Django framework.
* Booki uses Jquery for dynamic user interface elements. 
* Booki uses Postgres as the database but sqlite3 can also be used
* Redis is used by Booki for persistent data storage to mediate dynamic data delivery to the user interface
* Objavi utilises Webkit for PDF generation. Later Gecko will be added. 
* Rendering of .odt by Objavi requires OpenOffice to be installed with unoconv. 
* The Booki Web/IRC gateway may eventually (and optionally) require a dedicated standalone IRC service hosted on domain. 
* Content editing in Booki is done by default with the Xinha WYSIWYG editor
* XHTML is the file format for content. 
* Content will be ultimately be stored in GIT. 
* Localisation in Booki is managed with Portable Object files (.po).
* The code repository for both projects is GIT with a dedicated Trac for bug reporting and milestone tracking :
http://booki-dev.flossmanuals.net 
* A Dev mailing list is maintained here:
http://lists.flossmanuals.net/listinfo.cgi/booki-dev-flossmanuals.net 
* Developers can be reached in IRC (freenode, #flossmanuals)
* Each release will be as source. Beta and later releases will also be available as Debian .deb packages. 
* User and API Documentation will be maintained in the FLOSS Manuals
Booki Group. 
* For development we use Apache2 for http delivery
* The license is GPL2+ for all softwares

2.5 User Documentation
Maintained here : http://www.booki.cc/booki-user-guide/

3 SYSTEM FEATURES

3.1 Booki Features

3.1.1 Booki-zip (Internal File Format)
Status: High Priority, Implemented
Function: A Booki-specific file structure for describing books 
Interface: Used for internal data exchange between Booki and Objavi. 
Notes: booki-zip definition maintained here :
http://booki-dev.flossmanuals.net/git?p=objavi2.git;a=blob_plain;f=htdocs/booki-zip-standard.txt

3.1.2 Account Creation
Status: High Priority, Partially Implemented
Function: Quick access to a registration form from the front page for account creation 
Interface: Requires only username, password, email and real name (required for attribution). Email is sent to the user with autogenerated link for verification
Notes: email confirmation mechanism missing

3.1.3 Sign in
Status: High Priority, Implemented
Function: Quick access to a sign-in form from the front page 
Interface: Username and Password form and submit button. Username and
pass remembered. 

3.1.4 Profile Control
Status: Medium Priority, Implemented
Function: When logged in the user can access a profile settings page to set personal details (email, name, bio, image). Personal details can be browsed by other users
Interface: "My Settings" link in user-specific menu on left gives access to a form for changing the details.

3.1.5 Book Creation
Status: High Priority, Implemented
Function: Users can create a book from their homepage ("My Profile").
Interface: User can click on "My Profile" link from the user-specific menu on the left. On the Profile page a text field for the name of the book, and a license drop down menu (license *must* be set) is presented.
Clicking on "Create" adds the empty book with edit button to the listing of the users books on the same page.

3.1.6 Archive.org Book Import
Status: Medium Priority, Implemented
Function: Users can import books from Archive.org
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the ID of any book from
Archive.org. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Relies on Archive.org successfully delivering epub for each book but this is not always happening. Needs error catching and user friendly progress/error messages.

3.1.7 Wikibooks Book Import
Status: Medium Priority, Implemented
Function: Users can import books from Wikibooks
(http://en.wikibooks.org)
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the URL of any book from Wikibooks. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Needs thorough testing as it is sometimes failing possibly due to time-outs. Needs error catching and user friendly progress/error messages. Should be extended to be a "mediawiki import" tool, not just for Wikibooks.

3.1.8 Epub Book Import
Status: Medium Priority, Implemented
Function: Users can import any epub available online
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the URL of any epub. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Needs thorough testing as it is sometimes failing possibly due to time-outs. Needs error catching and user friendly progress/error messages.

3.1.9 Group Creation
Status: High Priority, Implemented
Function: Users can create groups. 
Interface: "My Groups" link in the user-specific menu on the left presents user with 2 text fields - group name, and description. When a name for a group is entered and "Create" is clicked then the group is created.
Notes: Group admin features missing.

3.1.10 Joining Groups
Status: High Priority, Implemented
Function: Users can join groups with one click.
Interface: "Groups" link in the general menu on the left presents a list of all Groups, by clicking on link the user is transported to the homepage for that group. At the bottom of the page the user can click "Join this group" and they are subscribed.

3.1.11 Adding Books to Groups
Status: High Priority, Implemented
Function: Users can add their own books to groups they belong to.
Interface: While on a Group page that the user is subscribed to the user can add their own books to the group. 
Notes: When Group Admin features are in place we will change this so that Group Admins set who can and cannot add books to groups. At present a book can only belong to one group.

3.1.12 Readable Book Display
Status: High Priority, Implemented
Function: Users can read stable content in Booki without the need to log-in.
Interface: Upon clicking on the "Books" link in the general menu on the left a page listing all books is presented. Clicking on any of these presents a basic readable version of the stable content. Alternatively users can link to a book on the url http://[booki install domain]/[book name]

3.1.13 Edit Page
Status: High Priority, Implemented
Function: Page for editing content.
Interface: The edit page is accessed by clicking on "edit" next to the name of a book in "My Books" or "Books" (all books) listings. The user is then presented with a page with tabs for : editing, notes, exporting, history

3.1.14 Edit Tab
Status: High Priority, Implemented
Function: Edit interface for chapters.
Interface: Clicking ?edit? on a chapter title will open the Xinha WYSIWYG editor with the content in place. 

3.1.15 Notes Tab
Status: High Priority, Implemented
Function: A place for contributors to keep notes on the development of the book
Interface: User clicks on the Notes tab for a book and is presented with a shared notepad for recording issues or discussing the development.
Notes : Implemented but future direction TBD 

3.1.16 History Tab
Status: High Priority, Implemented
Function: Shows edit history of the book
Interface: User clicks on the history tab and can see the edit history with edit notes. 
Notes: Implemented but unreadable. Users should also be able to access diffs here.

3.1.17 Export Tab
Status: High Priority, Implemented
Function: Export content to various formats
Interface: User clicks on the Export tab and is presented with a form for choosing export options. Clicking "Export" returns the desired output for download. 

3.1.18 Version Tab
Status: High priority, Not Implemented
Function: can easily freeze content at stable stages while work continues on the unstable version.
Interface: From the Edit Page a maintainer sees an extra tab "Version".
>From here a maintainer can click "create stable version" - the last stable version is archived recorded and the current version becomes the new stable version. 

3.1.19 Subscribe to edit notifications
Status: High Priority, Not Implemented
Function: Users can subscribe to edit notifications
Interface: User clicks "Subscribe to edit notifications" from the Edit Page for a book. If there are edits made a synopsis is emailed with basic edit information (time, chapter, person who made the change, version numbers) and a link to the diff.

3.1.20 Chat
Status: High priority, Implemented
Function: A real time chat (web / IRC gateway).
Interface: Persistent on the edit page for any book. 

3.1.21 Localisation
Status: High priority, Not Implemented
Function: Booki needs to be available in any language where it is needed. Hence we may integrate the Pootle code base into Booki to enable localisation of the environment.
Interface: TBD

3.1.22 Translation
Status: High priority, Not Implemented
Function: Content can be forked and marked for translation. A
translation version of a book will provide link backs to the original
material, be placed in a translation work flow, and edited in a
side-by-side view where the translator can also see the original
source. 
Interface: TBD 

3.1.23 Copyright Tracking (Attribution)
Status: High Priority, Implemented 
Function: Any user contributions are recorded and attributed.
Interface: All attributions are automated in Booki. Book level attribution is output in any chapter that contains the string "##AUTHORS##"
Note: should be a syntax for producing Attribution notes on a per-chapter basis eg. "##CHAPTER-AUTHORS##"

3.2 Objavi Features

3.2.1 Book-Formatted PDF Output
Status: High Priority, Implemented
Function: the server side creation of Book Formatted PDF is a pivotal feature. This is managed by Objavi which runs as a separate service. The book formatted PDF supports Unicode, bi-directional text, and reverse binding for printing right-to-left texts on a left-to-right press and vice versa. The formatting engine outputs customisable sizes including split column PDF suitable for printing on large scale newsprint.
Interface: This feature is managed by Objavi, an API is functional and feature rich but not well documented at present. Objavi also presents a web interface for those wanting more nuanced control (see http://objavi.flossmanuals.net/).

3.2.2 CSS Book Design
Status: High Priority, Implemented
Function: The default PDF rendering engine for Booki is now Webkit and will eventually be Mozilla Firefox hence there is full CSS support for creating book-formatted PDF in Booki. This changes the language of design from Indesign to CSS - which means any web native can control the design of the book. 

3.2.3 Export Formats
Status: High Priority, Implemented 
Function: Users also can export to self contained templated (tar.gz) HTML, to .odt (OpenOffice rich text format), epub, and screen readable PDF. Other XML output options can be developed as required.

I guess I can never claim to not having project management experience again. Darn it.

In-Browser Design

The page is changing in so many ways – time-based media is making its way into book pages, reactive content, scrollable space, and a multitude of differing display devices make designing pages pretty hard work these days. How to design for so many possibilities? How to understand so many possibilities?

Craig Mod of flipboard makes a very compelling argument for two forms of page : formless and definite content in an article he wrote for Book: A Futurists Manifesto – the first book to be produced by PressBooks. Craig’s argument, in a nutshell and in his own words is:

the key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries; Definite Content is not only aware of the page, but embraces it. It edits, shifts, and resizes itself to fit the page [...] Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas.

Craig argues that most book content we know is formless – the text can reflow into other containers without affecting the meaning. This position is in tension to the thinking of most book designers today. Designers of paper books design contained space and desktop publishing applications are built to manage pixel-perfect manipulation within a strictly defined and known container. If the finished digital article does not exactly co-relate to the printed artefact then something went wrong; it is assumed that either the designer, or the tool, has done a bad job.

Those familiar with this kind of process are uneasy with designing formless content – how can you design a page when you do not know its container? It is literally like asking a book designer to design a book without telling them the page dimensions. Web designers, on the other hand, have been thinking about page design too, and they have for a long time, at least in part, been designing for formless content.

The design of formless content is really a partially-formless, partially-constrained design process since elements within the page have some kind of relationship to each other, and they can have relationships to characteristics of a page, such as top or top left, for example. These relationships are defined by rules, the same rules I have discussed previously – CSS aka Cascading Style Sheets. Relationships can be articulated with CSS which will be preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements and page features more than by their relationship to the the exact x,y position of a page with a specific dimension, although strict placement is possible. This is the job of Cascading Style Sheets – the design language of the web. It is rule-based design with some conditional arguments and it is the method for designing electronic books; it will become, increasingly, the technology for describing the layout and design of paper-based print.

All of this can be manipulated in the browser. In fact, the browser is the best place to design flowable text since it is the flowable type environment of our time and, as mentioned before, the browser (Webkit) is the background technology for many e-readers. We have not yet seen the development of very good flowable design environments in the browser, but that is changing. The closest we have seen so far are the ‘in-browser’ design environments that some internet service providers make available for their customers to ‘design their own website online!’ While actually quite powerful, these environments are generally horrible to use, but this practice is applicable to the design of ebooks.

The desktop publishing world is not taking this lying down, and Adobe, in particular, has been pursuing what they call “Adaptive Design Tools” for the production of ‘liquid content’. Liquid content is flowable content, content that can rescale and position itself to fit the container. Adobe’s tools are intended for content targeted for mobile devices and tablets, although they also identify a role for it in print production. Adobe’s yet-to-be-released Adobe Edge is the product targeted at this flowable design process and their background technology for this design environment is – Webkit, the same browser mentioned earlier. Webkit is the ‘design surface’ for the new generation of desktop design tools coming from established publishing technology providers.

Coming back to the paper book. Until recently it has been extremely difficult to generate a PDF that exactly co-relates to what you see in a browser. Until now the browser accessed the PDF-creation features of the operating system. Hence a PDF from the same browser would look different if that browser were running in Windows, Mac or Linux. Just recently this has changed and the browser itself is now making the PDF. Chrome has been pioneering this ‘Native PDF’ output from the browser and the output looks exactly as you see it in the browser. One to one co-relation of content in the browser to the content in the PDF is a breaking point which points the way to designing your paper book in a browser. We are getting to the point where you can use a browser just as you would a desktop publishing application to design paper books.

The browser can now play every part of the book production process except the actual printing (although from the browser you can upload PDF to print-on-demand services such as Lulu.com).

What this means is that you can write a book in the browser, while at the same time it is being proofed and edited, and designed. Each part of this formerly-linear production cycle can now become synchronous. You can now write, edit, proof, design the book ‘in the book’.

WYSIWYG vs WYSI

HTML is the new paper and the new path to paper online editing environments are becoming much more important for publishing. Dominant until now has been the WYSIWYG editor we all know and…err…love? However, the current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Producing text with a WYSIWYG editor feels like trying to write a letter while it’s still in the envelope. Let’s face it…these kinds of online text editors are not an extension of yourself, they are a cumbersome hindrance to getting a job done.

Apart from huge user experience issues the WYSIWYG editor has some big technical issues. Starting with the fact that the WYSIWYG editor is not ‘part of the page’ it is instead its own internally nested world. In essence, it is an emulator that, through Javascript, ‘reproduces’ HTML. As a walled/emulated garden, it is hard to operate on the objects in the garden using standard Javascript libraries and CSS. All interactions must be mediated by the editor. The ‘walled garden’ has little to do with the rest of the page – it offers a window through which you can edit text, but it does not offer you the ability to act on other objects on the page or have other objects act on it.

Thankfully a new era of editors is here and maturing fast. Still in search of a clearly embraced category name they are sometimes called ‘inline editors’ or HTML5 editors. This new generation takes a large step forward because they enable the user to act on the elements in the page directly through the HTML5 ‘contenteditable’ attribute. That allows ‘the page’ to be the editing environment which in turn opens up the possibility for the content to be represented in a variety of forms/views. By changing the CSS of the page, for example, we can have the same editable content shown as multi-column (useful for newspaper layout), as a ‘Google docs type’ clean editing interface, in a semantic view for highlighting paragraphs and other structural elements (important for academics), as well as other possibilities….

Additionally, it is possible to apply other javascript libraries to the page including annotation software such as AnnotateIt or typographical libraries such as kern.js. This opens up an enormous amount of possibilities for any use case to be extended by custom or existing third-party JavaScript libraries.

It is also possible to consider creating CSS snippets and apply them dynamically using the editor. This in effect turns the editor into a design interface which will open the path for in-browser design of various media including, importantly, ebooks and paper books.

There are various attempts at the HTML5 editor, which might also be called a ‘WYSI’ (‘What you see is‘) editor. The most successful are Mercury, Aloha and the recent fork of Aloha called ‘WYSIWHAT‘.

Each of these is treading their own path but things are really opening up. As an example, and with reference to the last post I made about math in browsers, the WYSIWHAT group is making some giant strides in equation editing. Their equation plugin which was first built by Mihai Billy Balaceanu at the September WYSIWHAT hack meet in Berlin has since been improved and extended by the Connexions team and the good people at OERPUB (including the talented trio of Phil Schatz, Kathi Fletcher and Marvin Reimer). The plugin was made by including MathJax in the page and allowing the editor to interact with that. This was not easily possible with previous WYSIWYG editors.

The progress on the equation front is looking very good but what this shows more than anything is that by using WYSI editors the entire page is available for interaction by the user or JavaScript. Anything you can think of that JavaScript can do you can bring to the editing environment, and that is quite a lot…

Published on O’Reilly, 3 December 2012 http://toc.oreilly.com/2012/12/wysiwyg-vs-wysi.html

Math Typesetting

Typesetting math in HTML was for a long time one of those ‘I can’t believe this hasn’t been solved by now!’ issues. It seemed a bit wrong – wasn’t the Internet more or less invented by math geeks? Did they give up using the web back in 1996 because it didn’t support math? (That would explain the aesthetic of many ‘home pages’ for math professors.)

MathML is the W3C-recommended standard markup for equations – it’s like ‘HTML tags for math.’ While MathML has a long history and has been established in XML workflows for quite some time, it was only with HTML5 that mathematics finally entered the web as a first-class citizen. This will hopefully lead to some interesting developments as more users explore MathML and actually use it as creatively as they’ve used ‘plain’ text.

However, the support in browsers has been sketchy. Internet Explorer does not support MathML natively, Opera only supports a subset, and Konqueror does not support it. Webkit’s partial support only recently made it into Chrome 24 and was held back on Safari due to a font bug. Firefox wins the math geek trophy hands down with early (since FF 3) and best (though not yet complete) support for MathML.

What’s the hold-up?

It seems that equation support is underwhelmingly resourced in the browser development world. Webkit’s great improvements this year (including a complete re-write + the effort to get it through Chrome’s code review) have been due to a single volunteer, Dave Barton. Frédéric Wang plays the same heroic (and unpaid) role for Firefox. The question is: why is this critical feature being left to part-time voluntary developers? aren’t there enough people and organisations out there that would need math support in the browser (think of all the university math departments just for starters…) to pay for development?

As a result, we have no browser that fully supports MathML. While you cannot overstate the accomplishments of the volunteer work, it’s important to tell the full story. Recent cries that Chrome and Safari support MathML can give the wrong impression of the potential for MathML when users encounter bad rendering of basic constructs. The combination of native MathML support, font support, and authoring tools, [ see this more recent post for more detail] makes mathematical content one of the most complex situations for web typesetting.

There have been some valiant attempts to fix this lack of equation support with third-party math typesetting code (JavaScript), notably Asciimath by Peter Jipsen with its human-readable syntax and image fallbacks, jqmath by Dave Barton (same as above), and MathQuill.

However, by far the most comprehensive solution is the MathJax libraries (JavaScript) released as Open Source. While MathJax is developed by a small team (including Frédéric Wang above) they are bigger than most projects, with a growing community and sponsors. MathJax renders beautiful equations as HTML-CSS (using web fonts) or as SVG. The markup used can be either MathML, Asciimath or TeX. That means authors can write (ugly) markup like this:

J\alpha(x) = \sum\limits{m=0}^\infty \frac{(-1)^m}{m! , \Gamma(m + \alpha + 1)}{\left({\frac{x}{2}}\right)}^{2 m + \alpha}

into an HTML page and it will be rendered into a lovely looking scalable, copy-and-paste-able equation. You can see it in action here.

So why is this really interesting to publishing?

Well… while EPUB3 specifications support MathML, this has not made it very far into e-reader devices. However, MathJax is being utilised in e-reader software that has JavaScript support. Since many ebook readers are built upon Webkit (notably Android and iOS apps, including iBooks) this strategy can work reasonably effectively. Image rendering of equations in ebook format is another strategy, and possibly the only guaranteed strategy at present, however, you can’t copy, edit, annotate or scale the equations and you cannot expect proper accessibility with images.

The only real solution is full equation support in all browsers and e-readers either through native MathML support or through the inclusion of libraries like MathJax. We can’t do anything to help the proprietary reader developments get this functionality other than by lobbying them to support EPUB3 (a worthwhile effort) but since more and more reading devices are using the Open Source WebKit, we can influence that directly.

The publishing industry should really be asking itself why it is leaving such an important issue to under-resourced volunteers and small organisations like MathJax to solve. Are there no large publishers who need equation support in their electronic books that could step forward and put some money on the table to assist WebKit support of equations? Couldn’t more publishers be as enlightened as Springer and support the development of MathJax? You don’t even have to be a large publisher to help – any coding or financial support would be extremely useful.

It does seem that this is a case of an important technological issue central to the development of the publishing industry ‘being left to others.’ I have the impression that it is because the industry as a whole doesn’t actually understand what technologies are at the centre of their business. Bold statement as it is, I just don’t see how such important developments could go otherwise untouched by publishers. It could all be helped enormously with relatively small amounts of cash. Hire a coder and dedicate them to assist these developments. Contact Dave Barton or MathJax and ask them how your publishing company can help move this along and back that offer up with cash or coding time. It’s actually that simple.

Many thanks to Peter Krautzberger for fact checking and technical clarifications.

Published on O’Reilly, 26 November 2012 http://toc.oreilly.com/2012/11/math-typesetting.html

Gutenberg Regions

With the onward march towards the browser typesetting engine, not an invention but a combination of technologies with some improvements (much like Gutenberg’s press), it’s interesting to think what that would mean for print production. Although there are various perspectives on how the printing press changed society – and they mostly reflect on the mass production of books – and while the first great demonstration involved a book (The Gutenberg Bible), the invention itself was really about automating the printing process. It affected all paper products that were formerly inscribed by hand and it brought in new print product innovations (no not just Hallmark birthday cards but also new ways of assembling and organising information).

The press affected not just the book but also print production. And now we have browsers able to produce print-ready PDF and the technology arriving to output PDF from the browser that directly corresponds with what you see in the browser window, we are entering the new phase of print (and book) production – networked in-browser design. We are not talking here of emulated template-like design but the 1:1 design process you experience with software like Scribus and InDesign.

The evolution of CSS

There are several JavaScript libraries that deal with this, as I have mentioned in earlier posts (here and here), and the evolution of CSS is really opening this field up. Of particular interest is what Adobe is doing behind the scenes with CSS Regions. These regions are part of the W3C specification for CSS and the browser adopting this specific feature the fastest is the Open Source browser engine Webkit, which is used by Chrome and Safari (not to mention Chromium and other browsers).

CSS Regions allow text to flow from one page element to another. That means you can flow text from one box to another box, which is what is leveraged in the book.js technology I wrote about here. This feature was included in Webkit by the Romanian development team working for Adobe. It appears that Adobe has seen the writing on the wall for desktop publishing although they might not be singing that song too loudly considering most of their business comes out of that market. Their primary (public facing) reason for including CSS Regions and other features in Webkit is to support their new product Adobe Edge. Adobe Edge uses, according to the website, Webkit as a ‘design surface’.

A moment of respect please for the Adobe team for contributing these features to Webkit. Also don’t forget in that moment to also reflect quietly on Konquerer (specifically KHTML), the ‘little open source project’ borne out of the Linux Desktop KDE which grew into Webkit. It’s an astonishing success story for Open Source and possibly in the medium term a more significant contribution to our world than Open Source kernels (I’m sure that statement will get a few bites).

”HTML-based design surface” is about as close to a carefully constructed non-market-cannibalising euphemism as I would care to imagine. Adobe Edge is in-browser design in action produced by one of the world’s leading print technology providers but the role of the browser in this technology is not the biggest noise being made at its release. Edge is ‘all about’ adaptive design but in reality it’s about the new role of the browser as a ‘target agnostic’ (paper, device, webpage, whatever – it’s all the same) typesetting engine.

A consortium, not an individual company

However, we should not rely on Adobe for these advances. It is about time a real consortium focused on Open Source and Open Standards started paying for these developments as they are critical to the print and publishing industries and for anyone else wanting to design for devices and/or paper. That’s pretty much everyone.

Gutenberg died relatively poor because someone else took his idea and cornered the market. Imagine if he put all the design documents out there for the printing press and said ‘go to it.’ Knowing what you know now, would you get involved and help build the printing press? If the answer is no, I deeply respect your honesty. But that’s where we are now with CSS standards like regions, exclusions, and the page-generated content module. The blueprints are there for the new typesetting engine, right there out in the open. The print and publishing industries should take that opportunity and make their next future.

Originally posted on Nov 6, 2012 on O’Reillys Tools of Change site: http://toc.oreilly.com/2012/11/gutenberg-regions.html

The New New Typography

In the 1920s and 1930s in Europe, there was a movement known as the New Typography. It was a movement that rejected traditional type set in symmetrical columns and instead treated the printer’s block as a blank canvas to be explored in its entirety. The calling card of the movement was type arranged in harmonious and beautiful asymmetric compositions. In the past two years, there has been another slow-breaking wave of typographical exploration. The printer’s block is now HTML, and CSS and JavaScript are fast becoming the new tools of the typographer – not just for the web but for ebooks and for print, and not just for printed books, but for all printed material.

Browser as typesetting machine

The change of the book’s basic carrier medium from paper to HTML (the stuff web pages are made of) has meant many changes to what we might still call typesetting. Kindle and other e-ink devices actually move ink on a display screen to form words, sentences and paragraphs. The moveable type of Gutenberg’s time has become real time – in a very real sense, each book is typeset as we read it. Content is dynamically re-flowed for each device, depending on display dimensions and individualised settings to aid readability. Moving type in ‘read time’ marks a significant paradigm shift from moveable type systems, including digital moveable type manipulated by desktop publishing software, to flowable typesetting. We are leaving behind moveable type for flowable type.

The engine for reflowing a page in real time is something we have seen before. It is the job of the browser. And, since ebooks are webpages, browsers have come to play a central role in digital e-readers. In the case of the iPad, the iBook reader is actually a fully featured browser engine, Webkit, the very same technology behind the Chrome and Safari browsers. Browsers are the typesetting machines for ebooks.

What is interesting here, is that the browser can also reflow content into fixed page formats such as PDF, which means that the browser is becoming the typesetting engine for print. CSS and Javascript are the print design tools of our immediate future and the vast majority of innovations in this area are based on Open Source and Open Standards.

The power of CSS and JavaScript

CSS is the set of rules followed by the browser in placing type, images and other elements on a webpage and styling those elements. Typical rules define where an image is placed in relationship to text, the font used, the font size, background colour of the page, and the maximum width of an image, and so on. While designed originally for the exclusive application to webpages, the CSS Working Group responsible for overseeing the development and direction of CSS, anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standards, new additions are almost entirely focused on typography and page control. As a consequence, this area is starting to blossom. In particular, the CSS Generated Content for Paged Media Module specification is astonishing for its reframing of flowable text into a fixed page. Cross reference and footnote controls, not needed on the web, are among many book-like structure controls being addressed by CSS. Table of contents creation, figure annotations, page references, page numbers, margin controls, page size, and more, are all included. The definition of these rules precedes their adoption in browsers, however they are being included in browser engines, notably Webkit, at a very fast pace.

Coincidently, there has recently been an explosion in interest in improving browser typography primarily for the better design of websites. Although these advances have not been made with book production in mind, these advances can be inherited by the browser for typesetting both electronic and paper books. Of interest is the sharp rise in the websites offering tips on CSS typography, an associated explosion of the available web fonts, and some very interesting JavaScript libraries.

JavaScript is the programming language of the web and it can be used to create dynamic content or manipulate objects on a webpage in ways CSS cannot, or cannot yet. Of particular interest is kerning.js, inspired by the previously available lettering.js library. These code libraries allow you to change each letter individually in a paragraph or heading and control the spacing between letters (called ‘kerning’). Kerning is essential for printed books, and ebooks, but missing from browsers for a very long time. colorfont.js is another JavaScript library which enables dual toned glyphs, and the amazing typeset.js emulates the sophisticated TeX line spacing algorithms developed by Donald Knuth.

Even the layout of musical notation and guitar tablature (which were never effectively mechanised with Gutenberg’s moveable type and were handwritten into books for many decades after the printing press came into the world) have come into focus with another JavaScript library, VexFlow. With libraries like these, it is apparent that JavaScript, the programming language of the browser, has a future with typography, and that JavaScript is fast becoming the lingua franca for all typesetting.

There is a lot of fuel in these developments and, interestingly, most of it is coming from outside the traditional print and publishing industry. It could be said that these industries, built upon the printing press, have lost sight of their very foundation. Instead, the IT industry is taking hold on a very deep level.

Apple and Google are behind the development of Webkit – the rendering engine behind iBooks, Safari and Chrome – which makes a lot of these typesetting innovations possible. Apple utilises these typographical features not just in its browser, but in the development of its iBook reader – the ebook reader on iPad which is itself based on Webkit. Google also fuels these innovations for many reasons other than the browser – better typography in Google Docs being one of them. We can expect the momentum to build and it is possible to say with some confidence that the browser, together with CSS and JavaScript, is to become the most important typesetting engine of our time as it is fast becoming the typesetting mechanism for digital and paper books and the web.

Ease and efficiencies

The implications of this succession by the browser are enormous and possibly not yet fully realised. At publishing industry conferences and other book-focused forums, the attention has largely been on the ebook’s affect on distribution, and on e-readers and the demise of the so-called bricks-and-mortar book stores. The biggest effects, however, are elsewhere, ‘bubbling under’ in the recasting of the browser as a typesetting engine, and with it the slow realisation that the technical ecosystem surrounding book production can be replaced by tools for producing webpages.

We are beginning to turn our attention to the tools for making webpages, to make books, and this, it turns out, is much easier than with desktop word processing and publishing software. Additionally due to recent developments, all of this, as it turns out, can also be used to design print (more on in-browser print production in a future post). Book production once again is becoming faster and cheaper and is on its way to achieving another leap of magical efficiency.

The future of book production right now is exploding all around us. These pieces of the puzzle are coming together and coming together fast. We can almost watch in real time as the necessary mechanics get filled in by new release candidates of major browsers and searching online for ‘out of the blue’ small innovations such as JavaScript typography controls. It is getting easier and easier to make books in the browser and consequently there has never been a time when it has been this easy to make books of all kinds.

Ease of production is where it all started for Gutenberg and it is starting again for us. If you believe Gutenberg’s efficiencies changed society forever, then what affect will the new-new typesetting engines have? It’s a giddy question. Making books in the browser will have an enormous impact on society as a whole, and just like the printing press, it will not revolutionise the old order, but create a new one.

Originally published on O’Reilly website, 18 Oct 2012 http://toc.oreilly.com/2012/10/the-new-new-typography.html

CSS is the new typography

The new layout language for the book is HTML. It has never been easier to make web content using HTML, hence it has never been easier to make a book.

Generally speaking, HTML is frowned upon as a source file format for books because it is seen as worst practice. Best practices require complicated file formats like “docbook” or, worse, Latex. These file formats have been designed to contain and describe content so that beautiful books can be made. Unfortunately, the process of creating docbook and Latex is extremely complicated. Getting a new user to work with either of these formats is quite a process. On the other hand, WYSWYG editors which produce HTML work very much like simple text editors. It is trivial to create HTML with a WYSIWYG editor or similar tool and it can be done online.

HTML is a very established, very well used, and very well distributed format. There are already an enormous number of people using HTML, and an enormous amount of content already stored in HTML. That content and those people are networked, and HTML has a rich legacy of tools that enable transformations into other formats. HTML is the new source format for books.

CSS (Cascading Style Sheets) is the syntax that controls the look and feel of HTML. E-readers and web-browsers can read this syntax and present the content accordingly. Book production platforms such as Booktype enable the customisation of CSS for ebook output, but, more interestingly Booktype also enables CSS to control the look and feel of paper books. Designing in this way takes some thought since it is usually disorientating for book designers to ‘design in code’ and it is equally disorientating for web designers to use code to design material products.

The W3C CSS Working Group¹ (responsible for overseeing the standard) anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standard, new additions are almost entirely focused on typography² . As a consequence of this emphasis, this area is starting to blossom. There has also recently been a sharp rise in the websites offering tips on CSS typography³and an explosion of web fonts. (If you are interested in a very good insight about how fonts get to the web please watch the Unbound Book video presentation by Otmar Hoefer, the Director of Font Marketing at Linotype Library⁴ ).

There are also some very interesting JavaScript libraries available that are trying to make up for what is lacking in CSS typographical controls. Most are based on the well-used and prolifically distributed JQuery JavaScript libraries.

Of particular interest is the kerning.js library which combines the previously available lettering.js library. What these libraries do is to make each glyph (letter/number) into its own element, each of which can then be transformed by CSS-like rules. In plain speak, these code libraries allow you to change each letter individually in a paragraph or heading etc.

There are some nice demonstrations online about why this is interesting, of which the most interesting demo can be found at kern.js. Try visiting that page, double click the big blue circle, then click on and drag the letters individually.

If you then click ‘Finish Editing,’ you will get the CSS controls necessary to implement this effect (if you had kerning.js linked from your page).

There is also another interesting typographical library called colorfont which enables dual toned glyphs.

It is a pretty good trick they used to achieve this. Essentially they created two fonts from the same master font, each displaying just partial glyphs. When overlayed, they display the full glyph. Hence each ‘layer’ can be targeted with a different color.

With libraries like this, it is apparent that JavaScript has a future with web typography but maybe it doesn’t stop at that. These kind of tricks can also be implemented with ebooks and with more and more book designers entering the world of ebook design, I am sure we will see a growing need for more of these libraries.

Good nuanced control over font rendering is good enough at the moment and getting better quickly. However, many e-readers and all web-browsers do not support all of the CSS controls and most ebook readers do not currently support JavaScript. This will change in time, especially since ebooks are becoming a revenue stream for Apple, and Apple (together with Google) is behind the development of webkit – the rendering engine behind iBooks, Safari and Chrome. Good support of CSS typographical controls is on its way and we can expect more web designers to start designing books, and to see more book designers learning code.

What is dismaying, however, is the current trend of vendors like Apple to use non-standard CSS controls to layout the books. Baldur Bjarnasons has written some very good blog posts about this. The strategy by Apple is to make any book authored by the iBook Author software only work (or work well) when viewed with the iPad. I do not really understand this strategy – yes it is the typical platform / sales channel lock-in that Apple is known to perpetuate. However, it means that content creator content has limited distribution because of this. Apple might wave this away by saying that it is ‘innovating,’ but innovation like this cannot be seen without a degree of skepticism about the intended goals.

Nevertheless, it is possible to say with some confidence that CSS and JavaScript will come to be seen as an important development in the history of typography. Just as Gutenberg “was concerned only to imitate the book of his day – which was handwritten”⁵ but unintentionally gave birth to new aesthetics, we can imagine the new CSS typography to have similar consequences.

http://www.w3.org/Style/CSS/members.en.php3^{^}
http://dev.w3.org/csswg/css3-text/^{^}
http://www.1stwebdesigner.com/css/advanced-css-text-effects-web-typography-tips/^{^}
http://vimeo.com/24415178^{^}
Jan Tschichold, The New Typography, University of California Press, 2006, pg 15^{^}