Where does that leave the publishing business? Well, it might be better to ask yourself, ‘where does that leave business?’ Forget capital P, ‘Publishing’, for a moment. What are the skills necessary to survive here, what will you be doing, and what is the economy?

People are going to continue to require services that deliver and produce information. Finding ways to create information and finding someone to pay for it is the heart of the matter. That is not going to change any time soon. The need for information won’t change, how information is produced and delivered will change. In fact I believe the demand for content is going to rise (it is already rising rapidly), and the demand will increasingly be for more individualised, customised content and it will need to be delivered faster, much faster than today.

So, what would the world look like when the walls that contain the publishing industry fail and spill their innards onto the web. Or to see the same question through the lens of Eric Raymond, what is the essential difference between the cathedral and the bazaar?

Lets quickly look at the environment of this particular kind of “bazaar” – the web – for a few clues. The most important issue at play is that the web always appears to find a way to route around arbitrary constraints. People, processes, and information route their way around unnecessary blockages looking for and finding the most efficient and least resistant paths. So what would happen if publishing was immersed in that environment? What are the containers, the constructs of the publishing industry, that would be routed around and may breakdown and fail? Here, I want to explore four main issues pertinent to this discussion – Books, Ownership, Authors and Authority.

Books: In this environment content containers, like books, lose the definitiveness of their boundaries. What is separating an EPUB, which is made of HTML, from the web? As Hugh McGuire has said many times, this differentiation is arbitrary. Arbitrary containers like zip files (EPUBs, which we might call portable websites) might assist in the transport of curated content but in the long run they will be under a lot of pressure to remain contained and will increasingly become unbound.

Ownership: Another “container” that will come under increased pressure from these forces. If the mere fact of copyright ownership protected their content then publishers wouldn’t be looking to DRM (digital rights management). We know that the way in which book content is owned and licensed will change dramatically. Protecting ownership will increasingly become an impediment to business as it decreases the utility of information (something that O’Reilly was smart to recognise early on and perhaps reflects Samuel Johnsons’ famous quip regarding his writings that “I have been paid for them, and have no right to enquire about them”).

Authors: Also an arbitrary construct, in as much as both the realities of book authorship, and its production, are more collaborative and iterative than commonly perceived. This is another dimension that will be radically transformed by the new collaborative possibilities opened up by digital technologies. Indeed, perhaps the cultural construct of isolated genius will remain only as a brand. In reality, people are less and less isolated on the web and there is more genius out there than you can imagine. I would argue here that the concept of the author will also become more “porous”. We will be looking at a world of “networked genius” rather than the traditional standalone kind. This has been discussed in fascinating detail by Martha Woodmansee and Jack Stillinger.

Authority: The web doesn’t seem to allow anyone to merely assert ‘authority’ – such notions are subject to the ebb and flow of public web “opinion”. Publishing as an authority will certainly come under immense pressure and one possibility is the move to “distributed opinion networks” built and mediated by technologists. We have already seen this on the web, and the question of authority in these networks is well articulated in commentary surrounding Wikipedia vs Encyclopedia Britannica, for example.

When paper fails it affects creators, content, ownership, and trust in radically transformative ways. Production processes change, content is both harvested and produced, contributors are corralled and facilitated, books become individualised ‘outcomes’. We might say the engine this “new” publishing economy revolves around includes two critical factors: (1) content production, harvesting and curation for increasingly individualised contexts; and (2) speed of delivery. Helping people to get what they want, their outcome, is going to be the bread and butter of this economy. This is a move from selling the artifact, to developing and selling a service, or towards providing services to help others produce and distribute content. The faster you can deliver it the more competitive you will become. People, businesses, governments, schools, etc., are all going to be very happy to pay for that.

*Please note the Open Oil project is a small project and not provided here to illustrate this kind of model at scale but to point at a very interesting and important emerging model.

Many thanks to David Berry for improving this post. This post and all others by Adam Hyde are CC-BY-SA

