publish.js

A list of some interesting Open Source Javascripts (mostly JS) that hold good possibilities for knowledge production and publishing.

Content Production

Lens
License: FreeBSD
Code: https://github.com/elifesciences/lens
WWW: http://lens.elifesciences.org/about/

Tangle
License: MIT
Code: https://github.com/worrydream/Tangle
WWW: http://worrydream.com/Tangle/

Flatsheet
License: MIT
Code: https://github.com/flatsheet/flatsheet
WWW: http://flatsheet.io/

Realtime Markdown Editor
License: TBD (emailed dev)
Code: https://github.com/scotch-io/node-realtime-markdown-viewer
WWW: https://scotch.io/tutorials/building-a-real-time-markdown-viewer(tutorial)
Demo: http://realtimemarkdown.herokuapp.com/

PlumbJS
License: MIT & GPL
Code: https://github.com/sporritt/jsplumb/
WWW: http://jsplumbtoolkit.com/

Ice
License: GPL 2
Code: https://github.com/NYTimes/ice
WWW: http://nytimes.github.io/ice/demo/

Annotator
License: MIT & GPL v3
Code: https://github.com/openannotation/annotator/
WWW: http://annotatorjs.org/

Space.js
License: MIT
Code: https://github.com/gopatrik/space.js
WWW: http://www.slashie.org/space.js/

MathJax
License: Apache
Code: https://github.com/mathjax/MathJax
WWW: https://www.mathjax.org/

KaTeX
License: MIT
Code: https://github.com/Khan/KaTeX
WWW: http://khan.github.io/KaTeX/

Velocity.js
License: MIT
Code: https://github.com/julianshapiro/velocity
WWW: http://julian.com/research/velocity/

JuxtaposeJS
License: Mozilla
Code: https://github.com/NUKnightLab/juxtapose
WWW: https://juxtapose.knightlab.com/

TimelineJS3
License: Mozilla
Code: https://github.com/NUKnightLab/TimelineJS
WWW: http://timeline.knightlab.com/

StoryMap
License: Mozilla
Code: https://github.com/NUKnightLab/StoryMapJS
WWW: https://storymap.knightlab.com/

Chartbuilder
License: MIT
Code: https://github.com/NUKnightLab/Chartbuilder
WWW: http://quartz.github.io/Chartbuilder/

Soundcite
License: Mozilla
Code: https://github.com/NUKnightLab/soundcite
WWW: http://soundcite.knightlab.com/

Pagination

BookJS
License: AGPL
Code: https://github.com/booktype/BookJS
Web: none

Cassius
License: AGPL
Code: https://github.com/MartinPaulEve/CaSSius
Web: https://www.martineve.com/2015/07/24/getting-started-typesetting-with-cassius/

Vivliostyle
License: Apache
Code: https://github.com/vivliostyle
Web: http://vivliostyle.com/

BookJS Polyfil
License: AGPL
Code: https://github.com/BookSprints/bookjs-polyfill
Web: none

Typography

Hyphenation

Sweet Justice
License: BSD
Code: https://github.com/aristus/sweet-justice
WWW: http://carlos.bueno.org/2010/04/sweet-justice.html

Hyphenator
License: LGPL
Code: https://code.google.com/p/hyphenator/downloads/list
WWW: https://code.google.com/p/hyphenator/

Hypher
License: BSD
Code: https://github.com/bramstein/hypher
WWW: http://www.bramstein.com/projects/hypher/

Font Resizing

FlowType.js
License: MIT
Code: http://github.com/simplefocus/FlowType.JS
WWW: http://simplefocus.com/flowtype/

Squishy
License: unspecified (argh! please include a license file!)
Code: https://github.com/lemonmade/squishy
WWW: http://cmsauve.com/projects/squishy/

Fittext
License: WTFPL
Code: https://github.com/davatron5000/FitText.js
WWW: http://fittextjs.com/

SlabText
License: MIT
Code: https://github.com/freqDec/slabText/
WWW: http://freqdec.github.io/slabText/

Responsive Text
License: MIT
Code: https://github.com/ghepting/jquery-responsive-text
WWW: n/a

Line Spacing

Typeset
License: unspecified (argh… )
Code: https://github.com/bramstein/typeset
WWW: http://www.bramstein.com/projects/typeset/

