Some time ago I employed Julie Blanc from my Shuttleworth Fellowship to work for the PagedMedia project. Julie has been doing amazing work and just today released this incredible article about Page Floats:
With a running demo app: http://demos.pagedmedia.org/page-floats/
Really amazing stuff. Please share it widely!
(Julies demo code is here – https://gitlab.pagedmedia.org/JulieBlanc/demo-page-floats)
PagedMedia.org is launching a new community-led development at MIT Press on January 9, 2018. The project will develop a suite of Javascripts to paginate HTML/CSS in the browser, and to apply PagedMedia controls to paginated content for the purposes of exporting print-ready or display- friendly, PDFs from the browser.
This will be an Open Source initiative, appropriately licensed with the MIT license.
The January meeting will be the first meeting of the project and attending will be:
For further information please contact: adam@coko.foundation
PagedMedia.org is funded by the Shuttleworth Foundation.
Also posted here – https://www.pagedmedia.org/paged-media-open-source-initiative/
The page is changing in so many ways – time-based media is making its way into book pages, reactive content, scrollable space, and a multitude of differing display devices make designing pages pretty hard work these days. How to design for so many possibilities? How to understand so many possibilities?
Craig Mod of flipboard makes a very compelling argument for two forms of page : formless and definite content in an article he wrote for Book: A Futurists Manifesto – the first book to be produced by PressBooks. Craig’s argument, in a nutshell and in his own words is:
the key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries; Definite Content is not only aware of the page, but embraces it. It edits, shifts, and resizes itself to fit the page [...] Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas.
Craig argues that most book content we know is formless – the text can reflow into other containers without affecting the meaning. This position is in tension to the thinking of most book designers today. Designers of paper books design contained space and desktop publishing applications are built to manage pixel-perfect manipulation within a strictly defined and known container. If the finished digital article does not exactly co-relate to the printed artefact then something went wrong; it is assumed that either the designer, or the tool, has done a bad job.
Those familiar with this kind of process are uneasy with designing formless content – how can you design a page when you do not know its container? It is literally like asking a book designer to design a book without telling them the page dimensions. Web designers, on the other hand, have been thinking about page design too, and they have for a long time, at least in part, been designing for formless content.
The design of formless content is really a partially-formless, partially-constrained design process since elements within the page have some kind of relationship to each other, and they can have relationships to characteristics of a page, such as top or top left, for example. These relationships are defined by rules, the same rules I have discussed previously – CSS aka Cascading Style Sheets. Relationships can be articulated with CSS which will be preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements and page features more than by their relationship to the the exact x,y position of a page with a specific dimension, although strict placement is possible. This is the job of Cascading Style Sheets – the design language of the web. It is rule-based design with some conditional arguments and it is the method for designing electronic books; it will become, increasingly, the technology for describing the layout and design of paper-based print.
All of this can be manipulated in the browser. In fact, the browser is the best place to design flowable text since it is the flowable type environment of our time and, as mentioned before, the browser (Webkit) is the background technology for many e-readers. We have not yet seen the development of very good flowable design environments in the browser, but that is changing. The closest we have seen so far are the ‘in-browser’ design environments that some internet service providers make available for their customers to ‘design their own website online!’ While actually quite powerful, these environments are generally horrible to use, but this practice is applicable to the design of ebooks.
The desktop publishing world is not taking this lying down, and Adobe, in particular, has been pursuing what they call “Adaptive Design Tools” for the production of ‘liquid content’. Liquid content is flowable content, content that can rescale and position itself to fit the container. Adobe’s tools are intended for content targeted for mobile devices and tablets, although they also identify a role for it in print production. Adobe’s yet-to-be-released Adobe Edge is the product targeted at this flowable design process and their background technology for this design environment is – Webkit, the same browser mentioned earlier. Webkit is the ‘design surface’ for the new generation of desktop design tools coming from established publishing technology providers.
Coming back to the paper book. Until recently it has been extremely difficult to generate a PDF that exactly co-relates to what you see in a browser. Until now the browser accessed the PDF-creation features of the operating system. Hence a PDF from the same browser would look different if that browser were running in Windows, Mac or Linux. Just recently this has changed and the browser itself is now making the PDF. Chrome has been pioneering this ‘Native PDF’ output from the browser and the output looks exactly as you see it in the browser. One to one co-relation of content in the browser to the content in the PDF is a breaking point which points the way to designing your paper book in a browser. We are getting to the point where you can use a browser just as you would a desktop publishing application to design paper books.
The browser can now play every part of the book production process except the actual printing (although from the browser you can upload PDF to print-on-demand services such as Lulu.com).
What this means is that you can write a book in the browser, while at the same time it is being proofed and edited, and designed. Each part of this formerly-linear production cycle can now become synchronous. You can now write, edit, proof, design the book ‘in the book’.
The engine for reflowing a page in real time is something we have seen before. It is the job of the browser. And, since ebooks are webpages, browsers have come to play a central role in digital e-readers. In the case of the iPad, the iBook reader is actually a fully featured browser engine, Webkit, the very same technology behind the Chrome and Safari browsers. Browsers are the typesetting machines for ebooks.
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 becoming the typesetting engine for print. CSS and Javascript are the print design tools of our immediate future and the vast majority of innovations in this area are based on Open Source and Open Standards.
CSS is the set of rules followed by the browser in placing type, images and other elements on a webpage and styling those elements. Typical rules define where an image is placed in relationship to text, the font used, the font size, background colour of the page, and the maximum width of an image, and so on. While designed originally for the exclusive application to webpages, the CSS Working Group responsible for overseeing the development and direction of CSS, anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standards, new additions are almost entirely focused on typography and page control. As a consequence, this area is starting to blossom. In particular, the CSS Generated Content for Paged Media Module specification is astonishing for its reframing of flowable text into a fixed page. Cross reference and footnote controls, not needed on the web, are among many book-like structure controls being addressed by CSS. Table of contents creation, figure annotations, page references, page numbers, margin controls, page size, and more, are all included. The definition of these rules precedes their adoption in browsers, however they are being included in browser engines, notably Webkit, at a very fast pace.
Coincidently, there has recently been an explosion in interest in improving browser typography primarily for the better design of websites. Although these advances have not been made with book production in mind, these advances can be inherited by the browser for typesetting both electronic and paper books. Of interest is the sharp rise in the websites offering tips on CSS typography, an associated explosion of the available web fonts, and some very interesting JavaScript libraries.
JavaScript is the programming language of the web and it can be used to create dynamic content or manipulate objects on a webpage in ways CSS cannot, or cannot yet. Of particular interest is kerning.js, inspired by the previously available lettering.js library. These code libraries allow you to change each letter individually in a paragraph or heading and control the spacing between letters (called ‘kerning’). Kerning is essential for printed books, and ebooks, but missing from browsers for a very long time. colorfont.js is another JavaScript library which enables dual toned glyphs, and the amazing typeset.js emulates the sophisticated TeX line spacing algorithms developed by Donald Knuth.
Even the layout of musical notation and guitar tablature (which were never effectively mechanised with Gutenberg’s moveable type and were handwritten into books for many decades after the printing press came into the world) have come into focus with another JavaScript library, VexFlow. With libraries like these, it is apparent that JavaScript, the programming language of the browser, has a future with typography, and that JavaScript is fast becoming the lingua franca for all typesetting.
There is a lot of fuel in these developments and, interestingly, most of it is coming from outside the traditional print and publishing industry. It could be said that these industries, built upon the printing press, have lost sight of their very foundation. Instead, the IT industry is taking hold on a very deep level.
Apple and Google are behind the development of Webkit – the rendering engine behind iBooks, Safari and Chrome – which makes a lot of these typesetting innovations possible. Apple utilises these typographical features not just in its browser, but in the development of its iBook reader – the ebook reader on iPad which is itself based on Webkit. Google also fuels these innovations for many reasons other than the browser – better typography in Google Docs being one of them. We can expect the momentum to build and it is possible to say with some confidence that the browser, together with CSS and JavaScript, is to become the most important typesetting engine of our time as it is fast becoming the typesetting mechanism for digital and paper books and the web.
The implications of this succession by the browser are enormous and possibly not yet fully realised. At publishing industry conferences and other book-focused forums, the attention has largely been on the ebook’s affect on distribution, and on e-readers and the demise of the so-called bricks-and-mortar book stores. The biggest effects, however, are elsewhere, ‘bubbling under’ in the recasting of the browser as a typesetting engine, and with it the slow realisation that the technical ecosystem surrounding book production can be replaced by tools for producing webpages.
We are beginning to turn our attention to the tools for making webpages, to make books, and this, it turns out, is much easier than with desktop word processing and publishing software. Additionally due to recent developments, all of this, as it turns out, can also be used to design print (more on in-browser print production in a future post). Book production once again is becoming faster and cheaper and is on its way to achieving another leap of magical efficiency.
The future of book production right now is exploding all around us. These pieces of the puzzle are coming together and coming together fast. We can almost watch in real time as the necessary mechanics get filled in by new release candidates of major browsers and searching online for ‘out of the blue’ small innovations such as JavaScript typography controls. It is getting easier and easier to make books in the browser and consequently there has never been a time when it has been this easy to make books of all kinds.
Ease of production is where it all started for Gutenberg and it is starting again for us. If you believe Gutenberg’s efficiencies changed society forever, then what affect will the new-new typesetting engines have? It’s a giddy question. Making books in the browser will have an enormous impact on society as a whole, and just like the printing press, it will not revolutionise the old order, but create a new one.
Originally published on O’Reilly website, 18 Oct 2012 http://toc.oreilly.com/2012/10/the-new-new-typography.html
The current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Using a WYSIWYG editor is pokey and horrible. Producing text this way feels like trying to write a letter while it’s still in the envelope. These kinds of editors are not an extension of yourself, they are cumbersome hindrances 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 the rendering of HTML. However, 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.
The new generation of HTML5 editors have taken a large step forward, not because they integrate HTML5, as such, but because they act on the elements in the page directly. 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, we can have the same content represented as a multi-column editing environment (useful for newspaper layout), as a ‘google docs type’ clean editing interface (see demo below), a semantic layout 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 Annotate It or typographical libraries such as lettering.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 applying them dynamically using the editor. This is in effect turns the editor into a design interface, which will open the path for in-browser design of various media.
Lastly, WYSIWYG editors, while marvellous in their day, have had their day. They feel too pokey and ‘old school’. Largely due to the success of Google Docs users no longer want to poke around in a tiny WYSIWYG editor. They want large clean interfaces for content production.
The above screen shot is taken from the semi-functional demo at http://data.flossmanuals.net/mercury/index.html (all demos work only in Chrome for now).
In brief summary, essential problems of the current WYSIWYG world are:
Online book production has special needs such as the ability to display the content as it might appear in the output, annotations, draft view etc.
A short list of starting list of features for a new editor might look something like this:
Many of these features are relatively easy to achieve, others will take some careful thought and planning.
We need to develop with an editor in the hand. The current batch of html editors does pretty well but we need to choose one which has a good support community and a good feature set. Currently, there is just one option – Mercury editor. It currently has a new home page (less than 2 weeks old), and a thriving community.
Some demos if what could be done with Mercury in a book production environment:
http://data.flossmanuals.net/mercury/index_semantics.html
http://data.flossmanuals.net/mercury/index.html
http://data.flossmanuals.net/mercury/index_hyphen.html
http://data.flossmanuals.net/mercury/index_prettify.html
If anyone would like to work on this, please contact me adam@booki.cc
If you want some more convincing, try this math editor using Mercury and MathJax… http://data.flossmanuals.net/mercury/index_math.html
Try typing $f(x)$ into the window to see how it works
Or try this to see how AnnotateIt works in this environment.
There is a lot of interesting stuff happening to the page right now. The page is changing in so many ways – time-based media is making its way into book pages, reactive content, scrollable space, and a multitude of differing display devices make designing pages pretty hard work these days. How to design for so many possibilities? How to understand so many possibilities?
Craig Mod of flipboard makes a very compelling argument for two forms of page in an article he wrote for Book: A Futurist’s Manifesto : formless content and definite content. (This was the first book to be produced by PressBooks.)
Craig’s argument in a nutshell and in his own words is:
The key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries; Definite Content is not only aware of the page, but embraces it. It edits, shifts, and resizes itself to fit the page [...] Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas.
Craig argues that most book content we know is formless – the text can reflow into other containers without affecting the meaning. It’s a really well-argued position and one that is in tension to the current design methodologies of book designers today. Book designers are taught to design contained space – books are a very definite context in which they work. Desktop publishing applications are built to meet this methodology and are designed to enable pixel-perfect manipulation within a strictly contained space. If the designed digital article does not exactly match the printed artifact then something went wrong. A lot of energy has gone into this process.
Formless design principles are uneasy to consider for traditional book designers – how can you design for a page that does not yet know its container? It is literally like asking a book designer to design a book without telling them the page dimensions.
As it happens, web designers have been thinking about page design too. For a long time now web designers have made pages that embrace differing containers – they have been working, at least in part, with formless content.
What is missing, however, are good tools for taking the web designer’s aptitude for working with formless content to enable them to produce books. A good tool set for designing formless books should not work with constrained page dimensions. It is tempting, for example, to think of working with a design environment with constrained page-like artifacts – think of Google Docs as an example. Could something like Google Docs with its digital, scrollable, yet fixed page size be a good starting point for some kind of design tool? Place layout and typographical controls on top of Google Docs and do we have the next book design environment?
I don’t think so, because it is exactly the kind of idea that is blinded by the media of the past and cannot accept that things have changed. We must design tools that enable book design for formless content. What those tools look like is a very interesting question and one which Aleksandar Erkalovic (Booktype lead dev) and I have been working on with students (Hannes Bernard and Aiwen Yin) from the Sandberg Institute in Amsterdam.
Our argument is that the design of formless content is really a partially constrained environment, since elements within the page have some kind of relationship to each other. This is an argument web designers are familiar with when using design tools like position:relative – a rule which sets a relative position relationships between objects. Relationships can be constrained or shaped by rules which will be at least partially preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements, more than by their relationship to the constraints of a page.
This is the reasoning behind Cascading Style Sheets – the design language of the web. It is rule-based design and even partly conditional. It is possible to express conditions in CSS even though it is not done that often. A CSS rule such as :
h2+p {page-break-inside:avoid;}
is a conditional CSS rule which will apply the style only when a paragraph follows heading 2 (h2) element.
Web designers know this kind of thinking, but book designers are going to have to let go of pixel-perfect design and enjoy thinking and designing this way. It seems like a simple idea but it takes a lot to overcome legacy. The legacy is so strong that designers are pretending the issue does not exist. There are tools now appearing and sold as design environments for iPad books. They give near 1:1 page relationship between the design environment and the final result. However, we all know what happens to digital hardware – it changes. What is true now will not be true 5 years from now, so the idea that an ebook is a contained space is very appealing to traditional book designers but it will be a short-lived myth. iPads might keep the same form for 5 years, they might not but they certainly will not keep it over the next 5-10 years. Better to learn how to design in the new way than be fooled into thinking you can bring all the old methods to a new medium and get away with it for long.
What we are working on now, is a way to meet the designers half way – a visual design environment which is used for rule and condition based design. Can book designers accept a tool like like this? Will web designers just step in and take the role of book designers? Its an interesting question and one we hope to have some more experience with soon.
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.
Book creation is usually managed in multiple environments – the simplest toolchain consists of the writing and editing environment – usually a word processor – and the design environment – usually desktop publishing software such as Scribus or InDesign. The transition is time-consuming and ‘clunky’ and made worse if multiple text sources are to be combined in the design processes.
Additionally, this process means there are two sources for the text. Changes made to the text once the source is in the design environment usually have to be copied also into the word processing files if the integrity of that source is to be maintained, and vice versa.
It would be simpler if there was one environment that could be used for creating and editing AND for design. That is what we have created with Booki.
Booki enables content creation through a web interface. Chapters can be easily moved around and content can be easily modified through a very simple WYSIWYG interface. The design environment is also Booki and is web based, and we have developed a technology for creating book-formatted PDF using CSS.
The interface is simple to use – in the ‘export’ tab of any book you can paste CSS into the text field provided in the ‘Advanced Options’ press ‘export’ and a very short time later you have the book-formatted PDF complete with Table of Contents, numbering, headers, and margin control.
While the interface is easy to use, the tool does not ‘by itself’ create a good looking book. The secret to a good looking book is a well-defined stylesheet and time spent manually tweaking some ‘content’ elements in the WYSIWYG editor (paragraph breaks, placement of images).
To understand the relationship between CSS and the final result, there is no substitute for trial and error. Designers must first understand how a ‘web native’ technology – CSS – applies to page-based media (books). This paradigm appears simple but it requires a slight re-alignment of how book designers think about designing books, and to do this, designers must try the process and persevere until they succeed. After that initial success, things become easier.
Probably the best way to start is to take an existing book and look at the CSS, then change it and see what happens. Generating a PDF takes anywhere from half a minute to a few minutes, so this is a pretty quick method for seeing how CSS affects the layout of the book. For experimenting, first, create an account in Booki and then visit this page. On this page, go to the ‘export’ tab and press the ‘Publish this book’ button. The PDF will be quickly generated – beware the ‘progress bar’ is rather fake… the PDF might be ready more quickly or slowly than the progress bar suggests.
Next, click on ‘Show Advanced Options’ scroll down and choose ‘Custom’ from the ‘CSS mode’ drop down menu. Now a text field will appear with the default CSS – the same CSS that was used for the design of the book you just created.
Now either change the CSS in the text box OR visit this site for help.
At the bottom of this page, you will find a link to the CSS used for the print version of the second edition of this book – it’s the same book you are currently working on. You can see that the CSS states:
/* Main CSS File: */
@import url("http://collaborative-futures.org/material/styles.css");
/* Uncomment based on the book size you export: */
/* A5 */
/* @import url("http://collaborative-futures.org/material/size/a5-hacks.css"); */
/* 5.5"x8.5" */
/* @import url("http://collaborative-futures.org/material/size/5.5x8.5-hacks.css");*/
This is CSS syntax that imports the ‘real’ CSS used which can be found here: http://collaborative-futures.org/material/styles.css
Copy this CSS, change it, and enter it into the CSS text field of Booki, then try exporting the book again. Experiment with changing the CSS and see what happens.