Open data activists in particular have been lobbying governments for access to databases which they use to create infographics and visualisations for campaigns. It’s not a new science of course, it was here long before the net (for some background on contemporary practice see the wonderful books by Edward Tufte) but the net is made of data and a good mechanism for transporting it. The net is a good medium for scraping and re-presenting data in more palatable forms.

Prior to the net visualising book production has been tricky since the information either wasn’t recorded or is embedded in ungainly ‘record changes’ data in word processing files. So the few examples were preceded with some forensic historical research. One pre-Word example is the wonderful Traces by Processing inventor Ben Fry. Traces visualises the production of The Origin of Species over time to illustrate Darwin’s evolving thesis. Rather appropriately it is a  nice visualisation of the evolution of a book.

This is where the web steps in and changes the game. Online book production platforms enable you to store and retrieve historical data and use it as you like. You can record and access information quite easily. Information such as who is actively working on a book and when, how much they changed, what they changed, who else was online, word counts over time, is all available. If we could access and process this information in chunks it could perhaps help us to make books better.

Just to show you where this might go, the following are simple prototypes Juan Barquero and I put together using real data from the online book production platform Booktype. The nice thing about Booktype is that it already has all this data recorded in the history for each book so we could write a visualisation application and then look back over the history of many books. So we made a simple API (Application Programming Interface) and Juan put together a few demos using the JavaScript visusalisation library D3JS. The following are some images taken from these trials:

And you can try some if these prototypes here (all using real book production data):

1. Visualisation of book production over time. Clicking around changes the zoom level. Clicking on names removes them from the timeline.
2. These graphics show the activity of contributors. Clicking on the first graph shows the breakdown of activities by a specific contributor.
3. Very basic remapping of the same data as #2 above. With this example you can sort by actions or contributor  Clicking on the graph zooms in.

These are just a few simple and raw examples that are of course very far away from being production-ready. However they serve as interesting prototypes for thinking about how this might look and what we might learn from such techniques in a production environment.

How does three days sound? Enter Book Sprints.

These three books were created in a three-day Book Sprint and output to paper, MOBI and EPUB on the third day.

Book Sprints bring together 4-12 people to work in an intensely collaborative way to go from zero to book in 3-5 days. There is no pre-production and the group is guided by a facilitator from zero to published book in the time available. The books produced are made available immediately at the end of the sprint in print (using print-on-demand services) and ebook formats. Books Sprints produce great books and they are a great learning environment and team-building process.

This kind of spectacular efficiency can only occur because of intense collaboration, facilitation and synchronous shared production environments. Forget mailing Word files around and recording changes. This is a different process entirely. Think contributors and facilitators, not authors and editors.

There are five main parts of a Book Sprint (thanks to Dr D. Berry and M. Dieter for articulating the following so succinctly):

1. Concept Mapping: development of themes, concepts, ideas, developing ownership, etc.
2. Structuring: creating chapter headings, dividing the work, scoping the book (in Booktype, for example).
3. Writing: distributing sections/chapters, writing and discussion, but mostly writing (into Booktype, for example).
4. Composition: iterative process of re-structure, checking, discussing, copy editing, and proofing.
5. Publication

The emphasis is on ‘here and now’ production and the facilitator’s role is to manage interpersonal dynamics and production requirements through these phases (illustration and creation of other content types can take place along this timeline and following similar phases).

Since founding the method four years ago I have refined the methodology greatly and facilitated more than 50 Book Sprints – each wildly different from the other. There have been sprints about software, activism, oil contract transparency, collaboration, work spaces, marketing, training materials, open spending data, notation systems, Internet security, making fonts, OER, art theory and many other topics.

People love participating in Book Sprints partly because at the end of a fixed time they have been part of something special – making a book – but they are also amazed at the quality of the books made and proud of their achievement. Finally, it releases them from the extended timelines (and burdens of guilt) required to produce single authored works.

Here are some interesting write ups that provide more detail on the process:

