InDesign vs. CSS

The explosion in web typesetting has been largely unnoticed by everyone except the typography geeks. One of the first posts that raised my awareness of this phenomenon was From Print to Web: Creating Print-Quality Typography in the Browser by Joshua Gross. It is a great article which is almost a year old yet still needs to be read by those that haven’t 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/or 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 as 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, and 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.

Originally published on O’Reilly, 19 Nov 2012 http://toc.oreilly.com/2012/11/indesign-vs-css.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