• Print

Gutenberg Regions

The new typesetting engine blueprint is right here in front of us

The “best price” phase of TOC NY 2013 registration is about to end. Don’t wait or you’ll end up paying more than you would today. To save even more on your registration, sign up here and use the discount code JOE20 to get an additional 20% off the current price on the conference package of your choice.

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.

tags: , , , , , , , ,

Comments: 3

  1. Adam I agree with your high-level vision. But I’m not sure about your call to action. 

    W3C and IDPF are both consortia and the W3C and WebKit work on submissions on CSS regions, exclusions, and page-generate content are in fact a subset of a more comprehensive Adobe proposal that evolved into the IDPF EPUB Adaptive Layout specification ( http://idpf.org/epub/pgt/csspgt-20120808.html ). Both W3C and IDPF facilitate open source development projects as well as developing specifications. IDPF is sponsoring four active OSS projects: Readium implementation of EPUB 3, EPUBCheck content validator, EPUB 3 Samples repository, and a new project to develop an EPUB reading system conformance test suite. Work in Readium is leading to improvements in WebKit and ultimately I believe that browsers will directly support EPUB as the publication packaging of the Open Web Platform. W3C, with IDPF & BISG, are holding a workshop on the big picture in Feb. ( http://www.w3.org/2012/08/electronic-books/ ).

    I agree we need to take this to the next level, that we can’t let this get stuck in CSS WG paralysis, nor let Adobe solely control what happens (it’s no coincidence that what Adobe submitted to W3C is substantially less capable than their proposal to IDPF – which they had in the meantime decided to bolt on to their proprietary DPS solution as a “Liquid Layout” feature). But I don’t see that more consortia are needed, rather I think we need more help to push harder on the open source and open standards work already in progress and help pull organizations like Adobe towards the Open Web Platform (for websites, apps, and eBooks).

    • Hey Bill. Many thanks for your comment, I actually wanted to introduce myself at Books in Browsers but didn’t have the time. I agree with your points but I think you might have misunderstood me a little – the consortium I suggest would be to work on implementation of standards – specifically the implementation of CSS support for features the print and publishing industry needs from webkit. 

  2. those blueprints are badly flawed, because they are
    too complex, the kind of thing that only a bureaucracy
    — like adobe — would create.  use a simpler blueprint,
    or be hopelessly hindered by unnecessary complexity.


Leave a Reply

Your email address will not be published. Required fields are marked *