1. 0 to Book in 3 Days? (Molly Sharp, Safari Books Online)
2. Google Document Sprint 2012 – 3 more Books Written in 3 days (Stephanie Taylor, Google)
3. Everything you wanted to know… (Dr David M. Berry and Michael Dieter)

If you would like to learn more about Book Sprints come to my workshop “Zero to Book in 5 Days” at TOC NYC.

While we continue to refer to ebooks as ‘books’ stability seems to be carried on as part of the currency. We don’t really even challenge it. EPUBs and mobi (etc.) with their ‘self -contained’ exactly reproducible nature also appear to reinforce the static nature of things.

Books are stable. Websites are not. That seems to be a delimiter that’s ‘in the air’.

However this seems to be a little arbitrary these days. Books were only stable because of the (long brewing) perfect storm of the invention of the printing press, creation of copyright, and the evolution of authorship. Before these three things brought stability, books were added to as ideas changed and prose improved, just like websites.

Now however books and websites are made of the same stuff. So its interesting to ask ourselves how long it will be before the book becomes unstable again.

Well, of course the technology is right here to make books unstable again. EPUBs, for example, are easy to re-edit and ‘re-publish’. Take a look at this quick demo I have been working on with Juan Barquero (the interface will become part of a forthcoming Booktype release).

What you see in this demo is an editor working on EPUB (essentially using EPUB as a storage mechanism). You can edit the pages (remember it’s just a prototype, it hasn’t been tested, etc.) and save and export a new EPUB by clicking ‘Publish’. The interesting thing about this is that it uses GIT as a backend (Adam Witwer and the O’Reilly crew have also been working on using GIT with Atlas). GIT is a technology programmers use to collaborate on code. It allows programmers to copy (fork) code, work on it and then re-combine (merge) the changes with the work of others. So with this demo we are using GIT with a book so you can clone, edit, fork and merge the book into infinite versions. If you want to, you can then re-merge it all back again.

OK, so that’s interesting – but what does it point to? It points to a return of the instability of books. The question really is – will instability of the book return? I believe it will come back and come back sooner than we think. Why? Because it’s better for the book.

As a very small case in point lets have a quick peak at the life of a forkable book. The Crypotparty Handbook.

The CryptoParty Handbook was created in Berlin during a 3 day Book Sprint last October. It consists of over 440 pages of information for those wanting to be safe online. The book was created so fast because it reused content from two existing books (licensed under Creative Commons): How to Bypass Internet Censorship and Basic Internet Security. Both of these were also created with Book Sprints the previous year.

Creating the CryptoParty Handbook was simply a matter of forking each of the other books and merging them into a new container. Easily done. The team, under my facilitation, then structured the table of contents, removed chapters that were not necessary, identified content that needed to be created and then started writing and illustrating. It didn’t take them much time to produce a book which was immensely useful for their audience and a book that could also be easily remixed and translated.

The handbook has now been forked quite a bit. The first version hit 30,000 downloads in the first few weeks.  There have also been some interesting forks including one by the Liberation Tech list hosted by Stanford University from where it has been forked again another 50 or 60 times.

The book is now being used by CryptoParties all over the world to train people in small informal workshops.

This is just one example highlighting what can happen when books embrace their natural unstable state. They become extremely powerful bodies of content that can be re-purposed infinitely for whatever context is necessary.

This is not some kind of hippie content love-in. There are economies in action here. It takes skill to curate and corral content, shape it, get it to meet the needs of a specific audience, and find experts to fill in the gaps. It takes experts in facilitation and curation. Each of these are attributes required of successful publishers, content creators, and editors who plan to create tomorrow’s dynamic content.

Please note: the demo I provided is very rough. It will only take 60 save requests per minute in its present state. If it doesn’t save your edits it might be because there are too many people trying it out. If that happens to you, please come back at another time and try it again.

While all content is trending towards CSS and JavaScript, the core technologies of the browser, it seems a little weird to position EPUB as being a collection of things that do something different from what browsers do. The nuance might not be clear so here goes…

