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.

Can you briefly situate the collective work of Open Source
Publishing (OSP)?

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 1,
the OSP caravan consists today of a dozen individuals of different
backgrounds and practices.

Since how long are you working as a duo, and as a team in
OSP?

3 to 4 years.

And how many books have you conceived?

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. 2

Similar in the type of content or in the process?

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 3 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.

What is OSPImpose?

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. 4 Is it
currently the main production tool at OSP?

It’s more like an in-depth initiation journey!

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.

Maybe for a publication/compilation of OSP’s
adventures.

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.

What are your next projects?

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 5 on the topic of
Bootstrapping. In April we will travel as a group to Madrid to LGRU
6 and LGM 7. We also continually work on
'Co-position”', a project for building a post-gutenberg
typographical tool.

http://www.constantvzw.org

http://www.ooooo.be/interpunctie/

a software written in 1978 by Donald Knuth

distinguished by the Fernand Baudin Prize 2009

http://www.balsamine.be/

http://lgru.net/

the international Libre Graphics Meeting:
http://libregraphicsmeeting.org/2013/