Coko Team Meet 2017, Kenya

Open API: The Blanche DuBois Economy

‘Open API’ is a well-known term that seldom gets challenged. It passes in conversation as an agreed-upon good. However, it should be recognised that there is no such thing as an Open API – the term is a euphemism for a specific kind of technical service offered with no contractual agreement to secure those services.

‘Open API’ trades off the term ‘open’ to imply some kind of transparency – which often is missing on both technical and business levels. Badly documented APIs with no guarantee of service are usually what you will be dealing with. To rely on an Open API is to  lack transparency – it is doing 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 are  discontinuing 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 was 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 contract, 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.

Originally posted on O’Reilly, 13 November 2012 http://toc.oreilly.com/2012/11/open-api-the-blanche-dubois-economy.html

Why Attribution is not Sustainable

It’s easy to understand the problems with attribution. In the one book = one author days, it was easy – put the author’s name on the cover. 50 years later, same book, same solution.

However, this does not work for collaboratively-produced works and it is one of the most difficult issues for free culture going forward. Already in FLOSS Manuals, we have books that have 8 pages of credits – each chapter individually referenced with the copyright and attribution data. Some books have 40-50 chapters and some chapters have 20+ collaborators, all of which need to be listed. For FLOSS Manuals, we solved the problem by generating these lists – when edits are done in Booktype, there is a digital record of who did what, so we just automatically generate this list. However, this is just the beginning and we are already asking ourselves – are 8 pages of credits really necessary?

The answer is no, it is not necessary. Attribution is not as important with collaboratively-produced works as one might have suspected. Those involved in the process are not too worried about it – there is some kind of excitement generated by pushing your name forward as a protagonist at some key moment in the life of a book but this can happen in the text, as part of the book’s story, or in press releases, blog posts and so on. We don’t actually need attribution – the prominent foregrounding of all the names of the individuals involved in the book’s production. What we need is backgrounding of this information and the ability to know the history and lineage of a book.

We need standards to maintain history records for a book’s development and we also need this to be stored in publicly- accessible repositories so we can check this information for interest’s sake or more meaningful uses such as historical records, or research.

These records of book history could be also very necessary for verification of content. If, for example, we use open licenses or (one day) no copyright then how do we verify quotes, for example? (In reality, provenance is orthogonal to copyright restrictions, and indeed such restrictions are an obstacle to maintaining provenance, but still. people often ask this question.)  How do I know that this book, which purports to be the thoughts of the author, actually does present the thoughts of the author and not some maliciously invented text masquerading as such ?

Currently, in free software circles, there are at least three major strategies for dealing with this kind of issue:

  • Use a publicly-trusted source for the distribution of content so people know that if the book comes from a trusted source it is what it says it is.
  • Use a ‘checksum’ – a method for verifying of any errors have been introduced in the text during the transmission (delivery) of the content.
  • Digitally-sign content so that it can be verified as coming from the purported source.
  • Libraries or public archives could play a very strong role here. Records of history would become very important in a federated or prolific free-content environment, not just for research but for providing public mechanisms and standards for the ongoing verification of sources.

Attribution is the star system of the single author = single book publishing system. With the breakdown of these models, or at least with the diversification of these models, author attribution will, out-of-necessity, become a more transient commodity. Collating version and contribution history, however, might become a business in itself.

Which is all to say that lowercase attribution (a useful bit of provenance info) is sustainable. By contrast, Attribution to Authors as creator-gods is suspect and superfluous.

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

 

book.js

I mentioned in an earlier post that the movable type of Gutenberg’s time has become realtime, 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. Since ebooks are web pages, browsers have come to play a central role in digital e-readers.
bookjs
Three books produced by the book.js in-browser typesetting library. Photo by Kristin Tretheway.
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 on its way to becoming the typesetting engine for print. book.js demonstrates nicely the role of the browser as print typesetting engine.book.js is a JavaScript library that you can use to turn a web page into a PDF formatted for printing as a book. Take a web page, add the Javascript, and you will see the page transformed into a paginated book complete with page breaks, margins, page numbers, table of contents, front matter, headers and so on. When you print that page, you have a book-formatted PDF ready to print. It’s that simple.
1_plainhtml3
Plain HTML file with book content
2_bookjs
Same file with book.js applied
3_illustration
A page with an illustration
4_toc
Illustration of Table of Contents automatically generated by book.js

It brings us closer to in-browser print design and a step closer to the demise of desktop publishing. Although book.js is in an alpha form, it is a clear demonstration that the browser is fast becoming the new environment for print design.

That is an enormous leap, one that not only means print design environments can be developed using browser-based technology, which will surely lead to enormous innovation, but it radically changes the process of design. The design of books and paper products enters a networked environment. This will enable more possibilities for collaborative design and bring print production into the workflow of online content production. There will be no need to exit browser-based environments to take content from source to final output. This means there is no need to juggle multiple sources for different stages of production, there can be efficiency gains through integrated workflow, and, most interestingly, content production and design can occur simultaneously…

It is also important to realise that these same technologies, book.js and others that will follow it, can make the same things possible for ebook production. Flowing text into PDF for a paper book, or into e-reader screen display dimensions, is the same thing. This enables synchronous in-browser design and production on a single source for multiple output formats.

book.js is Open Source, developed originally by and for Booktype, but the team is looking to collaborate with whoever would like to push this code base further. It is at the alpha stage and a lot of work still needs to be done, so please consider jumping in, improving the code and contributing back into the public repository.

book.js demo and information can be found here .  Note: This is strictly for the geeks to try as it requires the latest version of Chrome; see the demo information.

Originally posted on O’Reilly, 29 October 2012
http://toc.oreilly.com/2012/10/bookjs-turns-your-browser-into-a-print-typesetting-engine.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