EPUB is essentially a collection of standards wrapped up inside a zip file with a few extra bits that ‘bind’ the content together. The extra bits give metadata and information needed for books including a table of contents, etc. Most of the standards wrapped up by this zip file are standards made for, or predominantly made for, browsers. The line is blurry of course. Is HTML 5 a browser technology? No, it is a standard that could be implemented by anything. But lets face it…browsers came into existence to render HTML and kind of became the name for that sort of technology.

Add into the mix CSS, used to style webpages displayed in browsers, and JavaScript, used to program webpages through browsers – browsers became software capable of all kinds of things. At the same time some things became capable of working with these technologies. It is possible, for example, to manipulate HTML using tools that are not browsers. You can, for example, use programming languages for creating and interpreting HTML for all sorts of reasons (like file conversion) without the content ever seeing a browser in its lifetime.

However, when does a tool share so much functionality with a browser that you just call it a browser? When does a duck become a duck?

I believe that any technology that does all that EPUB requires it to do is a browser.

EPUB requires HTML, CSS, bitmap support, MathML support, vector graphic support, JavaScript, etc., etc., etc.

All of this stuff is just common browser stuff. If you need to read an EPUB and display it, the technology you are using is a browser. Its not an ‘ereader software’, or ‘ereader’, its a browser and let’s call it that.

If it has feathers and quacks, it’s a duck.

Why is this mild semantic re-orientation important? Well it’s important because the very foundation of the discussion about what EPUB should be is based on the assumption that EPUB is something of itself. That starts an entirely different discussion than just simply stating that browsers are the things that read EPUBs.

Case in point is an interesting statement from Bill McCoy from the IDPF (I have great respect for both Bill and the IDPF) that the addition of JavaScript to EPUB3 was a controversial decision (see comments here). Extremely interesting. If EPUB was discussed as being something to feed browsers content you would imagine that JavaScript would be the first on the list to be included. Why not? JavaScript is already there on a platter in browsers and in a very mature state – you would be foolish to ignore it and foolish not to include it as a supported content type.

I don’t mean to hold up this apparent controversy as anything other than an indicator of an interesting problem. We are pretending we are dealing with something special – EPUB – and weirdly this is limiting our understanding of what we are actually working with – browsers.

The future of the book is inherently linked to the browser. Discussion of EPUB as a technology somehow ‘separate’ from browsers is not helping us see that very rich and quite unbelievable future, one that is entirely different to what is in front of us now. If we see EPUB as something other than a subset browser functionality we are not seeing the present or the future clearly.

I’m not sure what is holding us back from this way of seeing things. It could be that we somehow consider the browser too mundane to be the future of the book. It could be that the browser is too scary as it gestures strongly in the direction of ‘the web’ and content out ‘in the wild’. It could be that all of this triggers challenges we don’t want to consider – challenges to current business models, the status value of the book, professional pride, roles, and infrastructure. Whatever it is, I am sure it’s there; legacy ideas that prevent us from understanding what is actually going on, from understanding that an EPUB is nothing special.

We could perhaps clarify this by calling EPUB a standard for ‘portable websites’ and stop talking about books altogether. It would be interesting to spend a lunch hour thinking about that simple statement and how it would affect what you do.

Collaboration on a book is the ultimate unnatural act.
—Tom Clancy

The emergence of online book production tools is of course bringing writers online. Authoring books online seems to bring two apparently opposing dynamics into play – the social web and the author. The production in the context of the increasingly noisy, social web seems at odds with the typical conception of solitary writer and the juxtaposition simultaneously brings into focus the potential for collaboration or ‘social production’ together with questions of authorship.

We must first recognise that 300 years of copyright and a long era of romantic authorship has left us with inadequate tools for engaging in the collaborative process. It is difficult to get beyond our deeply internalised ideas of book production; we find ourselves unwilling to leave behind the romantic notion of single authorship. Collaboration, on the other hand, has an army of derisionists in the wing like Tom Clancy, not to mention the academic and commercial publishing worlds that are invested in devaluing it. Can books really be produced collaboratively and what does the process offer? It is difficult for many of us to answer these basic questions whereas we feel we understand the value and the offer of sole authorship.