Kerning

Kern.js
License: WTFPL
Code: https://github.com/bstro/kern.js
WWW: http://www.kernjs.com/

Kerning.js
License: MIT (license file is in the wrong place – check the README)
Code: https://github.com/endtwist/kerning.js
WWW: http://kerningjs.com/

TypeButter
License: CC-BY-SA 3.0
Code: https://github.com/hudsonfoo/typebutter
WWW: http://typebutter.com/

Drop Caps

DropCap.js
License: confused (All rights reserved and apache??)
Code: https://github.com/adobe-webplatform/dropcap.js
WWW: http://blogs.adobe.com/webplatform/2014/10/02/drop-caps-are-beautiful/

Color

Color Font
Licence: WTFPL
Code: http://manufacturaindependente.com/colorfont/media/js/colorfont.js
WWW: http://manufacturaindependente.com/colorfont/

Font Tricks

Lettering JS
License: WTFPL
Code: https://github.com/davatron5000/Lettering.js
WWW: http://letteringjs.com/

jqisotext
License: MIT & GPL
Code: https://code.google.com/p/jqisotext/downloads/list
WWW: http://workshop.rs/2010/01/jqisotext-jquery-text-effect-plugin/

Arctext.js
License: MIT
Code: http://tympanus.net/Development/Arctext/Arctext.zip
WWW: http://tympanus.net/codrops/2012/01/24/arctext-js-curving-text-with-css3-and-jquery/

Blast.js
License: MIT
Code: https://github.com/julianshapiro/blast
WWW: http://julian.com/research/blast/

Base Lines

Baseline.js
License: WTFPL
Code: https://github.com/daneden/Baseline.js
WWW: n/a

Baseline CSS
License: CC-BY-SA 3.0
Code: http://baselinecss.com/download/baseline.zip
WWW: http://baselinecss.com/

HUGrid
License: GPL
Code: http://bohemianalps.com/tools/grid/HeadsUpGrid_download.zip
WWW: http://bohemianalps.com/tools/grid/

CSS Stuff

Tufte CSS
License: MIT
Code: https://github.com/daveliepmann/tufte-css
WWW: http://www.daveliepmann.com/tufte-css/

Other Resources
This and That

https://github.com/yumyo/js-type-master
http://stateofwebtype.com/
http://nytlabs.com/projects/editor.html
https://www.youtube.com/watch?v=VbCqFQ1sTYQ
http://dat-data.com/
https://github.com/sharelatex/clsi-sharelatex
https://anmolkoul.wordpress.com/2015/06/05/interactive-data-visualization-using-d3-js-dc-js-nodejs-and-mongodb/
http://webapplayers.com/inspiniaadmin-v2.2/cssanimation.html
http://yusugomori.com/projects/css-sans/fonts
http://codepen.io/juliangarnier/pen/idhuG
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
https://github.com/WebComponents/webcomponentsjs

Some Good Reading

https://medium.com/@mql/self-host-a-scientific-journal-with-elife-lens-f420afb678aa
https://medium.com/@
mql/centralised-vs-decentralised-publishing-626055376c81
http://book.pressbooks.com/

Platforms

Booktype
License: AGPL
Code: https://github.com/sourcefabric/Booktype
WWW: https://www.sourcefabric.org/en/booktype/

PressBooks
License: not specified 🙁 emailed org
Code: https://github.com/pressbooks/pressbooks
WWW: http://pressbooks.com/

PubSweet
License: Apache
Code: https://github.com/BookSprints/PubSweet
WWW: none

More coming…

WYSIWYG vs WYSI

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 software such as AnnotateIt or typographical libraries such as 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 and the recent fork of Aloha called ‘WYSIWHAT‘.

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


Published on O’Reilly, 3 December 2012 http://toc.oreilly.com/2012/12/wysiwyg-vs-wysi.html

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

 

CSS is the new typography

The new layout language for the book is HTML. It has never been easier to make web content using HTML, hence it has never been easier to make a book.

Generally speaking, HTML is frowned upon as a source file format for books because it is seen as worst practice. Best practices require complicated file formats like “docbook” or, worse, Latex. These file formats have been designed to contain and describe content so that beautiful books can be made. Unfortunately, the process of creating docbook and Latex is extremely complicated. Getting a new user to work with either of these formats is quite a process. On the other hand, WYSWYG editors which produce HTML work very much like simple text editors. It is trivial to create HTML with a WYSIWYG editor or similar tool and it can be done online.

