• Print

InDesign vs. CSS

Any typesetting engine without Javascript support is going to lose

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 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
tags: , , , , , , , , ,
  • amarie000

    Looking for the “InDesign vs. CSS” content here, promised by the headline … 

    • http://blog.booki.cc adam hyde

      check out the post linked in the first para. 

  • bowerbird

    adam-

    please provide some info on how to contact you
    in a place other than this one.  thanks very much.

    -bowerbird

    • http://blog.booki.cc adam hyde

      at flossmanuals.net

  • http://www.princexml.com/ Michael Day

    We have already added JavaScript support to Prince XML, and now we are improving compatibility with browsers so you can use the same scripts and libraries when you need to print to PDF! :)

    • http://blog.booki.cc adam hyde

      thanks, will check and add as a a correction

      • http://blog.booki.cc adam hyde

        I see 8.1 has what appears to be limited beta support of JS, is that correct Michael? Could you provide information about how far JS is supported?

        • http://www.princexml.com/ Michael Day

          Yes that is correct, primarily to support structural transformations of the document beyond what CSS can do, such as generating indices or tables of contents.

          For the next release of Prince we are supporting the element, AJAX and typed array APIs, and many more DOM interfaces needed to support popular scripts like HighCharts, d3, MathJax, HighlightJS, and so on.

          Our goal is for Prince to be a powerful and extensible typesetting system that is compatible with browser scripting engines. We plan to be here for the long-term. :)

    • http://blog.booki.cc adam hyde

      i provided a correction Michael, thanks for the tip.

  • Bill McCoy

    I agree with you Adam. EPUB 3 being fully aligned with HTML5 and modern web standards inc. JavaScript was controversial but I’m very glad that we took this path. I don’t much like the word “typesetting” since it connotes a batch process whereas I see digital book rendering increasingly being a dynamic process at the point of consumption. That’s to me where JS will add the power in interactivity, not just as a replacement for CSS for making pretty pages. In fact for pretty pages I believe over time more powerful declarative mechanisms (like EPUB Adaptive Layout) will win even if in many cases their *implementations* in browsers as JS-based.

    We are still in a transition period but I see the non-JS-powered Reading Systems like Adobe RMSDK fading away in favor of browser-engine-powered Reading Systems. Apple iBooks, Kobo, VitalSource for example all have shipped EPUB 3 support based on WebKit’s engine. And, all support JS (although Apple’s implementation is slightly crippled at this point, disabling remote data access).

    That said there are of course non-trivial security issues to be addressed in considering JS contained within untrusted content moving across multiple distribution channels (which is entirely different than a trusted browser-engine-based Reading System partially or completely implemented in JS). The security concerns are a key reason that uploading HTML with JavaScript to online forums is not generally allowed. But these issues will be addressed, and the somewhat more structured nature of JS in EPUB 3 should help with this.  And, again, favoring declarative content representations over programmatic content where possible will help minimize security issues  (as well as help maximize content accessibility and remixability).

    • http://blog.booki.cc adam hyde

      Hi Bill, Great information, many thanks for commenting on the post. What you describe highlights for me the growing importance of the browser (specifically webkit) as a core technology for the publishing industry. The need for JS support in EPUB3 must surely play a role in pushing more reading devices into using webkit…I begin to wonder once again, and I know you found this contentious, why there isn’t more collective focus on webkits development from the publishing (and print) industry. If these businesses got behind the development of webkit with even a small amount of financial muscle things would shoot ahead for the industry as a whole

      MathML, for example, has limited support in Webkit which was the result of one developer doing this in their ‘hobby time’. MathML is also part of the EPUB3 spec, and equation support is obviously an important requirement for publishers. It would be a very good thing if the publishing industry got behind this development and put some money into it rather than sitting back and ‘waiting’. adam

  • http://twitter.com/DrJayVA Eric Jablow

    I thought the TeX family of software was the lingua franca of typesetting.

    • http://blog.booki.cc adam hyde

      I think it will eventually be overtaken by JS. As an interesting example see http://www.bramstein.com/projects/typeset/ which is a JS script that emulates/replicates the Tex line spacing algorithms

      TeX won’t disappear of course but its hard to argue it has the growth / uptake potential of JS.

    • OriIdan

      It seems that HTML and related technologies such as XML are more and more taking the place of TeX.
      After all, HTML is the basis of EPUB digital books format.

  • ldweeks

    One of the most interesting statements here is “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.”

    However, I’m confused by that statement. I don’t work in the industry, so perhaps the answer to my question is obvious to most here. But my understanding is that print publishers go from something like Indesign to PDF, and then print from the PDF. How, practically, can publishers use HTML as a base file format? I know there are tools for creating ebooks that way, but what about print? 

    It sounds awesome to be able to use HTML as the base file format for web, print and ebook production, but what tools are available that can do all three from HTML right now?