In order to ease into the question it is perhaps worth avoiding the word ‘author’ to describe the book production process. Instead of talking about the author, or even multiple authorship, lets forget the word all together and re-frame it in another way. I propose we instead think about strong and weak collaboration.

It is evident that the books you see in the stores in your town are not produced by one person alone. Let’s imagine that someone did in fact write the entire book and it was untouched by an editor’s hand – we can at least accept that the sole writer did not design the book or the cover or take the entire bundle to the printer to be produced. There may be some cases where this has happened, certainly in the self-publishing world this is not uncommon, but let’s talk specifically about the established publishing industry. That book by Tom Clancy had at least one person, and likely many more people, involved in the process (unless Tom is hiding his Desktop Publishing talents from us).

However, lets just limit our focus to possible collaborative relationships which affect the actual text. There is practically no book that goes through the publishing process entirely untouched. At some point someone made a modification, even if it only resulted in a small improvement. Did Tom do a thorough grammar check? Were there any proofreading or editorial comments made before printing?

This kind of textual interaction is minimal or weak collaboration. More than one hand was at play to make that exact text which appears in the book; this was a collaborative effort, albeit an extremely weak one.

Now let’s move up the collaboration scale a bit. A writer and an editor might interact a lot with the text as it is being produced. The editor offers suggestions for improvement, or edits the text directly. This could be characterised as having a stronger collaborative nature than the previous example.

Stronger still is a relationship of two or more writers working very closely together to produce a text. This is evident in any number of ‘single author’ classics like Frankenstein which is attributed to Mary Shelley but Percy Shelly clearly had a strong hand in some of the text. Another example is the Wasteland which has been discussed by many as a case in point where T.S Eliot collaborated closely with both Vivienne Elliot and Ezra Pound in its production.

Lastly, at the far end of the scale, we have intense collaboration where the delineation between ‘who wrote what’ disappears even to the collaborators themselves as they are producing the text.

As it happens most books feature not just collaboration but strong to intense collaboration between writer and editor.

If we allow ourselves to do away with the notion of authorship and instead characterise the interactions on a spectrum we can see that collaboration already plays an important role in a ‘typical’ process, and it has more value than we may have first thought. Book production is actually a collaborative process. The publishing world has hidden this from the reader largely because the legislative and market forces have favored the promotion of single authorship. But collaboration is a technique we use to produce and improve all books, and we should stop ignoring it. We need to bring collaborative production into focus and explore it.

The advantage of producing books online is that we have an enormous scope of collaborative activity available to us. Until now exploration of the possibilities has largely been limited because of our investment in myths of authorship but if we discard this notion we can explore the opportunities the web offers. The good thing about the net is that ‘the door’ can be regulated depending on the production needs. We may wish to fling the door wide and invite anyone to come in and work on a text, or we may shut the door completely and work in isolation. We may need to, for example, remain in a weak collaborative position for quite some time as we flesh out a work. Later, when we ask for feedback we move slightly up the scale, and later still when the first manuscript is in the hands of an editor we move up the scale to strong collaboration. The point is, we have the choice, and much more choice than we had before.

With thanks to Benjamin Mako Hill for asynchronous inspiration and collaboration on this text.

This post and all others by Adam Hyde are CC-BY-SA

TOC NY 2013— The publishing industry will gather at the Tools of Change for Publishing Conference in New York City, February 12-14, to explore the forces and solutions that are transforming publishing.Save 15% on registration with the code COMM15

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 softwares like AnnotateIt or typographical libraries like 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 are 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…

All posts by Adam Hyde are CC-BY-SA

TOC NY 2013— The publishing industry will gather at the Tools of Change for Publishing Conference in New York City, February 12-14, to explore the forces and solutions that are transforming publishing.Save 15% on registration with the code COMM15