HTML is a very established, very well used, and very well distributed format. There are already an enormous number of people using HTML, and an enormous amount of content already stored in HTML. That content and those people are networked, and HTML has a rich legacy of tools that enable transformations into other formats. HTML is the new source format for books.

CSS (Cascading Style Sheets) is the syntax that controls the look and feel of HTML. E-readers and web-browsers can read this syntax and present the content accordingly. Book production platforms such as Booktype enable the customisation of CSS for ebook output, but, more interestingly Booktype also enables CSS to control the look and feel of paper books. Designing in this way takes some thought since it is usually disorientating for book designers to ‘design in code’ and it is equally disorientating for web designers to use code to design material products.

The W3C CSS Working Group1 (responsible for overseeing the standard) anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standard, new additions are almost entirely focused on typography2 . As a consequence of this emphasis, this area is starting to blossom. There has also recently been a sharp rise in the websites offering tips on CSS typography3 and an explosion of web fonts. (If you are interested in a very good insight about how fonts get to the web please watch the Unbound Book video presentation by Otmar Hoefer, the Director of Font Marketing at Linotype Library4 ).

There are also some very interesting JavaScript libraries available that are trying to make up for what is lacking in CSS typographical controls. Most are based on the well-used and prolifically distributed JQuery JavaScript libraries.

Of particular interest is the kerning.js library which combines the previously available lettering.js library. What these libraries do is to make each glyph (letter/number) into its own element, each of which can then be transformed by CSS-like rules. In plain speak, these code libraries allow you to change each letter individually in a paragraph or heading etc.

There are some nice demonstrations online about why this is interesting, of which the most interesting demo can be found at kern.js. Try visiting that page, double click the big blue circle, then click on and drag the letters individually.

If you then click ‘Finish Editing,’ you will get the CSS controls necessary to implement this effect (if you had kerning.js linked from your page).

There is also another interesting typographical library called colorfont which enables dual toned glyphs.

It is a pretty good trick they used to achieve this. Essentially they created two fonts from the same master font, each displaying just partial glyphs. When overlayed, they display the full glyph. Hence each ‘layer’ can be targeted with a different color.

With libraries like this, it is apparent that JavaScript has a future with web typography but maybe it doesn’t stop at that. These kind of tricks can also be implemented with ebooks and with more and more book designers entering the world of ebook design, I am sure we will see a growing need for more of these libraries.

Good nuanced control over font rendering is good enough at the moment and getting better quickly. However, many e-readers and all web-browsers do not support all of the CSS controls and most ebook readers do not currently support JavaScript. This will change in time, especially since ebooks are becoming a revenue stream for Apple, and Apple (together with Google) is behind the development of webkit – the rendering engine behind iBooks, Safari and Chrome. Good support of CSS typographical controls is on its way and we can expect more web designers to start designing books, and to see more book designers learning code.

What is dismaying, however, is the current trend of vendors like Apple to use non-standard CSS controls to layout the books. Baldur Bjarnasons has written some very good blog posts about this. The strategy by Apple is to make any book authored by the iBook Author software only work (or work well) when viewed with the iPad. I do not really understand this strategy – yes it is the typical platform / sales channel lock-in that Apple is known to perpetuate. However, it means that content creator content has limited distribution because of this. Apple might wave this away by saying that it is ‘innovating,’ but innovation like this cannot be seen without a degree of skepticism about the intended goals.

Nevertheless, it is possible to say with some confidence that CSS and JavaScript will come to be seen as an important development in the history of typography. Just as Gutenberg “was concerned only to imitate the book of his day – which was handwritten”5 but unintentionally gave birth to new aesthetics, we can imagine the new CSS typography to have similar consequences.

  1. http://www.w3.org/Style/CSS/members.en.php3^
  2. http://dev.w3.org/csswg/css3-text/^
  3. http://www.1stwebdesigner.com/css/advanced-css-text-effects-web-typography-tips/^
  4. http://vimeo.com/24415178^
  5. Jan Tschichold, The New Typography, University of California Press, 2006, pg 15^