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 effected 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 print. With 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 BookJS 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 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 OR’eillys Tools of Change site: http://toc.oreilly.com/2012/11/gutenberg-regions.html

Posted in Uncategorized | Leave a reply
Posted on July 22, 2013
2
WYSI

Since 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 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, the recent fork of Aloha called ‘WYSIWHAT‘, TinyMCE, and CKEditor.

Each of these are treading their own path but things are really opening up. As an example and with reference a 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…

Originally posted on Dec 3, 2012 on OR’eillys Tools of Change site: http://toc.oreilly.com/2012/12/wysiwyg-vs-wysi.html