MathML is the W3C-recommended standard markup for equations – its 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 (more on this in a later post) 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 webfonts) or as SVG. The mark up used can be either MathML, Asciimath or TeX. That means authors can write (ugly) mark up 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-past-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 ereader devices. However MathJax is being utilised in ereader 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 ereaders either through native MathML support or through 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 center 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.

All posts by Adam Hyde are CC-BY-SA

TOC NY 2013— The publishing industry will gather at the Tools of Change for Publishing Conference in New York City, February 12-14, to explore the forces and solutions that are transforming publishing.Save 15% on registration with the code COMM15

It is a great article which is almost a year old but still needs to be read by those that haven’t yet come across it. Apart from pointing to some very good Javascript typesetting libraries Joshua does a quick comparison of InDesign features vs. what is available in CSS and JS libs (at the time of writing).

It’s a very quick run down and shows just how close things are getting. In addition Joshua points to strategies for working with baselines using grids formulated by Javascript and CSS. Joshua focuses on Hugrid but also worth mentioning is the JMetronome library and BaselineCSS. These approaches are getting increasingly sophisticated and of course they are all Open Source.

It brings to our attention that rendering engines utilising HTML as a base file format are ready to cash in on some pretty interesting developments. However it also highlights how rendering engines that support only CSS (**such as the proprietary PrinceXML) are going to lose out in the medium and long term since they lack Javascript support. Javascript, as I mentioned before, is the lingua franca of typesetting. JS libs enable us to augment, improve, and innovate on top of what is available directly through the browser. Any typesetting engine without Javascript support is simply going to lose out in the long run. Any engine that ignores Javascript and is proprietary loses out doubly so since it is essentially existing on a technical island and cannot take advantage of the huge innovations happening in this field which are available to everyone else.

Once again, this points the way for the browser as typesetting engine; HTML as the base file format for web, print, and ebook production; and CSS and Javascript are the dynamic duo lingua franca of typesetting. All that means Open Source and Open Standards are gravitating further and faster towards the core of the print and publishing industries. If you didn’t think Open Source is a serious proposition it might be a good idea to call time-out, get some JS and CSS wizards in, have a heart-to-heart talk about the direction the industry is heading in.

** Correction: The latest release of PrinceXML has limited beta Javascript support. Thanks to Michael Day for pointing this out.

This and all posts by Adam Hyde are CC-BY-SA

TOC NY 2013— The publishing industry will gather at the Tools of Change for Publishing Conference in New York City, February 12-14, to explore the forces and solutions that are transforming publishing.Save 15% on registration with the code COMM15

‘Open API’ trades off the term ‘Open’ to imply some kind of transparency – which there is often not on either a technical or business level. Badly documented APIs with no guarantee of service is usually what you are dealing with. To rely on an ‘Open API’ is not to have transparency; it is to do business by relying on the kindness of strangers (as Blanche DuBois would say).

In other words, the ‘Web 2.0′ economy encourages us to utilise third-party services with no contractual agreements in place for these critical, and sometimes core, business processes.

This week there was a very interesting case in point. Lulu.com announced they will discontinue the support for their publishing API. In an email sent out early in the week clients were informed:

We’d like to thank you for your participation in the Lulu API Program and share an important update. Over the last two years, we have made significant investments into building our APIs and making them useful to third-party developers, however they have not achieved the adoption which we had anticipated and we will no longer be supporting APIs.

We will discontinue support of our existing APIs on January 15th, 2013.

The Lulu API was, by the way, a very good API and very well documented. However the above means that if you relied on the Lulu API for your business then bad luck, you better find another way to do it.

Lulu of course, is subject to its own business processes and they have obviously invested a lot in the development of an API for little return. Their approach has been very straightforward and they communicated to their clients well in advance that there is going to be a change in their API service. As far as things go, Lulu has done it pretty much by the book however my point is addressed to a wider concern: API providers should offer their clients a contract which guarantees the terms and conditions of technical services provided by their APIs. Without this businesses are not in a position (and should not be tempted) to confidently build innovative models that leverage the powerful possibilities that these APIs can offer.