The construction of a book (Aether9)

This brief interview with Ludivine Loiseau and Pierre Marchand from OSP was made in December 2012 by editor and designer Manuel Schmalstieg. It unravels the design process of Aether9, a book based on the archives of a collaborative adventure exploring the danger zones of networked audio-visual live performance. The text was published in that same publication.

OSP is a working group producing graphic design objects using only Libre and/or Open Source software. Founded in 2006 in the frame of the arts organisation Constant ¹, the OSP caravan consists today of a dozen individuals of different backgrounds and practices.

As a team, it’s our first 'real' book. We previously worked together on a somewhat similar project of archive exploration, but without printed material in the end. ²

The process: we developed scripts to 'scrap' the project archives, but it’s output was more abstract; we collected the fonts used in all the files and produced a graph from this process. These archives weren’t structured, so the exploration was less linear.

You rapidly chose TeX/ConTeXt as a software environment to produce this book. Was it an obvious choice given the nature of the project, or did you hesitate between different approaches?

The construction of the book focused on two axes/threads: chronology and a series of 'trace-route' keywords. Within this approach of reading and navigation using cross-references, ConTeXt appeared as an appropriate tool.

The world of TeX ³ is very intriguing, in particular for graphic designers. It seems to me that it is always a struggle to push back the limits of what is 'intended' by the software.

ConTeXt is a constant fight! I wouldn’t say the same about other TeX system instances. With ConTeXt, we found ourselves facing a very personal project, because composition decisions are hardcoded to the liking of the package main maintainer. And when we clash with these decisions, we are in the strange position of using a tool while not agreeing with its builder.

As a concrete example, we could mention the automatic line spacing adjustments. It was a struggle to get it right on the lines that include keywords typeset with our custom 'traced' fonts. ConTeXt tried to do better, and was increasing the line height of those words, as if it wanted to avoid collisions.

Were you ever worried that what you wanted to obtain was not doable? Did you reject some choices – in the graphic design, the layout, the structure – because of software limitations?

Yes. Opting for a two column layout appeared to be quite tough when filling in the content, as it introduced many gaps. At some point we decided to narrow the format on a single column. To obtain the two columns layout in the final output, the whole book was recomposed during the pdf-construction, through OSPImpose.

This allowed us to make micro adjustments in the end of the production process, while introducing new games, such as shifting the images on double pages.

It’s a re-writing of a pdf imposition software that I wrote a couple years ago for PoDoFo.

Again regarding ConTeXt: this system was used for other OSP works – notably for the book Verbindingen/Jonctions 10; Tracks in electr(on)ic fields. ⁴ Is it currently the main production tool at OSP?

But it hasn’t become a standard in our workflow yet. In fact, each new important book layout project raises each time the question of the tool. Scribus and LibreOffice (spreadsheet) are also part of our book making toolbox.

During our work session with you at Constant Variable, we noticed that it was difficult to install a sufficiently complete TeX/ConTeXt/Python environment to be able to generate the book. Is Pierre’s machine still the only one, or did you manage to set it up on other computers?

Now we all have similar setups, so it’s a generalized generation. But it’s true that this represented a difficulty at some times.

The source code and the Python scripts created for the book are publicly accessible on the OSP Git server. Would these sources be realistically re-usable? Could other publication projects use parts of the code ? Or, without any explicit documentation, would it be highly improbable?

Indeed, the documentation part is still on the to-do list. Yet a large part of the code is quite directly reusable. The code allows to parse different types of files. E-mails and chat-logs are often found in project archives. Here the Python scripts allows to order them according to date information, and will automatically assign a style to the different content fields.

The code itself is a documentation source, as much on concrete aspects, such as e-mail parsing, than on a possible architecture, on certain coding motives, etc. And most importantly, is consists in a form of common experience.

Do you think you will reuse some of the general functions/features of archive parsing for other projects ?

Hard to say. We haven’t anything in perspective that is close to the Aether9 project. But for sure, if the need of such treatment comes up again, we’ll retrieve these software components.

Have there been 'revelations', discoveries of unsuspected Python/ConText features during this development?

I can’t recall having this kind of pleasure. The revelation, at least from my point of view, happened in the very rich articulation of a graphical intention enacted in programming objects. It remains a kind of uncharted territory, exploring it is always an exciting adventure.

Three fonts are used in the book: Karla, Crimson and Consola Mono. Three pretty recent fonts, born in the webfonts contexts I believe. What considerations brought you to this choice?

Our typographical choices and researches lead us towards fonts with different style variations. As the textual content is quite rich and spreads on several layers, it was essential to have variation possibilities. Also, each project brings the opportunity to test new fonts and we opted for recently published fonts, indeed published, amongst others, on the Google font directory. Yet Karla and Crimson aren’t fonts specifically designed for a web usage. Karla is one of the rare libre grotesque fonts, and it’s other specificity it that it includes Tamil glyphs.

Apart from the original glyphs specially created for this book, you drew the Ç glyph that was missing to Karla … Is it going to be included to its official distribution?

Oh, that’s a proposal for Jonathan Pinhorn. We haven’t contacted him yet. For the moment, this cedilla has been snatched from the traced variant collections.

Were there any surprises when printing? I am thinking in particular of your choice of a colored ink instead of the usual black, or to the low res quality (72dpi) of most of the images.

At the end of the process, the spontaneous decision to switch to blue ink was a guaranteed source of surprise. We were confident that it wouldn’t destroy the book, and we surely didn’t take too many risks since we were working with low res images. But we weren’t sure how the images would react to such an offense. It was an great surprise to see that it gave the book a very special radiance.

We are currently operating as an invited collective at the Valence Academy of Fine Arts in the frame of a series of workshops named 'Up pen down'. We’re preparing a performance for the Balsamine theatre ⁵ on the topic of Bootstrapping. In April we will travel as a group to Madrid to LGRU ⁶ and LGM ⁷. We also continually work on 'Co-position”', a project for building a post-gutenberg typographical tool.